Jump to content
IGNORED

Harmony DPC+ programming


Recommended Posts

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

Link to comment
Share on other sites

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 by ScumSoft
Link to comment
Share on other sites

Indeed I will, once I get it working :P

 

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 :D

But if you want to help me make it better, then by all means let me know how I can improve it!

DPCtest.zip

Link to comment
Share on other sites

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 by ScumSoft
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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 by eshu
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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 by eshu
  • Like 1
Link to comment
Share on other sites

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 :P

 

[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 by ScumSoft
Link to comment
Share on other sites

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....

  • Like 1
Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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 by ScumSoft
Link to comment
Share on other sites

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 by SpiceWare
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 :D

DPCtest2.zip

Edited by ScumSoft
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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 by ScumSoft
Link to comment
Share on other sites

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? :D

Edited by ScumSoft
Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...