Using SSCAN2 & SH10 register to repeat sprites horizontally in Blitz2

[leathered]

I'm writing this up partly to help me remember but also to learn from. I don't have the deepest understanding of how it works so if it's up here maybe someone can put me right. A lot of what I get up to is more like amateur hacking. Much of this will be obvious to experienced programmers, but hopefully this will help BB2 users get more out of their language.

I remember trying quite a lot to get this working. To begin with I first heard about about a method of producing a scrolling background using sprites without copper tricks as a reply on a thread here before coming across this. To begin with I just tried changing the FMODE register with a MOVE. This did absolutely nothing, and that was that. I had no idea what the post above really means (and still true, I just managed to use it).

Following this failure I tried to do sprite multiplexing the proper way, using Codetapper's website as a guide. I didn't get very far; The data grabbed by the BB2 GETASPRITE seemed at first to be correctly stored in SPRDAT, but attaching sprites didn't give the correct palette and I wasn't able to use more than 2 sprites. I divided 1 'attached' sprite using a different vertical reference point; not what I was hoping for. I think it's mostly me and will hopefully revisit that someday.

Revisiting FMODE I searched for anything I could find on the 'Fantastic Dizzy' trick. Mostly this was a re-wording of the information I had, but there was an old post somewhere to do with WINUAE Fantastic Dizzy CD32 and the state of the scrolling, which was IIRC displaying horizontally one half of the sprite background and then flicking to display the other scan doubled.

I loaded the game into the WINUAE debugger. I was looking for any sign of FMODE and hoping to see some glimpse of how to use it the way the game produces. Eventually I noticed the bit changes in the copper, and in BB2 was finally able to see some horizontal doubling of the sprite data, with some scan doubling going on. Seeing then that the sprites only appeared scan doubled when SH10 of SPRxPOS was TRUE, I repositioned the sprites until the scrolling spanned the screen without it happening. This, as far as I understand is because SH10 is one of the registers used to control where your sprite is displayed horizontally (forming the upper 7 bits of the X coordinate of your sprite). From $80 (decimal X coordinate 128 for most uses in BB2) an extra bit is required to be set in SH10.

So with the correct bits set in the copper, I kept the scrolling within 128 and -128. The doubling of the sprite data makes up the rest of the screen where your sprites are not drawn.

Anyway, tada! Hope you enjoy and I'll try to write up a bit more rather than just tell folks to RTFM, but I don't get that much time.

;Using the SH10 register to repeat sprites horizontally in Blitz2. 
;AGA only
;Doubling of the sprite data is on the other side of the screen.
;The trick is to re-position them accordingly to get the thing
;scrolling without the unwanted scan doubling!
;Could be done so that only the scan doubled sprites are shown.
;2013 Paul Leonard

;I once found a very handy list of constants for the hardware register addresses.
;But for the purpose of this example only the following is needed.
#fmode         =$1fc
;----------------------------------------------------------------------------------------------
SpriteMode 2
BitMap 0,320,256,5
LoadPalette 0,"FFB32/LYR_BKG_16_SPR.iff",240
;Colour registers 240+ now contain the correct colours for our sprites

;Cut the background shapes, convert to sprites, free the bitmap and shapes
;The bitmap is cut into 64*194 chunks of 16 colours
BitMap 4,320,256,4
LoadBitMap 4,"FFB32/LYR_BKG_16_SPR.iff"    
Use BitMap 4
GetaShape 0,0,0,64,194
GetaShape 1,64,0,64,194
GetaShape 2,128,0,64,194
GetaShape 3,192,0,64,194
GetaSprite 0,0
GetaSprite 1,1
GetaSprite 2,2
GetaSprite 3,3
Free BitMap 4
For t=0 To 3
Free Shape t
Next t

Vwait
BLITZ

;Copperlist
Mouse On
offset=56
height=200
InitCopList 0,offset,height,$30415,8,256,3 ;also works with -3

;CopperWait, CopperMove, will also work with decimal numbers
;CopperCommand allows you to change the registers with normal copper instructions.

CopperReset 0,offset,0      ;needed to use copper commands
                                    ;explanation should be in REDHelp in the  
                                    ;Blitz Support Suite

CopperMove #fmode,$800c   ;set SSCAN2 bit
                                       ;fetchmodes also set
                                       ;should be the same bits
                                       ;as SPRITEMODE 2 command
                                       ;and INITCOPLIST (eg. double CAS)

 ;Change $800c to $400c to see the 'real' sprites

 ;The following 2 lines not actually needed as Blitz will end the copperlist.
 ;With CopperReset and ending InitCopList with the number of 'customs'
 ;we have effectively inserted our own commands into the Blitz CopList object.

 CopperWait 0,256                ; Wait for end of display
 CopperCommand $ffe1,$ffee  ; Wait for copper wraparound

 ;set.b=GetCCOffset             ;how many customs needed?
                                        ;set CUSTOMS to a high number
                                        ;use debugger + STOP command 
                                        ;then trace set.b (or just count the lines, 
                                        ;taking into account that some commands require
                                        ;more than the BASIC    command line)

 DisplayAdjust 0,-8,16,-16,32,-32  ; 256*256 without 'clipping'
 ;This will prob work with much wider displays
 ;but my Amiga presented a small glitch on the left of screen
 ;not present in UAE. Looks nice with 256 =)

 DisplayPalette 0,0
 DisplayControls 0,$220,$0,$ee  ;Set BPLCON registers 2/3/4 for coplist 0
                                           ;$ee sets the sprites to use the last 16
                                           ;colours of our palette
                                           ;Do NOT trust the manual!
                                           ;Only the Appendix is correct!        

CreateDisplay 0

;co-ords for sprites
;It works by doubling sprites left of x co-ord 128 ($80)
;Sprites higher than this x co-ord will be scan doubled!
;<-128 affects similarly.
;SH10 of SPRPOS is set to 1 for sprite positions
;out of these coords. 
  
;.Position sprites: .q for hi-res positioning if needed.
 l.q=-65
 l1.q=-1
 l2.q=63
 l3.q=127

 speed.q=0.5         ;Where 1 would be a pixel
 #y=10

 .startloop
 While Joyb(0)=0

 DisplayBitMap 0,0,0,0;xscr.q,yscr

 DisplaySprite 0,0,l.q,#y,0
 l.q-speed
 If l.q<-128 Then l.q+256

 DisplaySprite 0,1,l1.q,#y,2
 l1.q-speed
 If l1.q<-128 Then l1.q+256

 DisplaySprite 0,2,l2.q,#y,4
 l2.q-speed
 If l2.q<-128 Then l2.q+256

 DisplaySprite 0,3,l3.q,#y,6
 l3.q-speed
 If l3.q<-128 Then l3.q+256

 VWait
 Wend

 ;Quick clean up
 Free Bitmap 0
 For t=0 To 7
 Free Sprite t
 Next t
 End

[Graham Humphrey]

Very interesting, great work there. Not really applicable to my current projects but will take a look at this sometime, might well come in handy eventually