Splitting ROM images, and how to do it backwards

Splitting ROMs using srec_cat

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.

Here the blue bytes are what turns into the LOW ROM

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.

Atari 520ST Repair, part 1

I’ve recently gotten my hands on an Atari 520ST. A faulty one, of course. I’ve had some fun attempting to learn my way around it’s design, and have come to some minor conclusions of what it’s diagnosis is; But first, the actual problem: The CPU is being halted almost immediately after reset.

I didn’t have a thumb drive on hand, i swear i know how to screenshot.

The scope capture here shows the DTACK signal (top) in reference to the system clock (bottom). The DTACK input of the MC68000 microprocessor signals to the CPU that it is ready to commence the data transfer. DTACK oscillating with different pulse widths as seen above is exactly i would expect, and tells me that the CPU is definitely running.

It doesn’t run for very long though; In fact it’s only a ~1000 cycles total before DTACK stops oscillating. Running might not be the best term here either, as it turns out. While the CPU is definitely trying to execute something, the is absolutely 0 activity on it’s data bus. This could explain the crash, however when the MC68000 encounters an error like this, it is supposed to pull its BERR pin low so signal to the rest of the system that its given up it’s futile attempt to work. Here though, it stays constantly high.

That’s a lot of contradicting information, so what do i know works: All 6 ROMS, plus the SHIFTER (The ST’s video controller).

Not a very impressive list, I’ll admit. I’m still trying to figure my way around this board; as of now I suspect the CPU is busted. the original MC68000 dies very quickly when exposed to bus contention, I’ve found, so i wouldn’t be surprised.