| |
Krill
Registered: Apr 2002
Posts: 2980 |
C-64 coding cargo cults
The most-discussed coding cargo cult on the C-64 is probably SEI/CLI around interrupt setup code.
Here's another one: acknowledging VIC raster interrupts.
According to the datasheet http://archive.6502.org/datasheets/mos_6567_vic_ii_preliminary... an active VIC interrupt is acknowledged by writing a "1" to the corresponding bit in $d019.
The usual way to achieve this seems to be "DEC $D019" and to a lesser extent other read-modify-write instructions, saving a few bytes and/or cycles compared to "LDA $D019 : STA $D019" or "LDA #$xF : STA $D019".
This works because RMW instructions on 6502/6510 read a value (here, the pending interrupts) and write the same value again (clearing the interrupt latches) before writing the modified value.
This is also why this technique does not work on SuperCPU's 65816 in native mode, as its RMW instructions lack the dummy-write of the unmodified value.
Now, the cargo cult bit is this: For raster interrupts, it suffices to write any value with bit 0 set (likewise for other VIC interrupts). Clearing all VIC interrupts can be achieved by writing any value with bits 0..3 set.
So, you can save 2 cycles by simply recycling any register value that happens to have bit 0 set, writing that one to $d019 to acknowledge a VIC raster interrupt.
Please post other coding cargo cults here. =) |
|
... 31 posts hidden. Click here to view all posts....
|
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Here's another one: X-scrolling.
With the 38-columns mode (without open sideborders), the rightmost column is never visible, regardless of XSCROLL.
Thus, hardscroll handling can safely operate on 39 columns only and ignore the final one, saving cycles in copy loops and the like.
(Bonus: Compared to the 40-columns mode, the left border is collapsed by 7 pixels and the right border by 9 pixels. With XSCROLL = 7, only 38 columns are visible.) |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: Here's another one: X-scrolling.
With the 38-columns mode (without open sideborders), the rightmost column is never visible, regardless of XSCROLL.
Thus, hardscroll handling can safely operate on 39 columns only and ignore the final one, saving cycles in copy loops and the like.
(Bonus: Compared to the 40-columns mode, the left border is collapsed by 7 pixels and the right border by 9 pixels. With XSCROLL = 7, only 38 columns are visible.)
Speaking of that. Did anyone ever give a proper explanation with the 7/9 division and not 8/8? |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Quoting JackAsserSpeaking of that. Did anyone ever give a proper explanation with the 7/9 division and not 8/8? Haven't come across one yet. My guess is that there are technical reasons, something with the internal workings of the sideborder latches vs the pixel clock vs the clocks derived from the pixel clock vs register updates.
One practical upside is that with the more common right-to-left scrolling, the second-to-rightmost column may only be updated one video frame later upon an XSCROLL wrap from 0 to 7 (at a scroll speed of 1 pixel per video frame). |
| |
Golara
Account closed
Registered: Jan 2018
Posts: 212 |
Quote: Speaking of that. Did anyone ever give a proper explanation with the 7/9 division and not 8/8?
Yeah, top border is weird too, with the screen being fully visible only at Yscroll = 3 |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Quoting GolaraYeah, top border is weird too, with the screen being fully visible only at Yscroll = 3 I guess that is to do with acceptable Y-centering of the screen, also it's 24 vs 25 char rows, so it makes sense to have the default somewhere at half a char row. Now, why the default is 3 and not 4... =) |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: Quoting JackAsserSpeaking of that. Did anyone ever give a proper explanation with the 7/9 division and not 8/8? Haven't come across one yet. My guess is that there are technical reasons, something with the internal workings of the sideborder latches vs the pixel clock vs the clocks derived from the pixel clock vs register updates.
One practical upside is that with the more common right-to-left scrolling, the second-to-rightmost column may only be updated one video frame later upon an XSCROLL wrap from 0 to 7 (at a scroll speed of 1 pixel per video frame).
Sounds reasonable that it's an effect of the pixel pipeline (that nobody described properly in text). |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Quoting JackAsserSounds reasonable that it's an effect of the pixel pipeline (that nobody described properly in text). Plus it's Commodore, so if there's a fraction of a penny to be saved, a fraction of a penny will be saved. |
| |
Perplex
Registered: Feb 2009
Posts: 255 |
Quoting Krillit's Commodore, so if there's a fraction of a penny to be saved, a fraction of a penny will be saved.
7/9 compared to 8/8, that's more than 22% saved! |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Quoting oziphantom
lda vic reg
and value
ora value
sta vic reg
there are cases where this is needed, and it should be taught this way to hammer the point of setting a bit. But 99.8% of the time you can just do lda sta
I've often seen things like "LDA #$D8 : STA $D016" or similar. That is, setting the unconnected don't-care bits to one (because they are read like that).
I prefer not to set them ($18 in this case), unless i need the don't-care bits with specific values for re-use. |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
pff any idea why I sometimes needed lda $dc0d ? iirc without that the raster irq behaved for me like never acknowledged (altho d019 ack was in) so its like the cia forces a timer interrupt endlessly. |
| Previous - 1 | 2 | 3 | 4 | 5 - Next |
