Somehow I end up in RAM

[Nukey Shay]

BTW it appears that you are JSRing from the "jump table" (which is a confusing thing to name it)...but the idea is that you can jump to the macro which is present in all banks, have it execute the subroutine, then return to where it started.  The last step is not done.  In fact, there is no provision to check which bank it was called from to begin with.

Snippet:

InitSystem
    cmp SelectBank1                            ; bank 1
    jmp Reset                                ; inits system
PositionSprite
    cmp SelectBank3                            ; bank 3
    jsr Sub_PositionSprite                    ; positions sprite
VerticalSync
    cmp SelectBank3                            ; bank 3
    jsr Sub_VerticalSync

 

OK...let's assume you want to position a sprite from bank 1.  The code there JMP's to the PositionSprite tag (i.e. no record is kept on how to return when using JMP), the CMP selects the 3rd bank (where the subroutine exists), and then does a JSR.  After performing that task, the RTS there sends it back to where it was called...below the JSR in the 3rd bank.  So how do you get back to the bank where you started (bank 1)?  Nevermind, the program just continues on with doing the vertical sync, etc.  Proceeding right down the list of that bank's "jump table".

Edited August 10, 2019 by Nukey Shay

[Nukey Shay]

I edited some of it to include return code.  The way that this works is to read the MSB placed on the stack by the original bank's JSR (with banks ORGed to be $1000, $3000, $5000, and $7000).  By using the stack pointer, this value is read after the subroutine has executed, then rolled to a low position using LSR's and given back to the x register to use as an index for the following bankswitch.  Needless to say, this makes the jump table pretty large itself.  Might want to limit how many tags exist in the jump table.  If something is always called from a specific bank, get rid of it and just use a regular JSR.

The macro needed 2 versions (one without tags to avoid label mismatch errors).

 

I didn't reinstate any other commented-out code, tho I did fix the timing structure for the title screen PF writes (this data is also incorrect).

 

Pretty messy.

 

I'd suggest keeping each of the 4 loops (init, title, game screen, game logic) confined in their own banks or else you may go bonkers.

 

sourcehack.asm

bankswitchhack.h

Edited August 10, 2019 by Nukey Shay

[Nukey Shay]

EDIT: bankswitch macro altered to use less space

[Mallard Games]

On 8/10/2019 at 6:28 PM, Nukey Shay said:

EDIT: bankswitch macro altered to use less space

Sooooooo close well beside the titlescreen being upside down and copied which I will fix once i find the correct playfield registers to modify and flip the playfield data, the issue now is I only have 167 scanlines of a frame. I know I'm only using 96 lines of playfield data but, I'm doing the same thing for the playfield for the "game state". what would be the cause of there only being 167 scanlines?

Edited August 14, 2019 by Mallard Games

[Nukey Shay]

Because is should be more like 192 scanlines (visible).  Add more gfx or use an empty loop after your title to fill the screen.

 

After that is done, set a timer to bring it up to 262 (NTSC standard).

[+Andrew Davie]

12 hours ago, Mallard Games said:

Sooooooo close well beside the titlescreen being upside down and copied which I will fix once i find the correct playfield registers to modify and flip the playfield data, the issue now is I only have 167 scanlines of a frame. I know I'm only using 96 lines of playfield data but, I'm doing the same thing for the playfield for the "game state". what would be the cause of there only being 167 scanlines?

There aren't any registers to flip the screen vertically. You need to feed the data to the screen properly. One option is to flip your graphics data so IT is upside-down. Another is to change the direction of your index register that accesses it. It is usually more efficient to store the DATA "upside down".

[Mallard Games]

13 hours ago, Andrew Davie said:

There aren't any registers to flip the screen vertically. You need to feed the data to the screen properly. One option is to flip your graphics data so IT is upside-down. Another is to change the direction of your index register that accesses it. It is usually more efficient to store the DATA "upside down".

Ok i fliped the data and added an empty loop like you suggested. The issue now is the playfield seems to be all scrambled, with some playfield bits "faded" to put in in words.

 

Source: https://www.dropbox.com/s/r64fr0ymwjwbjp7/source.asm?dl=1

