mikro wrote:ThorstenOtto wrote:This is happily accepted by GEMDOS. But trying to add some debug output, it does not seem to be the case for asm56000, so there must be something else that prevents it from writing to the files in such emulations.
Just recently I've asked about status of this bug in Hatari ML (see subject "asm56000.ttp problem") -- Eero seemed looking into it but then it faded away.
We were finally able to track down the problem with Thomas doing the final finding (thanks!).
asm56000.ttp is just broken.
It works only when Fopen() returns very small file handle numbers (e.g. <32 is OK), otherwise it:
* Does 3 redundant Fseek()s for each Fread()
* Opens wrong input file when it's re-opening that to output compilation results
* Doesn't Fcreate() / open the output file and craps out
Hatari GEMDOS HD emulation returns larger (>= 64) file handle numbers from Fopen() calls to avoid conflicts with the TOS file handles. I.e. this tool bug cannot really be worked around in Hatari GEMDOS HD emulation.
Note that GEMDOS HD emulation can be used for everything else, you just need to have the files that asm56000.ttp directly accesses on a disk image (so that it gets smaller file handles from real TOS).
One can automate disk image usage with Hatari too, it's just a bit more work:
* EmuTOS boots much faster and doesn't need HD driver to access disk images like real TOS which makes things faster
* If DSP files fit onto floppy image, host mtools utilities can be used to copy files across
* For larger things, atari-hd-image script can (re-)create larger disk images of directory contents
* Small Atari shell (Tomshell, Mupfel, Gulam...) and shell scripts to automate build process to copy DSP files between disk image drive and GEMDOS HD drive ("--gemdos-drive <drive-letter>" option is our friend)
EDIT: tested that using 32 as GEMDOS HD BASE_FILEHANDLE is still OK, but e.g. 40 is too large.