RevEng Posted January 15, 2020 Share Posted January 15, 2020 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. 3 Quote Link to comment Share on other sites More sharing options...
Lillapojkenpåön Posted January 15, 2020 Author Share Posted January 15, 2020 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. Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted January 25, 2020 Share Posted January 25, 2020 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 2 Quote Link to comment Share on other sites More sharing options...
Lillapojkenpåön Posted January 26, 2020 Author Share Posted January 26, 2020 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. 2 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.