Re: [hatari-devel] asm56000.ttp problem

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On 10/1/18 3:26 AM, Thorsten Otto wrote:
> On Montag, 1. Oktober 2018 00:15:34 CEST Eero Tamminen wrote:
> > Just having GEMDOS HD enabled doesn't trigger the extra Fseek()s,
> > one needs to run Tomshell from it.
>
> Did you trace all gemdos calls, including Fforce()/Fdup?

Sure.

I wasn't tracking their return values, but everything that gets done
after them, seems to be fine (FD numbers etc).


> Sounds like some interfering there. I did not investigate it yet, but
> asm56000.ttp did not work on STonX either, which has a similar approach
> to Hatari. This happened also when using gemini/mupfel.

Redirection doesn't have anything to do with this issue. If
gemini / mupfel have some other issue than as56000, please mail
about it separately.


Only things one needs for reproducing the issue are these
files from the zip:
	asm56000.ttp  decoder.asm  equates.asm

And giving these arguments to as56000.ttp:
	-A -B decoder.asm

With GEMDOS HD, it doesn't create decoder.cld file before re-opening
equates.asm file, and it does Pterm(-1) shortly after opening that.
With disk image (even floppy one), it works fine.

I've now verified that the same issue happens with TOS v1.04, TOS v4
and EmuTOS, so it's not TOS version or machine specific, and has
nothing to do with e.g. caches (GEMDOS HD code needs to flush them
on reads).


> > Why asm56000 does all these extra Fseek()s to beginning of file?
>
> Might depend on the c-library being used. Sometimes isatty() does such things,
> maybe even before main() is called, to set the stdio buffering modes.

Why 56000 would do those extra Fseek()s *only* with GEMDOS HD?


The only differences in GEMDOS (and XBIOS) calls I had noticed
were:

* GEMDOS HD returning higher FD indexes from Fopen(), to avoid
  conflicting with TOS internal FD values.

* The extra Cart ASM GEMDOS traps [2] for Pexec() implementation,
  which don't show up with HD images as TOS imiplementation of Pexec()
  calls that extra stuff without going through the trap interface.


But now I noticed another one...

Floppy image:
----------------------------------
GEMDOS 0x3F Fread(6, 1024, 0x5229a) at PC 0x488A4
GEMDOS 0x19 Dgetdrv() at PC 0x4A18C
GEMDOS 0x47 Dgetpath(0x51d50, 0) at PC 0x4A1AC
GEMDOS 0x43 Fattrib("A:\DECODER.CLD", 0, 0x0) at PC 0x48356
GEMDOS 0x3C Fcreate("A:\DECODER.CLD", 0x0) at PC 0x483B6
GEMDOS 0x42 Fseek(0, 7, 1) at PC 0x48100
GEMDOS 0x42 Fseek(1, 7, 0) at PC 0x48116
GEMDOS 0x42 Fseek(0, 7, 0) at PC 0x48142
GEMDOS 0x19 Dgetdrv() at PC 0x4A18C
GEMDOS 0x47 Dgetpath(0x51d74, 0) at PC 0x4A1AC
GEMDOS 0x3D Fopen("A:\DECODER.ASM", read-only) at PC=0x4833A
----------------------------------

GEMDOS HD:
----------------------------------
GEMDOS 0x3F Fread(64, 1024, 0x5229a) at PC 0x488A4
GEMDOS 0x19 Dgetdrv() at PC 0x4A18C
GEMDOS 0x47 Dgetpath(0x51d74, 0) at PC 0x4A1AC
GEMDOS 0x3D Fopen("C:", read-only) at PC=0x4833A
GEMDOS 0x42 Fseek(0, 65, 1) at PC 0x48100
GEMDOS 0x42 Fseek(1, 65, 0) at PC 0x48116
GEMDOS 0x42 Fseek(0, 65, 0) at PC 0x48142
GEMDOS 0x0B Cconis() at PC 0x47CDC
----------------------------------

56000.ttp opens "C:" (or "C:\") with GEMDOS HD, but with
floppy image, it creates "A:\DECODER.CLD" instead, as it
should.


	- Eero

[2]
GEMDOS 0x4B Pexec(0, "C:\ASM56000.TTP", [0]"", 0x0) at PC 0xFDD2DA
GEMDOS 0x2F Fgetdta() at PC 0xFA009E
GEMDOS 0x4E Fsfirst("C:\ASM56000.TTP", 0x17) at PC 0xFA00C8
GEMDOS 0x4F Fsnext() at PC 0xFA00C8
GEMDOS 0x3D Fopen("C:\ASM56000.TTP", read-only) at PC=0xFA00FC
GEMDOS 0x3F Fread(64, 2, 0x7b20) at PC 0xFA0118
GEMDOS 0x42 Fseek(22, 64, 0) at PC 0xFA0148
GEMDOS 0x3F Fread(64, 4, 0x7b1e) at PC 0xFA0168
GEMDOS 0x4B Pexec(7, 0x0, 0xa542, 0x0) at PC 0xFA018C
GEMDOS 0x4B Pexec(5, 0x0, 0xa542, 0x0) at PC 0xFA01A8
GEMDOS 0x42 Fseek(0, 64, 0) at PC 0xFA01C0
GEMDOS 0x3F Fread(64, 28, 0xf196) at PC 0xFA01DE
GEMDOS 0x3F Fread(64, 2147483647, 0xf196) at PC 0xFA024A
GEMDOS 0x3E Fclose(64) at PC 0xFA0256
GEMDOS 0x30 Sversion() at PC 0xFA006E