Hacker News Reader

Comment by tenebrisalietum | Hacker News Reader

> What’s worse, this tiny amount of RAM had to serve as both the scratchpad/heap and as the stack!

Heap? Lol you are not doing ANY dynamic allocation of any kind on the Atari 2600.

Also you're not using the stack to pass parameters to routines here either. You might not even use subroutines.

> This pin-reduced 6507 eliminated the 6502’s NMI and IRQ pins, so there was no hardware interrupt capability at all. Everything had to be accomplished with software timing and polling.

STA WSYNC will make the CPU halt until the TIA is at the next scan line. This is the chief video synchronization tool on the Atari 2600. You do have to keep track of the number of scanlines you've generated. Horizontal timing takes care of itself but you need to track that too for various effects.

View on HN

> Also you're not using the stack to pass parameters to routines here either. You might not even use subroutines.

Well that 128 bytes was in the upper half of page 1 and the 6502's stack was in page 1, but at least one source says that the upper half of page 1 was also mapped to page 0.

I'd guess that at least some programs would push to the stack - if nothing else you could save a byte when storing a byte to memory (PHA vs STA #FF).

I worked on a system in which the address decoding for the RAM mapped $0-$1FF to 256 bytes of RAM. Fortunately it was easier to do graphics on that than on the 2600

Yes, if the 128 of the 6537 is mapped starting at 0x100, then one would use ldx, txs, pha, pla, etc., for any possible optimization. S register is a precious resource! Anything to squeeze between those hsyncs.

I'd have to look at the "fan dissassemblies" floating around--you are 100% right and I think Combat did this.

Thanks! Interesting to have this confirmed. I had a think about how this might be used in practice. Probably not huge wins but every byte counted in those days!

Thanks, I almost had to stop reading after seeing multiple fundamental misunderstandings like that. I respect the author and have BMOW stuff for my Mac, but he should throw a big “I’m new to this” caveat around this article.

Geez, it wasn't that bad, but the article is literally wrapped in disclaimers.

"Recently over the holiday break, I became interested in the 2600’s hardware architecture"

"Did I butcher some technical explanation here, or omit important details? Please let me know! I’m just a beginner on this Atari hardware journey, with much still to learn."

Every time you do a JSR $XXXX it's doing dynamic allocation of sorts. The return address is kept on the stack. I honestly have never seen a game of any complexity that doesn't use subroutines (it saves ROM).

No idea whether it meets your personal complexity bar, but 2600 Centipede seemingly doesn't contain a single JSR or RTS: https://github.com/DNSDEBRO/Disassemblies/blob/master/Atari2...

Sure it meets my bar. That's interesting!

Reply on news.ycombinator.com