List: https://www.dropbox.com/s/15kim88ckmu65a3/duckgame.txt?dl=1

Binary: https://www.dropbox.com/s/bj4p9kqgeh7lool/duckgame.bin?dl=1

[+Andrew Davie]

I looked at the binary. It just looks to me like you don't have the timing correct on your PF writes.

Have you checked carefully against the timing diagram in the tutorials, exactly where you are doing each write in terms of cycles?

[Mallard Games]

I looked at the binary. It just looks to me like you don't have the timing correct on your PF writes.
Have you checked carefully against the timing diagram in the tutorials, exactly where you are doing each write in terms of cycles?

Actually the titlescreen playfield code was modified a bit by Nukey Shae for that exact reason. All I did was add an empty loop at the very bottom to get to 262 scanlines. Could I have fubared Nukey's code with my empty loop?

[+Andrew Davie]

9 minutes ago, Mallard Games said:

1 hour ago, Andrew Davie said:

I looked at the binary. It just looks to me like you don't have the timing correct on your PF writes.
Have you checked carefully against the timing diagram in the tutorials, exactly where you are doing each write in terms of cycles?

Actually the titlescreen playfield code was modified a bit by Nukey Shae for that exact reason. All I did was add an empty loop at the very bottom to get to 262 scanlines. Could I have fubared Nukey's code with my empty loop?

 

Possibly. Timing is sensitive to when branches have to cross a page boundary. If they do, then you add +1 to the cycle count for the branch. In display kernels, if your branch crosses a page, then you get this sort of effect. It's something you can check in the output listing.  Fix is to move code elsewhere so that it's not crossing a page

[Mallard Games]

8 hours ago, Andrew Davie said:

 

Possibly. Timing is sensitive to when branches have to cross a page boundary. If they do, then you add +1 to the cycle count for the branch. In display kernels, if your branch crosses a page, then you get this sort of effect. It's something you can check in the output listing.  Fix is to move code elsewhere so that it's not crossing a page

Nope, the issue is somewhere else:

Quote

    156  10c8               a2 05              ldx    #5
    157  10ca                   EmptyLoop
    158  10ca               ca                  dex
    159  10cb               d0 fd              bne    EmptyLoop

 

Hmmm..... will having 263 scanline instead of 262 have any effect on the playfield?

[+SpiceWare]

No, though having 263 scanlines will cause the color to become black and white on PAL consoles.  They require an even number of scanlines for the color to work correctly.

[Mallard Games]

5 hours ago, SpiceWare said:

No, though having 263 scanlines will cause the color to become black and white on PAL consoles.  They require an even number of scanlines for the color to work correctly.

What happens if when there's 270,  cause my game frames are at 270 scanlines already and I haven't added collision checking or score display yet.

[+SpiceWare]

7 minutes ago, Mallard Games said:

What happens if when there's 270,  cause my game frames are at 270 scanlines already and I haven't added collision checking or score display yet.

 

Depends on the TV, most can handle some variation from the specs but the further from 262 the greater the chance it it won't work for somebody.

 

You also need to make sure it's consist over time.  If you normally output 270, but sometimes output 271, then the screen will noticeably jitter up/down whenever the count changes.

[Mallard Games]

3 minutes ago, SpiceWare said:

 

Depends on the TV, most can handle some variation from the specs but the further from 262 the greater the chance it it won't work for somebody.

 

You also need to make sure it's consist over time.  If you normally output 270, but sometimes output 271, then the screen will noticeably jitter up/down whenever the count changes.

So I should probably work on trying to get my scanlines from 270 to 262 for the game screen.

[Nukey Shay]

First priority is to get the total scanline count consistent over time...regardless if it is 262, 270, or whatever.  This is easily checked in Stella's debugger, use the (Frame +1) button repeatedly and watch for changes in the Scn Ln values shown at top center.  Then move on to fixing it at 262.

 

As mentioned...if the count is inconsistent, a CRT television display will roll.  Newer LCD displays may blank the entire screen whenever a change occurs...or simply refuse to update the display at all.

[+Andrew Davie]

