Converting MSX ROM to BIN

Page 2/2
1 |


Enlighted (6011)

NYYRIKKI's picture

08-03-2020, 12:22

It's easy for 8kB and 16kB ROMs only. Rom location can be easily determined thanks to the header.[/quote}
I do not recommend trying to determine the location... In case of 8kB/16kB just make it "mirrored ROM" == copy the code to all possible locations... You can't go wrong then. Smile

For 32kB ROMs is a little less easy because some Roms are copyright protected and the location can change. In addition, these Roms can have two headers and slot change routine is not always easy to find automatically.

Indeed the copy protections may be painful and there is relatively little you can do automatically to remove them. I would say the biggest problem is that sometimes the ROM's have been dumped by just saving the memory area #4000-#BFFF but this causes a problem since in real life there is a ROM chip that has address space #0000-#7FFF and the /CS12 signal is just connected to /OE ... This means that the address space #4000-#7FFF is displayed as is and #0000-#3FFF is displayed when area #8000-#BFFF is selected... so when the ROM dump is made with MSX the upper and lower half of the memory is swapped.


BLOAD-able format Roms do not work on the majority of MSXs in general, and cassette tape compatible versions must be split into parts which makes loading and saving laborious.

I think this is quite a biased opinion... The ROM-format you prefer is relatively ok when used with external ROM-emulating devices, but "MSXs in general" that have just their internal RAM are always gonna have troubles with these files, because these files don't include any kind of information about how they should be mapped to memory space and usually also required cracks to load them in to RAM are missing. (Because the are originally targeted for emulation and preservation, not for playing on real hardware.) This means the loader always needs to make a guess (or have other method such as database) to load the games from ROM-files correctly. I think we have to thank blind followers of Marat Fayzullin for making these ROM and CAS files as today's defacto standard. I guess they were good enough for their original use case, but at least on real hardware they are both if not "pretty miserable" then at least long way from optimal.

The fact that there are lots of bad cracks in BLOAD-able format floating around does not make the format bad... This is actually much better and more compatible format to play games as it can include unlimited number of patches, fixes, cheats and loading routines for all kinds of game specific needs. The files can also match the game size and don't need to be forced to match some specific chip size. The files can be even self decompressing and needed load tools don't require separate downloading as they are already included in BASIC ROM... -> I think this format is much better for playing games.

By spacemoai1973

Ambassador (0)

spacemoai1973's picture

08-03-2020, 17:18


There is also quite a well known "MAP2.COM" that fixes this "compatibility problem" on machines that allow mapper readback. I have it on my AUTOEXEC.BAT as this practically makes it possible to run cracked megaroms and other mapper using games from HDD, but as a warning: It is also known to break GEM (GameBoy emulator for MSX) if your mapper does not return all the bits on read.

But that breaks all DOS2 programs that read back the mapper segments, not just GEM?

By alexito

Paladin (760)

alexito's picture

08-03-2020, 23:35

Great tutorial Cax, very pleased to read also thanks to Nyyrikki and Gdx for the complementary advices.

By saccopharynx

Master (175)

saccopharynx's picture

09-03-2020, 00:49

spacemoai1973, I do not think that it breaks all programs that read back. MAP2.COM overwrites the mapper support routines with "IN", which is an assembly instruction to read back from the mapper ports. However, on MSX2+ (e.g. Panasonic MSX2+), MAP2.COM can break DOS2, for example, if the OS uses an external mapper.


Enlighted (6011)

NYYRIKKI's picture

10-03-2020, 10:51

spacemoai1973 wrote:

But that breaks all DOS2 programs that read back the mapper segments, not just GEM?

The other DOS2 programs that I've encountered usually just read the value to use it afterwards to select same page again... How ever IIRC GEM reads the value and compares it to a value previously written and in this case the compare fails when upper bits are wrong.

By donluca

Expert (75)

donluca's picture

05-05-2020, 17:18

Sorry for the necrobump, just wanted to thanks cax for taking the time to write this fantastic thread.

It's incredibly informative and it helped me understand a lot better how loading stuff into memory works, the issues and limitations.

By iamweasel2

Paladin (708)

iamweasel2's picture

12-12-2020, 15:11

I also want to thank Cax and everyone that shared his knowledge about this subject.

I started my studies at the memory layout in MSX, and this thread will help me a lot, so thanks everybody. Smile

Page 2/2
1 |