Dune II / OpenDUNE for Falcon (and TT)

All about games on the Falcon, TT & clones

Moderators: Mug UK, moondog/.tSCc., lp, [ProToS], Moderator Team

User avatar
nanard
Captain Atari
Captain Atari
Posts: 177
Joined: Mon Apr 04, 2016 2:11 pm

Re: Dune II / OpenDUNE for Falcon (and TT)

Post by nanard »

shoggoth wrote: Sat Feb 19, 2022 8:16 pm The video init/exit code of this project needs some tweaking in order to not cause havoc on a multitasking machine.

The code causes the logical screen to be re-allocated on the Falcon, which will inevitably lead to disaster. Srealloc() can't be used this way, you have to use Mxalloc() to allocate the screen. Stick to Vsetmode(mode) and Vsetscreen(-1,phys-1,-1) to be on the safe side.

EDIT: And don't save the logical screen, just don't touch the logical screen at all. This is the screen of the VDI, it's not for application use anyway. Set up a private physical screen, do your stuff there, let the VDI has its logical screen intact.

I suspect this is why NVDI barfs too.
you mean change the code from https://github.com/OpenDUNE/OpenDUNE/bl ... ari.c#L216

Code: Select all

Vsetscreen(saddr, saddr, 3, newMode);
to

Code: Select all

VsetMode(newMode);
Vsetscree(-1, saddr, -1, -1); 
?
4MB STE + CosmosEx /|\ MegaST4 + MegaFile 44 /|\ Stacy 4
User avatar
sunaiac
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 119
Joined: Mon May 25, 2015 9:11 am
Location: Palaiseau, France

Re: Dune II / OpenDUNE for Falcon (and TT)

Post by sunaiac »

Hello.
I've tried the suggested changes.

Added a physical screen static global :

Code: Select all

static long  s_savedPScreen = 0;
Changed init :

Code: Select all

	
	if(s_machine_type == MCH_FALCON) {
		short newMode;
		long vSize;

		s_savedMode = VsetMode(VM_INQUIRE);	/* get current mode */
		/*  8 planes 256 colours + 40 columns + double line (if VGA) */
		newMode = (s_savedMode & (VGA | PAL)) | BPS8 | COL40 | ((s_savedMode & VGA) ? VERTFLAG : 0);
		vSize = VgetSize(newMode);
		s_center_image_offset = (vSize-(SCREEN_WIDTH*SCREEN_HEIGHT)) >> 1;
		Debug("allocate %ld + %d bytes for mode $%04x\n", vSize, 4*SCREEN_WIDTH, (int)newMode);
		s_savedPScreen = Mxalloc(vSize + 4*SCREEN_WIDTH, 0);	/* allocate 4 lines more for explosions */
		memset(s_savedPScreen, 0, vSize + 4 * SCREEN_WIDTH);
		VsetScreen(-1, s_savedPScreen, -1, -1);
		(void)VsetMode(newMode);
		VgetRGB(0, 256, s_paletteBackup);	/* backup palette */

	}
Adapted uninit :

Code: Select all

	if(s_machine_type == MCH_FALCON) {
		VsetRGB(0, 256, s_paletteBackup);
		(void)VsetMode(s_savedMode);
		VsetScreen(-1, Logbase(), -1, -1);
		Mfree(s_savedPScreen);
	} 
Changed references in video_tick :

Code: Select all

uint8 *screen = Physbase();
[...]
screenwords = (uint16 *)Physbase();
(Didn't touch in Video_SetOffset. Can't just offset as we want since we reserved a certain amount of memory. That function seems dangerous to me?)

