QL Snapshots

Anything QL Software or Programming Related.
RWAP
RWAP Master
Posts: 2834
Joined: Sun Nov 28, 2010 4:51 pm
Location: Stone, United Kingdom
Contact:

QL Snapshots

Post by RWAP »

The one thing which is missing from all QL interfaces, and yet exists on many Spectrum ones, is the ability to press a button and create a snapshot of a game and save it to a memory card.

That is something which could be useful for some of the copy protected programs which have not been cracked (some of which rely on loading a bit of the code from a specific sector(s) on a cartridge - and that code overwrites part of the original program.

As well as there still being quite a lot of missing in action QL software titles, the biggest danger looking forward for old software is the continued lack of permission for it to be made available again. Although that is more from a historic point of view than anything else, as I doubt there is very much of the old software which will be actually used.


User avatar
tofro
Font of All Knowledge
Posts: 2685
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: Issue 8 and WiFi

Post by tofro »

That button is called

Code: Select all

<CTRL><ALT>7
on the QL - You could write some routine that dumps occupied memory to disk when you press it. (Results in a level 7 interrupt) - Just needs a "tiny bit of software"

You'd need to reset the QL after you're done, because you might have shut down comms to the keyboard processor, but that would have some chance to get it working

Tobias


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
Martin_Head
Aurora
Posts: 847
Joined: Tue Dec 17, 2013 1:17 pm

Re: Issue 8 and WiFi

Post by Martin_Head »

tofro wrote:That button is called

Code: Select all

<CTRL><ALT>7
on the QL - You could write some routine that dumps occupied memory to disk when you press it. (Results in a level 7 interrupt) - Just needs a "tiny bit of software"

You'd need to reset the QL after you're done, because you might have shut down comms to the keyboard processor, but that would have some chance to get it working

Tobias
You might manage to make the dump. But I suspect you would have great problems trying to get it back in, and working again. (Without the aid of some special external hardware)

Martin


User avatar
tofro
Font of All Knowledge
Posts: 2685
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: Issue 8 and WiFi

Post by tofro »

Martin,

I guess special hardware wouldn't help. The QL already has most of the hardware that was added to the Spectrum by the likes of Multifaces - A button to trigger an NMI and some memory that holds the service routines - Only that in the Multifaces it was an EPROM.

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
  • Press <CTRL><ALT>7 to dump using the full 640k of your QL, all memory in the lower memory area, and the registers of all currently running jobs
  • A restore routine would do pretty much the same, simulating a 128k (or 256k, whatever) QL within a fully expanded system, then kick the job into activity that was running during the time of the dump (If you do a full dump including all system variables, that should practically happen automagically)


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
Martin_Head
Aurora
Posts: 847
Joined: Tue Dec 17, 2013 1:17 pm

Re: Issue 8 and WiFi

Post by Martin_Head »

And what if you are trying to restore the dump into another QL with a different ROM version. That was in the middle of a ROM routine when you pressed the 'button'?

And what if the 'button' had been pressed while the slave blocks were in the middle of writing to a file?


User avatar
tofro
Font of All Knowledge
Posts: 2685
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: Issue 8 and WiFi

Post by tofro »

That's all the same issues the Multiface had to "face" - You couldn't restore 16k dumps on a 48k machine and vice versa, and you couldn't restore Opus Discovery dumps on, for example, a Betadisk system. Later Multifaces even artificially restricted re-loading of dumps to computers that had a Multiface connected.
Martin_Head wrote:And what if you are trying to restore the dump into another QL with a different ROM version. That was in the middle of a ROM routine when you pressed the 'button'?
That scenario is never going to work - Cannot be fixed with hardware and cannot be fixed by software. You would only be able to restore a dump on the exact same configuration it was created - Everything else working would be pure luck.
Martin_Head wrote:And what if the 'button' had been pressed while the slave blocks were in the middle of writing to a file?
That is why I'm saying that the game must be loaded into a restricted environment that simulates a lower-memory QL in a 640k QL - The simulated re-boot of the QL before loading a game would make sure all slave blocks would be contained in the dump. Other than that, the old saying "you can make a system foolproof, but not damn-foolproof" applies.

I still believe you could make that work purely in software (with some restrictions like not changing ROM version and hardware configuration between dump and restore) and still believe that adding hardware (except maybe an EPROM containing the dump and restore code in a "safe area") wouldn't make the task any easier.

The DIY toolkit series contains somewhat similar routines in its Multibasic implementation - This code dumps all of a currently running SuperBASIC job into confined reserved memory areas, allows you to run another SuperBASIC program, and then to restore the original SuperBASIC environment, completely replacing the interim one. So it does something similar, but limits the dump and restore to SuperBASIC job areas, allowing to switch back and forth between various SuperBASIC jobs in memory.

Tobias


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
User avatar
dilwyn
Mr QL
Posts: 2753
Joined: Wed Dec 01, 2010 10:39 pm

Re: Issue 8 and WiFi

Post by dilwyn »

A very interesting discussion - thank you guys. I hope this comes to some sort of fruition!


RWAP
RWAP Master
Posts: 2834
Joined: Sun Nov 28, 2010 4:51 pm
Location: Stone, United Kingdom
Contact:

Re: Issue 8 and WiFi

Post by RWAP »

This is indeed leading into an interesting discussion - perhaps vanpeebles could split this into a new topic :D

Given that the problematic software is generally going to be designed to be run on a basic 128K QL, then it should be possible to do this.

In order to overcome some of the issues, I wonder if the routine could monitor the program counter and store it (but only whilst it is in the RAM area) - then if the dump routine was called in the midst of a ROM call, the memory would be saved, with the program counter set to where it was at the point of making the ROM call. Otherwise surely the QL ROM must store the address of the calling instruction for TRAP #x or JSR (Vector) in order to know where to return to (albeit probably the address of the next instruction)...

As others have said, the Multiface must have found a way around this issue...


User avatar
janbredenbeek
Super Gold Card
Posts: 629
Joined: Wed Jan 21, 2015 4:54 pm
Location: Hilversum, The Netherlands

Re: Issue 8 and WiFi

Post by janbredenbeek »

RWAP wrote:This is indeed leading into an interesting discussion - perhaps vanpeebles could split this into a new topic :D

Given that the problematic software is generally going to be designed to be run on a basic 128K QL, then it should be possible to do this.

In order to overcome some of the issues, I wonder if the routine could monitor the program counter and store it (but only whilst it is in the RAM area) - then if the dump routine was called in the midst of a ROM call, the memory would be saved, with the program counter set to where it was at the point of making the ROM call. Otherwise surely the QL ROM must store the address of the calling instruction for TRAP #x or JSR (Vector) in order to know where to return to (albeit probably the address of the next instruction)...
This would be possible if you put the 68008 in Trace mode, then it generates a Trace exception after each instruction so you can inspect the program counter and flag register's contents.

My MULTIMON monitor/disassembler even has a provision for the CTRL-ALT-7 sequence. I've duplicated the ROM code which resets the 8049 in my exception handler and on a bare QL I'm able to successfully enter the monitor when pressing CTRL-ALT-7. I can even do it several times, however since the SSP isn't cleaned up the QL eventually crashes due to a stack overflow :) .

It only works on a bare QL though; on a GoldCard it has no effect since the IPLx lines from the edge connector are probably not wired to the 68000 on the GC.

Jan.


User avatar
vanpeebles
Commissario Pebbli
Posts: 2815
Joined: Sat Nov 20, 2010 7:13 pm
Location: North East UK

Re: QL Snapshots

Post by vanpeebles »

Done :D I nearly made a right bog of that :oops:


Post Reply