Somehow I end up in RAM

+SpiceWare · August 19, 2019

To double up the playfield scanlines like you want, make your KernelLoop something like this (untested). The X register controls how many times each Y value is used.

    ldy #$60
    ldx #$02
KernelLoop:
    sta WSYNC
    lda $1100,y
    sta PF0
    lda $1160,y
    sta PF1
    lda $1200,y
    sta PF2
    SLEEP 20 ; try other values too, this is a guess
    lda $1260,y
    sta PF0
    lda $1300,y
    sta PF1
    lda $1360,y
    sta PF2
    dex
    bne KernelLoop
    ldx #$02
    dey
    bne KernelLoop
    rts

Mallard Games · August 22, 2019

On 8/19/2019 at 12:21 PM, SpiceWare said:
To double up the playfield scanlines like you want, make your KernelLoop something like this (untested). The X register controls how many times each Y value is used.
    ldy #$60
    ldx #$02
KernelLoop:
    sta WSYNC
    lda $1100,y
    sta PF0
    lda $1160,y
    sta PF1
    lda $1200,y
    sta PF2
    SLEEP 20 ; try other values too, this is a guess
    lda $1260,y
    sta PF0
    lda $1300,y
    sta PF1
    lda $1360,y
    sta PF2
    dex
    bne KernelLoop
    ldx #$02
    dey
    bne KernelLoop
    rts

Almost there:

Playfield.png?dl=1

I'm using Junkosoft's Playfield Editor which generates 64 bytes of playfield data. I pad the top and bottom of that data with

	.byte %00000000
	.byte %00000000
	.byte %00000000
	.byte %00000000
	.byte %00000000
	.byte %00000000
	.byte %00000000
	.byte %00000000
	.byte %00000000
	.byte %00000000
	.byte %00000000
	.byte %00000000
	.byte %00000000
	.byte %00000000
	.byte %00000000
	.byte %00000000

to get to 96 bytes of playfield data per pf_x.The editor for whatever reason doesn't generate pf2 data for the right side. Seems I am having a lot of issues with this playfield editor. Can anyone recommend any other ones that I won't have as many issues getting the generated code to work?

Binrary: https://www.dropbox.com/s/03uebn0n96qnv6z/duckgame.bin?dl=1

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

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

Edited August 22, 2019 by Mallard Games

+SpiceWare · August 22, 2019

Nice!

You can eliminate those padding bytes and save a lot of ROM by putting a WSYNC loop above and below your title screen kernel. Something like:

    ldy #32
BeforeLoop:
    sta WSYNC
    dey
    bne BeforeLoop

    ldy #96-32
    ldx #2
ScanLoop_TitleScreen
    ...
    dey
    bne ScanLoop_TitleScreen

    ldy #32
AfterLoop:
    sta WSYNC
    dey
    bne AfterLoop
    rts

Mallard Games · August 22, 2019

9 hours ago, SpiceWare said:
Nice!

You can eliminate those padding bytes and save a lot of ROM by putting a WSYNC loop above and below your title screen kernel. Something like:
    ldy #32
BeforeLoop:
    sta WSYNC
    dey
    bne BeforeLoop

    ldy #96-32
    ldx #2
ScanLoop_TitleScreen
    ...
    dey
    bne ScanLoop_TitleScreen

    ldy #32
AfterLoop:
    sta WSYNC
    dey
    bne AfterLoop
    rts

Done but now my scanline count are wrong again at 231 scanlines. Also the right side is still not working as intended but, we'll get to that in time. The other issue is I think my playfield is bleeding cause there are extraneous playfield pixels.

Playfield.png?dl=1

As always here is the latest build:

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

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

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

+SpiceWare · August 23, 2019

Adjust the delay loops as needed to get back to 262 scanlines. Remember the title screen kernel repeats everything twice, so if you removed 10 rows of 0's you need to delay a total of 20, not 10.

I noticed the extraneous pixels before, that's how the image is in your data tables.

