"Sierra Maestra", an Early WIP

[ZackAttack]

You could always pad the Sprite to make it 32 high. Of course that will waste space.

[JeremiahK]

True. If you could find a way to fill the wasted space with other data, that would help.

 

Are you aware that Stella can be made to show your labels and variables in the debugger using .lst and .sym files?

 

This is how I execute DASM:

dasm filename.asm -v5 -f3 -sfilename.sym -lfilename.lst -ofilename.bin

The list and symbol files tell Stella extra information about the code, like labels. Sometimes it confuses constants with RAM, though, which can be confusing.

Edited December 10, 2017 by JeremiahK

[vidak]

I have managed to get the Che character to animate properly while he is moving up and down.

 

This is how I solved the problem. The order of operations in the AnimationDelay subroutine used to be this:

AnimationDelay:
    inc AnimFrameCounter
    lda AnimFrameCounter
    cmp #9
    bcs .ResFrmCntr
    bcc .IncFrameNo
    beq .IncFrameYes

...

    rts

Now BCS actually branches if A is GREATER THAN OR EQUAL TO the value in memory. This was causing the local frame counter to constantly be set to zero over and over again.

 

I think THIS is the proper order in which you should test if a number is equal to a certain number, or if it has gotten too high for the loop:

    beq .IncFrameYes
    bcc .IncFrameNo
    bcs .ResFrmCntr

Changing the order of testing to this caused the animation sequence for Che moving up and down the screen to work.

guerrilla8_6.bin

coloured_guerrilla009.asm

[vidak]

Are you aware that Stella can be made to show your labels and variables in the debugger using .lst and .sym files?

 

This is how I execute DASM:

dasm filename.asm -v5 -f3 -sfilename.sym -lfilename.lst -ofilename.bin

The list and symbol files tell Stella extra information about the code, like labels. Sometimes it confuses constants with RAM, though, which can be confusing.

 

I DID NOT KNOW THAT. WOW!!!!

 

I know that may be an over-reaction but that actually makes my life so much easier!!

[vidak]

Okay. I've completely solved the issue.

 

Che will now animate and walk around the screen (a) with the proper limits; (b) at a delay of 10 screen frames per animation frame.

 

Please find the source code, symbol files, and binary attached.

 

This was the problem:

AnimateHorizontalYes:
    inc AnimateHor0

AnimateHorizontalNo:
    lda AnimateHor0
    and #2
    sta AnimateHor0
    sta Animation0
    jmp SaveFrame

The AND operation is a bitmask operation. It will only let this value through: %00000010. Because we are counting up from 0 to 2, it masks and returns a value of 0 every time. So we are never allowed to count up to 2. This means Che will never animate horizontally.

 

This is what I replaced the code with:

AnimateHorizontalYes:
    inc AnimateHor0

AnimateHorizontalNo:
    lda AnimateHor0
    cmp #2
    beq .CntHorCntr
    bcc .CntHorCntr
    bcs .ResHorCntr
.ResHorCntr
    lda #0
.CntHorCntr
    sta AnimateHor0
    sta Animation0
    jmp SaveFrame

It's slower, and more ugly, but it works.

 

Now my goal of getting Che to walk around the screen has been completed. This marks the end of the first phase of the development of this game. There may be 20 or 50 phases of development, but this is a huge step for me.

 

One thing I need to do right now is fix the colours on the graphics to make sure they all match.

coloured_guerrilla010.asm

guerrilla10.bin

guerrilla10.lst

guerrilla10.sym.zip

[JeremiahK]

Is that bcs command neccesary? It branches to the very next instruction.

[vidak]

oh you're totally right!

 

that'll totally increase the parsimony of the programming

[tschak909]

he hops quite nicely

[+stephena]

 

I DID NOT KNOW THAT. WOW!!!!

 

I know that may be an over-reaction but that actually makes my life so much easier!!

 

In the future, we hope to extend this in Stella, and when debugging a ROM that was generated by DASM, have it display all info generated by DASM. This is then very close to eventual the end goal: source-level debugging.

[vidak]

I am moving onto the next phase of the development of the game. This phase of the development is writing a kernel which will draw multiple bands of GRP1 down the screen.

 

