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

[ Thread Index | Date Index | More Archives ]

Am Sun, 26 Apr 2015 17:30:22 +0300
schrieb 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)

That's of course an option, but sounds quite like a hack, too ... but
likely still one of the only feasible ways to get along without too much
68k assembly code in the cartridge space or somewhere else. I haven't
looked very closely at STeem yet, but seems like they mess around with
the emulation of RTE there instead to intercept the end of the GEMDOS
call... also sounds like it's quite a hack to me. ... well, I guess
there's no real very nice solution to this problem available :-/


Mail converted by MHonArc 2.6.19+