4 ms·

Mapping the stack to the graphics screen is also a staple for fast animation on the Apple IIgs. On pretty much all the micros of that era, stack operations wou

Mapping the stack to the graphics screen is also a staple for fast animation on the Apple IIgs. On pretty much all the micros of that era, stack operations would be the fastest instruction due to the auto-decrement behavior. If one could leverage the stack for bitblts, it was usually a win.

vikingerik 5y ago
Yup, and it goes back at least to the Atari 2600, with a 6502-equivalent CPU. For a homebrew game on that, I did the same thing of pointing the stack at the video registers, to get faster throughput with push instructions. The machine has no interrupts so you can always do whatever you want with the stack pointer register. The 2600's video hardware is actually intentionally designed for such a trick. The register to enable the "missile" objects has its hot bit at bit 1. Why that, why not bit 0 or 7? Because bit 1 is the location of the zero flag in the 6502's flags register. You can enable/disable an object by doing a compare on its coordinate, then push the flags register. No conditionals or branching needed, and you even get a consistent cycle-invariant code path, a useful property on this machine. And there are registers for several such objects adjacent in addressing space, so you can handle them with consecutive push instructions without resetting the stack pointer. As for inverting the storage to deal with the directionality, that trick was also known on the 2600. Store a sprite bottom-first in memory, so that your indexing counter decrements towards zero rather than incrementing upwards, so you can "branch if zero flag" to know when you're done rather than needing a compare instruction.
- Someone 5y ago
  > Yup, and it goes back at least to the Atari 2600, with a 6502-equivalent CPU For those wondering whether the 2600 even _had_ a stack: it had 128 bytes of RAM that appeared at both $80-$FF _and_ $180-$1FF (maybe also other places) in the address map. The former means you can read and write it using zero page addressing (faster, shorter instructions), the latter that you’d have half of the 6502 hardware stack, which the CPU thought was at $100-$1FF. It was up to the programmer to ensure the stack didn’t accidentally ran into your variable storage.
  - vikingerik 5y ago
    The RAM appears at every page where lines 9 and 12 of the 16-bit address space are zero. Bit 9 means pages $00xx, $01xx, $04xx, $05xx, $08xx, $09xx, $0Cxx, $0Dxx. Furthermore, then all that is also mirrored for every even-numbered topmost hex digit ($20xx, $21xx, etc), because the 2600's motherboard just omits address lines 13 or higher so those bits don't do anything. When bit 9 is 1 (pages $02xx, $03xx, $07xx, $08xx, etc), you're accessing the timer and console input registers instead. When bit 12 is 1, you're accessing ROM instead of anything onboard. It's not really useful to mirror the RAM anywhere else besides page 1 for the stack, but the architecture just ended up that way for simplicity - no need to decode any other lines than 9 and 12. It would have been possible to use that address space for more ROM, but at the cost of more logic gates - as-is, address line 12 is simply directly wired to the ROM chip-enable line.

vikingerik 5y ago

Yup, and it goes back at least to the Atari 2600, with a 6502-equivalent CPU. For a homebrew game on that, I did the same thing of pointing the stack at the video registers, to get faster throughput with push instructions. The machine has no interrupts so you can always do whatever you want with the stack pointer register. The 2600's video hardware is actually intentionally designed for such a trick. The register to enable the "missile" objects has its hot bit at bit 1. Why that, why not bit 0 or 7? Because bit 1 is the location of the zero flag in the 6502's flags register. You can enable/disable an object by doing a compare on its coordinate, then push the flags register. No conditionals or branching needed, and you even get a consistent cycle-invariant code path, a useful property on this machine. And there are registers for several such objects adjacent in addressing space, so you can handle them with consecutive push instructions without resetting the stack pointer. As for inverting the storage to deal with the directionality, that trick was also known on the 2600. Store a sprite bottom-first in memory, so that your indexing counter decrements towards zero rather than incrementing upwards, so you can "branch if zero flag" to know when you're done rather than needing a compare instruction.

Someone 5y ago
> Yup, and it goes back at least to the Atari 2600, with a 6502-equivalent CPU For those wondering whether the 2600 even _had_ a stack: it had 128 bytes of RAM that appeared at both $80-$FF _and_ $180-$1FF (maybe also other places) in the address map. The former means you can read and write it using zero page addressing (faster, shorter instructions), the latter that you’d have half of the 6502 hardware stack, which the CPU thought was at $100-$1FF. It was up to the programmer to ensure the stack didn’t accidentally ran into your variable storage.
- vikingerik 5y ago
  The RAM appears at every page where lines 9 and 12 of the 16-bit address space are zero. Bit 9 means pages $00xx, $01xx, $04xx, $05xx, $08xx, $09xx, $0Cxx, $0Dxx. Furthermore, then all that is also mirrored for every even-numbered topmost hex digit ($20xx, $21xx, etc), because the 2600's motherboard just omits address lines 13 or higher so those bits don't do anything. When bit 9 is 1 (pages $02xx, $03xx, $07xx, $08xx, etc), you're accessing the timer and console input registers instead. When bit 12 is 1, you're accessing ROM instead of anything onboard. It's not really useful to mirror the RAM anywhere else besides page 1 for the stack, but the architecture just ended up that way for simplicity - no need to decode any other lines than 9 and 12. It would have been possible to use that address space for more ROM, but at the cost of more logic gates - as-is, address line 12 is simply directly wired to the ROM chip-enable line.