What is the layout of Atari VCS/2600 ROM files?

Question

I understand the CPU had fewer address lines than a 6502, limiting it to 8kb but that the Atari hardware didn't connect one line thus limiting cartridge access to 4kb.

I further understand that the hardware maps the cartridge ROM into the top of the address space to $FFFF since the start vector is at $FFFC, and that RAM is mapped from $0000 since the zero page is essential for 6502 family programming.

I believe that, for emulators, both .a26 and .bin ROM files are the same format and the extensions can be freely switched. They actually have no format and are just dumps of the ROMs with no headers.

So that's fine for old/small games that only use 2k or 4k, but newer games used memory paging. Since these files are just longer binary files with no header, how are the ROM pages/banks arranged in them? They can't have different addresses and all the paging is controlled by the software and whatever extra chips might be in the cartridge, meaning there is no standard.

If there were a standard I assume bigger ROMs would just just at addresses at lower powers of 2, $E000 for 8k games, $C000 for 16k games, $8000 for 8k games, etc. But as they all can only get mapped into the $F000 to $FFFF range 4kb at a time, they don't have an inherent order.

One thing I can think of is that internally inside the cartridge the ROM is contiguous and the chips inside map from these internal ranges to the bank actually switched into the address range the console can see.

But this brings me to the next wrinkle. Most ROMs I find online are 2k, 4k, 8k, or 16k, as I expected. But there are also plenty of 25k, 34k, and 64k. How do those work? Common sizes, in hex: $2100, $6300, $3000, $8400, and, strangely, $28ff and $2003!

I never programmed on machines with banked memory back in the day, I went straight from a 48K Speccy to an Amiga 1000, so I might be missing some obvious things.

(Please feel free to ask for clarification or edit for clarity. It's hard to explain, I think.)

Answer 1

The file can contain the ROM data in any possible ways. There is no information in the file or file name about the original cart banking type/method how it needs to be banked, if it is just a raw dump of a large ROM chip read in an external reader/programmer.

Therefore the emulator needs to auto-detect what kind of banking method is used, in order to know which banking method to emulate for the CPU.

There are many ways to do the auto detection and narrow down the options. For example file size limits the options to only those methods that have been used carts with that certain ROM size. The ROM can be scanned for specific patterns of opcodes that are known to be used for specific types of bank switching, or specific patterns of signature bytes or strings.

Once the emulator has determined which known cart type it could be and which type of bank switching type/method the ROM file likely uses it can then apply the emulation of that specific type of cartridge that implements the bank switching in that specific way in hardware to run it.

There are dozens of different methods used on carts and while rather similar, the emulator has to support emulating the cart banking method to be able to run the ROM that was on a cart that uses some specific method.

So the detection of the cart type from ROM contents is an additional analysis step once a particular cart type or bank switching method is known/emulated.

For the odd-sized ROM carts that are not powers-of-two, maybe two smaller and different size ROMs are used instead of one large, or some part of ROM cannot be accessed because the cart implements RAM.

Examples: "Tigervision" scheme splits the 4K window into two 2K parts. The first 2K is banked and the latter 2K is fixed and contains the reset and interrupt vectors. Bank is switched by writing the bank number to addres 0x3F. The scheme supports 256 banks for 512KB of ROM but games only used up to 8K.

Another scheme expands the previous scheme with SRAM support, where writing to 0x3F selects which 2K ROM bank is visible, but writing to 0x3E selects which SRAM bank is visible. The 2K SRAM window is actually split into 1K read and 1K write windows as the read/write signal does not go to cart, so different memory addresses have to be used to determine between read and write access. The bank switching scheme is limited to 32 SRAM banks for 32K of SRAM.

And so only the case of 4K ROM is simple - if fills the 4K ROM area fully, and is only subject to the wraparounds of the hardware, i.e. the to the CPU, the ROM is mapped 8 times in 64K address space. Any smaller ROM such as 1K would be mapped 4 times in the 4K ROM window.

No matter if the ROM is 1K or 2K or 4K, all that matters is that the CPU will fetch interrupt and reset vectors from end of memory, $FFFx area, but to the 4K ROM chip, this is $0FFx, to a 2K ROM chip this is $07Fx, to a 1K ROM chip this is $03Fx. So the code in ROM can either assume the address space where it is running in any way possible based on the address wraparounds - code could keep running in $F000..$FFFF area or go tell the CPU to run code from $1000..$1FFF area, as the ROM is readable from all those addresses.

Answer 2

A cartridge is a device which, when address pin A12 is high, will examine the states of address pins A0-A11 and typically output a value on data pins D0-D7 in response. Typically, this will be done by having one or more 4K banks and (if a cartridge has more than one 4K bank) having circuitry respond to certain addresses by switching banks, and otherwise using A0-A11 to select a location within the selected 4K bank.

Most commonly, 8K cartridges will switch to bank 0 any time they see an address of the form xxx1 1111 1111 000, and switch to bank 1 any time they see one of the form xxx1 1111 1111 001. Most 16K cartridges cartridges use those two along with xxx1 1111 1111 010 and xxx1 1111 1111 011. For 32K cartridges, those four addresses would be used along with the addresses of the form xxx1 1111 1110 1bb, where bb identify one of the banks 4-7.

Some cartridge designs may always select the lowest numbered bank on startup, some may always select the highest numbered bank, and some may select a bank at random. Additionally, some may honor a bank-change request on the cycle where it is issued (so a read of $1FF8 would yield the contents of address $FF8 in bank zero, i.e. offset $0FF8 in the ROM image, regardless of the bank from which the request was issued), while others may yield the value at adress $FF8 of the previous bank). Such issues usually don't matter, though, because most cartridges will be programmed to contain identical data in all banks where such ambiguities could arise.

