Splitting ROMs using
When preparing ROM images for use on real hardware, there are a few seemingly odd actions that need to be done in order for the binary to function in-system. When designing a system with a data bus width greater than 8-bits, its common to have multiple 8-bit ROMs cover different segments of the full bus. Consider the following schematic:
Obviously for our 16-bit bus & CPU, we’re going to need a 16-bit wide ROM for it to execute from. Here I’ve used two 8-bit ROMs; One device serves bits D0-D7 (the LOW byte) and another serves bits D8-D15 (the HIGH byte). This sort of setup is used very often when ROMs over 8-bits in width are required. If i had to guess why, I would assume its due to larger ROMs being prohibitively expensive, and a pain to burn.
The one catch with this design is that the ROM image needs to be split into two 2 separate pieces in order to be burned; The LOW ROM must contain the odd (LOW) bytes, and the HIGH ROM the even (HIGH) bytes.
The reason this needs to happen is because the bus geometry is no longer flat. The way I’m used to splitting ROM images is with
srec_cat . For now, it’s syntax isn’t important. Just know that to split the binary how we want, we can use the following commands:
srec_cat -o LOW.bin -binary ROM.bin -binary -split 2 0 srec_cat -o HIGH.bin -binary ROM.bin -binary -split 2 0
The final .bin files are now ready to be burned onto their respective EEPROMs for use in-system!
The same thing, but in reverse
Now we get to the real reason I wrote this: Combining two ROM dumps into a single, flat binary. There is absolutely 0 information on how to do this anywhere on the public internet; at least, as far as I can tell. After spending many hours of digging I was finally able to do this using just
srec_cat from before:
srec_cat -o ROM.bin -binary LOW.bin -binary \ -unsplit 2 0 HIGH.bin -binary -unsplit 2 1
If you run a binary through
srec_cat using the first set of commands, then back through with the second set, the final binary will be exactly the same as the starting binary, since these commands are exact bit-wise opposites of each other.