After thinking about your method..
tofro wrote:What you need is a piece of software that restores the system to the exact state that it was in when you dumped the memory contents - Including system variables and all S*Basic internal variable areas - so at least the lower memory in the lower 128kBytes must be restored as it was before (most games are 128k anyways, so a partial memory dump would suffice- This all depends a bit on where the system allocated the disk buffers by the time of dumping - You don't want these to interfere with the memory areas you are restoring from the dump as otherwise you'd be screwing yourselves up during the restore. Something like the below might work:
- Boot into (e.g.) 640k. Work with the disk so the driver allocates its memory in the upper 512k
- Load your IRQ7 service routine into the upper 512k and set vectors accordingly
- Cheat the system into 128k (or 256, 384,...) mode (a kind of "simulated reset" with not a full initialisation, but rather a partial one, carefully keeping the modifications intact you did above. This would involve a lot of patching in the system areas. I'm not saying it's easy, but doable. If you have exact control on what's in memory at this moment (No extra stuff loaded), it should be possible.
- Load your game into lower memory (The QL should believe it's a non-fully-expanded QL)
- Play your game
Now instead of just dumping the memory to a file. Copy the 128K block to a higher address in memory (above the 128K area) , along with the state of the 68008 registers, and the screen mode when <CTRL><ALT>7 was pressed. Reset the system again in a 128K mode. Then save the still existing 128K dump in memory.
When you restore. Start the QL in 128k, load the dump into memory above 128K. Then copy the dump back into the 128K area, and restart the program.
This should help to prevent you running the risk of overwriting the Physical Definition Block of the device you are using for saving/loading.
Or is this what you were getting at, and I did not follow..
Martin