Your problem is nothing to do with scanline counts. I am almost certain it is to do with timing of the PF writes during the kernal. I will look at it tonight. Having said that, your scanline count should be consistent, whatever you choose. But it is not set in stone the exact value it has to be. PAL *usually* is set to 312 lines, and NTSC to 262. But some of my games use 276 for NTSC and that works perfectly fine.

As noted, if you have an odd number of scanlines in PAL, then PAL televisions will display in black and white.

 

Finally, you allude to having to "add stuff" and you're worried about that increasing scanline count. What you need to do is think of the overscan "wait loop" as the area where you can put stuff (above it). Basically at that point you have finished drawing to the screen and you're just waiting until the scanline gets to #262 or whatever. There is usually plenty of time in there. Or, in the vertical blank. Those INTIM wait loops are chewing up cycles doing nothing. Instead of having massive wait loops, put code before them, make sure that code doesn't take too long, and THEN do your wait loops.

Remember, they are not loops waiting for a set amount of time. They are loops waiting UNTIL a particular time.

 

[Mallard Games]

18 minutes ago, Andrew Davie said:

Your problem is nothing to do with scanline counts. I am almost certain it is to do with timing of the PF writes during the kernal. I will look at it tonight. Having said that, your scanline count should be consistent, whatever you choose. But it is not set in stone the exact value it has to be. PAL *usually* is set to 312 lines, and NTSC to 262. But some of my games use 276 for NTSC and that works perfectly fine.

As noted, if you have an odd number of scanlines in PAL, then PAL televisions will display in black and white.

 

Finally, you allude to having to "add stuff" and you're worried about that increasing scanline count. What you need to do is think of the overscan "wait loop" as the area where you can put stuff (above it). Basically at that point you have finished drawing to the screen and you're just waiting until the scanline gets to #262 or whatever. There is usually plenty of time in there. Or, in the vertical blank. Those INTIM wait loops are chewing up cycles doing nothing. Instead of having massive wait loops, put code before them, make sure that code doesn't take too long, and THEN do your wait loops.

Remember, they are not loops waiting for a set amount of time. They are loops waiting UNTIL a particular time.

 

Here is my title screen loop:

TitleScreenLoop
	jsr VerticalSync						; perform vertical sync
	jsr CheckJoystick						; check for joystick input
	jsr TitleScreen_Kernal					; jump to title screen kernal
	jsr OverScan							; (3 13) jump to OverScan Routine
	jmp TitleScreenLoop

 

Well here's the code that I'm using for the title screen kernal to draw the playfield:

TitleScreen_Kernal
WaitForVblankEnd_TitleScreen
	bit TIMINT								; load timer...
	bpl WaitForVblankEnd_TitleScreen		; killing time if the timer's not yet zero
	ldy #96									; Y is going to hold how many lines we have to do
											; ...we're going to count scanlines here. theoretically
											; since this example is ass simple, we could just repeat
											; the timer trick, but often its important to know
											; just what scan line we're at.
	sta WSYNC								; We do a WSYNC just before that so we don't turn on
	sta VBLANK								; End the VBLANK period with the zero
	;*********************** Scan line Loop
ScanLoop_TitleScreen
	sta WSYNC								; (3 3) Wait for the previous line to finish
	lda pf0dataleft,y						; (4 7) load left pf0 data into the acumulator
	sta PF0									; (3 10) and store it
	lda pf1dataleft,y						; (4 14) load left pf1 data into the acumulator
	sta PF1									; (3 17) and store it
	lda pf2dataleft,y						; (4 21) load left pf2 data into the acumulator
	sta PF2									; (3 24) and store it
	sta PF2									; (3 27) waste 3 cycles so subsequent writes do not affect left side
	lda pf0dataright,y						; (4 31) load right pf0 data into the acumulator
	sta PF0									; (3 34) and store it
	lda pf1dataright,y						; (4 38) load right pf1 data into the acumulator
	sta PF1									; (3 41) and store it
	lda pf2dataright,y						; (4 45) load right pf2 data into the acumulator
	sta PF2									; (3 48) and store it (right PF2 MUST hit on cycle 48 to avoid writing too soon or too late)
	ldx #5
