The Greatest Justification For Messed-Up Video Game Graphics
kotaku.com
kotaku.com
First, the characters used one multicolored sprite(which gives you double-width pixels), and on top of that sprite they put a black-bordered monochrome(single-pixel widths) sprite to give the characters a cartoony feel.
Maybe the memory savings was from reusing frames from one of these sprites, I don't know.
All the above is for above the waist. Then, when the raster has painted the last line of those sprites, an IRQ occurs and the sprites are moved 21 pixels down and have different frames and perhaps even new colors assigned to them.
This is where the difficulties happen. You have to update 8 sprite y-positions and 8 sprite frame indices. Also up to 4 colors if that is also changed. You only have one scanline(63 cycles) to do this and one update is LDA + STA = 2 + 4 = 6 cycles.
So 8+8+4 moves is 20*6 cycles = 120 cycles. Just less than 2 scanlines.
They could have solves this by spreading out the sprites a bit in the y-direction so they had to do less but one more scanlines. I don't think anyone would even see this.
Most sprite multiplexers sorted the sprites by y-position and then did one IRQ per sprite. If you did this you'd do much less each time and if you could spare the IRQ overhead you'd easily could have 32 sprites on-screen.
In any case, it shouldn't be that hard just to draw a bunch of black pixels on the waistline before the beam reaches the waistline and erase the line if a player moves.
I seem to recall Ray Kelm worked around this for the CNet/Image BBS sysop console in his custom high-speed serial routines, but I may be conflating stories. (Commodore's serial routines couldn't go far above 2400bps; Ray managed to get 9600 working reliably.)
On an Apple II, I was, once, asked to move something half a pixel to the left. And I did it. ;-)
I think early IIs didn't have this 8th bit magig, but, from the II+and on, all IIs had it.
(Random guesstimation).