Looking at the M and G in the lower-left:

They are drawn using this data:

I made a a minor edit using Stella to this:

and they now look correct

Mallard Games · August 23, 2019

3 hours ago, SpiceWare said:

Adjust the delay loops as needed to get back to 262 scanlines. Remember the title screen kernel repeats everything twice, so if you removed 10 rows of 0's you need to delay a total of 20, not 10.

I noticed the extraneous pixels before, that's how the image is in your data tables.

Looking at the M and G in the lower-left:

They are drawn using this data:

I made a a minor edit using Stella to this:

and they now look correct

Thanks for all the help, especially the very helpful Stella debugger tutorial. I read it, and then practice using it by fixing all the inconsistent playfield data. Well most of it at least. The broken D, N with a hole in it, and Siamese AE seem having something to have to do with the missing pf2 data that the playfield editor didn't include. Unfortunately I was working on it for so long that it got very late so I wasn't able to check the last S and date.

EDIT: Also thanks to everyone else who was very patient and helped me. I'm still learning the ropes so i'm sorry if I inadvertently frustrated you with my noobie problems. ?

Edited August 23, 2019 by Mallard Games

Mallard Games · August 24, 2019

@SpiceWareI can confirm at least based on my limited knowledge of using the Stella debugger that the rest are issues with the right side of pf2 which strangely enough is set to 0.

Folder: https://www.dropbox.com/sh/lnzuzeszgsu6flz/AABLl2llKZjm8Z9pusrXeNRKa?dl=0

+SpiceWare · August 24, 2019

On 8/19/2019 at 9:33 AM, SpiceWare said:

I'm guessing around a SLEEP 20 would do it.

The 20 was just a guess. Step thru the program with the TIA tab visible and you'll see the source of the problem:

TIA Output is in the middle of the first bit for right side PF1
Bit pattern in A is %10010000
A was just written to PF1
Bit pattern in PF1 is still %00101000
Queued Writes, there's a 2 clock delay for writes to a playfield register to take effect

After stepping one more instruction:

Bit pattern in PF1 is now %10010000
Queued Writes have been processed

So the write to PF1 occurs too late for the right side. If you change that SLEEP to 19 you'll see:

Note: it's possible you'll need to adjust the SLEEP value again when you get the data in place for PF2.

Mallard Games · August 26, 2019

On 8/24/2019 at 9:37 AM, SpiceWare said:

The 20 was just a guess. Step thru the program with the TIA tab visible and you'll see the source of the problem:

TIA Output is in the middle of the first bit for right side PF1

Bit pattern in A is %10010000

A was just written to PF1

Bit pattern in PF1 is still %00101000

Queued Writes, there's a 2 clock delay for writes to a playfield register to take effect

After stepping one more instruction:

Bit pattern in PF1 is now %10010000

Queued Writes have been processed

So the write to PF1 occurs too late for the right side. If you change that SLEEP to 19 you'll see:

Note: it's possible you'll need to adjust the SLEEP value again when you get the data in place for PF2.

@SpiceWare How do you calculate the sleep value exactly, i tried every possible combination and why i try altering the playfield in the Stella debugger the bit's don't match what is expected.

+SpiceWare · August 26, 2019

21 hours ago, Mallard Games said:

@SpiceWare How do you calculate the sleep value exactly, i tried every possible combination

I spotted two issues in the comments of your source that will lead to problems getting the critical updates done at the proper time.

1) the cycle count for WSYNC:

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

Cycle is reset to 0 after the WSYNC, not 3.

sta WSYNC         ; (3 0) Wait for the previous line to finish
lda pf0dataleft,y ; (4 4) load left pf0 data into the acumulator
sta PF0           ; (3 7) and store it

Also make sure the instruction before the stay WSYNC finished by cycle 73. If it finished on 74 or later you'll end up with an extra scanline that'll likely cause problems.

2) Putting time-critical updates in the comments like this is very smart thing to do:

