Okay, I spent a little bit of time optimising the IRQ side of the multiplexor, and I can now get a sprite within 10-11 lines of the other set. Thats not bad, not bad at all (I seem to remember Blood Money being almost 20). This should be more than enough for a game. I more or less copied Dan's IRQ model for this (although I did a macro with some paramaters rather than having to maintain a whole chunk of code) and I've gotten it down to the barest minimum I can get away with. Heres the macro I used, which if you compare with Dan's, you'll find it quite close with only minor changes. If I had a couple of these, I could save an extra 4 per sprite - but thats excessive :)
;
; \0 = sprite number ( 1,2,3,4,5,6,7 )
; \1 = x+y offset ( 2,4,6,8,10,12,14 )
; \2 = NEXT sprite ( 2,3,4,5,6,7,1 )
; \3 = "b" for bcc or "j" for jcc
;
sub_amount equ 10 ; number of lines before a sprite needs to be setup
SetUpSprite macro
DoSprite\0:
cpy #\0 ; is this the Hardware sprite we're after?
bne NextHWSprite\0 ; not THIS sprite ->jump to next
SkipCPY\0:
lda XTable,x ; Store the sprites "X" coordinate in the
sta $d000+\1 ; VIC hardware sprite register
lda $d010 ; get all sprite significant bits
and #~(1<<\0) ; mask OFF this one
ora XSig,x ; already set for the correct bit!
sta $d010 ; so we OR in this sprite and store it!
lda YTable,x ; Get sprite Y coordinate
sta $d001+\1 ; store in VIC hardware register
lda XShape,x ; get the sprite graphic
sta HWShape1+\0 ; Since we have a double buffered screen,
sta HWShape2+\0 ; we store it in BOTH locations.
lda SprCol,x ; Get sprite colour
sta $d027+\0 ; store in VIC hardware
inx ; next sprite in list
ldy #\2 ; next hardware sprite
lda YTable,x ; Get sprite Y
jeq EndOfSpriteList2 ; 0? If so all finished
sbc $d012
cmp #4 ; do we HAVE enough time for another IRQ? (magic number)
\3cc SkipCPY\2 ; if not do it now!
;
; If we've lots of raster time until the next sprite
; but the sprite we will be copying over was already drawn
; by the VIC, then just copy it over NOW!
;
;sec ; Carry is ALREADY set
lda $d012 ; Get the current raster
sbc #22 ; -22 gets us the last "safe" sprite
sbc $d001+(\2*2) ; location. Now subtract the next sprite Y
\3cs SkipCPY\2 ; is > last sprite, then setup NOW!
;
; If its further down the screen, and the current sprite
; is still being drawn, then setup a new IRQ just above the
; sprite to handle it
;
;sec ; dont set carry, we'll offset this in the SBC
lda YTable,x ; if we can't copy now, then we set up
sbc #sub_amount-1 ; a new RASTER IRQ based on the next sprite (-1 for SEC)
sta $D012 ; and its Y coord.
jmp EndMultiIRQ ; and then this starts all over again!
NextHWSprite\0:
endm
I may not have mentioned this to the C64 guys, but once the game is finished, I plan on giving the source out, along with some documentaion that should allow others to either skin it quickly into another shooter, or to hack it into something completely different. I've always thought that the main problem with the scene was that good games take time, so no one can usually be bothered to make one - and when they do, they feel completely attached to the source and want to keep their master-peice. So I decieded from Day 1 of the Plus4 version that it was all going to get released. There no money in it, so why hold on to it when it could do so much good the scene.
That supercpu shoot-em-up is a good example - I wonder how much they
actually made from it.... whats the point? I'm even trying to keep the comments up to date!! So don't say I'm not good to you all!!
Also, if theres anything I've touched on that anyone would liked explained, then just drop a comment letting me know, and I'll try to post something more about it.
I got my new dual parallel port today, so I spent the evening updating the Plus/4 downloader to allow me to change port address, and writing the new C64 downloader. The piccy shows the new cable before I've tidied it all up and put the casing on; but now that I know it all works, I can do that whenever. 
