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

Page 1/2
| 2

By eimaster

Master (251)

eimaster's picture

03-04-2018, 11:14

Hi
In the good old days I had both MSX and SVI-328 and I love them both especially that they are so close to each other beside having the same hardware components.
As you know that some MSX games have been successfully ported to SVI-3x8. Recently, I got the urge of porting SVI-3x8 games or at least some of them to MSX like SPECTRON and Armored Assault and others. As I wanted to start my own project I faced some big obstacles. I don't have a table of MSX I/O ports and their equivelent in SVI-3x8 such as video and audio and others! So I tried to do an utopsy on a famous MSX games which already been ported to SVI-3x8 in order to compare the differences and try to fill my own I/O ports table.
I began with an SVI-3x8 cassette tape containing the famous Konami "The Goonies". So here are my findings:

Utopsy main hardware: My Android mobile phone
Utopsy software: Hex Editor v.2.5.8 by First Row (thanks for such a useful free tool)
File is in TOSEC: Spectravideo SVI-318 & SVI-328 - Various - [CAS] (TOSEC-v2014-05-29_CM).zip
Filename: Goonies, The (1986)(Konami)[h Lord Wezzex][CLOAD + RUN].cas
File Length: 52 Kb = 53,248 Bytes
MSX Goonies.rom Length: 32 Kb = 32,768 Bytes

After doing a few byte searching for starting bytes of the real MSX "Goonies.rom" game I found it starting at 42F8H of the SVI-328 cas file! (what the hell all of the starting 16.74 Kb (17,144 Bytes) is for anyway?!
And the final byte of the MSX goonies.rom file is at C3B2H of the SVI-328 cas file, so I
1- Opened the SVI-328 cas file in the Hex Editor
2- Deleted bytes from C3B3H to the end of the file which is here CFFFH then saved the changes and closed the file
3- cas filesize have decreased from (52 Kb = 53,248 Bytes) to (48.92 Kb = 50,099 Bytes)
4- Reopened the file and deleted bytes from the start of file to 42F7H then saved the changes and closed the file
5- cas filesize have decreased from (48.92 Kb = 50,099 Bytes) to (32.18 Kb = 32,955 Bytes)
6- Reopened the file and deleted bytes from 4000H -apparently the start of the 2nd BIN file in the SVI-328 cas file- to 40BAH then saved the changes and closed the file
7- Now cas filesize have decreased from (32.18 Kb = 32,955 Bytes) to be exactly (32 Kb = 32,768 Bytes) same as goonies.rom file
8- Rename the SVI-328 cas file extension from cas to rom
9- I tried to load the new ROM file in openMSX SVI-3x8 machine but it doesn't work (I don't know how the SVI-328 run normal ROMs but out of hitting the wall feelings and out of pure curiousity I changed the machine to an MSX and loaded the new ROM with "guess rom type" option and it amazingly worked!

I thought that the rom have lots of bytes changed because it was meant to be run in the SVI-3x8. For example:
CD046F CALL BREAKX <- MSX CTRL+STOP check
expected to be:
CD3512 CALL BREAKX <- SVI-3x8 CTRL+STOP check

and:
CD4F08 CALL CHGMOD <- MSX CHGMOD= Change VDP mode
It should be:
CDD937 CALL CHGMOD <- SVI-3x8 CHGMOD= Change VDP mode

and so on but since the ROM is running on MSX without any changes so how can it be runing on SVI-3x8 without any modification?! My only guess is that the answer might be in the 20480 bytes of machine code I deleted earlier from the SVI-3x8 cas file. Anyway it is quite huge to be just a simple BIN loader and RAM mapper for the game. It might contain a table coordinator of MSX to SVI-3x8 ports numbers & BIOS equivelent routines addresses.

So, what do you think?!
Thanks in advance for sharing your experties and/or answers and for helping me understand.

BTW, another crazy idea I wonna try. I'll devide another 32 Kb MSX ROM into 2 equal BIN files (using the Hex Editor), then I'll just add the things I deleted and then convert the resulting 52 Kb file to a wave file, then I'll try running it in SVI-3x8 machine (without the Goonies cheats of course) and I'll see if it would run.

Login or register to post comments

By NYYRIKKI

Enlighted (5889)

NYYRIKKI's picture

03-04-2018, 13:50

I think I know exactly what you are looking at Smile

eimaster wrote:

and so on but since the ROM is running on MSX without any changes so how can it be runing on SVI-3x8 without any modification?! My only guess is that the answer might be in the 20480 bytes of machine code I deleted earlier from the SVI-3x8 cas file. Anyway it is quite huge to be just a simple BIN loader and RAM mapper for the game. It might contain a table coordinator of MSX to SVI-3x8 ports numbers & BIOS equivelent routines addresses.

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)

Quote:

9- I tried to load the new ROM file in openMSX SVI-3x8 machine but it doesn't work (I don't know how the SVI-328 run normal ROMs

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

Quote:

BTW, another crazy idea I wonna try. I'll devide another 32 Kb MSX ROM into 2 equal BIN files (using the Hex Editor), then I'll just add the things I deleted and then convert the resulting 52 Kb file to a wave file, then I'll try running it in SVI-3x8 machine (without the Goonies cheats of course) and I'll see if it would run.

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.

By NYYRIKKI

Enlighted (5889)

NYYRIKKI's picture

03-04-2018, 14:02

Quote:

As I wanted to start my own project I faced some big obstacles. I don't have a table of MSX I/O ports and their equivelent in SVI-3x8 such as video and audio and others!

Here are few very good links to start with:
MSX: https://www.msx.org/wiki/Category:Programming
SVI: https://www.msx.org/wiki/Category:SVI-3x8_Programming

By eimaster

Master (251)

eimaster's picture

04-04-2018, 01:03

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)?!

By jltursan

Prophet (2561)

jltursan's picture

04-04-2018, 20:57

Is "Frantic Freddy" ported to MSX?, one of my fave 3x8 games, fondly memories from it even before my first MSX machine Smile

By NYYRIKKI

Enlighted (5889)

NYYRIKKI's picture

04-04-2018, 21:15

eimaster wrote:

1- how can it know what bytes are z80 code and what bytes are music or graphics or data?

Well... It is kind of NYYRIKKI emulator Smile 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.

Quote:

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, 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"

By gdx

Enlighted (4818)

gdx's picture

05-04-2018, 02:11

What are the interesting games to port to MSX?

By eimaster

Master (251)

eimaster's picture

06-04-2018, 14:09

gdx wrote:

What are the interesting games to port to MSX?

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.

By CrazyBoss

Master (209)

CrazyBoss's picture

27-07-2018, 21:50

I am quite sure I had Spectron for MSX.
I actually ported the ColecoVision version of Spectron to the Memotech MTX. (Choose the CV as a source to avoid to convert the sounds!)

Armoured Assault I started to port to ColecoVision but gave up, its not a so great game and still need to be two players

By sunn

Expert (69)

sunn's picture

24-06-2021, 08:21

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

[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.

By Randam

Paragon (1417)

Randam's picture

24-06-2021, 08:47

Have the Spectron and Armoured Assault games been converted in the end or has an msx version surfaced?

Page 1/2
| 2