sta PF2 ; (3 48) and store it (right PF2 MUST hit on cycle 48 to avoid writing too soon or too late)

However, that 48 cycle update of PF2 is only if you're using Reflected Serial Output for an asymmetrical playfield. You're using Normal Serial Output which has different critical times. These are the cycles^* I've used.

PF0L 56-21
PF1L 66-28
PF2L 0-37
PF0R 28-49
PF1R 39-54
PF2R 50-65

Those ranges are for the cycle the store instruction finishes on. Ranges for PF0L (and PF1L) look odd at first, but those just mean store should occur on or after cycle 56 (and 66) of the prior scanline and on or before cycle 21(and 28) of the current scanline.

21 hours ago, Mallard Games said:

@SpiceWare I try altering the playfield in the Stella debugger the bit's don't match what is expected.

My guess would be you're trying to alter the data for PF0 and PF1. Their output is the reverse of what you'd expect. See Step 3 of my Collect Tutorial.

^* Note it's entirely possible I'm off on a value in that list as I've not done extensive testing on the ranges.

Mallard Games · August 26, 2019

What is the difference between Reflected Serial Output and Normal Serial Output on an asymmetrical playfield?

+Karl G · August 26, 2019

14 minutes ago, Mallard Games said:

What is the difference between Reflected Serial Output and Normal Serial Output on an asymmetrical playfield?

The playfield is either repeated or mirrored regardless of whether or not it is asymmetrical. In effect, the difference is which playfield registers need to be updated when to achieve an asymmetrical playfield depending on whether the playfield is repeated or mirrored. E.g. the register update order would be PF0, PF1, PF2, PF2, PF1, PF0 for mirrored asymmetrical, and PF0, PF1, PF2, PF0, PF1, PF0 for repeated asymmetrical.

+SpiceWare · August 26, 2019

31 minutes ago, Mallard Games said:

What is the difference between Reflected Serial Output and Normal Serial Output on an asymmetrical playfield?

Terms used in the Stella Programmer's Guide, you can find a link to it in Step 1 of my tutorial.

You can see an example in Step 9 where this is Reflected:

and this is Normal:

An asymmetrical playfield means you're updating the PFx registers twice per scanline so they don't show the same image on the left and right sides of the screen.

Mallard Games · August 26, 2019

50 minutes ago, SpiceWare said:

Terms used in the Stella Programmer's Guide, you can find a link to it in Step 1 of my tutorial.

You can see an example in Step 9 where this is Reflected:

and this is Normal:

An asymmetrical playfield means you're updating the PFx registers twice per scanline so they don't show the same image on the left and right sides of the screen.

Question for SLEEP x how do i count it cycle wise? Do i use x * 2or the actual sleep time x?

+Karl G · August 27, 2019

The number passed to the sleep macro is the number of cycles, with a minimum of two.

Mallard Games · August 27, 2019

10 hours ago, SpiceWare said:
I spotted two issues in the comments of your source that will lead to problems getting the critical updates done at the proper time.

1) the cycle count for WSYNC:
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
Cycle is reset to 0 after the WSYNC, not 3.
sta WSYNC         ; (3 0) Wait for the previous line to finish
lda pf0dataleft,y ; (4 4) load left pf0 data into the acumulator
sta PF0           ; (3 7) and store it
Also make sure the instruction before the stay WSYNC finished by cycle 73. If it finished on 74 or later you'll end up with an extra scanline that'll likely cause problems.

2) Putting time-critical updates in the comments like this is very smart thing to do:
sta PF2 ; (3 48) and store it (right PF2 MUST hit on cycle 48 to avoid writing too soon or too late)
However, that 48 cycle update of PF2 is only if you're using Reflected Serial Output for an asymmetrical playfield. You're using Normal Serial Output which has different critical times. These are the cycles^* I've used.

PF0L 56-21

PF1L 66-28

PF2L 0-37

PF0R 28-49

PF1R 39-54

PF2R 50-65

