[hatari-devel] Problem with Dfree() on emulated drive using EmuTOS

["Roger Burrows" <rfburrows@xxxxxxxxx>]

Hi,
Eero Tamminen reported a problem with getting free space on a GEMDOS drive 
under EmuCON2, the builtin EmuTOS console.  Puzzlingly, this does not show up 
with normal programs, only with the builtin console.  But I did a Hatari trace 
and it does seem to be a Hatari problem.  Here's the summary:

EmuCON2 has a builtin command called SHOW which issues a Dfree() and displays 
disk info.  EmuCON2 expects a return code of zero for OK, otherwise a negative 
error code.  Hatari is returning a positive value.  The value in the low order 
word of D0 seems to be related to the disk drive number (e.g. for disk C: the 
low-order word is 3, for disk G: the number is 7).

I did a trace and after the gemdos emulation instruction at $fa002a is 
"executed", register d0 is not set to zero, although the info[] array seems to
have been updated.  But I don't know enough about Hatari to figure out where to
look further in the source.  BTW, the bug didn't occur in my testing when the 
Dfree() was done by a normal user program ...

It may be relevant that EmuCON2 calls Dfree() by placing values on the stack 
and then calling an assembler stub _jmp_gemdos(). _jmp_gemdos() pulls the 
return address off the stack & saves it, then issues a trap #1, then pushes the 
old return address back on the stack and does an RTS.

Roger Burrows