ROM ADD HEADER
It is not quite that easy because BIN-files usually expect to be run on RAM and expect BIOS+BASIC to be present in #0000-#7FFF. You practically need to relocate the binaries from ROM to RAM and take care of the slot layout. Practically this means that you need to add your own RAM init routine. If the BIN is expected to be loaded from disk, you may also need to initialize some disk related variables such as RAM slot in #F341-#F344 area your self before starting the actual code inside a BIN.
hnmmm. seems no easy. but there no method to run a bload"",r command for start to read the .rom file so it loaded into the RAM?
Now i'm pretty sure that there are 2 type of BIN extracted from old .cas image:
1° have correct address memory to be converted to .rom and work perfectly.
2° not have the address correct on the first 7 bytes, so the only solution are launched with a ascii code and recreate the .cas or wav, or put into a dsk and launched by bload command. But is impossibile to put into a eeprom cartridge 64kb.
Is it a pity!!
alessandro_scaccia wrote:
hnmmm. seems no easy. but there no method to run a bload"",r command for start to read the .rom file so it loaded into the RAM?
No, I'll try to explain a bit more in detail...
- ROM-files are dumps of ROM-chips that are mounted in to MSX cartridges (or on some case in to motherboard) there is no native way to load them in to RAM instead. There are anyway many tools that do exactly this. Lately most popular has been SofaROM, but there are lots of other choices as well.
- BIN-files are machine language (later ML) programs, that can be loaded in to RAM by using BLOAD-command.
Crackers during the years have copied the programs from ROM-chips and added their home made loading routines around to make them look like normal ML programs and stored them in to BIN-format. Practically this means loading the ROM-image to RAM in to same Z80 address space where ROM normally would be and then writing a program that sets the computer in correct state to execute the program. Sometimes removing copy protection (=writes over the program space) is also needed. To convert such a program back in to ROM-format that can be put in to chip is usually easy due to it's origin: Usually removing the loader that cracker added around is enough.
Now ML-programs them self can be pretty much anything... When they are stored in BLOAD format aka BIN-format they are stored as is with the exception that the 7-byte header is added to the start. BIN-files can be loaded to RAM in any address above $8000. It can be simple "Hello world"-program in few bytes or as I explained it can be also ROM-image with loader added around it, but computer does not see any difference in these variations. It only knows how to load & execute the program due to the instructions in header.
To put such a ML program that is mean to be run from RAM (read/write) in to ROM (read only) it practically means that you have to consider ROM more like a storage device where you just load stuff from and you need to practically emulate what the BASIC BLOAD-command does when it loads the program and executes it (I tried to explain the steps in first post).
What the BIN2ROM program does is exactly this, but obviously it now fails to do something that this program requires in order to run... Most probably it is not a big thing... Some variable is uninitialized, stack is in wrong address or something like that... How ever to figure out why it does not work requires investigation what the loader does, what the game does and what is the root cause the program does not load correctly. I would say that if the program loads as BIN, but not as ROM, then there is a bug in the BIN2ROM program. I've not tested that kind of program, so I don't know how it exactly does the loading, but obviously what it does is now not quite right.