|Re: [hatari-devel] Cartridge code Pexec7 / AUTO issue|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
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
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
- 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
* 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.