New tool to read openMSX savestates into MSX2 or FPGA

Master (174)

06-09-2020, 21:37

Hi all!

This weekend I've been coding a small MSX-DOS tool that allows to read openMSX savestates and run it into a real MSX2 or FPGA. It's absolutely not finished, but it works with about 70% of the games I tried. I'm still on it!

My motivation is that it's quite frustrating that I can't load in my FPGA MSX1's games. Of course, there are LOADCAS, CASLOAD, and other tools, but a large quantity of games won't work with them, unfortunately.

I've only tested my tool in my FPGA and emulated turbo-R and msx2 in openMSX, so be prepared for failures. It's just an alpha version. But at least I'm happy now I can play Madmix game and Bounder on the FPGA!

If you want to try it: https://github.com/mcolom/MSX_lstate

Greetings,
M.

Aangemeld of registreer om reacties te plaatsen

Van Manuel

Ascended (17265)

06-09-2020, 22:31

That's a cool appraoch

Van Briqunullus

Champion (260)

07-09-2020, 09:40

Very interesting indeed! A few weeks ago I saw llopis's video about the Multiface II for Amstrad CPC. I'd wish such a device would exist for the MSX. And then especially the savestate part.

Van mcolom

Master (174)

08-09-2020, 17:02

Thanks Manuel and Briqunullus!

Briqunullus wrote:

Very interesting indeed! A few weeks ago I saw llopis's video about the Multiface II for Amstrad CPC. I'd wish such a device would exist for the MSX. And then especially the savestate part.

I've seen some of his videos on repairing the ZX-spectrum which are really great!
My thing is like a "software Multiface" and now the problems I'm finding most is that some games aren't compatible at all with MSX2 even if you manage to restore the state. They like to write on 0xFFFF and stuff like that. Buy many others seem to work! I'll keep working on that...

Van ~mk~

Champion (263)

08-09-2020, 18:13

Excellent idea, similar to ZX Spectrum snapshot format?
I couldn't find the MSX-DOS loader in the repo.

Van pgimeno

Master (252)

09-09-2020, 01:08

The idea is cool!

I imagine it's prone to problems if it is generated with openMSX using a different machine to that you're going to use as a target, because the program may have captured data about the slot layout before saving the state, meaning that the state is bound to a machine with that slot layout. This is especially true in case the program uses more than 32K and calls BIOS routines.

I've seen that write-to-FFFF problem with Robocop. I managed to patch it.

Van mcolom

Master (174)

15-09-2020, 15:30

~mk~ wrote:

Excellent idea, similar to ZX Spectrum snapshot format?
I couldn't find the MSX-DOS loader in the repo.

It's in the releases, here:
https://github.com/mcolom/MSX_lstate/releases/tag/0.2
I didn't answer until now because I was finishing a second release, which work much better than the one before.
It include the Python3 program to read the savestates and the MSX-DOS .com file.

pgimeno wrote:

The idea is cool!

Yes, if I want to make it work in no matter which MSX2 I should include code to figure out what's the memory layout.
For the moment I'm assuming a typical config. that works well (well, sometimes) with OCM and derivatives, and some emulated MSX2.

About the 0xFFFF writes, I have added code to patch LD SP, 0xFFFF into LD SP, 0xFFFE, but it's commented in the PYthon code so far. But one might end up writing there by other means, so I don't expect that I'll find a solution in the short term.

Van pgimeno

Master (252)

15-09-2020, 15:43

mcolom wrote:

About the 0xFFFF writes, I have added code to patch LD SP, 0xFFFF into LD SP, 0xFFFE, but it's commented in the PYthon code so far.

LD SP,0FFFFh should be safe; a push first decrements and then stores, so a push modifies (SP-1) and (SP-2) but not (SP). LD SP,0 is the unsafe one, but I doubt it's used. Robocop writes to FFFF via ldir, IIRC.

Van mcolom

Master (174)

15-09-2020, 16:37

pgimeno wrote:

Oops, you're right. I got fooled because when I disassembled Boogaboo I saw that it didn't work in MSX2 and I thought that it was because of writing to 0xFFFF. But a push when SP=0xFFFF it's safe, indeed. The reason why Boogaboo doesn't work is simple because the CAS version is overwritting the system variables space in MSX2. In the cardridge version I see that it was changed to LD SP, 0xF380 (which I think is still not enough).
Clearly, the MSX2 extensions were a bad thing for the poor MSX1 and programmers without access to documentation at the time

Van Manuel

Ascended (17265)

15-09-2020, 21:07

0xFFFF is not an MSX2 thing... MSX1 machines can also have expanded slots.

Van mcolom

Master (174)

15-09-2020, 22:19

Manuel wrote:

0xFFFF is not an MSX2 thing... MSX1 machines can also have expanded slots.

Sure, and not taking that into account is a flaw of the sofware. That's why I said programmers without access to documentation.
It's something that I have always wondered, why the designers of the standard decided to use a memory-mapped location for the sub-slots. Yes, it's documented and the programmer should know about it, but in practice it's like a trap: it looks like a normal memory location, and it seems a good place for the stack. You've got the primary slot register I/O port 0xA8, and the memory mappers in ports 0xFC-0xFF. Why not selecting the sub-slots with reserved I/O ports? Perhaps that would have improved compatibility with MSX1 and MSX2.
I guess there must be some good design reasons for that, I'm just wondering...