cd-w Posted April 27, 2011 Share Posted April 27, 2011 The problem is that the data fetchers can only point to bank 6, so setting DF0 to point to the TitleScreen data (in bank 5) will not work. You will need to use a pointer (e.g. lda (PTR),Y) to access the TitleScreen data, or put the TitleScreen data in bank 6 from the start. Chris Quote Link to comment Share on other sites More sharing options...
ScumSoft Posted April 27, 2011 Share Posted April 27, 2011 (edited) I see, works fine now. Thank you again. [edit] Also forgot the #< for DF0DATA as well the code I post is used for example and not what I am actually using right now. It's always changing so don't bother posting improvements to it. Just in case some of you wanted to. Edited April 27, 2011 by ScumSoft Quote Link to comment Share on other sites More sharing options...
cd-w Posted April 27, 2011 Share Posted April 27, 2011 I'm interested to see what you are working on - I hope you will post it here when it is working? Chris Quote Link to comment Share on other sites More sharing options...
ScumSoft Posted April 28, 2011 Share Posted April 28, 2011 Indeed I will, once I get it working I'm completely stumped, it's not fetching the data correctly after all I'm not sure why so I'll post it here for you all to look at. It should display "TESTING12345" on the screen, but it fetches the data in the wrong order. I stripped it down to bare bones for less confusion. It should split the test pattern into 2 ScreenRAM banks for drawing between 2 frames. I'm trying to take advantage of the Data Fetchers self advancing pointer to parse the entire set of data. If you have any questions about what it going on let me know, and I'll do my best to explain it. Also don't go stealing my kernal implementation because it's just so amazing okay But if you want to help me make it better, then by all means let me know how I can improve it! DPCtest.zip Quote Link to comment Share on other sites More sharing options...
ScumSoft Posted April 28, 2011 Share Posted April 28, 2011 (edited) Correction to the cycle times on Frame2, they were off 2 cycles and causing the video to skew a bit. ;************* ;* [FRAME 2/4] ;************* FRAME2: sta WSYNC ;[]+3 ;-PixelPos [-68], Color clock [0] dey ;[0]+2 ;Decrement scanline and compare to #0 bne .doDraw2 ;[2]+2/3 ;If more scanlines left, branch jmp OVERSCAN ;[]+3 ;EXIT PLAYFIELD KERNAL ;***CYCLE EXACT DRAW KERNAL*** .doDraw2 sleep 17 ;[5]+17 ;Cycle padding ;***Preload P0(0) and P1(0) lda #<DF2DATA ;[22]+2 Load P0(0) sta.w GRP0 ;[24]+4 Store P0(0) lda #<DF2DATA ;[28]+2 Load P1(0) sta.w GRP1 ;[30]+4 Store P1(0) ;***TIME TO DRAW! ;***Waiting for P0(0) to draw ;***Update P0 2 More times lda #<DF2DATA ;[34]+2 Load P0(1) sta.w GRP0 ;[36]+4 Draw P0(1) lda #<DF2DATA ;[40]+2 Load P0(2) sta.w GRP0 ;[42]+4 Draw P0(2) sleep 4 ;[46]+4 Padding ;***Waiting for P1(0) to draw ;***Update P1 2 More times lda #<DF2DATA ;[50]+2 Load P1(1) sta.w GRP1 ;[52]+4 Draw P1(1) lda #<DF2DATA ;[56]+2 Load P1(2) sta.w GRP1 ;[58]+4 Draw P1(2) ;***END DRAW*** jmp FRAME2 ;[62]+3 ;Will WSYNC after jump Notice how "TESTING12345" is "TEING1ST2345" Edited April 28, 2011 by ScumSoft Quote Link to comment Share on other sites More sharing options...
cd-w Posted April 28, 2011 Share Posted April 28, 2011 I haven't looked at your code yet, but it is probably a problem with timings. You know that there is a 5 color clock delay from when you hit RESPx and the actual position of the player sprite (4 for missiles)? There is also a 1 color clock delay from when you write to GRPx and the sprite data being displayed. Chris Quote Link to comment Share on other sites More sharing options...
ScumSoft Posted April 28, 2011 Share Posted April 28, 2011 Yeah look at the code and you'll see I manage this completely different than how everyone is used to It's not a timing issue in the draw kernal, it's a parsing error in either byte storage or byte retrieval I think. Quote Link to comment Share on other sites More sharing options...
eshu Posted April 28, 2011 Share Posted April 28, 2011 (edited) Correction to the cycle times on Frame2, they were off 2 cycles and causing the video to skew a bit. ;************* ;* [FRAME 2/4] ;************* FRAME2: sta WSYNC ;[]+3 ;-PixelPos [-68], Color clock [0] dey ;[0]+2 ;Decrement scanline and compare to #0 bne .doDraw2 ;[2]+2/3 ;If more scanlines left, branch jmp OVERSCAN ;[]+3 ;EXIT PLAYFIELD KERNAL ;***CYCLE EXACT DRAW KERNAL*** .doDraw2 sleep 17 ;[5]+17 ;Cycle padding ;***Preload P0(0) and P1(0) lda #<DF2DATA ;[22]+2 Load P0(0) sta.w GRP0 ;[24]+4 Store P0(0) lda #<DF2DATA ;[28]+2 Load P1(0) sta.w GRP1 ;[30]+4 Store P1(0) ;***TIME TO DRAW! ;***Waiting for P0(0) to draw ;***Update P0 2 More times lda #<DF2DATA ;[34]+2 Load P0(1) sta.w GRP0 ;[36]+4 Draw P0(1) lda #<DF2DATA ;[40]+2 Load P0(2) sta.w GRP0 ;[42]+4 Draw P0(2) sleep 4 ;[46]+4 Padding ;***Waiting for P1(0) to draw ;***Update P1 2 More times lda #<DF2DATA ;[50]+2 Load P1(1) sta.w GRP1 ;[52]+4 Draw P1(1) lda #<DF2DATA ;[56]+2 Load P1(2) sta.w GRP1 ;[58]+4 Draw P1(2) ;***END DRAW*** jmp FRAME2 ;[62]+3 ;Will WSYNC after jump Notice how "TESTING12345" is "TEING1ST2345" I might be totally wrong, but you're writing to GRP0,GRP1,GRP0,GRP0,GRP1,GRP1 - that doesn't seem right GRP0,GRP1,GRP0,GRP1,GRP0,GRP1 would be more normal.... Edited April 28, 2011 by eshu Quote Link to comment Share on other sites More sharing options...
ScumSoft Posted April 28, 2011 Share Posted April 28, 2011 I'll post a compiled binary for ease of reference. I've written a 96x192 pixel controlled playfield. The players are aligned 8 pixels apart and set to 3 copies. 01-DPCtest.bin Quote Link to comment Share on other sites More sharing options...
cd-w Posted April 28, 2011 Share Posted April 28, 2011 OK, your timings look correct, but I think the problem is the write to GRP1? If you were to write GRP0,GRP0,GRP0,GRP1,GRP1,GRP1 then it would display correctly, but since you write GRP1 before completing the writes to GRP0, you will need to reorder the data in the fetcher to compensate? Chris Quote Link to comment Share on other sites More sharing options...
eshu Posted April 28, 2011 Share Posted April 28, 2011 (edited) You've stored your data in linear order - let's say: TESTING12345 abcdefghijkl You then interleave it between the two banks, so frame 1 is: acegik And frame 2 is: bdfhjl Let A1 be the first copy of P0 and B1 be the first copy of P1 Your displaying: A1 A2 A3 B1 B2 B3 Your data is setting for the first frame: A1=a B1=c A2=e A3=g B2=i B3=k Displaying: a e g c i k The second frame: A1=b B1=d A2=f A3=h B2=j B3=l Displaying: b f h d j l So overall your displaying abefghcdijkl Referring back to: TESTING12345 abcdefghijkl You get: TEING1ST2345 You need to re-order your data - I'll see if I can come up with something.... Edited April 28, 2011 by eshu 1 Quote Link to comment Share on other sites More sharing options...
ScumSoft Posted April 28, 2011 Share Posted April 28, 2011 (edited) OH! Yes, I know exactly why it's doing this now. My original kernal I wrote used a 6-byte ram buffer and I called them back in the correct order, when it is done linearly it's causing this jumble. Thanks for the help, I can modify the parsing routine to adjust the bytes appropriately. Ok time to get some sleep, been up all night pondering over this [edit]The original code looked like this: ;Preload P0(0) and P1(0) lda GFXbuffer+0 ;[23]+3 Load P0(0) sta GRP0 ;[26]+3 Store P0(0) lda GFXbuffer+3 ;[29]+3 Load P1(0) sta GRP1 ;[32]+3 Store P1(0) ;***2 Cyc.left of HB, TIME TO DRAW!*** ;***Wait for P0(0) to draw*** ;Update P0 2 More times lda GFXbuffer+1 ;[35]+3 Load P0(1) sta GRP0 ;[38]+3 Draw P0(1) lda GFXbuffer+2 ;[41]+3 Load P0(2) sta GRP0 ;[44]+3 DRAW P0(2) stx.w GRP0 ;[47]+4 Clear GRP0 ;***Wait for P1(0) to draw*** ;Update P1 2 More times lda GFXbuffer+4 ;[51]+3 Load P1(1) sta GRP1 ;[54]+3 Draw P1(1) lda GFXbuffer+5 ;[57]+3 Load P1(2) sta GRP1 ;[60]+3 Draw P1(2) ;***FINISHED DRAWING*** stx.w GRP1 ;[63]+4 ;Clear GRP1 Edited April 28, 2011 by ScumSoft Quote Link to comment Share on other sites More sharing options...
eshu Posted April 28, 2011 Share Posted April 28, 2011 I see, its very odd though as it should be: Read linear data from bank 6: 1,2,3,4,5,6,7,8,9,10,11,12 Store odd numbers in ScreenRAM1: 1,3,5,7,9,11 Store even numbers in ScreenRAM2: 2,4,6,8,10,12 Display ScreenRAM1 on frame 1: P0(0)=1, P0(1)=3, P0(2)=5, P1(0)=7, P1(1)=9, P1(2)=11 and, with Frame2 interleaved inbetween frame1's data: Display ScreenRAM2 on frame 2: P0(0)=2, P0(1)=4, P0(2)=6, P1(0)=8, P1(1)=10, P1(2)=12 This is how it should work if the banks are read back linearly as well. Which is why I separated them into two banks to begin with, to make the draw kernal reads linear as well. But the draw kernel doesn't read and store linear - you have: lda #<DF1DATA ;[18]+2 Load P0(0) ;[18] <-Cycles we need to be at sta.w GRP0 ;[20]+4 Store P0(0) ;[21] lda #<DF1DATA ;[24]+2 Load P1(0) ;[24] sta.w GRP1 ;[26]+4 Store P1(0) ;[27] ;***TIME TO DRAW! ;***Waiting for P0(0) to draw ;***Update P0 2 More times lda #<DF1DATA ;[30]+2 Load P0(1) ;[30] sta.w GRP0 ;[32]+4 Draw P0(1) ;[33] lda #<DF1DATA ;[36]+2 Load P0(2) ;[36] sta.w GRP0 ;[38]+4 Draw P0(2) ;[39] sleep 4 ;[42]+4 Padding ;[42] ;***Waiting for P1(0) to draw ;***Update P1 2 More times lda #<DF1DATA ;[46]+2 Load P1(1) ;[46] sta.w GRP1 ;[48]+4 Draw P1(1) ;[49] lda #<DF1DATA ;[52]+2 Load P1(2) ;[52] sta.w GRP1 ;[54]+4 Draw P1(2) ;[55] So it's reading and storing in the order P0(0),P1(0),P0(1),P0(2),P1(1),P1(2). You could re-order the data with something like: ldy #192 ;Wont index past 149 properly, GFX corruption occurs .fillRAMa lda #<DF0DATA ;Load byte from DF0 sta DF1WRITE ;Store in DF1 lda #<DF0DATA ;Load byte from DF0 sta DF2WRITE ;Store in DF2 ldx #<DF0DATA lda #<DF0DATA sta TMP1 lda #<DF0DATA sta TMP2 lda #<DF0DATA sta TMP3 lda #<DF0DATA sta DF1WRITE lda #<DF0DATA sta DF2WRITE stx DF1WRITE lda TMP1 sta DF2WRITE lda TMP2 sta DF1WRITE lda TMP3 sta DF2WRITE lda #<DF0DATA sta DF1WRITE lda #<DF0DATA sta DF2WRITE lda #<DF0DATA sta DF1WRITE lda #<DF0DATA sta DF2WRITE dey bne .fillRAMa Which uses 3 bytes for temporary storage - or rewrite the draw kernel - I think you might be better to rewrite the kernel to be honest, you'll probably want the cycles back from those sta.w's later anyway.... 1 Quote Link to comment Share on other sites More sharing options...
ScumSoft Posted April 28, 2011 Share Posted April 28, 2011 Not really, those extra cycles don't matter as that is all the drawing that needs done. Unless there is a way to cram more P0 and P1's into the scanline that would expand the drawing field. I do appreciate the assistance once again. Quote Link to comment Share on other sites More sharing options...
eshu Posted April 28, 2011 Share Posted April 28, 2011 Not really, those extra cycles don't matter as that is all the drawing that needs done. Unless there is a way to cram more P0 and P1's into the scanline that would expand the drawing field. I do appreciate the assistance once again. There probably is a way to cram more P0's and P1's, but not in an even layout - you can either strobe RESP0 and/or RESP1 (see this thread 32 chars for more details) or change NUSIZ0/1 during the scanline. Changing NUSIZ let's you have a fourth copy so you could have something like: X-X-X-Y-Y-Y---Y A-A-A-B-B-B---B Where X and Y are P0 and P1 on frame 1 and A and B are P0 and P1 on frame 2 - might be usefull for a status display or something? Quote Link to comment Share on other sites More sharing options...
ScumSoft Posted April 29, 2011 Share Posted April 29, 2011 Okay, I rewrote the display kernal to update in a linear fashion (needed to start thinking DPC+ style) and it looks correct now. However I still have that display corruption issue past scanline 190(stella counts vsync+vblank), so it starts on Playfield Scanline 153 to 192. This would place it at pointer offset #1836, so this is 468 bytes that aren't being parsed correctly. 00-DPCtest.zip Quote Link to comment Share on other sites More sharing options...
ScumSoft Posted May 2, 2011 Share Posted May 2, 2011 (edited) I got everything looking good in stella, but on the real harmony cart everything gets wonky. I think the pointers are addressing the wrong ram space. ;******************************** ; [*GRAPHICS ONLY* BANK 6] ;******************************** ORG $6000 RORG $0000 ScreenRAM1: ;***[1152 bytes]*** ds 1152 ScreenRAM2: ;***[1152 bytes]*** ds 1152 Space ds 2816 ;- ;BANK 6 100% full I have a pointer setup to access both ScreenRAMs and this works correct in stella, but on the real deal the graphics are restricted to the top of the screen and drawn out of order. What's going on? I'll check this thread after I wake up (bed time) so forgive me if there is a long delay in my reply. I believe all you need to know is that my pointers are set to index from $0000 to $0900, so unless the Harmony cart is placing this someplace else, it should work the same as stella. [edit]Almost forgot to mention that I make this demo draw random data(deliberately) with the joystick on my 96x192 pixel playfield. DPCtest5-2-11.zip Edited May 2, 2011 by ScumSoft Quote Link to comment Share on other sites More sharing options...
cd-w Posted May 2, 2011 Share Posted May 2, 2011 You will need to give the file a .CU (custom binary) file extension for the Harmony. Also, have you appended the DPC+ ARM file to the beginning? Chris Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted May 2, 2011 Author Share Posted May 2, 2011 (edited) I see the same problem here, though it's hard to say what's going on w/out source to look at. .CU isn't required, Harmony has auto detected all the DPC+ ROMs I've worked on. Edited May 2, 2011 by SpiceWare Quote Link to comment Share on other sites More sharing options...
+batari Posted May 2, 2011 Share Posted May 2, 2011 I see the same problem here, though it's hard to say what's going on w/out source to look at. .CU isn't required, Harmony has auto detected all the DPC+ ROMs I've worked on. Yes, DPC+ binaries contain a certain signature (IIRC, the word 0x10adab1e - aka "loadable" which I believe is at location 0x0020) and this automatically treats them as "custom" bankswitching so no .CU extension should normally be necessary. Quote Link to comment Share on other sites More sharing options...
ScumSoft Posted May 2, 2011 Share Posted May 2, 2011 (edited) Ok here is the source, I think the Harmony cart is relocating the ScreenRAM offsets. I can't watch the ram on the real thing so it's hard to tell how the pointers are behaving. It seems to index correctly going down till scanline 44, but then it wraps over to a different offset address. I am still working on a better way to calculate the pointer logic, so if it looks noobish, thats because it is DPCtest2.zip Edited May 2, 2011 by ScumSoft Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted May 3, 2011 Author Share Posted May 3, 2011 Looks like the order of setting DFxLOW and DFxHI matters on the hardware, but not in Stella. Your debug draw routine set HI first, I changed it to this and it fixed the problem. ;DEBUG DRAW TEST lda GENpoint sta DF0LOW lda GENpoint+1 sta DF0HI lda RANDOM0NEXT ;Random sta DF0WRITE Quote Link to comment Share on other sites More sharing options...
ScumSoft Posted May 3, 2011 Share Posted May 3, 2011 (edited) Oh thats an odd issue, I just have a habit of setting HI then LOW with all my pointers. One Caveat noted! Thanks for the help as always. [edit]Out of curiosity, how did you manage to identify this being the problem? I'd love to advance my debugging abilities. Edited May 3, 2011 by ScumSoft Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted May 4, 2011 Author Share Posted May 4, 2011 No problem. I just compared it with the sample code I posted and noticed the order was different. Quote Link to comment Share on other sites More sharing options...
ScumSoft Posted May 4, 2011 Share Posted May 4, 2011 (edited) I believe this question falls in the realm of ARM programming, but can the DPC+ be told to work on the internals of bank6 while the CPU does other things? Such as rotate a region/entire screen buffer for smooth scrolling? I read somewhere around here that while ARM code is being ran, it sends NOP's to the 6507. But this would still finish in a reasonable amount of cycles correct? seeing as the ARM runs at around 70mhz. Sorry that I am filling this thread with my own questions and issues. Should I post these in my coding tricks thread and rename it to Coding Questions? Edited May 4, 2011 by ScumSoft 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.