Those ranges are for the cycle the store instruction finishes on. Ranges for PF0L (and PF1L) look odd at first, but those just mean store should occur on or after cycle 56 (and 66) of the prior scanline and on or before cycle 21(and 28) of the current scanline.

My guess would be you're trying to alter the data for PF0 and PF1. Their output is the reverse of what you'd expect. See Step 3 of my Collect Tutorial.

^* Note it's entirely possible I'm off on a value in that list as I've not done extensive testing on the ranges.

This is what I came up with:

	sta WSYNC								; (3 0) Wait for the previous line to finish
	SLEEP 14								; (14 14) sleep for 8 cycles
	lda pf0dataleft,y						; (4 18) load left pf0 data into the acumulator
	sta PF0									; (3 21) and store it
	lda pf1dataleft,y						; (4 25) load left pf1 data into the acumulator
	sta PF1									; (3 28) and store it
	lda pf2dataleft,y						; (4 32) load left pf2 data into the acumulator
	sta PF2									; (3 35) and store it
;	SLEEP 8									; (8 29) sleep for 8 cycles
	lda pf0dataright,y						; (4 39) load right pf0 data into the acumulator
	sta PF0									; (3 42) and store it
	lda pf1dataright,y						; (4 46) load right pf1 data into the acumulator
	sta PF1									; (3 49) and store it
	lda pf2dataright,y						; (4 53) load right pf2 data into the acumulator
	sta PF2									; (3 56) and store it (right PF2 MUST hit on cycle 48 to avoid writing too soon or too late)
	dex										; (2 58) decrement x
	bne ScanLoop_TitleScreen				; (2/3 60/61) and repeat if we're not finished with all the scanlines.
	ldx #02									; (2 62/63) decrement y
	dey										; (2 64/65) subtract one off the line counter thingy
	bne ScanLoop_TitleScreen				; (2/3 66/67) and repeat if we're not finished with all the scanlines.

M is now broken

+Andrew Davie · August 27, 2019

1 hour ago, Mallard Games said:

M is now broken

It seems that you are not really understanding what is happening, or how to fix it.

It is not a matter of putting random values of "SLEEP" in until it works. It's all about knowing exactly on what cycle you are writing to the PF registers, and exactly on what cycle ranges you are *allowed* to write to them. Or *required* to write to them. Ignore the "48" - that is a special-case if you are using reflected playfield, which in this case you most certainly should NOT be using.

I think you need to take a step back, and have a think about 76 cycles per line, start at cycle 0 just after you hit the WSYNC on each line, and then count out each cycle on every instruction so you know where the writes are happening. Compare the cycle the writes are on against the timing diagram that shows you the range of where you are "allowed" to write. Make sure they are all correctly timed. Make sure the line doesn't go over 76 cycles (including 3 for the WSYNC, if you have it)... and it should all fall into place.

Mallard Games · August 27, 2019

22 minutes ago, Andrew Davie said:

It seems that you are not really understanding what is happening, or how to fix it.

It is not a matter of putting random values of "SLEEP" in until it works. It's all about knowing exactly on what cycle you are writing to the PF registers, and exactly on what cycle ranges you are *allowed* to write to them. Or *required* to write to them. Ignore the "48" - that is a special-case if you are using reflected playfield, which in this case you most certainly should NOT be using.

I think you need to take a step back, and have a think about 76 cycles per line, start at cycle 0 just after you hit the WSYNC on each line, and then count out each cycle on every instruction so you know where the writes are happening. Compare the cycle the writes are on against the timing diagram that shows you the range of where you are "allowed" to write. Make sure they are all correctly timed. Make sure the line doesn't go over 76 cycles (including 3 for the WSYNC, if you have it)... and it should all fall into place.

12 hours ago, SpiceWare said:

PF0L 56-21

PF1L 66-28

PF2L 0-37

PF0R 28-49

PF1R 39-54

PF2R 50-65

This is what's confusing me, I'm trying to align the cycles exactly 21, 28, 37 etc.

