|[hatari-devel] Problem with Dfree() on emulated drive using EmuTOS|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
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.