Oliver Ford wrote:
Its not exactly elegant and currently requires knowing where the
specific instruction will be in virtual memory...
Having thought about it a bit more, a much neater, dynamic and more
general way to do this has occurred to me..
For the resume tracing part, haret could write
phys(resumeJumper->resumeIn) to some var like 'RESUMEPTR' (RAM+0x0800 in
this case) and then add RESUMEPTR to the mmu tracing. When windows
attemps to write to it, haret could store the address it is attempting
to write under resumeJumper->ReturnCode and leave RESUMEPTR as it set
it. Provided windows never tries to read what it thought it wrote back
(it doesn't at the moment) it should work for almost all systems that
write their resume vector to some RESUMEPTR location.
This has the added benefit that people can use it to find out the resume
code location, provided they know the RESUMEPTR location to start with.
Of course it does make life slightly more difficult for resume into boot
because it would require the mmu tracing to be used there as well.
Just an idea.
Oliver
_______________________________________________
Haret mailing list
[email protected]
https://handhelds.org/mailman/listinfo/haret
