ZX Spectrum Core - Save Games / States

[Lamaman1971]

Hi Folks, just getting back into my Spectrum and want to get started on something like Elite but I have to confess I am not at all sure how I save state or game - and honestly I am not sure if its just me being a bit stupid. Does anyone have any advice?

[akeley]

There's no super easy way of doing this. The two ways of making snapshots are:

-the +D method described in the wiki. It's a bit convoluted, you need to keep disk in .mgt or .img format for save states and learn some TRDOS commands.

-use DIVMMC vhd with esxdos. I think it's much more convenient overall, but it needs setting up first as described here. Also, not sure if it works for 128Kb mode.

Don't know how much you remember from handling ZX Spectrum, so if the above is still black magic feel free to ask questions.

An alternative can perhaps also be using the Spectrum Next core, though I haven't done any saving or making snapshots there myself.

[Jon]

I find the DIVMMC method to be rather slow (to take snapshots) and also unreliable. Some games work, some don't (across both 48k and 128k). Also you have to remember to launch the DIVMMC image first - before loading the game. Obviously not an issue if you load all your games via the DIVMMC - but that is not particularly convenient as I have most games in TZX format.

So for those reasons I use the +D method. Although it's fiddly to manage disks, rename saves etc.

I hadn't thought of trying the Spectrum Next core - thanks for the idea.

It would be wonderful if the core could natively take a snapshot.

[pgimeno]

Hi Folks, just getting back into my Spectrum and want to get started on something like Elite but I have to confess I am not at all sure how I save state or game - and honestly I am not sure if its just me being a bit stupid. Does anyone have any advice?

You can use a tape recorder

[akeley]

I find the DIVMMC method to be rather slow (to take snapshots) and also unreliable. Some games work, some don't (across both 48k and 128k). Also you have to remember to launch the DIVMMC image first - before loading the game. Obviously not an issue if you load all your games via the DIVMMC - but that is not particularly convenient as I have most games in TZX format.

So for those reasons I use the +D method. Although it's fiddly to manage disks, rename saves etc.

Yeah, both of these methods have pluses and minuses. I like how easy it is to navigate and generally use the div image menu once you get it mounted. I haven't tested it extensively, but the bunch of games I've tried to snap did work okay. Could you give some examples of the ones that don't?
The whole vhd could do with an update - esxdos, and especially bob_fossil's browser have had new versions released since.

Native core snapshot ability would be great but it seem unlikely to happen since no other micro core has this functionality.

[Lamaman1971]

Thanks everyone for the feedback - much appreciated as always!

[Jon]

I find the DIVMMC method to be rather slow (to take snapshots) and also unreliable. Some games work, some don't (across both 48k and 128k). Also you have to remember to launch the DIVMMC image first - before loading the game. Obviously not an issue if you load all your games via the DIVMMC - but that is not particularly convenient as I have most games in TZX format.

So for those reasons I use the +D method. Although it's fiddly to manage disks, rename saves etc.

Yeah, both of these methods have pluses and minuses. I like how easy it is to navigate and generally use the div image menu once you get it mounted. I haven't tested it extensively, but the bunch of games I've tried to snap did work okay. Could you give some examples of the ones that don't?
The whole vhd could do with an update - esxdos, and especially bob_fossil's browser have had new versions released since.

Native core snapshot ability would be great but it seem unlikely to happen since no other micro core has this functionality.

Games that didn't play nice with DivMMC:

• Jetpac
• Manic Miner
• Elite (128k)

Games that I successfully saved and restored on DivMMC:

• Treasure Island Dizzy
• Head Over Heels
• Hobbit
• Abbaye des Morts

For the games that don't work, if I just press F11, then shift-X to exit the browser immediately, the game quickly crashes. So it's not just that I can't save and restore - it seems like pressing the NMI button corrupts the game in memory (so when I save, the save is no good). I'd be interested if this happens for you too - perhaps I have a dodgy setting somewhere on the core.

I did actually create a new VHD with esxdos 0.89 and the newest version of the LFN browser - in the hope that it made it more robust - but no change. I also had the same issues on the default esxdos NMI menu - i.e. without the LFN browser.

[Jon]

After some more testing I noticed that DivMMC works very well in +3 mode (Alt-F3) - much better than with other models. In the default 128K mode it has the odd behaviour I described above. In 48K mode (Alt+F1) it is also unreliable, sometimes crashing with a "File not found" error when exiting from the NMI menu.

I wonder if this relates to boot.rom. I believe the default 128k mode is not using the standard 128k ROM - i.e. it has a TR-DOS option in the boot menu - which looks like the Pentagon 128k ROM. So presumably the DivMMC doesn't play nice with the Pentagon. I tried the other models (Alt-Fx) but none of them use the standard Spectrum 128K ROM. So it seems that my boot.rom is not correct. I'm definitely using the latest version from the Releases folder in Github. But the model mappings are not as described in the README.md. Has anyone else found this, and are there alternative versions of boot.rom? Or a way to build one?

There is also odd/unpredictable behaviour when switching models after loading the DivMMC vhd. Perhaps this is due to the DivMMC loading the Spectrum ROM into its RAM at launch, and this is then never reloaded. I have to switch to the desired model BEFORE selecting the DivMMC vhd. If I want to use a different model, I have to reboot the MiSTer core. I can live with this, but I thought it was worth mentioning in case anyone else encounters this.

[lister_of_smeg]

The DivMMC works by trapping execution at set addresses (for example, the IM1 interrupt vector at $0038 or the ROM tape loading routine at $0562) and quickly paging in it's own ROM to override/patch those routines. The rest of the time the on-board ROM of the Spectrum is used.
It also forces 128k models to page in their 48k editor ROM at boot (also known as 'USR 0' mode), so an altered 128k editor ROM shouldn't affect it's operation.

