bogax Posted September 7, 2014 Share Posted September 7, 2014 I'm trying to write to the player data area If I look at the list file for the player color statement I see 2323 30cf .L0107 ; player8color: 2324 30cf 2325 30cf a9 02 lda #<(playerpointers+32) 2326 30d1 8d 50 10 sta DF0LOW 2327 30d4 a9 02 lda #(>(playerpointers+32)) & $0F 2328 30d6 8d 68 10 sta DF0HI 2329 30d9 a2 b8 LDX #<playercolorL0107_8 2330 30db 8e 78 10 STX DF0WRITE 2331 30de a9 61 LDA #((>playercolorL0107_ & $0f) | (((>playercolorL0107_ / 2) & $70) 2332 30e0 8d 78 10 STA DF0WRITE so I set DF0 to $61B8 and try to write some data. nothing happens. before doing that I put the content of the player color pointer into the score and sure enuff it's $61B8 Where did I go wrong? (Yes there's a lot of cruft in here and I dimmed aliases for the data fetcher stuff that're more to my liking) set kernel DPC+ set tv ntsc set optimization noinlinedata dim sco1 = score dim sco2 = score+1 dim sco3 = score+2 dim sflg = temp1 dim insv = t dim count = b dim DF0LO = DF0LOW dim DF0 = DF0LOW dim DF0W = DF0WRITE dim DF0R = DF0DATA dim DF1LO = DF1LOW dim DF1 = DF1LOW dim DF1W = DF1WRITE dim DF1R = DF1DATA rem tmp is a 16 bit temp variable dim tmp = temp4.temp3 dim tmplo = temp3 dim tmphi = temp4 rem Plpt is player pointer temp where what goes in a rem player pointer can be manipulated dim Plpt = temp2.temp1 dim Plptlo = temp1 dim Plpthi = temp2 rem P5dpalo, P5dpahi, P5cpalo, P5cpahi are the address(es) rem of the pointers to the sprite data, colors const P5dpalo = <(playerpointers+ const P5dpahi = (>(playerpointers+) & $0F const P5cpalo = <(playerpointers+26) const P5cpahi = (>(playerpointers+26)) & $0F const P5ht = 8 rem P5dlo, P5dhi, P5clo, P5chi are the addresses of the beginning of the rem sprite data and color tables from the player shape and color declarations rem these are what the pointer to the sprite shape data and pointer to the rem sprite color data get initialized to by bB const P5dlo = $60 const P5dhi = $63 const P5clo = $A1 const P5chi = $63 macro x2 asm asl {1} rol {1} + 1 end end rem ************** bank 1 ****************** bank 1 temp1 = temp1 gosub setup bank3 c = $0A player8x = 80 : player8y = 80 goto b2 bank2 rem ************** bank 2 ****************** bank 2 temp1 = temp1 b2 DF0LO = $02 : DF0HI = $02 temp3 = DF0R temp4 = DF0R gosub display_16 main sflg = (INPT4 ^ $FF) & insv & $80 : insv = INPT4 if !sflg then draw c = c + $10 DF0LO = $B8 : DF0HI = $61 DF0W = c : DF0W = c : DF0W = c : DF0W = c : DF0W = c temp3 = c : temp4 = 0 : gosub update_score draw DF0FRACINC=128: DF1FRACINC=128: DF2FRACINC=128: DF3FRACINC=128: DF4FRACINC=255 DF6FRACINC = 255 drawscreen goto main update_score sco2 = sco2 & 240 : sco3 = 0 if temp3 >= 100 then sco2 = sco2 + 1 : temp3 = temp3 - 100 if temp3 >= 100 then sco2 = sco2 + 1 : temp3 = temp3 - 100 if temp3 >= 50 then sco3 = sco3 + 80 : temp3 = temp3 - 50 if temp3 >= 30 then sco3 = sco3 + 48 : temp3 = temp3 - 30 if temp3 >= 20 then sco3 = sco3 + 32 : temp3 = temp3 - 20 if temp3 >= 10 then sco3 = sco3 + 16 : temp3 = temp3 - 10 sco3 = sco3 | temp3 sco1 = 0 : sco2 = sco2 & 15 if temp4 >= 100 then sco1 = sco1 + 16 : temp4 = temp4 - 100 if temp4 >= 100 then sco1 = sco1 + 16 : temp4 = temp4 - 100 if temp4 >= 50 then sco1 = sco1 + 5 : temp4 = temp4 - 50 if temp4 >= 30 then sco1 = sco1 + 3 : temp4 = temp4 - 30 if temp4 >= 20 then sco1 = sco1 + 2 : temp4 = temp4 - 20 if temp4 >= 10 then sco1 = sco1 + 1 : temp4 = temp4 - 10 sco2 = (temp4 * 4 * 4) | sco2 return thisbank display_16 score = 0 if temp4{7} then score = score + 32768 if temp4{6} then score = score + 16384 if temp4{5} then score = score + 8192 if temp4{4} then score = score + 4096 if temp4{3} then score = score + 2048 if temp4{2} then score = score + 1024 if temp4{1} then score = score + 512 if temp4{0} then score = score + 256 if temp3{7} then score = score + 128 if temp3{6} then score = score + 64 if temp3{5} then score = score + 32 if temp3{4} then score = score + 16 if temp3{3} then score = score + 8 if temp3{2} then score = score + 4 if temp3{1} then score = score + 2 if temp3{0} then score = score + 1 return thisbank rem ************** bank 3 ****************** bank 3 temp1 = temp1 setup scorecolors: $06 $06 $06 $06 $06 $06 $06 $06 end player8: %11111111 %11111111 %11111111 %11111111 %11111111 %11111111 %11111111 %11111111 %11111111 %11111111 %11111111 %11111111 %11111111 %11111111 %11111111 %11111111 end player8color: $0A $0A $0A $0A $0A $0A $0A $0A $0A $0A $0A $0A $0A $0A $0A $0A end return I'm using Stella 3.7.2 If I can get that working the next thing I'm going to try is jimmy the score font for hex Quote Link to comment Share on other sites More sharing options...
iesposta Posted September 7, 2014 Share Posted September 7, 2014 Maybe? You set these up and then never use them: const P5dpalo = <(playerpointers+8) const P5dpahi = (>(playerpointers+8)) & $0F const P5cpalo = <(playerpointers+26) const P5cpahi = (>(playerpointers+26)) & $0F const P5ht = 8 rem P5dlo, P5dhi, P5clo, P5chi are the addresses of the beginning of the rem sprite data and color tables from the player shape and color declarations rem these are what the pointer to the sprite shape data and pointer to the rem sprite color data get initialized to by bB const P5dlo = $60 const P5dhi = $63 const P5clo = $A1 const P5chi = $63 Quote Link to comment Share on other sites More sharing options...
bogax Posted September 8, 2014 Author Share Posted September 8, 2014 (edited) Maybe? You set these up and then never use them: const P5dpalo = <(playerpointers+8) const P5dpahi = (>(playerpointers+8)) & $0F const P5cpalo = <(playerpointers+26) const P5cpahi = (>(playerpointers+26)) & $0F const P5ht = 8 rem P5dlo, P5dhi, P5clo, P5chi are the addresses of the beginning of the rem sprite data and color tables from the player shape and color declarations rem these are what the pointer to the sprite shape data and pointer to the rem sprite color data get initialized to by bB const P5dlo = $60 const P5dhi = $63 const P5clo = $A1 const P5chi = $63 yeah that's some of the cruft I was talking about. I started out doing something else. I left it in in case I wanted to try something else again. Besides I tend to load up on that stuff "just in case" Edited September 8, 2014 by bogax Quote Link to comment Share on other sites More sharing options...
iesposta Posted September 8, 2014 Share Posted September 8, 2014 My experiments were with the PUSH command. I had a counter running and watched values get pushed through all the Playfield and through the sprites, so there is a way to address them with the data fetchers as they are in RAM. I only managed to figure out the Playfield through trial and error. I'm currently experimenting the player pointers because I want to have a console switch change the sprites and colors. I think you would first define your player. Then use the math to find the low point and the high point. Then use the fractional data fetchers to write changes. There was also something a out setting the low before the high, or setting the high before the low. That was in a ScumSoft post.. The assembly coders understand this, it's just translating into batari Basic that we can't figure out. Quote Link to comment Share on other sites More sharing options...
bogax Posted September 8, 2014 Author Share Posted September 8, 2014 My experiments were with the PUSH command. I had a counter running and watched values get pushed through all the Playfield and through the sprites, so there is a way to address them with the data fetchers as they are in RAM. I only managed to figure out the Playfield through trial and error. I'm currently experimenting the player pointers because I want to have a console switch change the sprites and colors. I think you would first define your player. Then use the math to find the low point and the high point. Then use the fractional data fetchers to write changes. There was also something a out setting the low before the high, or setting the high before the low. That was in a ScumSoft post.. The assembly coders understand this, it's just translating into batari Basic that we can't figure out. I can write a big sprite and then change the pointer to show a little at a time but you're limited that way. The way I read things you should be able rewrite the sprite using the data fetchers but I can't get it to work. (more crufty code) set kernel DPC+ set tv ntsc set optimization noinlinedata dim sco1 = score dim sco2 = score+1 dim sco3 = score+2 dim sflg = temp1 dim insv = t dim count = b dim DF0LO = DF0LOW dim DF0 = DF0LOW dim DF0W = DF0WRITE dim DF0R = DF0DATA rem tmp is a 16 bit temp variable dim tmp = temp4.temp3 dim tmplo = temp3 dim tmphi = temp4 rem Plpt is player pointer temp where what goes in a rem player pointer can be manipulated dim Plpt = temp2.temp1 dim Plptlo = temp1 dim Plpthi = temp2 rem here you supply the particulars of the sprite animation rem no_bytes is the number of bytes per sprite rem no_sprites is the number of sprites in the player declaration rem fptr is a variable to use for the number of the current sprite rem no_frames is the number of frames/drawscreens between sprite changes rem no_list is the number of entries in the sprite display list def no_bytes = 8 const no_sprites = 8 dim fptr = p const no_frames = 30 const no_list = 17 const st_ani = no_list - 1 rem P5dpalo, P5dpahi, P5cpalo, P5cpahi are the address(es) rem of the pointers to the sprite data, colors const P5dpalo = <(playerpointers+ const P5dpahi = (>(playerpointers+) & $0F const P5cpalo = <(playerpointers+26) const P5cpahi = (>(playerpointers+26)) & $0F const P5ht = 8 rem P5dlo, P5dhi, P5clo, P5chi are the addresses of the beginning of the rem sprite data and color tables from the player shape and color declarations rem these are what the pointer to the sprite shape data and pointer to the rem sprite color data get initialized to by bB const P5dlo = $60 const P5dhi = $63 const P5clo = $A1 const P5chi = $63 rem here the offsets into the sprite table (the player5 data) rem for each individual sprite and color are created rem and named for the sprites/colors const sp0 = 0 const sp1 = P5ht const sp2 = P5ht * 2 const sp3 = P5ht * 3 const sp4 = P5ht * 4 const sp5 = P5ht * 5 const sp6 = P5ht * 6 const sp7 = P5ht * 7 const sc0 = 0 const sc1 = P5ht const sc2 = P5ht * 2 const sc3 = P5ht * 3 const sc4 = P5ht * 4 const sc5 = P5ht * 5 const sc6 = P5ht * 6 const sc7 = P5ht * 7 const sc8 = P5ht * 8 const sc9 = P5ht * 9 const scA = P5ht * 10 const scB = P5ht * 11 const scC = P5ht * 12 const scD = P5ht * 13 const scE = P5ht * 14 const scF = P5ht * 15 macro x2 asm asl {1} rol {1} + 1 end end rem ************** bank 1 ****************** bank 1 temp1 = temp1 gosub setup bank3 player5height = P5ht count = no_frames player5x = 80 : player5y = 54 goto b2 bank2 rem ************** bank 2 ****************** bank 2 temp1 = temp1 b2 main sflg = (INPT4 ^ $FF) & insv & $80 : insv = INPT4 if sflg{7} then fptr = st_ani : count = no_frames : goto start if !fptr then goto draw count = count - 1 if count then draw count = no_frames fptr = fptr - 1 start NUSIZ5 = (rand & $08) ^ NUSIZ5 rem point DF0 at the player 5 sprite data pointer DF0LO = P5dpalo : DF0HI = P5dpahi rem calculate the offset into the data rem spl is a list containing offsets corresponding to rem individual sprites in the player 5 sprite definition rem eg if the list item is sp3, sp3 is 3 * 8 the number rem of the individual sprite * the sprite height rem which gets added to the base of the sprite data tmphi = 0 : tmplo = spl[fptr] Plptlo = P5dlo : Plpthi = P5dhi Plpt = Plpt + tmp rem put it in to the sprite data pointer lo byte then hi byte rem (little endian) DF0W = Plptlo : DF0W = Plpthi rem same as sprite data but for color DF0LO = P5cpalo : DF0HI = P5cpahi tmphi = 0 : tmplo = spc[fptr] Plptlo = P5clo : Plpthi = P5chi Plpt = Plpt + tmp DF0W = Plptlo : DF0W = Plpthi gosub display_16 thisbank draw DF0FRACINC=128: DF1FRACINC=128: DF2FRACINC=128: DF3FRACINC=128: DF4FRACINC=255 DF6FRACINC = 255 drawscreen goto main rem spl is the sprite display list rem spc is the sprite color data list rem an odd color value results in a reflected sprite rem the lists are in reverse order the last item is rem displayed first the first item is displayed last rem the first item in the color list should be the rem playfield background color to blank the sprite rem when the animation finishes data spc sc0, sc1, sc2, sc3, sc4, sc5, sc2, sc6, sc7, sc8, sc9, scA, scB, scC, scD, scE, scF end data spl sp0, sp7, sp5, sp6, sp2, sp7, sp5, sp3, sp1, sp7, sp6, sp5, sp4, sp3, sp2, sp1, sp0 end update_score sco2 = sco2 & 240 : sco3 = 0 if temp3 >= 100 then sco2 = sco2 + 1 : temp3 = temp3 - 100 if temp3 >= 100 then sco2 = sco2 + 1 : temp3 = temp3 - 100 if temp3 >= 50 then sco3 = sco3 + 80 : temp3 = temp3 - 50 if temp3 >= 30 then sco3 = sco3 + 48 : temp3 = temp3 - 30 if temp3 >= 20 then sco3 = sco3 + 32 : temp3 = temp3 - 20 if temp3 >= 10 then sco3 = sco3 + 16 : temp3 = temp3 - 10 sco3 = sco3 | temp3 sco1 = 0 : sco2 = sco2 & 15 if temp4 >= 100 then sco1 = sco1 + 16 : temp4 = temp4 - 100 if temp4 >= 100 then sco1 = sco1 + 16 : temp4 = temp4 - 100 if temp4 >= 50 then sco1 = sco1 + 5 : temp4 = temp4 - 50 if temp4 >= 30 then sco1 = sco1 + 3 : temp4 = temp4 - 30 if temp4 >= 20 then sco1 = sco1 + 2 : temp4 = temp4 - 20 if temp4 >= 10 then sco1 = sco1 + 1 : temp4 = temp4 - 10 sco2 = (temp4 * 4 * 4) | sco2 return display_16 score = 0 if temp2{7} then score = score + 32768 if temp2{6} then score = score + 16384 if temp2{5} then score = score + 8192 if temp2{4} then score = score + 4096 if temp2{3} then score = score + 2048 if temp2{2} then score = score + 1024 if temp2{1} then score = score + 512 if temp2{0} then score = score + 256 if temp1{7} then score = score + 128 if temp1{6} then score = score + 64 if temp1{5} then score = score + 32 if temp1{4} then score = score + 16 if temp1{3} then score = score + 8 if temp1{2} then score = score + 4 if temp1{1} then score = score + 2 if temp1{0} then score = score + 1 return rem ************** bank 3 ****************** bank 3 temp1 = temp1 setup playfield: ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ end pfcolors: $4E $4E $4E $4E $4E $4E $4E $4E $4E $4E $4E $4E $4E $4E $4E $4E $4E $4E $4E $4E $4E $4E $4E $4E $4E $4E $4E $4E $4E $4E $4E $4E $4E $4E $4E $4E $4E $4E $4E $4E $4E $4E $4E $4E $4E $4E $4E $4E $4E $4E $4E $4E $4E $4E $4E $4E $4E $4E $4E $4E $4E $4E $4E $4E $4E $4E $4E $4E $4E $4E $4E $4E $4E $4E $4E $4E $4E $4E $4E $4E $4E $4E $4E $4E $4E $4E $4E $4E end player5: %00000000 %00000000 %00011000 %00111100 %00111100 %00011000 %00000000 %00000000 %00000000 %00000000 %00111000 %01110100 %01101100 %00111000 %00000000 %00000000 %00000000 %00111100 %01101110 %01100110 %01010110 %01111010 %00111100 %00000000 %00000000 %00101100 %01101010 %01100010 %01000110 %01011010 %00110100 %00000000 %00111100 %01110110 %01101011 %10000011 %11000100 %11011011 %00110110 %00111000 %00111100 %01010110 %01101011 %11000011 %11000100 %01011011 %01100110 %00101000 %00011100 %01000010 %10000001 %10000000 %00000001 %10000001 %01000000 %00011100 %00011000 %01000010 %10000001 %00000000 %10000001 %00000000 %01000010 %00110100 end player5color: $00 $00 $00 $00 $00 $00 $00 $00 $21 $21 $21 $21 $21 $21 $21 $21 $35 $35 $35 $35 $35 $35 $35 $35 $26 $26 $26 $26 $26 $26 $26 $26 $18 $18 $18 $18 $18 $18 $18 $18 $31 $31 $31 $31 $31 $31 $31 $31 $29 $29 $29 $29 $29 $29 $29 $29 $1B $1B $1B $1B $1B $1B $1B $1B $40 $40 $40 $40 $40 $40 $40 $40 $42 $42 $42 $42 $42 $42 $42 $42 $44 $44 $44 $44 $44 $44 $44 $44 $34 $34 $34 $34 $34 $34 $34 $34 $36 $36 $36 $36 $36 $36 $36 $36 $38 $38 $38 $38 $38 $38 $38 $38 $1A $1A $1A $1A $1A $1A $1A $1A $1E $1E $1E $1E $1E $1E $1E $1E end scorecolors: $06 $06 $06 $06 $06 $06 $06 $06 end return Quote Link to comment Share on other sites More sharing options...
RevEng Posted September 8, 2014 Share Posted September 8, 2014 Ok, I haven't exercised these particular grey cells for a while, but here goes... You can't stuff arbitrary data into the virtual players, at least, not without creating pointers to that arbitrary data first. The ARM virtual player drawing routine in includes/custom/main.c wants pointers to the player data, not the data itself. Then it renders all the data from those pointers into a continuous strip for all of the on-screen virtual players, including the unique position and size fetcher data for each. Finally, the bB DPC+ 6502 kernel grabs all that simplified data from the fetchers and throws it at TIA as fast as it can. Check out this post for an example of copying player0 data to the virtual players. It can probably be used with non-player data, though I'm not aware if there are limitations for positioning the data within the rom. Probably not a problem, but the ARM limitations is where I'm weakest, having learned solely by poking around and trial-and-error. 1 Quote Link to comment Share on other sites More sharing options...
bogax Posted September 8, 2014 Author Share Posted September 8, 2014 (edited) Ok, I haven't exercised these particular grey cells for a while, but here goes... You can't stuff arbitrary data into the virtual players, at least, not without creating pointers to that arbitrary data first. The ARM virtual player drawing routine in includes/custom/main.c wants pointers to the player data, not the data itself. Then it renders all the data from those pointers into a continuous strip for all of the on-screen virtual players, including the unique position and size fetcher data for each. Finally, the bB DPC+ 6502 kernel grabs all that simplified data from the fetchers and throws it at TIA as fast as it can. Check out this post for an example of copying player0 data to the virtual players. It can probably be used with non-player data, though I'm not aware if there are limitations for positioning the data within the rom. Probably not a problem, but the ARM limitations is where I'm weakest, having learned solely by poking around and trial-and-error. I haven't read all of that thread yet but it lools to me like there you're just copying pointers around (only changing the pointers). I can do that, that works. What I was trying to do is change what the pointers are pointing to and I can't get that to work. Looking at some of the comments in the files in the includes folder it looks like it should work. edit here's an excerpt from DPCplus.h ;---------------------------------------- ; The Data Fetchers can also be used to update the contents of the 4K ; Display Data bank. Point the Data Fetcher to the data to change, ; then Write to it The Data Fetcher's pointer will be incremented AFTER ; the data is written. ; ; point Data Fetcher 1 to the sprite data ; lda #<SpriteData ; sta DF1LOW ; lda #>SpriteData ; sta DF1HI ; ; then update it ; LDA #$FF ; STA DF1WRITE ; changes data at SpriteData ; LDA #$81 ; STA DF1WRITE ; changes data at SpriteData + 1 ;---------------------------------------- Edited September 8, 2014 by bogax Quote Link to comment Share on other sites More sharing options...
RevEng Posted September 8, 2014 Share Posted September 8, 2014 The "data" they're writing in that example is the hi and low bytes pointing to the sprite data. You can modify any DPC+ queue memory - there are examples around here for how to do so for the playfield memory with push/write - but the virtual players get a single fetcher queue. Just prior to running the 6502 DPC+ kernel loop, a custom ARM function is called that copies the data pointed to by all of the virtual player pointers into that fetcher queue, at the correct heights. (assuming the virtual player isn't currently blinked off) If you want to overwrite images in that queue, you'll need to insert your code between the ARM function call and the kernel proper. And you'll need to figure out the location in the queue to push your data into, based on the player's height and y. Or alternatively, change main.c to behave how you want, and recompile main.o. 1 Quote Link to comment Share on other sites More sharing options...
bogax Posted September 8, 2014 Author Share Posted September 8, 2014 The "data" they're writing in that example is the hi and low bytes pointing to the sprite data. You can modify any DPC+ queue memory - there are examples around here for how to do so for the playfield memory with push/write - but the virtual players get a single fetcher queue. Just prior to running the 6502 DPC+ kernel loop, a custom ARM function is called that copies the data pointed to by all of the virtual player pointers into that fetcher queue, at the correct heights. (assuming the virtual player isn't currently blinked off) If you want to overwrite images in that queue, you'll need to insert your code between the ARM function call and the kernel proper. And you'll need to figure out the location in the queue to push your data into, based on the player's height and y. Or alternatively, change main.c to behave how you want, and recompile main.o. Ah, ok I think I've got it. Thanks. So is there a bit of unused RAM where you could write sprite data and point the pointers to? Perhaps if eg the queue grows up you could let the sprite data grow down and write to the top of the display data area. I suppose if it's documented any where it's in the ARM code. I could try and fill the queue and see where it runs out of space except maybe it wouldn't. Guess I'll just have to try it. Thanks again. Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted September 8, 2014 Share Posted September 8, 2014 (edited) 2323 30cf .L0107 ; player8color: 2324 30cf 2325 30cf a9 02 lda #<(playerpointers+32) 2326 30d1 8d 50 10 sta DF0LOW 2327 30d4 a9 02 lda #(>(playerpointers+32)) & $0F 2328 30d6 8d 68 10 sta DF0HI 2329 30d9 a2 b8 LDX #<playercolorL0107_8 2330 30db 8e 78 10 STX DF0WRITE 2331 30de a9 61 LDA #((>playercolorL0107_ & $0f) | (((>playercolorL0107_ / 2) & $70) 2332 30e0 8d 78 10 STA DF0WRITE so I set DF0 to $61B8 and try to write some data. nothing happens. The valid address range for DPC+ RAM is $0000 - $0FFF. $61B8 is not in that range, which means the data you're trying to change must be in ROM - and being in ROM means you can't change it anyway. When setting the address, DPC+ will AND the address with $0FFF so $61B8 is treated as address $01B8. If you install the latest version of Stella you can use the new Cartridge RAM tab in the debugger to view the contents of DPC+ RAM, which may help you see what's going on: The page of RAM (the first 2 digits of the 4 digit address) is controller by the scroller. Move it down until the page is the one you're looking for, in this case 01. See the purple arrows. The 3rd digit of the address is denoted by the row, while the 4th digit is denoted by the column. See the orange arrows. I selected $01B8, so it's the green box in the datagrid that contains 00. Edited September 8, 2014 by SpiceWare 2 Quote Link to comment Share on other sites More sharing options...
RevEng Posted September 8, 2014 Share Posted September 8, 2014 Ah, ok I think I've got it. Thanks. So is there a bit of unused RAM where you could write sprite data and point the pointers to? I guess you could try pushing the bytes of the player image onto the bB DPC+ stack, and then use its address. It's 256 of spare ARM bytes dedicated to the bB program. (its not the actual ARM or 6502 stack) Only I'm not entirely sure of the ARM address (I just know its the 7th Fetcher) but looking at SpiceWare's comments above, it's one of the pages between 0 and $1000. 1 Quote Link to comment Share on other sites More sharing options...
RevEng Posted September 8, 2014 Share Posted September 8, 2014 A small bit of info on fetcher addresses. 1 Quote Link to comment Share on other sites More sharing options...
bogax Posted September 9, 2014 Author Share Posted September 9, 2014 The valid address range for DPC+ RAM is $0000 - $0FFF. $61B8 is not in that range, which means the data you're trying to change must be in ROM - and being in ROM means you can't change it anyway. When setting the address, DPC+ will AND the address with $0FFF so $61B8 is treated as address $01B8. If you install the latest version of Stella you can use the new Cartridge RAM tab in the debugger to view the contents of DPC+ RAM, which may help you see what's going on: Screen Shot 2014-09-08 at 1.51.58 PM.png The page of RAM (the first 2 digits of the 4 digit address) is controller by the scroller. Move it down until the page is the one you're looking for, in this case 01. See the purple arrows. The 3rd digit of the address is denoted by the row, while the 4th digit is denoted by the column. See the orange arrows. I selected $01B8, so it's the green box in the datagrid that contains 00. Well thanks for that little tutorial. Unfortunately I couldn't get Stella to run last time I tryed installing it. (apparently Stella won't run without Stella.ini and I suppose you have to run Stella to create it or something ) (I haven't tryed to dope it out yet) Quote Link to comment Share on other sites More sharing options...
bogax Posted September 9, 2014 Author Share Posted September 9, 2014 The "data" they're writing in that example is the hi and low bytes pointing to the sprite data. You can modify any DPC+ queue memory - there are examples around here for how to do so for the playfield memory with push/write - but the virtual players get a single fetcher queue. Just prior to running the 6502 DPC+ kernel loop, a custom ARM function is called that copies the data pointed to by all of the virtual player pointers into that fetcher queue, at the correct heights. (assuming the virtual player isn't currently blinked off) If you want to overwrite images in that queue, you'll need to insert your code between the ARM function call and the kernel proper. And you'll need to figure out the location in the queue to push your data into, based on the player's height and y. Or alternatively, change main.c to behave how you want, and recompile main.o. If I'm reading that correctly the problem is that queueing will only take data from the pseudo-ROM space. How hard do you think it would be to include the queue? Any non-obvious (or obvious for that matter) gotchas you could mention? Quote Link to comment Share on other sites More sharing options...
RevEng Posted September 9, 2014 Share Posted September 9, 2014 Yeah, you're right. I just checked the main.c memcpy statement that's responsible for copying the virtual player data into the queue, and it uses an offset to the ROM "flashdata" area.... my_memcpy(queue+get32bitdf(3), flashdata+(RIOT[player1pointerhi+Gfxindex*2]<<+RIOT[player1pointerlo+Gfxindex*2], RIOT[player1y+Gfxindex], RIOT[player1height+Gfxindex]); So as-is, you can only pass pointers/offsets to ROM based sprites. If you were going to rewrite it to use RAM instead, you could change the "flashdata" to "queue", or give it a special test to do both. e.g. for addresses with HI byte greater than 127, use an alternate memcpy with "HI-128" and "queue". The only caution I'd give is that the ARM code space is nearly stuffed. If you do the above, you may need to comment out some other unused functionality to accommodate it. Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
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.