Also I am trying to time it exactly but some of them won't line up perfectly.

	sta WSYNC								; (3 0) Wait for the previous line to finish
	SLEEP 11								; (11 14) sleep for 6 cycles
	lda pf0dataleft,y						; (4 18) load left pf0 data into the acumulator
	sta PF0									; (3 *21*) and store it
	lda pf1dataleft,y						; (4 25) load left pf1 data into the acumulator
	sta PF1									; (3 *28*) and store it
	lda pf2dataleft,y						; (4 32) load left pf2 data into the acumulator
	SLEEP 6									; (2 34) sleep for 2 cycles
	sta PF2									; (3 *37*) and store it
	SLEEP 5									; (5 42) sleep for 6 cycles
	lda pf0dataright,y						; (4 46) load right pf0 data into the acumulator
	sta PF0									; (3 *49*) and store it
	lda pf1dataright,y						; (4 53) load right pf1 data into the acumulator
	sta PF1									; (3 56 - OFF BY 2) and store it
	SLEEP 2									; (2 58) sleep for 6 cycles
	lda pf2dataright,y						; (4 62) load right pf2 data into the acumulator
	sta PF2									; (3 *65*) and store it (right PF2 MUST hit on cycle 65 to avoid writing too soon or too late)
	dex										; (2 67) decrement x
	bne ScanLoop_TitleScreen				; (2/3 69/70) and repeat if we're not finished with all the scanlines.
	ldx #02									; (2 71/72) decrement y
	dey										; (2 73/74) subtract one off the line counter thingy
	bne ScanLoop_TitleScreen				; (2/3 75/76 76/77) and repeat if we're not finished with all the scanlines.
	ldy #16									; (2 77/78 78/79) 16 scanlines of padding on the bottom

It's not possible to line pf1 right as the cycles there are very tight.

Edited August 27, 2019 by Mallard Games

+Andrew Davie · August 27, 2019

5 minutes ago, Mallard Games said:
This is what's confusing me, I'm trying to align the cycles exactly 21, 28, 37 etc.

Also I am trying to time it exactly but some of them won't line up perfectly.
	sta WSYNC								; (3 0) Wait for the previous line to finish
	SLEEP 15								; (14 14) sleep for 6 cycles
	lda pf0dataleft,y						; (4 18) load left pf0 data into the acumulator
	
It's not possible to line pf1 right as the cycles there are very tight.

Your comments are wrong, and they are only going to confuse you. Fix that up first.

The 1st line is OK

the 2nd line - should be (15 15) sleep for 15 cycles

the 3rd line - shoudl be (4 19) . ... etc

You're best to keep these comments up to date and correct all the time.

Fix those up, then report back.

Edited August 27, 2019 by Andrew Davie

Mallard Games · August 27, 2019

Just now, Andrew Davie said:

Your comments are wrong, and they are only going to confuse you. Fix that up first.

The 1st line is OK

the 2nd line - should be (15 15)

the 3rd line - shoudl be (4 19) . ... etc

You're best to keep these comments up to date and correct all the time.

Fix those up, then report back.

Sorry i updated my post while you were posting your response. I fixed the comments.

+Andrew Davie · August 27, 2019

7 minutes ago, Mallard Games said:

This is what's confusing me, I'm trying to align the cycles exactly 21, 28, 37 etc.