[pgimeno]

I've worked on reverse engineering the Spectrum core's boot.rom, and this is what I found. The file contains the following ROMs, concatenated:

Code: Select all

Offs. Len. File name
00000 4000 GLUK661.ROM
04000 4000 TRDOS-5.04T
08000 4000 128p-0.rom
0C000 4000 128-1.rom
10000 4000 plus3-41-0.rom
14000 4000 plus3-41-1.rom
18000 4000 plus3-41-2.rom
1C000 4000 plus3-41-3.rom
20000 2000 plusd-patched.rom
22000 2000 plusd-sys.bin
24000 2000 MF128_36_3C.ROM
26000 2000 disasm.rom
28000 2000 mf3.rom
2A000 2000 zeros.bin
2C000 4000 48.rom

GLUK661.ROM can be found in http://web.archive.org/web/202105152115 ... m/_CSR.htm (the original page appears to be gone).

MF128_36_3C.ROM can be obtained from http://web.archive.org/web/202110160517 ... om/_RR.htm

The following files can be obtained from https://github.com/Abdess/retroarch_sys ... 0Spectrum/ :

128p-0.rom
128-1.rom
48.rom (that's the regular 48K Speccy ROM available everywhere)

The following files can be obtained from https://worldofspectrum.net/item/1000496/ :

plus3-41-0.rom
plus3-41-1.rom
plus3-41-2.rom
plus3-41-3.rom

mf3.rom can be obtained from https://github.com/chernandezba/zesarux/tree/main/src

I can't find TRDOS-5.04T anywhere. It's close to TRD504t.ROM from http://web.archive.org/web/202012211201 ... om/_TR.htm but not exactly the same; some bytes are different. I wonder if it could be a version patched by the core author.

plusd-patched.rom is the Plus D ROM with two bytes that differ, don't know why - maybe also a patch by the core author.

plusd-sys.bin appears to be a preinstalled image of the +D loadable operating system. It seems to come from the MGT version which is available here in TZX format: https://spectrumcomputing.co.uk/entry.php?id=0011111

As for disasm.rom, I have no idea where it came from. From an ASCII view, it appears to be a disassembler (perhaps a debugger), hence the name I gave to the file.

zeros.bin is just a file with 8192 bytes that are all zero (NUL in ASCII).

[pgimeno]

Here's a Linux script to split boot.rom into the files mentioned:

Code: Select all

dd if=boot.rom of=GLUK661.ROM bs=8192 count=2
dd if=boot.rom of=TRDOS-5.04T bs=8192 count=2 skip=2
dd if=boot.rom of=128p-0.rom bs=8192 count=2 skip=4
dd if=boot.rom of=128-1.rom bs=8192 count=2 skip=6
dd if=boot.rom of=plus3-41-0.rom bs=8192 count=2 skip=8
dd if=boot.rom of=plus3-41-1.rom bs=8192 count=2 skip=10
dd if=boot.rom of=plus3-41-2.rom bs=8192 count=2 skip=12
dd if=boot.rom of=plus3-41-3.rom bs=8192 count=2 skip=14
dd if=boot.rom of=plusd-patched.rom bs=8192 count=1 skip=16
dd if=boot.rom of=plusd-sys.bin bs=8192 count=1 skip=17
dd if=boot.rom of=MF128_36_3C.ROM bs=8192 count=1 skip=18
dd if=boot.rom of=disasm.rom bs=8192 count=1 skip=19
dd if=boot.rom of=mf3.rom bs=8192 count=1 skip=20
dd if=/dev/zero of=zeros.bin bs=8192 count=1 skip=21
dd if=boot.rom of=48.rom bs=8192 count=2 skip=22

And here's one to put them together again:

Code: Select all

cat GLUK661.ROM TRDOS-5.04T.rom 128p-0.rom 128-1.rom\
 plus3-41-0.rom plus3-41-1.rom plus3-41-2.rom plus3-41-3.rom\
 plusd-patched.rom plusd-sys.bin MF128_36_3C.ROM disasm.rom\
 mf3.rom zeros.bin 48.rom\
 > boot.rom

You can try a different ROM by splitting, replacing the desired ROM and then rebuilding.

[Jon]

Thanks for this information, much appreciated. So that answers my question about the Alt+F2 model using the Pentagon rom - the only roms present are the 48k, Pentagon 128k and +3.

I still don't understand why the DivMMC only works reliably in +3 mode (Alt-F3). From the information above it sounds like the rom shouldn't matter. The only difference between Alt-F2 and Alt-F3 is the rom and the memory model. It's not possible to test these 2 variables independently, because selecting the +3 memory model and rebooting changes the rom.

I'm content enough to use DivMMC in just +3 mode, but I am curious why it is unreliable in other modes, and if others see the same behaviour. I might test with some different roms in boot.rom

[CartoonDonkey]

I know I'm going to get yelled at for this, but just use the ZX next core in 128 or 48k mode. Save states are super easy there and are compatible with everything.

[Jon]

Not at all! Rather shamefully, I haven't got around to trying the Next core yet. The Next has never really appealed to me, beyond the wonderful case & keyboard design. For me, the MiSTer is all about the authentic feel of the cores. I guess I will have to give the Next core a whirl and see how it feels with classic Speccy games, especially with the QoL enhancements like easy save states.

[akeley]

I know I'm going to get yelled at for this, but just use the ZX next core in 128 or 48k mode. Save states are super easy there and are compatible with everything.

This is a good alternative solution for people who don't care as much about the "feel" as some of us. NextOS is interesting, but I'd much rather use the normal cores with either the mgt or DivMMC saves.

The other angle is trying to make everything perfect (or as close to that ideal as possible) and work as it does on original hardware. That's what MiSTer is all about after all.