EmptyLoop
	dex
	bne EmptyLoop
	dey										; (2 50) subtract one off the line counter thingy
	bne ScanLoop_TitleScreen				; (2/3 52/53) and repeat if we're not finished with all the scanlines.
	rts

The only literal change I made was these 3 instructions to pad the scanline out to 262.

	ldx #5
EmptyLoop
	dex
	bne EmptyLoop

Which is past when the playfield writes are happening anyways.

[+Andrew Davie]

Some of your playfield data tables cross page boundaries. You incur a 1 cycle hit for indexing across page boundaries, if I recall correctly, so this stuffs up your kernel timing.  When you put in your code after the kernal, you ALSO shifted those tables... triggering your problem. So where that happens (tables crossing a page), put an '    align 256' in front of the tables to make sure they start on a boundary and therefore will not cross over. 

[Mallard Games]

On 8/17/2019 at 3:33 AM, Andrew Davie said:

Some of your playfield data tables cross page boundaries. You incur a 1 cycle hit for indexing across page boundaries, if I recall correctly, so this stuffs up your kernel timing.  When you put in your code after the kernal, you ALSO shifted those tables... triggering your problem. So where that happens (tables crossing a page), put an '    align 256' in front of the tables to make sure they start on a boundary and therefore will not cross over. 

Ok, i added

	align 256

every 192 bytes(96 bytes * 2 tables) and the problem still persists. I'm running out of ideas. ?

 

Source: https://www.dropbox.com/s/f9blrfgalukm4ax/source.asm?dl=1

Listing: https://www.dropbox.com/s/nsxgenzca72ff93/duckgame.txt?dl=1

Binary: https://www.dropbox.com/s/61o9wc6dy2rl2w4/duckgame.bin?dl=1

[+Andrew Davie]

I did start to look at it from a source/assembling point of view, but you haven't included all the necessary files, so there's that.

Gimme 'bankswitch.h' please

[+Andrew Davie]

ScanLoop_TitleScreen

	sta WSYNC			       	; TIME STARTS AT 0 - WSYNC is not counted
	lda pf0dataleft,y			; 4
	sta PF0					    ; 3 @ 7        that is, the write to PF0 is completed at cycle 7
	lda pf1dataleft,y			; 4
	sta PF1					    ; 3 @ 14
	lda pf2dataleft,y			; 4
	sta PF2						; 3 @ 21
	sta PF2						; 3 @ 24
	lda pf0dataright,y			; 4
	sta PF0						; 3 @ 31
	lda pf1dataright,y			; 4
	sta PF1						; 3 @ 38
	lda pf2dataright,y			; 4
	sta PF2						; 3 @ 45

	ldx #5
EmptyLoop
	dex
	bne EmptyLoop
	dey										; (2 50) subtract one off the line counter thingy
	bne ScanLoop_TitleScreen				; (2/3 52/53) and repeat if we're not finished with all the scanlines.

 

I reworked the timings on your screen loop, so you should check those. But THEN... I got to ...

well, something weird. In the middle of your screen draw, you have a 5x loop which wastes a total of about... well it doesn't matter.

Simply get rid of that loop.... the 4 lines starting at "ldx #5".  It *looks* like you're trying to waste cycles.  But you never do this sort of thing inside a kernel draw. Firstly, at the start of your line you have "sta WSYNC". This is correct.

 

What that line does is it HALTS the CPU. And the CPU stays halted until the TIA colour clock gets to the start of the screen line.

The point is, you know that as soon as you do "sta WSYNC" you *ARE* in synch with the start of a line to be drawn. So you don't have to always count 76 cycles - you can simply do a background colour change taking 5 cycles (of the 76 on the line) and then a "sta WSYNC" and you're at the start of the next line. So, that "EmptyLoop" looks incredibly weird and dangerous. I don't think that's your actual problem.

What I think is your actual problem is the timing of the writes to the registers.

Look at the timing diagram I did in the tutorials...

 

. .

 

We want PF0 to be completely written before CPU cycle 22

YOu're at 7, so that's OK.

Then PF1 completely written before CPU cycle 28, roughly

