Indexed Indirect Addressing
Many, if not all, 6502 coders are familiar with Indirect Indexed Addressing, but by all accounts very few have ever had reason to use its more esoteric cousin, the mysterious Indexed Indirect Addressing.
However, in the course of developing the "swarm" effect for Parallaxian, a rare case use emerged, specifically with regard to setting the MSB condition of each plexed sprite within the swarm.
The sprites in the swarm are plexed by the NMIs which operate on a minimalist "fast-in, fast-out" basis, with y- and x-positions set by the NMI along with pointers and colours and, of course, the tricky MSB conditions, as per the schematic below:
As intimated above, the coding brief for this required that everything be as lightweight and fast as possible within the NMI handlers, so I wanted to perform the logic for the MSB
conditions outside the NMIs to avoid losing CPU time with branch testing inside the NMIs.
We also must update each plexed sprite's MSB condition once per frame, independently of the others in the swarm, and do so by using just one subroutine to keep RAM overhead to a minimum .
So the idea is to set the MSB condition using a zero page value with an AND or ORA instruction that would be hard-written into each NMI handler once per frame by the raster interrupt (IRST) handler that deals with the lateral (x-direction) position updates for the swarm, thus requiring the IRST to be able to quickly modify the instruction dealing with the MSB condition inside each NMI handler.
(The actual value used by the relevant logical instruction in the NMI could much more easily be written into, and then read from, a ZP variable).
Where the MSB = 0, the relevant NMI handler would have to do this:
AND #%10111111 ; (Mask out sprite #06 as that's the one used in the swarm)
And where the MSB = 1, the relevant NMI handler would have to do this:
ORA #%01000000 ; (Mask in sprite #06)
But remember, we need to write the actual instruction into the NMI handler once per frame, in what is a pretty normal case of self-modifying coding practice; for example, in the truncated snippet from the NMI handler below, the instruction in NMIMSBSETROW0 has to be written to that address once per frame by the IRST that sets the MSB positions for all of the sprites in the swarm:
|NMIHANDLER2||STA ZPNMIHOLDA||; "Stack" the A-reg|
|; Set sprite y-pos + pointer|
|NMISETPOINTROW0||LDA #103||; SELF-MODIFIED value|
|; Set sprite MSB|
|NMIMSBSETROW0||ORA ZPSWARMMSBROW0||; SELF-MODIFIED instruction|
|; Set sprite x-pos + colour|
|NMISETCOLORROW0||LDA #00||; SELF-MODIFIED value|
|; Set NMI "vectors"|
|; NMI exit tasks|
|LDA ZPNMIHOLDA||; Recover A-reg|
|JMP $DD0C||; = BIT $DD0D + RTI|
Naturally, the IRST has to be able to exactly write to the correct address in memory within each NMI handler for that fast MSB-setting code, and it must do so from a single subroutine, so what we do is make the actual instructions (AND or ORA) to be written into the NMI handler done so indirectly through vectors held in a LO/HI byte format in dedicated zero page variables.
In other words, we use indexed indirect addressing to do it, as per the dumbed-down snippet from within the relevant IRST handler, shown below:
|SWARMSETXJ1||(tasks @ loop start)||; Y-reg = loop counter|
|; MSB = 0 @ this stage|
|SWARMSETMSB0||LDA #%10111111||; Mask for sprite 06 with MSB = 0|
|LDA #$25||; #$25 = AND in ZP mode|
|; MSB = 1 @ this stage|
|SWARMSETMSB1||LDA #%01000000||; Mask for sprite 06 with MSB = 1|
|LDA #$05||; #$05 = ORA in ZP mode|
|SWARMNEXTROWTEST0||LDX #00||; SELF-MODIFIED value|
|STA (ZPMSBLOINSROW0,X)||; INDEXED INDIRECT!|
|SWARMNEXTROWTEST||INY||; Increment swarm row counter|
|CPY #$06||; 6 rows to update|
|BEQ SWARMRESETROTEST||; Quit loop if counter = 6|
|ASL A||; Multiply counter by 2|
|STA SWARMNEXTROWTEST0+1||; Store as index|
|BCC SWARMSETXJ1||; Branch to start of loop|
|SWARMRESETROTEST||(continue with IRST)|
CONCLUSION: Where you need a fast operation within a loop to write to an absolute (i.e. 16-bit) address in RAM, where the target absolute address changes with each iteration of the loop as a function of the loop counter, indexed indirect addressing is ideal (so yes, it's something of an outlier case use).
In the case of Parallaxian, the (unspoken) brief stated:
- To minimise impact on the IRST handlers' on-screen operations, the NMI handlers had to execute ultra fast and thus consume a minimal amount of CPU cycles, to which end logic tests + branching within the NMIs had to be avoided; instead, any logic should be performed outside the NMIs and the results hard-written back into the NMIs in the form of an ORA instruction or an AND instruction, complete with appropriate masks, to ensure the MSB value is always correct for each sprite plexed by the NMIs.
- The code writing to the NMI handlers to modify the instructions as described would be executed from within the IRST schema once per frame for each of the 6 NMI plex zones and it too, given that it had to run from a RAM-efficient loop, had to execute as quickly as possible, so extraneous or bloaty instruction sequences had to be avoided (which, btw, is a general principle I use in Parallaxian).
- A C128 version of the game would not need the limitation of performing this via a loop, as RAM is much more abundant on that platform.
- The "heavy lifting" calculations for the swarm effect were to be performed by the game's main loop.
So hopefully by now you can see why I ended up using indexed indirect addressing for the swarm effect; it's the only thing that meets both the CPU cycle consumption and RAM efficiency requirements of the coding brief!
There is a slight downside, though; I had to sacrifice 6 x 2 = 12 zero page locations to hold the target addresses within the NMI handlers and I also had to have a subroutine during the game's initialisation that writes the addresses into those zero page locations in LO/HI byte form, but it still represents a RAM saving compared to unrolling the loop that updates the MSB instruction writes to the NMIs from the IRST and remember, the number one priority was a performance gain in terms of CPU cycle expenditure during the NMI handlers plexing the sprites and during the IRST that modifies the logic instructions within the said NMI handlers.
Last of all, here's a short clip of the net result:
Get up to speed with coding on the C64 with some light reading!
PS: Don't forget to check the home page regularly for more articles like this and visit the Everything64 Forum to comment further.
And of course, kindly follow me on Twitter and subscribe to my YouTube channel!
Help Make Parallaxian Happen
I would ask you if you could consider a small, recurring monthly donation (and depending on your tax situation, you might even be able to designate it as a charitable donation rather than let the taxman have it).
And don't worry, you can cancel at any time... but in the meantime, it would be a welcome contribution, however petite.
Oh, and as a special thank you, all who do this will be credited in the game (unless you opt out of it if you have the same kind of incognito hermit tendencies I do).