Find inline below the code for one of the 5 kernels of the overall screen. I am using an approach to SpiceWare's Stay Frosty, except I am not using a mask to blank out the Player0 character on the lines it is not supposed to appear. I am using FlipDraw to prevent myself from having to juggle between two scanline counters. This way I can set the Y offset for GRP0, and it will draw somewhere throughout the 5 kernels as the kernels go about drawing the screen.

 

Also, because the Y offsets for all the different GRP1 graphics are "local" (relative to the number of scanlines within their respective kernel), I do not need to adjust them relative to a global scanline counter. FlipDraw is the slowest method of drawing graphics down the screen, but for the fact that it does not need a scanline counter, which is what was pushing me over 76 cycles while I was using DoDraw.

 

I will have to readjust how all the pointers are set, but I am lead to believe FlipDraw allows for much easier setting of pointers.

 

Let me know if something doesn't seem right.

;---------------------------------
;
; SECTION 4 KERNEL
;
;---------------------------------

;=================================
;
; Preload GRP0 (Che) Graphics
;
;=================================


Kernel4:

    lda #P0_HEIGHT      ; 2 18
    dcp Player0Offset   ; 5 23
    bcc .p0FlipPre      ; 2 25 (3 26)
    ldy Player0Offset   ; 2 27

    lda (Player0Ptr),y  ; 5 32
    sta CheGfxTemp      ; 3 35
    lda (Player0Clr),y  ; 5 40
    sta COLUP0          ; 3 43 (27)

.p0FlipPre              ;(3 26)
                        ;(  43) - Longest way
    
; We will not be showing Player1 on the first line of the section.

    lda #0
    sta EnvGfxTemp
    
    ldx Heights+4
    dex

;=================================
;
; Start of the actual kernel
;
;=================================
    
    
    
.KernelLoop4

	sta WSYNC           ; 3 72

;------------------------------------------------------------------
	
;=================================
;
; Draw Che Graphics in time for left-most
; side of the screen.
;
;=================================

    lda CheGfxTemp      ; 3  3
    sta GRP0            ; 3  6
    lda EnvGfxTemp      ; 3  9
    sta GRP1            ; 3 12
;=================================
;
; Calculate Environment Graphics
;
;=================================

    lda EnvHeight4      ; 3 15
    dcp EnvGfxOffset4   ; 5 20
    bcc .p1FlipDraw     ; 2 22 (3 23)
    ldy EnvGfxOffset4   ; 2 24

    lda (EnvGfxPtr4),y  ; 5 29
    sta EnvGfxTemp      ; 3 32
    lda (EnvClrPtr4),y  ; 5 37
    sta COLUP1          ; 3 40 (28)

.p1FlipDraw             ;(3 23)
                        ;(  40) - Longest way
 
;=================================
;
; Calculate Che Graphics
;
;=================================

    lda #P0_HEIGHT      ; 2 42
    dcp Player0Offset   ; 5 47
    bcc .p0FlipDraw     ; 2 49 (3 50)
    ldy Player0Offset   ; 2 51

    lda (Player0Ptr),y  ; 5 56
    sta CheGfxTemp      ; 3 59
    lda (Player0Clr),y  ; 5 64
    sta COLUP0          ; 3 67 (27)

.p0FlipDraw             ;(3 50)
                        ;(  67) - Longest way
    
;=================================
; Even though we're using FlipDraw,
; we still need a scanline counter
; to keep track of which section
; we're in.
;=================================
        
    dex                 ; 2 69
    bne .KernelLoop4    ; 2 71 (3 72)

coloured_guerrilla014.asm

[vidak]

I think I am moving into the final version of the kernel of the first part of the game!

 

Please find the inline code for my current MACRO for a single band of the screen.

 

This kernel allows each GRP1 to be independently positioned within each band of the screen. This will allow me to animate some of the GRP1s within their respective bands on the screen. I will have Cuban peasants, and Batista soldiers. I will also have non-animated graphics such as trees.

 

The GRP1 graphics will have to be 3 scanlines shorter than the height of the band of the screen, due to timing constraints caused by the need to strobe HMOVEat the beginning of the first scanline.

 

I am using Manuel Rotchkar's FlipDraw for this kernel, because it means I don't have to use a scanline counter for the graphics Y offset when I don't want to. FlipDraw is the slowest method for drawing graphics on any individual scanline, but it completely removes the need to juggle line counters, which makes it faster overall when you compare it to other drawing methods WITH line counters.

 

