How did the Atari 2600's 6507 handle zero page and stack with only 128 bytes of RAM?

Question

The Atari 2600 used a cut-down version of the 6502 called the 6507. The 6507 was cost reduced by not supporting interrupts and (more importantly) having fewer address lines resulting in that it only supported 8KB. While this had its limitations, it worked just like a regular 6502.

Somewhat famously, the Atari 2600 had a ridiculously small amount of RAM: 128 bytes. This was provided by the 6532 RIOT chip and was sufficient for the primitive games that the VCS was originally designed for (basically a programmable Pong/Tank machine). Most of the address space for the 6507 would ultimately be provided by ROM cartridges which would be plugged into the Atari.

The question I have is that the 6502 treats two pages of RAM in a special way:

• 0x0000-0x00FF: The zero page. Every RAM addressing command supported a zero page mode which not only saved an operand byte (since it only needed 8 bits of a 16-bit address) but also saved a processor cycle or two because of the simpler address decoding.
• 0x0100-0x01FF: The stack. Any push/pop/subroutine operations would leverage this space and the pointer was managed by one of the 6502's registers.

(I presume that these locations are hard-coded into the workings of the 6502)

I'm curious how the Atari 2600 mapped RAM considering these two special memory pages. You need a stack and I believe that would start at 0x01FF and work downwards with every push, but then you wouldn't get the benefit of the zero page. If you mapped into the zero page, the stack operations probably wouldn't work because I'd guess an address line would be tripped up. If you overlapped at the top of the ZP into the bottom of the stack page (e.g. 0x0080-0x017F), you'd have the problem of the stack register needing to be defaulted to 7F instead of FF.

I suppose you could give up zero page and run everything out of the top half of the stack page and just try to limit your stack usage to maximize available RAM which would start at 0x0180. Or was there something fancier going on in the hardware?

So how did this work?

Answer 1

I presume that these locations [Zero Page and Stack] are hard-coded into the workings of the 6502

Yup, they are.

So how did this work?

Simply by partial address decode. Address bit A8 was not decoded when RAM was accessed and A7 was used as chip select. This mirrored the 128 ($80) bytes two times over ZP and Stack (at $0080 and $0180) (*1).

So all 128 bytes could be used both as Stack and ZP at the same time. Of course, SP does crawl down and could overwrite other data - but in real life game application stack is only used in small and quite controlled portions.

In fact, this addressing scheme did allow several neat tricks. For example a background routine prepares screen data to be displayed in ZP. While ZP-addressing is already fast, it would still limit what can be displayed during a line. A loop using zp,X addressing would need 6 clocks per byte (4 at LDA plus 2 to increment X), but by setting SP at the bottom of the display data and popping the data the same process gets reduced to just 4 clocks (*2)

---

The 6507 was cost reduced by not supporting interrupts [...]

I can't help, but this calls for some nitpicking, as it's not entirely true. There's still reset. Sure, a bit hard to handle, but still possible. The VCF badge is a great example showing how to use reset as interrupt to read a serial input signal :))

---

*1 - Well, due the fact that the whole decoding for RAM just goes by A7=1 and A12=0, the RAM is mirrored at $80..$FF in every page of the first 4 KiB. Much like the TIA is occupying the other half of each page - here mirrored several times in every half page.

*2 - Of course, unrolling the loop would reduce it to 3 clocks per byte (fixed address LDA zp), but also double the code length. So there's always a trade-off.