Also I am trying to time it exactly but some of them won't line up perfectly.


	sta WSYNC								; (3 0) Wait for the previous line to finish
	SLEEP 11								; (11 14) sleep for 6 cycles
	lda pf0dataleft,y						; (4 18) load left pf0 data into the acumulator
	sta PF0									; (3 *21*) and store it
	lda pf1dataleft,y						; (4 25) load left pf1 data into the acumulator
	sta PF1									; (3 *28*) and store it
	lda pf2dataleft,y						; (4 32) load left pf2 data into the acumulator
	SLEEP 6									; (2 34) sleep for 2 cycles
	sta PF2									; (3 *37*) and store it
	SLEEP 5									; (5 42) sleep for 6 cycles
	lda pf0dataright,y						; (4 46) load right pf0 data into the acumulator
	sta PF0									; (3 *49*) and store it
	lda pf1dataright,y						; (4 53) load right pf1 data into the acumulator
	sta PF1									; (3 56 - OFF BY 2) and store it
	SLEEP 2									; (2 58) sleep for 6 cycles
	lda pf2dataright,y						; (4 62) load right pf2 data into the acumulator
	sta PF2									; (3 *65*) and store it (right PF2 MUST hit on cycle 65 to avoid writing too soon or too late)
	dex										; (2 67) decrement x
	bne ScanLoop_TitleScreen				; (2/3 69/70) and repeat if we're not finished with all the scanlines.
	ldx #02									; (2 71/72) decrement y
	dey										; (2 73/74) subtract one off the line counter thingy
	bne ScanLoop_TitleScreen				; (2/3 75/76 76/77) and repeat if we're not finished with all the scanlines.
	ldy #16									; (2 77/78 78/79) 16 scanlines of padding on the bottom

It's not possible to line pf1 right as the cycles there are very tight.

You have a count of 2 cycles beside the SLEEP 6. That's not right.

+Andrew Davie · August 27, 2019

Please fix your comments; "ldx #02" has "decrement y" as the comment!

Some of the "SLEEP" lines have an incorrect comment about the duration of the sleep (e.g., "SLEEP 2 . ; (2 58) sleep for 6 cycles")

It's fairly pointless cycle-counting on that last line (ldy #16) as you have finished your kernel at that point and presumably just tidying up with WSYNCs etc. In any case "cycle counts" over 75 are meaningless, they just tell you you're past the scanline width and onto the next line!

See your "bne ScanLoop_TitleScreen"? That *cannot* start later than cycle 73. That's because it branches (3 cycles) back to a WSYNC (another 3 cycles) so you are waaaay overtime there. You don't really care once your last PF2 write is done - then you are just effectively waiting for the start of the next line, which is triggered by the next WSYNC. You just have to hit that WSYNC before cycle 73 on the *current* line.

Mallard Games · August 27, 2019

10 minutes ago, Andrew Davie said:

Please fix your comments; "ldx #02" has "decrement y" as the comment!

Some of the "SLEEP" lines have an incorrect comment about the duration of the sleep (e.g., "SLEEP 2 . ; (2 58) sleep for 6 cycles")

It's fairly pointless cycle-counting on that last line (ldy #16) as you have finished your kernel at that point and presumably just tidying up with WSYNCs etc. In any case "cycle counts" over 75 are meaningless, they just tell you you're past the scanline width and onto the next line!

See your "bne ScanLoop_TitleScreen"? That *cannot* start later than cycle 73. That's because it branches (3 cycles) back to a WSYNC (another 3 cycles) so you are waaaay overtime there. You don't really care once your last PF2 write is done - then you are just effectively waiting for the start of the next line, which is triggered by the next WSYNC. You just have to hit that WSYNC before cycle 73 on the *current* line.

	sta WSYNC								; (3 0) Wait for the previous line to finish
	SLEEP 11								; (11 14) sleep for 11 cycles
	lda pf0dataleft,y						; (4 18) load left pf0 data into the acumulator
	sta PF0									; (3 21) and store it
	lda pf1dataleft,y						; (4 25) load left pf1 data into the acumulator
	sta PF1									; (3 28) and store it
	SLEEP 2									; (2 30) sleep for 2 cycles
	lda pf2dataleft,y						; (4 34) load left pf2 data into the acumulator
	sta PF2									; (3 37) and store it
	SLEEP 5									; (5 42) sleep for 5 cycles
	lda pf0dataright,y						; (4 46) load right pf0 data into the acumulator
	sta PF0									; (3 49) and store it
	lda pf1dataright,y						; (4 53) load right pf1 data into the acumulator
	sta PF1									; (3 56) and store it
	SLEEP 2									; (2 58) sleep for 2 cycles
	lda pf2dataright,y						; (4 62) load right pf2 data into the acumulator
	sta PF2									; (3 65) and store it (right PF2 MUST hit on cycle 65 to avoid writing too soon or too late)
	dex										; (2 67) decrement x
	bne ScanLoop_TitleScreen				; (2/3 69/70) and repeat if we're not finished with all the scanlines.
	ldx #02									; (2 71/72) load 2 into x register
	dey										; (2 73/74) subtract one off the line counter thingy
	bne ScanLoop_TitleScreen				; (2/3 75/76 76/77) and repeat if we're not finished with all the scanlines.