I have counted the LDY instructions in the FlipDraw as 2 cycles, when they are in fact 3. I think I'm still within the goal posts, though - I'll fix up that counting issue later.

 

(Actually I've just looked over this, there are a lot of counting issues... Could I fit the calculation for line 2 of GRP0's graphics in after HMP1?)

 

Anyway it is my hope that this macro will enable me to draw as many as FIVE bands of multicoloured GRP1s down the screen.

 

I am about to develop a 2LK for the "Lock and Load" part of the game, the second part, which will feature:

 

• 2 coloured sprites
• 1 missile
• a coloured asymmetrical playfield

***

If someone would like to look over my work, I'd be very grateful.

 

***

;---------------------------------
;
; KERNEL MACRO
;
;---------------------------------

        MAC SCREEN_BANDS
.BAND   SET {1}


;=================================
;
; Preload GRP0 (Che) Graphics
;
;=================================

    lda #P0_HEIGHT      ; 2
    dcp Player0Offset   ; 5
    bcc .p0FlipPre0     ; 2 (3)
    ldy Player0Offset   ; 2

    lda (Player0Ptr),y  ; 5
    tax                 ; 3
    lda (Player0Clr),y  ; 5
    tay                 ; 3 (27)

.p0FlipPre0             ;(3 XX)
                        ;(  XX) - Longest way

;=================================
; Position GRP1 independently for
; each band of the screen.
;
; Accumulator holds X value.
;=================================

.PositionGRP1

    lda EnvObjectX+.BAND
    sec       
    sta WSYNC

;----------------------------------------------------- ENTER FIRST SCANLINE
    
    stx GRP0        ; 3  3
    sty COLUP0      ; 3  6
    
DivideLoop1
    sbc #15         ; 2  8
    bcs DivideLoop1 ; 2 10
    eor #7          ; 2 12
    asl             ; 2 14
    asl             ; 2 16
    asl             ; 2 18
    asl             ; 2 20
    sta RESP1       ; 2 23 <- set object position
    sta HMP1        ; 3 26

; Could I fit the below second scanline precalculation here?

    sta WSYNC
;------------------------------------------------------ ENTER SECOND SCANLINE
    sta HMOVE           ; 3  3
    
;=================================
; We haven't had time to preload
; any graphics, so now we have to
; rush and try and make sure we have
; something to draw on this line
;=================================
    
    lda #P0_HEIGHT      ; 2  5
    dcp Player0Offset   ; 5 10
    bcc .p0FlipPre1     ; 2 12 (3 10)
    ldy Player0Offset   ; 3 15

    lda (Player0Ptr),y  ; 5 20
    sta GRP0            ; 3 23     
    lda (Player0Clr),y  ; 5 28
    sta COLUP0          ; 3 31 (28) <-- delayed. So we'll have to restrict
                        ;               Che's movement on the left of the
                        ;               screen?

.p0FlipPre1             ;(3 10)
                        ;  (35)
;=================================
; Preload Che Graphics for THIRD
; scanline.
;=================================

                        
    lda #P0_HEIGHT      ; 2 37
    dcp Player0Offset   ; 5 42
    bcc .p0FlipPre2     ; 2 44 (3 45)
    ldy Player0Offset   ; 3 47

    lda (Player0Ptr),y  ; 5 52
    sta CheGfxTemp      ; 3 55
    lda (Player0Clr),y  ; 5 60
    sta COLUP0          ; 3 63 (27)

.p0FlipPre2             ;(3 45)
                        ;(  63) - Longest way                      
                        
    ; Load the scanline counter
    
    ldx Heights+.BAND   ; 3 66  - This variable equals the band height - 2
    
; Prime the NUSIZ1 register with the right copies/sizing data

    lda EnvCopies+.BAND ; 3 69
    sta NUSIZ1          ; 3 72    
    

;=================================
;
; Start of the actual kernel
;
;=================================
    
.KernelLoop

    sta WSYNC           ; 3 75

;----------------------------------------------------- ENTER THIRD SCANLINE
    
;=================================
;
; Draw Che Graphics in time for left-most
; side of the screen.
;
;=================================

    lda CheGfxTemp      ; 3  3
    sta GRP0            ; 3  6
    lda EnvGfxTemp      ; 3  9
    sta GRP1            ; 3 12
    
