Jump to content



1

Playfield updates


1 reply to this topic

#1 SmileyDude OFFLINE  

SmileyDude

    Chopper Commander

  • 213 posts
  • 6502 Hacker
  • Location:Wilmington, MA

Posted Thu Sep 29, 2011 11:07 AM

So, I'm attempting to put together a kernel that changes PF0, PF1 and PF2 twice per line, along with setting COLUBK and COLUPF at the beginning of the line. To get a stable display, I had to move the initial setting of PF0 and PF1 to the end of the line, but that means those two fields start one line lower than the others. My source data for those registers aren't line based, but instead line mod 8 so that I can keep the blocky look I was going for.

Does anyone have any examples of something like this being done that doesn't waste a bunch of ROM space doing so? Right now, I'm basically keeping my current line index in X (because my colors are changed on a per-line basis, unlike the play field) and then dividing that down by 8 and stuffing it into Y to use as an index into my PF tables. I just don't have the time necessary to adjust Y as needed for the PF0 and PF1 update. I'm okay with using illegal opcodes, but there wasn't any that I saw that immediately struck me as being useful.

I think for now I can just go back to my old method of updating PF0 and PF1 where I had a table that had an entry for each line, but that means that I'm going to be wasting 64 bytes. Much better than before when I was wasting 6 * 32 bytes, but hoping to improve it.

Thanks!

Edited by SmileyDude, Thu Sep 29, 2011 11:07 AM.


#2 SmileyDude OFFLINE  

SmileyDude

    Chopper Commander

  • 213 posts
  • 6502 Hacker
  • Location:Wilmington, MA

Posted Sat Oct 1, 2011 10:32 PM

I managed to get this working. The key was making sure my index registers were loaded at the end of each line, but doing the actual load/stores in order from the start of the line. So I'm basically setting PF0, PF1 and PF2 just before they will be read by the TIA. Now my play field tables are 5 bytes each times 6 tables, which means I'm only spending 30 bytes to store my graphics instead of the original method I had which used around 240 or so.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users