You're at 14, no problem.

Then PF2 done before CPU cycle 39 give or take (I'm eyeballing from the diagram thumbnail)

You're at 21, again no issue.

Then you need PF0 for the right hand side... must be done before cycle 49

You're at 31 which is OK - but note it is just past the right side of the LEFT PF0 usage. Don't want to stomp the left side

Next, PF1 for the right side. It must come after the end of the LEFT PF1 (which ends at cycle 38 or so).

And it must complete before cycle 54. You're doing it over cycles 35-38 so that's perilously close to stomping the graphics on the PF1 left. Edit: of course it IS stomping on the left PF1, as the write should NOT BE STARTED before cycle 38. 

Then finally, your last PF2 for RHS. That should start no earlier than cycle 50, and complete before 65 (ish).

You're doing it around cycle 45. Whoops. You've just stomped on the PF2 on the left side of the screen.

Soooo.... I just don't think your kernel is timed out correctly.

Why not go through it like I did just above, put in some SLEEP macros (SLEEP 6 - waste 6 cycles) where necessary, and get those writes in the correct places on the scanline so they don't stomp the earlier values.

 

The other issues related to page crossings were valid problems, so it's good that you have fixed those.


I am helping you because you're doing a good job being persistent and learning stuff. It's nice when people actually listen to and follow advice.
Good luck, and keep going!

 

 

 

 

Edited August 19, 2019 by Andrew Davie

[+SpiceWare]

I used the Developer Key COMMAND-COMMA on my Mac (ALT-COMMA on others) to switch to debug color mode.  Purple is used for the playfield, with different shades for PF0, PF1, and PF2.

 

Then hit the ` key (to left of 1, above TAB) to enter the integrated debugger.

 

 

Next Right-Click in the TIA Display and select Fill to scanline

 

That will advance the program to that point in time.  Everything below is greyed out to show it's part of the prior frame.

 

That little white dot on the left edge is the current position.  If you step thru the program a few times you'll see the following:

 

 

 

So basically you're writing the playfield values for the right side of the screen before the left side has finished being drawn.  

 

Looking at this part of the program, you do sta PF2 twice in a row for some reason.  Replace the second one with a SLEEP macro to delay when the updates for the right side occur. I'm guessing around a SLEEP 20 would do it.  Also remove that ldx #$05/dex/bne loop.

[Mallard Games]

27 minutes ago, Andrew Davie said:

ScanLoop_TitleScreen

	sta WSYNC			       	; TIME STARTS AT 0 - WSYNC is not counted
	lda pf0dataleft,y			; 4
	sta PF0					    ; 3 @ 7        that is, the write to PF0 is completed at cycle 7
	lda pf1dataleft,y			; 4
	sta PF1					    ; 3 @ 14
	lda pf2dataleft,y			; 4
	sta PF2						; 3 @ 21
	sta PF2						; 3 @ 24
	lda pf0dataright,y			; 4
	sta PF0						; 3 @ 31
	lda pf1dataright,y			; 4
	sta PF1						; 3 @ 38
	lda pf2dataright,y			; 4
	sta PF2						; 3 @ 45

	ldx #5
EmptyLoop
	dex
	bne EmptyLoop
	dey										; (2 50) subtract one off the line counter thingy
	bne ScanLoop_TitleScreen				; (2/3 52/53) and repeat if we're not finished with all the scanlines.

 

I reworked the timings on your screen loop, so you should check those. But THEN... I got to ...

well, something weird. In the middle of your screen draw, you have a 5x loop which wastes a total of about... well it doesn't matter.

Simply get rid of that loop.... the 4 lines starting at "ldx #5".  It *looks* like you're trying to waste cycles.  But you never do this sort of thing inside a kernel draw. Firstly, at the start of your line you have "sta WSYNC". This is correct.

 

What that line does is it HALTS the CPU. And the CPU stays halted until the TIA colour clock gets to the start of the screen line.

The point is, you know that as soon as you do "sta WSYNC" you *ARE* in synch with the start of a line to be drawn. So you don't have to always count 76 cycles - you can simply do a background colour change taking 5 cycles (of the 76 on the line) and then a "sta WSYNC" and you're at the start of the next line. So, that "EmptyLoop" looks incredibly weird and dangerous. I don't think that's your actual problem.

What I think is your actual problem is the timing of the writes to the registers.

Look at the timing diagram I did in the tutorials...

 

. .

 

We want PF0 to be completely written before CPU cycle 22

YOu're at 7, so that's OK.

Then PF1 completely written before CPU cycle 28, roughly

You're at 14, no problem.

Then PF2 done before CPU cycle 39 give or take (I'm eyeballing from the diagram thumbnail)

You're at 21, again no issue.

Then you need PF0 for the right hand side... must be done before cycle 49

You're at 31 which is OK - but note it is just past the right side of the LEFT PF0 usage. Don't want to stomp the left side

Next, PF1 for the right side. It must come after the end of the LEFT PF1 (which ends at cycle 38 or so).

And it must complete before cycle 54. You're doing it over cycles 35-38 so that's perilously close to stomping the graphics on the PF1 left.

Then finally, your last PF2 for RHS. That should start no earlier than cycle 50, and complete before 65 (ish).

You're doing it around cycle 45. Whoops. You've just stomped on the PF2 on the left side of the screen.

Soooo.... I just don't think your kernel is timed out correctly.

Why not go through it like I did just above, put in some SLEEP macros (SLEEP 6 - waste 6 cycles) where necessary, and get those writes in the correct places on the scanline so they don't stomp the earlier values.

 

The other issues related to page crossings were valid problems, so it's good that you have fixed those.


I am helping you because you're doing a good job being persistent and learning stuff. It's nice when people actually listen to and follow advice.
Good luck, and keep going!

 

 

 

 

Here's the Bankswitch.h header sorry about that. ☹️

 

15 minutes ago, SpiceWare said:

I used the DeveloperKey COMMAND-COMMA on my Mac (ALT-COMMA on others) to switch to debug color mode.  Purple is used for the playfield, with different shades for PF0, PF1, and PF2.

 

Then hit the ` key (to left of 1, above TAB) to enter the integrated debugger.

 

 

Next Right-Click in the TIA Display and select Fill to scanline

 

Will will advance the program to that point in time.  Everything below is greyed out to show it's part of the prior frame.

 

That little white dot on the left edge is the current position.  If you step thru the program a few times you'll see the following:

 

 

 

So basically you're writing the playfield values for the right side of the screen before the left side has finished being drawn.  

 

Looking at this part of the program, you do sta PF2 twice in a row for some reason.  Replace the second one with a SLEEP macro to delay when the updates for the right side occur. I'm guessing around a SLEEP 20 would do it.  Also remove that ldx #$05/dex/bne loop.

Sooooo close, the right side of the playfield is still borked despite removing the extra loop and PF2 call. The loop at the end was to bump the scanlines from 167 to 262 so this wouldn't happen:

 

 

Notice anything weird? ?

[+SpiceWare]

2 hours ago, Mallard Games said:

Sooooo close, the right side of the playfield is still borked despite removing the extra loop and PF2 call. The loop at the end was to bump the scanlines from 167 to 262 so this wouldn't happen:

 

Notice anything weird? ?

 

 

Yes, no image.

 

 

I stepped thru the code again and the X loop is basically making each time thru the Y loop output 2 scanlines.  However, due to how the playfield works, that will automatically give you the wrong results.  Even if your timing was correct for the playfield updates you'd get the wrong visual every other scanline:

1. scanline with left and right looking correct
2. scanline with prior scanline's right side values on both the left and right side
3. scanline with left and right looking correct
4. scanline with prior scanline's right side values on both the left and right side
5. ...

 

 

I also spotted another issue with the playfield updates. You're reading from the table at 1200 for both PF2 updates.  

 

 

I did a little ROM hacking by shifting the right PF2 updates and changing the middle to use a JSR to an RTS instruction and 4 NOPs - that wastes 20 cycles, the equivalent of a SLEEP 20.



Seems like the second PF2 would be using data at 1360, so I changed that as well but turns out there's no data there.

 

 

 

 

ROM

duckgame-dgs-hack.bin