Some DPC+ color examples

[RevEng]

It's been a very long time since I've looked at this, but if memory serves, the virtual player pointers point to what amounts to rom, (flash) and are copied over to their vertical position in the ram queue at the beginning of each frame. Even if you updated the ram queue, the virtual sprites being copied to the ram would erase those changes just before the kernel runs.

Of course, I could be wrong. It's been a while, and much of what I knew about the DPC+ kernel was discovered by hacking it, which isn't always the most reliable source.

[Lillapojkenpåön]

15 hours ago, RevEng said:

It's been a very long time since I've looked at this, but if memory serves, the virtual player pointers point to what amounts to rom, (flash) and are copied over to their vertical position in the ram queue at the beginning of each frame. Even if you updated the ram queue, the virtual sprites being copied to the ram would erase those changes just before the kernel runs.

Of course, I could be wrong. It's been a while, and much of what I knew about the DPC+ kernel was discovered by hacking it, which isn't always the most reliable source.

So if I understand correctly, somewhere in the C code all virtual sprites colors that will appear on the current frame gets copied and placed on this page according to the virtual sprites Y position

 <P1COLOR

 (>P1COLOR) & $0F

 

 and graphics merged to

 <P1GFX

 (>P1GFX) & $0F

 

That makes sense.

I understand that it's to late to change it by then, but before that we can obviously change it, we change graphics and colors all the time in bB, that's what I want to point to ram.

 

Instead of changing colors by pointing to different tables like bB does it

    lda #<(playerpointers+18)
    sta DF0LOW
    lda #(>(playerpointers+18)) & $0F
    sta DF0HI

    LDX #<playercolorL0138_1 ;these colors will later be copied to the que
    STX DF0WRITE
    LDA #((>playercolorL0138_1) & $0f) | (((>playercolorL0138_1) / 2) & $70)
    STA DF0WRITE

 

 Have it point to dpc+ ram like the stack, since I don't think the arm can access the riot ram?

 Like this

 

    lda #<(playerpointers+18)
    sta DF0LOW
    lda #(>(playerpointers+18)) & $0F
    sta DF0HI

    LDX #<STACKbegin
    STX DF0WRITE
    LDA #(>STACKbegin) & $0F
    STA DF0WRITE

 

 then pushing colors to the stack would be easy.

 

 

 

 

[+Random Terrain]

Did you get the sprites working?

 

I finally got the 4 example programs on the bB page:

 

https://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#ex_dpc_lilla_background_change_color

 

https://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#ex_dpc_lilla_playfield_change_color

 

https://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#ex_dpc_lilla_score_change_color

 

https://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#ex_dpc_lilla_score_background_change_color

 

 

[Lillapojkenpåön]

10 hours ago, Random Terrain said:

Did you get the sprites working?

 

I finally got the 4 example programs on the bB page:

Awesome! 

Nope

The c code copies from flashdata to ram

for player 0 colors it sends pointers to these adresses to my_memcpy

 

            flashdata+(RIOT[player0color+1]<<8)+RIOT[player0color],   //source

            queue+(fetcheraddr[46]<<8)+fetcheraddr[38],    //destination

 

 

If I understood the adresses a little better and what the bit shifting does I could get it to copy from queue to queue if that's possibe, but I don't.