Porting MSX games to SVI-3x8 & vice-versa

I think I know exactly what you are looking at

You got it almost correct... As you know the MSX and SVI ROM routines are quite different and not all of what SVI has can be found from MSX and other way around. Also although both machines have same chips they are connected to each other in very different way... ie. Joystick buttons are on MSX connected to PSG, but on SVI they are connected to PPI, I/O ports are different and also memory handling is build from completely different perspective... So what is going on?

The big ML program in front of the splitted ROM-file is old version of "MSX ROM-loader for SVI"... I expect it to be old version since latest versions usually use Pletter packing in order to reduce loading time although RAW data is supported as well... So what this program is made out of?

It includes very custom version of C-BIOS that is MSX-BIOS compatible replacement. This version is just adapted to run on SVI hardware and it is used to replace the SVI standard BIOS. This makes it possible to use MSX BIOS entry points just like if the computer would be MSX. How ever this is not all of the story... as I said the I/O port access is also different. For this purpose the binary blob at the beginning also contains an AI that I've given a pretty complex name "Self aware, self modifying artificial intelligence". It's job is to separate music, graphics etc. data from Z80-code and then patch the routines to work with the underlying hardware. In other words it is doing the porting effort that is usually left for humans to figure out. This patching of the game is partly done before starting the game and partly during the runtime when it can evaluate better what the program is actually doing and if it is doing it correctly... So indeed the game it self is stored as an MSX game without modifications (other than maybe copy protection removal, that this program does not do automatically)

SVI ROM-files are placed to address area #0000-#7FFF and they are started (jump to address 0 is made) if the ROM begins with commands DI & LD SP,xxxx

Yes, that should work as well... The original program that does all this for you without manual labor is unfortunately made as an Windows BAT-script, but it should not be hard to adapt to it run on some Linux based systems as well. There are also separate start addresses for 8KB and 16KB ROMs, but they are documented in the readme.txt file delivered with the program. Latest version can be found from Spectravideo facebook group files section. There exists also another version of the program that allows playing MSX games on Memotech MTX computer. This computer is also quite similar to MSX although it has different sound chip, CTC handling interrupts etc. small differences.

Thank you NYYRIKKI for your reply and help. I'll visit the links you provided to understand more so I might be able to fill in the gap of my MSX <-> SVI table.
Got 1 thing to ask you... about the AI program...
1- how can it know what bytes are z80 code and what bytes are music or graphics or data?
2- the AI part partialy done during runtime and the process of evaluating better what the program is actually doing and if it is doing it correctly, why all that work doesn't effect gameplay speed?! Is it because gameplay speed is controlled and synced with video referesh rate i.e 50Hz(PAL)/60Hz(NTSC)?!

Well... It is kind of NYYRIKKI emulator by this I mean that it tries to emulate my thinking processes by using fuzzy logic... When I look at the data I can pretty soon tell if it looks like proper Z80 program or something else by looking at the tiny clues... If I ie. see something like LD DE,10 & LD B,10 & LD D,A I immediately start to think like "hmm.. this looks a bit weird. Why D is loaded again while it not has been used to anything in between?". I also know that if I take ie. 30 bytes back from random place and step forward to it using Z80 command lengths, I can say that if I hit the starting byte exactly it is more likely that I've ended up to Z80 command byte than Z80 command parameter byte. (because Z80 command lengths vary) These kind of "partial thoughts" are very weak statements by them self but when you combine enough amount of such a small "partial thoughts" / "clues" together you will very soon start to gain much more strong thoughts. In this case I have also used some effort to teach details about "how MSX programs work" that gives us much better ideas about what programs are likely to do compared to considering just validity of pure Z80 code. We can for example say that "it is not likely that program tries to write over BIOS ROM. This is unlikely event." I hope you get the point.

Well, the sync definitely helps. Most of the MSX games are made to work on 60Hz, so on 50Hz SVI you get 20% spare time to figure things out. It is anyway important to understand that this program does not try to emulate MSX, but to fix the program on RAM to work on SVI. This means that when the code is executed for first time it might be quite a slow, but on next round it will be already fixed a lot more and if all went like on movies on third time it will be already fully valid SVI-code that is not really any slower than original MSX code.

Naturally there are a lot of things that can't be really patched to work on full speed... reading from ie MSX PPI port B is one of the worst "nightmare cases" as it returns 8 keys from MSX keyboard. Usually there is no other way than to emulate this and this means that it needs to read 8 different keys one by one from SVI keyboard and then construct MSX compatible result. This takes a LOT of time, but luckily keyboard is usually not read more often than once in an interrupt. I use some cached results also to avoid running in to total jam. All after all I would say that the reason why the overall result works quite nicely is that I've put the speed optimization effort to places where it counts most. (and naturally all of the program is written in assembly)

As you may understand this kind of approaches can't ever be perfect and work in all situations, but I'm actually pretty amazed even my self of how many games it can patch by it self while it just relies to it's own "common sense" and makes constantly evaluations that are not absolute like "is it this or that" but more like "would it be likely something like this or could it perhaps be something more like that"

I want to port Spectron and Armoured Assault if I could beside some other SVI-3x8 BASIC to MSX. Kinda a teenage dream which still I want to accomplish.

NYYRIKKI]I think I know exactly what you are looking at

[quote

wrote:

... There exists also another version of the program that allows playing MSX games on Memotech MTX computer. This computer is also quite similar to MSX although it has different sound chip, CTC handling interrupts etc. small differences.

Is the MSX -> Memotech MTX conversion tool still available somewhere?
ColecoVision -> Memotech MTX would also be interesting as they have the same sound chip.