That works in Hatari & Real HW.
But Real HW still crashes on exit if NVDI is up :( (which doesn't mean it's not better for other stuff, I'm a total Atari development noob anyways)
Other Ideas for NVDI ? Someone can reproduce the problem ?
I'll try starting from various video modes, to see ...
Last edited by sunaiac on Mon Feb 21, 2022 3:59 pm, edited 1 time in total.
Falcon 060 - Falcon 030 (x2)
Mega STE - 1040 STE - 520 STE (x2) - 1040 STF - 520 ST+ - 260 ST
Amiga 500 (x3), Amiga 2000, Amiga 1200
User avatar
sunaiac
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 119
Joined: Mon May 25, 2015 9:11 am
Location: Palaiseau, France

Re: Dune II / OpenDUNE for Falcon (and TT)

Post by sunaiac »

OK, understood the video offset thingy, it's for screen shaking during explosions/ I'll modify it too then, else first explosion will crash the game...
I still feel like this function should check its inputs, since a wrong value will send us to uninitialized memory. I'll add it.
Falcon 060 - Falcon 030 (x2)
Mega STE - 1040 STE - 520 STE (x2) - 1040 STF - 520 ST+ - 260 ST
Amiga 500 (x3), Amiga 2000, Amiga 1200
User avatar
sunaiac
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 119
Joined: Mon May 25, 2015 9:11 am
Location: Palaiseau, France

Re: Dune II / OpenDUNE for Falcon (and TT)

Post by sunaiac »

I've finally found time to correct the wrong usage of XBIOS screen functions in Dune 2, prompted by this topic : viewtopic.php?f=16&t=42238

I'm happy to say that my branch, compared to the master, has the following benefits :
- it compiles and links (master doesn't link because of bad case for VsetScreen function)
- you can leave the game and have correct colors if your desktop is not in 256 colors (Falcon only)

And being able to leave without reset is a game changer (pun intended)

I'm sad to say that it still doesn't work in mint. The master branch crashes right at the beginning. My fork can play the intro but crashes at menu screen.
That'll be for another day, but I really want to be able to play under mint.

Anyway, you can grab it there : https://github.com/sunaiac/OpenDUNE
There is a PR but I don't think it's been considered.
Falcon 060 - Falcon 030 (x2)
Mega STE - 1040 STE - 520 STE (x2) - 1040 STF - 520 ST+ - 260 ST
Amiga 500 (x3), Amiga 2000, Amiga 1200
User avatar
shoggoth
Nature
Nature
Posts: 1203
Joined: Tue Aug 01, 2006 9:21 am
Location: Halmstad, Sweden
Contact:

Re: Dune II / OpenDUNE for Falcon (and TT)

Post by shoggoth »

If it barfs on memory protection, try fiddling with the flags in the program header. You might need to set it to Super.
Ain't no space like PeP-space.
User avatar
sunaiac
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 119
Joined: Mon May 25, 2015 9:11 am
Location: Palaiseau, France

Re: Dune II / OpenDUNE for Falcon (and TT)

Post by sunaiac »

shoggoth wrote: Wed Oct 05, 2022 7:28 pm If it barfs on memory protection, try fiddling with the flags in the program header. You might need to set it to Super.
The fact it crashes at a specific point might make it a bit easier for me that just a random crash.
But it's a freeze, not a termination, wouldn't MP problem be cleanly intercepted by the OS ?
Video is fine, It plays the intro.
PCM and MIDI are fine, it plays the intro.
I may have to check mouse handler, it crashes as soon as I move it seems.
(Tests where in 060 mode, didn't try 030)

But I need a bit of background, if you guys don't mind sharing your knowledge with me.

First, I always run with memory protection.
Second, I come from a PC background.
I don't want to create something that would need deactivating memory protection, be it at OS level or at program level by giving it supervisor powers or whatever it's called. It's a game.
I mean, it's annoying. I can't run falcamp or uiptool from mint because of that kind of problems.

So, what's the problem with Protected Memory, in mint, on a Falcon 030/060 ? (How does it map to what I know from PC ?)

OpenDune is a C program.
As far as I can tell, it manipulates memory in a very standard way. It gets its buffers from malloc/calloc. It uses some static variables, and some stack variables. Only the screen buffer is Mxalloced.
On PC, crashes related to memory will be from reading/writing to addresses that have not been malloced yet/have been given back with free, and the usual read after last element etc...

So my questions :
- Do programs "see" a flat 4GB area that is private to them on Atari/mint ? Or are addresses shared between programs, i.e. "public" addresses only ?
- Or is some area of the memory "kernel" memory where operations are limited ?
- Are some system calls dangerous w.r.t memory ?
- Are the droids I'm looking for the usual "C" problems, or am I looking for Atari problems ?
- How do I know memory protection is actually the problem ? (I imagine if it works with MP off it's that ^^)
- Where's my valgrind :whistle:
- Where can I educate myself ?
Falcon 060 - Falcon 030 (x2)
Mega STE - 1040 STE - 520 STE (x2) - 1040 STF - 520 ST+ - 260 ST
Amiga 500 (x3), Amiga 2000, Amiga 1200
ThorstenOtto
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2320
Joined: Sun Aug 03, 2014 5:54 pm

Re: Dune II / OpenDUNE for Falcon (and TT)

Post by ThorstenOtto »

sunaiac wrote: Wed Oct 05, 2022 8:38 pm On PC, crashes related to memory will be from reading/writing to addresses that have not been malloced yet/have been given back with free, and the usual read after last element etc...
Yes, thats basically the same on Atari. Of course such errors are always hard to detect. Another common error is to use malloc and assume that the memory is zeroed, which is not the case.
Only the screen buffer is Mxalloced.
That is necessary on Atari, because the video hardware only can access memory <16MB, so you have to make sure the screen buffer ends up in ST-RAM.
- Do programs "see" a flat 4GB area that is private to them on Atari/mint ? Or are addresses shared between programs, i.e. "public" addresses only ?
They share a public address space. Without memory protection, every program could read/write any memory in the system.
- Or is some area of the memory "kernel" memory where operations are limited ?
That is what the MP in MiNT currently does. Unless an application explicitly allows it, it protects an apps memory from being read/written by someone else.
- Are some system calls dangerous w.r.t memory ?
Only in the sense that they typically don't do much checking. If you pass some stupid addresses to them, then your application may crash.
- Are the droids I'm looking for the usual "C" problems, or am I looking for Atari problems ?
Mostly, that sounds like usual C problems. Only place in Atari programs where you typically have to care about MP is when communicating with other programs using some protocol like AV. But i doubt that Dune uses such things.
- How do I know memory protection is actually the problem ? (I imagine if it works with MP off it's that ^^)
That does not mean that MP is the problem. Rather seems like bugs in the program, and you just don't notice them with MP turned off.
- Where's my valgrind :whistle:
Good question. Go ahead and write a port for m68k, then submit your patches ;)
mikro
Hardware Guru
Hardware Guru
Posts: 2946
Joined: Sat Sep 10, 2005 11:11 am
Location: Kosice, Slovakia
Contact:

Re: Dune II / OpenDUNE for Falcon (and TT)

Post by mikro »

ThorstenOtto wrote: Thu Oct 06, 2022 5:06 am Only place in Atari programs where you typically have to care about MP is when communicating with other programs using some protocol like AV
... and interrupt handlers. Be it for Timer A (sample playback) or VBL/HBL (screen effects). That is cured by the '-S' flag so kernel can access application's handler and execute it.
User avatar
Eero Tamminen
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2767
Joined: Sun Jul 31, 2011 1:11 pm

Re: Dune II / OpenDUNE for Falcon (and TT)

Post by Eero Tamminen »

sunaiac wrote: Wed Oct 05, 2022 8:38 pm - How do I know memory protection is actually the problem ? (I imagine if it works with MP off it's that ^^)
Yes, that is one indication. But it's possible that due to palette, you are not seeing error messages on screen.

When debugging things with Hatari emulator, use "--xconout 2" (or "--trace os_base") option to see Atari console messages also in host console.
sunaiac wrote: Wed Oct 05, 2022 8:38 pm - Where's my valgrind :whistle:
Hatari emulator provides already functionality similar to Valgrind Callgrind and Valgrind Cachegrind tools: https://hatari.tuxfamily.org/doc/debugg ... callgraphs

In regards to Valgrind Massif tool...

In Hatari, it's possible to:
* Set breakpoints on OS call entry and exits
* Load symbols for the binary and set breakpoints also to libc alloc and free functions
* Enable profiling to get backtraces on breakpoints (when symbols are present)
* output stack arguments & return values from breakpoints

After which one could write post-processing tool that matches alloc and frees to catch double frees, and provides callgraphs to where most of the remaining allocations go at given point. There has not been really requests for such memory usage analysis tooling though.

Hatari does not have support for tracking memory accesses, so Valgrind Memcheck tool is not possible. But when same code works also on PC, you can cover most of memory access checking there.

Btw. Nowadays I actually prefer GCC/LLVM ASAN feature over Valgrind Memcheck, because it's much faster and catches also array under/overwrites and other dubious stuff:
https://github.com/google/sanitizers/wi ... sSanitizer

(Who will make GCC or LLVM ASAN functionality work also on m68k?)

And as to Valgrind DRD and Valgrind Helgrind data-race detection tools, Atari machines have only single CPU core, so data-races are really not an issue, only deadlocks, and those one can already debug e.g. with Hatari profiler (get backtrace & profile of where time is spent).
User avatar
sunaiac
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 119
Joined: Mon May 25, 2015 9:11 am
Location: Palaiseau, France

Re: Dune II / OpenDUNE for Falcon (and TT)

Post by sunaiac »

Thanks for all the information.
I tested with MP off (yeah I caved and deactivated it temporarily :p), it does not crash.
The surface of code that runs in the intro / menu is limited, I'll see what's what there.
The only place I can see where code seems to address pointers that are out of program memory, or seem to, is the mouse Handler.

Code: Select all

void Mouse_Handler(char * ikbd_packet)
and I pretty much confirmed it crashes as soon as the mouse moves.
I'll read a bit about the ikbd thingy and come back to you :)
ThorstenOtto wrote: Thu Oct 06, 2022 5:06 am
- Where's my valgrind :whistle:
Good question. Go ahead and write a port for m68k, then submit your patches ;)
Ouch. Touché, my friend :D
Falcon 060 - Falcon 030 (x2)
Mega STE - 1040 STE - 520 STE (x2) - 1040 STF - 520 ST+ - 260 ST
Amiga 500 (x3), Amiga 2000, Amiga 1200
User avatar
sunaiac
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 119
Joined: Mon May 25, 2015 9:11 am
Location: Palaiseau, France

Re: Dune II / OpenDUNE for Falcon (and TT)

Post by sunaiac »

F*&k, it's all in assembly language :(
Falcon 060 - Falcon 030 (x2)
Mega STE - 1040 STE - 520 STE (x2) - 1040 STF - 520 ST+ - 260 ST
Amiga 500 (x3), Amiga 2000, Amiga 1200
Badwolf
Captain Atari
Captain Atari
Posts: 366
Joined: Thu Mar 16, 2017 12:09 pm

Re: Dune II / OpenDUNE for Falcon (and TT)

Post by Badwolf »

sunaiac wrote: Thu Oct 06, 2022 7:05 pm F*&k, it's all in assembly language :(
Wrap the call in Supexec()?

BW
DFB1 Open source 50MHz 030 and TT-RAM accelerator for the Falcon
DSTB1 Open source 16Mhz 68k and AltRAM accelerator for the ST
Smalliermouse ST-optimised USB mouse adapter based on SmallyMouse2
FrontBench The Frontier: Elite 2 intro as a benchmark
User avatar
sunaiac
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 119
Joined: Mon May 25, 2015 9:11 am
Location: Palaiseau, France

Re: Dune II / OpenDUNE for Falcon (and TT)

Post by sunaiac »

Badwolf wrote: Thu Oct 06, 2022 7:16 pm
sunaiac wrote: Thu Oct 06, 2022 7:05 pm F*&k, it's all in assembly language :(
Wrap the call in Supexec()?

BW
Hello :)
I wouldn't know how to do that.
The C method mouse_handler is called from the assembly code, which is run from an interrupt.
The best I can gather with my total lack of assembly language skills is that the assembly written handlers put the relevant data in some place, gives the address of that place to the C function, and the C function crashes when trying to access it.
edit : yeah it uses pea to compute the adress of variables declared in the assembly section / edit

I guess the solution would be to make the interrupt handler push data by copy instead of address/reference. Then the C method would be on its stack only. But alas, I'll have to let someone do that, someone who knows WTF they are doing when assembly coding :D

edit : note that the handlers are installed using supexec, and handler installation code is itself in assembly

Code: Select all

Supexec(install_ikbd_handler);
/edit

Extracts :
interrupt handlers : (https://github.com/sunaiac/OpenDUNE/blo ... ari_ikbd.s)

Code: Select all

ikbd_mousex:
	btst	#0,$fffffc00.w	; test bit 0 of MC6850 Status register
							; RDRF = Receive Data Register Full
	beq.s	ikbd_callold	; nothing to receive might be MIDI ?
	move.b	$fffffc02.w,ikbd_mouse_pktx
	move.l	#ikbd_mousey,$118.w		; handler for mouse 3rd byte
	bra.s	ikbd_return

	; 3nd byte mouse packet handler
ikbd_mousey:
	btst	#0,$fffffc00.w	; test bit 0 of MC6850 Status register
							; RDRF = Receive Data Register Full
	beq.s	ikbd_callold	; nothing to receive might be MIDI ?
	move.b	$fffffc02.w,ikbd_mouse_pkty
	move.l	#ikbd,$118.w		; back to regular handler
	movem.l	d0-d1/a0-a1,-(sp)
	pea		ikbd_mouse_pkt0
	jsr		_Mouse_Handler		; call higher level mouse handler
	addq.l	#4,sp
	movem.l	(sp)+,d0-d1/a0-a1
	bra.s	ikbd_return

	; joystick 2nd byte handler
	
[...]

ikbd_ierb:
	ds.b 1
ikbd_imrb:
	ds.b 1
ikbd_mouse_pkt0:
	ds.b	1
ikbd_mouse_pktx:
	ds.b	1
ikbd_mouse_pkty:
	ds.b	1

C function called by handler :

Code: Select all

void Mouse_Handler(char * ikbd_packet)
{
	[...] // do stuff reading address given (positions [0], [1] and [2])
}
Falcon 060 - Falcon 030 (x2)
Mega STE - 1040 STE - 520 STE (x2) - 1040 STF - 520 ST+ - 260 ST
Amiga 500 (x3), Amiga 2000, Amiga 1200
User avatar
sunaiac
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 119
Joined: Mon May 25, 2015 9:11 am
Location: Palaiseau, France

Re: Dune II / OpenDUNE for Falcon (and TT)

Post by sunaiac »

I'll try something. If it pushes a 32 bits address on the stack, it can copy the needed values there instead.
Just have to replace the pea ikbd_mouse_pkt0 by copying ikbd_mouse_pkt0, ikbd_mouse_pktx and ikbd_mouse_pkty there instead.
I guess.
I'll see, be right back when my cpu is in flames because of stupid instructions :D
Falcon 060 - Falcon 030 (x2)
Mega STE - 1040 STE - 520 STE (x2) - 1040 STF - 520 ST+ - 260 ST
Amiga 500 (x3), Amiga 2000, Amiga 1200
ThorstenOtto
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2320
Joined: Sun Aug 03, 2014 5:54 pm

Re: Dune II / OpenDUNE for Falcon (and TT)

Post by ThorstenOtto »

sunaiac wrote: Thu Oct 06, 2022 7:30 pm I guess the solution would be to make the interrupt handler push data by copy instead of address/reference. Then the C method would be on its stack only.
The C-routine is directly called from the interrupt handler, and both are therefor already in supervisor mode. It does not make any difference whether you access the variables from the interrupt handler or from C.

Simpliest solution would be to make the programs memory supervisor-accessible, by passing in the corresponding flags when linking, or using the prgflags utility.
User avatar
sunaiac
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 119
Joined: Mon May 25, 2015 9:11 am
Location: Palaiseau, France

Re: Dune II / OpenDUNE for Falcon (and TT)

Post by sunaiac »

Oh ok, I had it reversed. Thought it crashed because the main program was trying to access memory in the handler and not because the handler tried to access the rest of the program.

So that works, when using "m68k-atari-mint-flags.exe -S bin/opendune.tos" before copying it to the falcon.

I can now play dune 2 in mint yeah !!! In addition with my changes for video setup and with the help of the CT60, dune 2 is completely playable.
I'll try to find better performances for 030 mode. Opendune is completely architectured to run on PC/VGA with timer systems and lotsa buffer copies, might find some wins there.

Thanks again @ThorstenOtto.

I do have a few more questions tho :D, if anyone has time to answer :

- Is there a way to do the same through code, so that anyone building directly has something that works in mint without the additional step ? (I will add them to the how to build doc in my PR, but who reads doc amiright ?)
- Is this the accepted way of doing inputs, through interrupts + handler + mandatory supervisor access flags ? Or is there a better way that would leave the program fully private ?
Falcon 060 - Falcon 030 (x2)
Mega STE - 1040 STE - 520 STE (x2) - 1040 STF - 520 ST+ - 260 ST
Amiga 500 (x3), Amiga 2000, Amiga 1200
mikro
Hardware Guru
Hardware Guru
Posts: 2946
Joined: Sat Sep 10, 2005 11:11 am
Location: Kosice, Slovakia
Contact:

Re: Dune II / OpenDUNE for Falcon (and TT)

Post by mikro »

You mean like... adding "m68k-atari-mint-flags.exe -S bin/opendune.tos" into Makefile? ;)

If you are interested in pressed/released states, your own handler is unfortunately the only way (not counting using SDL, which does the same for you).
User avatar
sunaiac
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 119
Joined: Mon May 25, 2015 9:11 am
Location: Palaiseau, France

Re: Dune II / OpenDUNE for Falcon (and TT)

Post by sunaiac »

mikro wrote: Fri Oct 07, 2022 7:39 am You mean like... adding "m68k-atari-mint-flags.exe -S bin/opendune.tos" into Makefile? ;)

If you are interested in pressed/released states, your own handler is unfortunately the only way (not counting using SDL, which does the same for you).
Well, yes, but without breaking everything for good people building in Linux or Mint directly :D

OK, then I'll stop digging that subject, I guess we are were we should.

Thanks !
Falcon 060 - Falcon 030 (x2)
Mega STE - 1040 STE - 520 STE (x2) - 1040 STF - 520 ST+ - 260 ST
Amiga 500 (x3), Amiga 2000, Amiga 1200
Post Reply

Return to “Games”