+SpiceWare Posted August 19, 2019 Share Posted 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 Quote Link to comment Share on other sites More sharing options...
Mallard Games Posted August 22, 2019 Author Share Posted August 22, 2019 (edited) 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: 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 pfx. 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 1 Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted August 22, 2019 Share Posted 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 Quote Link to comment Share on other sites More sharing options...
Mallard Games Posted August 22, 2019 Author Share Posted 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. 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 Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted August 23, 2019 Share Posted 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 Quote Link to comment Share on other sites More sharing options...
Mallard Games Posted August 23, 2019 Author Share Posted August 23, 2019 (edited) 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 1 Quote Link to comment Share on other sites More sharing options...
Mallard Games Posted August 24, 2019 Author Share Posted 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 Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted August 24, 2019 Share Posted 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. Quote Link to comment Share on other sites More sharing options...
Mallard Games Posted August 26, 2019 Author Share Posted 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. Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted August 26, 2019 Share Posted 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. Quote Link to comment Share on other sites More sharing options...
Mallard Games Posted August 26, 2019 Author Share Posted August 26, 2019 What is the difference between Reflected Serial Output and Normal Serial Output on an asymmetrical playfield? Quote Link to comment Share on other sites More sharing options...
+Karl G Posted August 26, 2019 Share Posted 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. 1 Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted August 26, 2019 Share Posted 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. Quote Link to comment Share on other sites More sharing options...
Mallard Games Posted August 26, 2019 Author Share Posted 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 * 2 or the actual sleep time x? Quote Link to comment Share on other sites More sharing options...
+Karl G Posted August 27, 2019 Share Posted August 27, 2019 The number passed to the sleep macro is the number of cycles, with a minimum of two. 1 Quote Link to comment Share on other sites More sharing options...
Mallard Games Posted August 27, 2019 Author Share Posted 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 Quote Link to comment Share on other sites More sharing options...
+Andrew Davie Posted August 27, 2019 Share Posted 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. Quote Link to comment Share on other sites More sharing options...
Mallard Games Posted August 27, 2019 Author Share Posted August 27, 2019 (edited) 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 Quote Link to comment Share on other sites More sharing options...
+Andrew Davie Posted August 27, 2019 Share Posted August 27, 2019 (edited) 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 Quote Link to comment Share on other sites More sharing options...
Mallard Games Posted August 27, 2019 Author Share Posted 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. Quote Link to comment Share on other sites More sharing options...
+Andrew Davie Posted August 27, 2019 Share Posted 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. Quote Link to comment Share on other sites More sharing options...
+Andrew Davie Posted August 27, 2019 Share Posted 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. Quote Link to comment Share on other sites More sharing options...
Mallard Games Posted August 27, 2019 Author Share Posted 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? Quote Link to comment Share on other sites More sharing options...
+Andrew Davie Posted August 27, 2019 Share Posted 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? Quote Link to comment Share on other sites More sharing options...
+Andrew Davie Posted August 27, 2019 Share Posted 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. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.