Re: [hatari-devel] Cartridge code Pexec7 / AUTO issue

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On sunnuntai 26 huhtikuu 2015, Thomas Huth wrote:
> Could be an option, yes, but on the other hand, that would be another
> difference to an original TOS system again (some very weird exotic
> programs might depend on the fact that none of the cartridge space is
> writable).

There are already some programs that don't work with HD emulation
just because cartridge is present.


> So let's keep that in mind in case other problems occur with
> the current code - if not, let's simply hope that we don't have to
> touch it that often again.
> 
> Another idea would be to get rid of most of the assembly code in the
> cardridge and to do something completely in C code in Hatari instead,
> just like it is done in the "stemdos" of STeem ... but I haven't quite
> understood yet how they deal with the problem of getting memory via
> pexec there.

I have no idea what STeem does, but emulation can do anything:

* Modify original Pexec arguments in stack so it's Pexec7/Pexec5
  instead of Pexec0 (after fetching program flags).

* Set breakpoint for return from Pexec before continuing
  emulation

  - E.g. like native debuggers do it, i.e. by replacing next
    instruction with a breakpoint instruction and pointing CPU core
    handler	for that instruction to Pexec return value handler
	(which would also restore the original instruction / BKPT
	instruction handler)

* After return, load the program from disk to area returned by
  Pexec7/5, relocate it and correct D0 before calling program code
  (or replacing D0 with suitable error value if things fail)

The nice point about this is that emulation can do all checks
for the program (header magic etc) *before* calling Pexec7/5.


	- Eero