SpiceWare's Blog

Cool... it looks like the stars are streaking across the sky.

 

Wonder how that could be used in a game... ?

I see this pattern a lot:

 

  
  lda #<DS_HMMB           ; 2 58 <- just to keep stream in sync        
  lda #<DS_M1M0BL         ; 2 60        
  sta ENABL               ; 3 63 <- on VDEL, for next scanline       
  lsr                     ; 2 65       
  tay                     ; 2 67 <- Y has enable for M0        
  lsr                     ; 2 69 <- A has enable for M1        
  ldx DS_GRP1             ; 4 73        
  jmp R76                 ; 3 76

Could you use the DS_HMMB fetch to eliminate an LSR and save 2 cycles, e.g:

  lda #<DS_HMMB           ; 2 58 <- just to keep stream in sync        
  tay                     ; 2 60
  lda #<DS_M1M0BL         ; 2 62        
  sta ENABL               ; 3 65 <- on VDEL, for next scanline       
  lsr                     ; 2 67 <- A has enable for M1        
  ldx DS_GRP1             ; 4 71
  jmp R76                 ; 3 74

Even where the HMMB value is used, I think you can still use this trick. It looks like the Y value is only used for ENAM0, which won't overlap with the bits needed for HMBL, i.e:

 

  lda #<DS_HMMB
  sta HMBL
  tay
  ...
  sty ENAM0

Or even better if you can put the HMBL and ENAM0 together you could free up the Y register entirely:

 

  lda #<DS_HMMB
  sta HMBL
  sta ENAM0

You could possible combine one of the other HMMx values with ENAM1 and save a fecther ...

 

Chris

I guess this won't work because the HMMx need to come before the HMOVE and the ENAMx need to come after.

 

I wonder if you could do something like this instead to eliminate the LSRs and allow the GRP1 to be a fast fetch:

 

        
        lda #<DS_HMP0
        sta HMP0
        tax
        lda #<DS_HMP1
        sta HMP1
        tay
        lda #<DS_HMMB
        sta HMBL
        sta ENABL
        ...
        lda #<DS_GRP1
        sta HMOVE
        sta GRP1
        stx ENAM0
        sty ENAM1

Chris

I would be tempted to inline the R76 code in ever single kernel. Also, the few kernels that are really tight for cycles could probably go in the same bank as the JMP table and avoid the initial JMP?

 

Trying to find you enough cycles to do digital audio during the kernel

 

Chris

Originally the DS_HMMB datastream was DS_COLUP_HMMB as it held the color change for player repositions or HM value for missiles ball. I might be able to merge DS_HMMB with DS_M1M0BL, say DS_HMMB_ENMB which would save a couple cycles. Would still require the LSRs...

 

Something else that might work better would be this:

• DS_HMP0 -> DS_HMP0_ENAM0
• DS_HMP1 -> DS_HMP1_ENAM1
• DS_HMMB -> DS_HMMB_ENABL

Then no LSRs would be needed, just do this:

 lda #<DS_HMP0_ENAM0
 sta HMP0
 tax
 lda #<DS_HMP1_ENAM1
 sta HMP1
 tay
 lda #<DS_HMMB_ENABL
 sta HMM0/M1/BL/not used for player repositions
 sta ENABL <- on VDEL
 ...
 lda #<DS_GRP1
 ...
 sta HMOVE
 sta GRP1
 stx ENAM0
 sty ENAM1
 jmp (NextKernel)

---

 

At the moment the DS_HMPx datastreams use the lower nybble for housekeeping, so that would need to be changed. Bit 3 flags "in use" so I know which scanlines a player appears on - I can't use what's in DS_GRPx as some images, like the explosions, have blank lines which could allow reuse to occur when it shouldn't. Bit 3 also flags the lines above the graphics as the reposition could occur up to 5 scanlines prior. The lowest 3 bits also hold the X offset for the sprites that use line-by-line shifting.

StationHorizontal_Shift:
        .byte HMOVE_0  |  0  |  8   ; bit 3 on for "in use" test in DataStream()
        .byte HMOVE_0  |  0  |  8
        .byte HMOVE_R2 |  2  |  8
        .byte HMOVE_0  |  2  |  8
        .byte HMOVE_0  |  2  |  8
...
        .byte HMOVE_0  |  2  |  8
        .byte HMOVE_L2 |  0  |  8
        .byte HMOVE_0  |  0  |  8