;=================================
;
; Decrement line counter, and
; branch out if we're at zero.
;
; Even though we're using FlipDraw,
; we still need a scanline counter
; to keep track of which section
; we're in.
;
;=================================
    
    dex                ; 2 14
    beq .EndKernel     ; 2 16 (3 17)
    
;=================================
;
; Calculate Environment Graphics
;
;=================================

    lda EnvHeight+.BAND         ; 3 19
    dcp EnvGfxOffset+.BAND      ; 5 24
    bcc .p1FlipDraw             ; 2 26 (3 27)
    ldy EnvGfxOffset+.BAND      ; 2 28

    lda (EnvGfxPtr+.BAND*2),y   ; 5 33
    sta EnvGfxTemp              ; 3 36
    lda (EnvClrPtr+.BAND*2),y   ; 5 41
    sta COLUP1                  ; 3 44 (28)

.p1FlipDraw                     ;(3 27)
                                ;(  44) - Longest way
 
;=================================
;
; Calculate Che Graphics
;
;=================================

    lda #P0_HEIGHT      ; 2 46
    dcp Player0Offset   ; 5 51
    bcc .p0FlipDraw     ; 2 53 (3 54)
    ldy Player0Offset   ; 2 55

    lda (Player0Ptr),y  ; 5 60
    sta CheGfxTemp      ; 3 63
    lda (Player0Clr),y  ; 5 68
    sta COLUP0          ; 3 71 (27)

.p0FlipDraw             ;(3 54)
                        ;(  71) - Longest way
    
;=================================
;
; We branch out of the kernel at the
; beginning of the last scanline AT
; THE TOP. So if we are allowed to
; reach this part of the kernel,
; we unconditionally jump back to the
; top!
;
;=================================
        
    jmp .KernelLoop     ; 3 74
    
;=================================
; END OF THE KERNEL.
; Here we "fall into" the next band
; of the screen!
;=================================
    
.EndKernel              ; (3 17)

    ENDM

coloured_guerrilla015.asm

Edited December 19, 2017 by vidak

[vidak]

Here is the updated kernel with the proper timing.

 

The guts of the kernel are now so finely timed, I would need to completely rewrite it if I wanted to put something else in.

 

the unconditional jump back to the top of the kernel now finishes exactly as a new scanline starts.

coloured_guerrilla016.asm

[ZackAttack]

I wasn't able to build 016.asm:

 

guerrilla.asm (508): error: Value in 'cpy #PF_HEIGHT*2+2' must be <$100.

 

--- Unresolved Symbol List
EnvGfxOffset 0000 ???? (R )
--- 1 Unresolved Symbol

[JeremiahK]

I had the same issue. Since PF_HEIGHT is 192, PF_HEIGHT*2+2 = 386, which doesn't fit into 8 bits.

 

I think line 508 needs to be changed:

    cpy #PF_HEIGHT*2+2  ; Test for bottom of screen

...to this:

    cpy #PF_HEIGHT      ; Test for bottom of screen

Unless there was a reason for performing the PF_HEIGHT*2+2. Line 528 needs to be changed, as well.

 

Also, "EnvGfxOffset" is never defined, though "EnvGfxOffset0" through "EnvGfxOffset4" are defined. One thing you could do is define the first one as both "EnvGfxOffset" and "EnvGfxOffset0".

Edited December 19, 2017 by JeremiahK

[vidak]

Oh! Thanks for noticing that.

 

The code was never in a buildable state!

I'm going to try and get it to a buildable state today...

Anyway thanks so much for taking a look in any case!

[vidak]

Okay! I have prepared something which compiles.

 

This version 18 does not draw 262 scanlines. It draws between 192 exactly and 197-198.

 

I think it may have something to do with the offset of the pointers and the heights of the different sections of the bands of the kernel.

 

Take a look if you feel like it, or don't!

 

This source file definitely compiles, I just don't have enough effort today to completely debug it.

 

I suppose I like to be really verbose on this thread to show I am working through the different problems as they crop up.

 

***

Any debugging would be very appreciated.

coloured_guerrilla018.asm

[zilog_z80a]

Okay! I have prepared something which compiles.

 

This version 18 does not draw 262 scanlines. It draws between 192 exactly and 197-198.

 

I think it may have something to do with the offset of the pointers and the heights of the different sections of the bands of the kernel.

 

Take a look if you feel like it, or don't!

 

