Theory of rom chips and idea for a tool similar to swapbin

When a rom is burned is the data carried into the D0-D7 lines and broken up into 8 parts? I want to get a better idea of how the data is arranged and try to write a tool similar to what swapbin does. It would swap the data of a hirom game(that doesn't use sram) into a rom that could be programed onto a tsop adapter and soldered into a lorom donor to make it work properly. Lorom donors without sram are obviously more common than the hirom ones.

You can basically think of a ROM as basically a big lookup table, F(A)→D. Using swapbin, any address line can be exchanged with any address line, and any data line can exchanged with any data line.

As far as what the physical ROM does "under the hood", it's usually one or two square dice, each containing exactly 4ⁿ bits, and demultiplexer hardware on one axis and multiplexer hardware on the other. For example, an 8KiB ROM is usually arranged as 256×256 grid of bits, where A5..A12 ask for the data from one "row", and a set of multiplexers select eight "columns" to emit on the data pins. As to whether each bitplane is physically adjacent (all 1s bits together), or is instead sorted by byte, is an implementation detail that probably varies.

As an (amazing, insane) example, someone built a ROM by hand, from multiplexers and demultiplexers, and put a tiny (64 byte) Atari 2600 program into it: http://atariage.com/forums/topic/226940 ... tari-2600/ – here he didn't bother with the "multiplexer" stage; it's just a 64x8 bit array.

Thanks for the details lidnariq, that home made rom that was built was interesting.

I tried to use a pin swap program for nes roms, made by FARID, and used a 512kb test file then did a file compare of the two. Thought there would be like chunks that are just swapped in a different order for each pin that was swapped but there was literally not one line that was the same. I guess it's more in depth than that and over my head for the time.

Just going to try to swap the pins on a new programming adapter instead of the rom rearrangement idea, seems easier.

If a swap affects D0-D7 or A0-A3, it'll be harder to see correlation by looking for "lines" in common.

Swapping address lines would rearrange the data. For example, take the original data:



Now, if you swap A0 and A1, you would get the following:



If you were to instead swap A1 and A2, you would get:



Now, if you were to swap the data lines instead, what you're actually doing is swapping bits within each individual byte of data, for instance, if you swap D0 and D1, then the byte 0x0A becomes 0x09. To see why, take a look at the binary representation of each:

0x09: 0b00001001
0x0A: 0b00001010

See how the two right-most bits are swapped? It's easy to see in binary, but it's very difficult to see visually in hex, so if you did a data-line swap and then compared, you probably wouldn't see any kind of discernible pattern viewing it in hex.

I did once write a program that would exchange the address lines and/or data lines of a ROM image (as well as the ability to invert any of the address/data lines, and maybe even the ability to use 16-bit memory cells if I remember it properly); you may find it if you search these forums. But if you just want to swap A0 with A1 you could use "dd conv=swab". There may be many other programs too that can do such thing in certain cases, maybe even SoX or ImageMagick or sed or whatever

You messed it up by missing 05!
This should be correct :




Here is a simple Excel file which can calculate it automatically.
But you have to fill the bits manually, copy and pate won't work because it mess up the Function :