Some cartridges use the same general scheme, but use different bank-switching triggers because the hardware can be slightly simpler. The game Toyshop Trouble is so far as I know the first cartridge that can use a single common-off-the-shelf logic chip to interface an 8K ROM to the 2600 (while making both banks acceptable). If memory serves, it switches to bank 0 when it sees any address of the form xxx0 1xxx x0xx xxxx, and switches to bank 1 when it sees any address of the form xxx0 1xxx x1xx xxxx. Since it only cares about the states of 3 address lines, the other ten address lines don't need to be connected to the bank-switching circuitry.

Most cartridge images that are 4096, 8192, 16384, or 32768 bytes will be designed for one of the above banking schemes. Cartridge images that are a multiple of 256 but not one of the above sizes may be intended for use with the Arcadia/Starpath Supercharger, a really cool oversized cartridge that contains an audio input. Back in the day, one would connect the cartridge to a cassette player holding a rewound game cassette, power on the console, and push play on the player. About 10 seconds later, a message to PUSH STOP would appear, and after one pushed stop one could start playing the game. Some games may have data for multiple levels stored on tape; when reaching the end of a level, one would push play to load the next level's data. Each tape segment would have a multiple of 256 bytes, preceded by a header. The author of a utility to convert audio files to data image, or generate audio files from an image, documented a format which always reserves 256 bytes for the header, regardless of the encoded length on the tape.

Files of other lengths typically use other banking schemes; using them would require knowing more about the particulars of the file in question.

Answer 3

While I understood that the lack of address lines led to mirroring of memory regions, I didn't understand the full ramifications of that.

With 13 address lines, the 6507 can access 8K, and it will be mirrored in 8 places. With 12 address lines, the cartridge slot can only make 4K available to be accessed by the 6507.

This means that in a straightforward ROM dump file, only 4K maximum can directly map into the system without extra logic. This means that 2K ROM cartridges and 4K ROM cartridges are the only ones that won't do anything tricky.

For ROM dump files > 4K the raw file format is lacking and as Justme pointed out in his answer, software that makes use of these files has to have special knowledge such as identifying games from the bytes and looking up which games use which technique, or heuristics to look for known patterns such as code blocks that are the same in many cartridges for the logic that pages address ranges in and out.

A naïve piece of software can only treat 2K and 4K cartridges in a known manner, and even that is not 100% guaranteed. 2K cartridges map to $F800 to $FFFF, 4K cartridges map to $F000 to $FFFF, and all other sizes have "undocumented" layouts, for want of a better term.