Hopefully i fixed all the comments. As far as bne ScanlineLoop_Titlescreen goes I got to that count by aligning the cycles perfectly using the sleep macros and Spiceware's guide. If I remove the sleep 5 macro I should be below 73 cycles by the time I get there but, the right pf0 will hit at cycle 44 which is 5 cycles too early?

+Andrew Davie · August 27, 2019

1 minute ago, Mallard Games said:


	sta WSYNC								; (3 0) Wait for the previous line to finish
	SLEEP 11								; (11 14) sleep for 11 cycles
	lda pf0dataleft,y						; (4 18) load left pf0 data into the acumulator
	sta PF0									; (3 21) and store it
	lda pf1dataleft,y						; (4 25) load left pf1 data into the acumulator
	sta PF1									; (3 28) and store it
	SLEEP 2									; (2 30) sleep for 2 cycles
	lda pf2dataleft,y						; (4 34) load left pf2 data into the acumulator
	sta PF2									; (3 37) and store it
	SLEEP 5									; (5 42) sleep for 5 cycles
	lda pf0dataright,y						; (4 46) load right pf0 data into the acumulator
	sta PF0									; (3 49) and store it
	lda pf1dataright,y						; (4 53) load right pf1 data into the acumulator
	sta PF1									; (3 56) and store it
	SLEEP 2									; (2 58) sleep for 2 cycles
	lda pf2dataright,y						; (4 62) load right pf2 data into the acumulator
	sta PF2									; (3 65) and store it (right PF2 MUST hit on cycle 65 to avoid writing too soon or too late)
	dex										; (2 67) decrement x
	bne ScanLoop_TitleScreen				; (2/3 69/70) and repeat if we're not finished with all the scanlines.
	ldx #02									; (2 71/72) load 2 into x register
	dey										; (2 73/74) subtract one off the line counter thingy
	bne ScanLoop_TitleScreen				; (2/3 75/76 76/77) and repeat if we're not finished with all the scanlines.

Hopefully i fixed all the comments. As far as bne ScanlineLoop_Titlescreen goes I got to that count by aligning the cycles perfectly using the sleep macros and Spiceware's guide. If I remove the sleep 5 macro I should be below 73 cycles by the time I get there but, the right pf0 will hit at cycle 44 which is 5 cycles too early?

You do not care if the branch is *early*, as it goes to a WSYNC, which will then immediately halt the CPU until the start of the next scanline.

What you DO care is that the PF writes are at the correct cycle count. So, just make sure that the whole line uses 73 cycles or preferably LESS.

Now that you have counted out (hopefully correctly!) the cycles, are your PF writes happening in the correct range as specified by the timing diagram?

+Andrew Davie · August 27, 2019

According to the timing diagram, the right PF0 can be hit *anywhere* in cycle range 28 to 49, roughly. You don't care about your writes being early, you just care about them not happening while the left-side PF0 is being displayed. And the left side is being displayed during cycles 22-28 (roughly). In other words, you have all that time available to do your PF0 write, and you can even do your PF1 write as early as cycle 38(ish). Have a good look at the timing diagram - those darker shaded areas are where you CAN do the writes for the right-side registers.

Somehow I end up in RAM

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Join the conversation

Recently Browsing 0 members