Re: [hatari-devel] Bug: cart_asm.s Pexec() implementation overwrites basepage command line end

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On maanantai 12 marraskuu 2012, Thomas Huth wrote:
> schrieb Eero Tamminen <oak@xxxxxxxxxxxxxx>:
> > Btw. Is there some specific reason why it needs to be implemented
> > with 68k-asm in cartridge instead of with normal C-code in Hatari?
> 
> The code has to run some GEMDOS calls of the original ROM GEMDOS ...
> doing that would be quite cumbersome from normal C-code in Hatari.

I think those are mainly related to allocations needed for:
- basepage
- program itself

As they need to be visible to TOS i.e. best done by TOS routines.
The actual running of the program after loading has been done
belongs there too.

But current cartridge code does also a lot of GEMDOS file system
calls that are currently done by Hatari C-code through a really
convoluted route [1] and then there's the relocation code.

There could be some additional (illegal) opcode that is used by
the cartridge code to ask Hatari to perform those actions on its
behalf.  Such an opcode shouldn't harm rest of the emulation because
Hatari can check whether they originate from the cartridge code
(like VDI opcode handler does).

Comments?


	- Eero

[1] Currently Hatari traps GEMDOS calls by:
- overwriting GEMDOS vector by its own cartridge code address
  (magic value 0xfa002a which points to new_gemdos label in cart_asm.s)
- that address in carridge code then does illegal opcode (GEMDOS_OPCODE),
  which in opcode table is mapped to Hatari OpCode_GemDos() function
- OpCode_GemDos() calls GemDOS_OpCode() that parses the GEMDOS trap
  stack for GEMDOS call number and arguments.

In case of Pexec() on a file that resides on GEMDOS emulated HD, some
status register bits are set so that when execution gets back to emulator,
the cartrige asm knows to do Pexec().

Asm code needs to do same trap stack parsing as C-code.

Then it will do GEMDOS Fgetdta() and Fsfirst() to find
the correct program, which will again go through the above
described trap dance, for both of those calls.

After that, it goes through another trap to ask TOS with
Pexec(5) to allocate a basepage.

If everything is still OK, it will do further GEMDOS trap dances
to load the program data and then it will set the basepage
values and relocate the data.

And if those GEMDOS operations also succeeded and program
was fine, it will again call GEMDOS to actually execute
the loaded program.  Depending on GEMDOS version, the called
Pexec() version can differ a bit.