...
        .byte HMOVE_0  |  0  |  8
        .byte HMOVE_R2 |  2  |  8
        .byte HMOVE_0  |  2  |  8
...

Cool... it looks like the stars are streaking across the sky.

 

Wonder how that could be used in a game... ?

Was thinking the same thing - after clearing a sector warp left/right to get to the next. A multilevel parallax effect could be accomplished by changing the star's speed based on their widths.

Ok - the ball will be the most time constrained kernel, so I worked this up at lunch:

DS_GRP0         = DS1DATA
DS_GRP1         = DS2DATA
DS_HMP0_ENAM0   = DS3DATA
DS_HMP1_ENAM1   = DS4DATA
DS_HMMB_ENABL   = DS5DATA   ; HMxx for missile/ball, ENABL
DS_COLOR        = DS6DATA   ; COLUP0, COLUP1, COLUPF - only used during reposition
DS_SIZE         = DS7DATA   ; NUSIZ0, NUSIZ1, CTRLPF - only used during reposition
DS_JUMP         = DS8DATA

RealResblStrobe73:              ;   20
        lda #<DS_SIZE           ; 2 22
        sta CTRLPF              ; 3 25
        lda #<DS_GRP0           ; 2 27
        sta GRP0                ; 3 30 <- for next scanline, VDELP0 on
        lda #<DS_JUMP           ; 2 32
        sta NextKernel          ; 3 35
        sta HMCLR               ; 3 38 <- reset missile/ball HMOVE
        ldx DS_HMP0_ENAM0       ; 4 42
        stx HMP0                ; 3 45
        ldy DS_HMP1_ENAM1       ; 4 49
        sty HMP1                ; 3 52
        lda #<HMMB_ENABL        ; 2 54
        sta HMBL                ; 3 57
        sta ENABL               ; 3 60 <- for next scanline, VDELBL on
        lda #<DS_COLOR          ; 2 62
        sta COLUPF              ; 3 65
        lda #<AMPLITUDE         ; 2 67
        sta AUDV0               ; 3 70
        sta RESBL               ; 3 73
        lda #<DS_GRP1           ; 2 75        
        sta.w HMOVE             ; 4  3
        sta GRP1                ; 3  6
        stx ENAM0               ; 3  9
        sty ENAM1               ; 3 12
        jmp (NextKernel)        ; 5 17

---

For the player kernels:

• sta CTRLPF -> sta NUSIZ#
• sta HMBL is eliminated
• sta COLUPF -> sta COLUP#
• sta RESBL -> sta RESP#

For the missile kernels:

• sta CTRLPF -> sta NUSIZ#
• sta HMBL ->sta HMM#
• sta COLUPF is eliminated
• sta RESBL -> sta RESM#

So, if I didn't miscount any cycles, or miss any updates, we can change the ball's color and size, *and* add in support for digitized speech

 

Thanks Chris - I foresee another Draconian reboot

I should have pointed this out before you rewrote all of the kernels yesterday!

 

One final suggestion is to move the HMP1/ENAM1 writes to the end to free up the Y register and 3 more cycles:

 

lda #<DS_HMP1_ENAM1     ; 2 71
sta HMP1                ; 3 74
sta HMOVE               ; 3 1
sta ENAM1               ; 3 4
stx ENAM0               ; 3 7
lda #<DS_GRP1           ; 2 9
sta GRP1                ; 3 12
jmp (Next)              ; 5 17

Chris

Oh well, at least I wasn't further along in the reboot

 

There's a RES## that needs to occur @ 73, that's why I did that particular kernel as the test case, the others have a bit more flexibility (though @ 68 can be tricky too).

Ah - I missed the RESxx, but it will still work before the HMP1 with a bit of padding.

 

On the VCS - if you don't rewrite the kernel at least 10 times then you aren't trying hard enough . I lost count of the rewrites for star castle!

 

Chris

I had a minor issue squeezing in the new kernels yesterday, think I'll expand the 6507 code into bank 5 before I do anything else. Moving just the menu screen kernel into 5 should give me enough room to work on the next reboot.

Thursday's Expanse and Magicians night (having cut the cord, I get shows like these via iTunes the day after they broadcast) so didn't get much work in on Draconian last night. I did manage to relocate the 6507 main menu code into bank 5, so bank 6 has plenty of room again for working on the rewrite for digital audio support.