Cartridges are read as 8k, 16k, 32k, or 64k. Cartridge dumps will be one of those sizes. But, cartridges themselves can contain ROM chips totaling different sizes (4k, 6k, 12k, 48k etc...). When these other sizes are used, Atari 8-bit machines will pad it with $FF to the next largest it can read. Tools on the Atari 8-bit computer will always report the padded size, not the actual size.

There is no multi-color text mode on any stock Atari 8-bit computers. Text can only be one color at a time per line. The Atari can change the text color every eight scan lines (using machine code, BASIC is too slow) to produce lines of text with each having their own color. Atari 8-bit can mix modes on the screen, but all text in every text mode uses the current text color. If you see more than one text color on the same line of text, you are seeing a raster image, not text. The XEGS system could be hacked by setting a text mode and poking the GITA chip with a graphics mode value. This seemingly had the effect of allowing the text color and text background to be set per character. However, what is really going on is the data of the text character is being written into the graphics mode. Effectively, in this way one can manipulate multicolored text as if they were using a text mode (the BASIC PRINT command and sending values to the text memory will have the expected result of putting a character on the screen). But technically, everything is being written to a graphics mode screen. This is actually much more awesome than multicolored text when you learn that this not only undocumented, but is actually a bug! So, why is this not used in commercial games? Well, probably because its using all the CPU cycles and RAM that would be required to print text to the text mode and to change the text colors and to write graphics to the screen. It is much faster and uses far less memory to simply draw text shaped graphics in various colors in a graphics mode. In fact, when using the hack, 100% of the CPU is used for the entire duration of a text character being drawn to the graphics mode. The kernel is completely devoted to drawing the character while everything else in the system is in a wait state. There is an additional hack to add to this that cuts this down to 50% CPU usage. But it involves [i]indirectly[/] invoking and canceling IRQs; using system timers and 27 machine code instructions every two scanlines, wasting many, many clock cycles, so it barely speeds up the operation at all. Also, 64 of the Atari's text characters cannot be written to screen using this hack.

Various Atari systems had ROM revisions that were backward compatible. ROM upgrades were possible on Atari 8-bit platforms. Rarely, a game requires a newer ROM to run on an older system but in practice, companies tended to list compatible systems rather than compatible ROMS. The Atari 900, for example, first shipped with Revision A and and later Revision B. Some games do not list compatibility with the Atari 800 but in fact will run if the older system has Revision B upgrade. Atari's BASIC that is built into ROMs also has Revision A, Revision B, and Revision C variants. This can produce similar issues as companies tended to list systems rather than the internal BASIC revisions. Also, confusingly, "Revision A" and "Revision B" might refer to a ROM version or a BASIC version (in the ROM). Since ROM revisions A and B only occurred in the Atari 400 and 800, the ROMS are. thankfully, often called "OS-A" and "OS-B"

ROM versions:
Revision A (OS-A)
Revision B (OS-B)
Revision 10
Revision 11
Revision 1
Revision 2
Revision 3
Revision 3B (Arabic)
Revision 4
rev.2

BASIC versions:
Revision A
Revision B
Revision C