This source file definitely compiles, I just don't have enough effort today to completely debug it.

 

I suppose I like to be really verbose on this thread to show I am working through the different problems as they crop up.

 

***

Any debugging would be very appreciated.

 

hI vidak!! i'm using stella 3.5 and when running this program i just get a black screen, could be something related to my emulator?

cheers

Edited December 20, 2017 by zilog_z80a

[DirtyHairy]

 

hI vidak!! i'm using stella 3.5 and when running this program i just get a black screen, could be something related to my emulator?

 

Stella 3.5 is ancient. Please upgrade to Stella 5.0.2.

[zilog_z80a]

 

Stella 3.5 is ancient. Please upgrade to Stella 5.0.2.

 

will try this bin at work, must upgrade my desktop pc at home.

 

ty DirtyHairy.

Edited December 20, 2017 by zilog_z80a

[DirtyHairy]

 

will try this bin at work, must upgrade my desktop pc at home.

 

 

If you have a recent browser, you can also use Stellerator (see my signature). However, mind that Vidak posted assembly source; you'll have to assemble it with DASM before you can run It with any emulator.

[vidak]

I think it might have something to do with the fact this version is drawing WELL under the proper 262 scan line limit.

 

I'm glad it seemed to compile okay for you!

 

I will step through everything in the Stella debugger tomorrow.

 

I recommend you get Stella 5!

[vidak]

Okay!

I figured out why I was not drawing enough lines. I was counting the cycles in the kernel for when both GRP1 and GRP0 were being drawn. When both are drawn on a scanline, the cycles add up to 76. When neither are drawn, the unconditional JMP back up to the top of the kernel was returning at cycle 40-46, which is waaaay too early.

 

So I economised some code and forced a WSYNC at the start of each line. Now we're drawing 263 lines - much better.

 

There are still problems:

• GRP0 doesn't move properly vertically OR horizontally. Every band of the screen GRP0 moves vertically it seems to shear left when moving up, and shear right when moving down. When moving horizontally, GRP0 seems to be "glued" between horizontal bands on the screen, and oscillates between them. My best guess as to why this is happening is that the HMOVE for GRP1 seems to be interfering with the HMOVE for GRP0.
• There are strange artifacts for GRP0 occuring on every band of the screen.

***

If anyone would like to help debug, I would be very grateful! I like to post the work I finish at the end of the day here just anyone feels like they want to help out : )

guerrilla19 binary, lst and sym.zip

coloured_guerrilla019.asm

[+SpiceWare]

My best guess as to why this is happening is that the HMOVE for GRP1 seems to be interfering with the HMOVE for GRP0

From Stella Programmers Guide:

8.0 Horizontal Motion

 

Horizontal motion allows the programmer to move any of the 5 graphics objects relative to their current horizontal position. Each object has a 4 bit horizontal motion register (HMP0, HMP1, HMM0, HMM1, HMBL) that can be loaded with a value in the range of +7 to -8 (negative values are expressed in twos complement from). This motion is not executed until the HMOVE register is written to, at which time all motion registers move their respective objects. Objects can be moved repeatedly by simply executing HMOVE. Any object that is not to move must have a 0 in its motion register. With the horizontal positioning command confined to positioning objects at 15 color clock intervals, the motion registers fills in the gaps by moving objects +7 to -8 color clocks. Objects can not be placed at any color clock position across the screen. All 5 motion registers can be set to zero simultaneously by writing to the horizontal motion clear register (HMCLR).

 

There are timing constraints for the HMOVE command. The HMOVE command must immediately follow a WSYNC (Wait for SYNC) to insure the HMOVE operation occurs during horizontal blanking. This is to allow sufficient time for the motion registers to do their thing before the electron beam starts drawing the next scan line. Also, for mysterious internal hardware considerations, the motion registers should not be modified for at least 24 machine cycles after an HMOVE command.

[vidak]

Hmm... then the bizarre oscillating that GRP0 is displaying must be because the horizontal movement register for GRP0 is not zero when I set the HMOVE for GRP1.

 

That sounds like that would fix that problem.

 

I will have to do some thinking about this. I do a HMOVE for GRP1 every band, but a HMOVE for GRP0 every FRAME.

 

I suppose I better look at your Stay Frosty a bit more...

[vidak]

Oh!!! I could just write HMCLR before I position GRP1!!