| |
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....
|
| |
Laurent
Registered: Apr 2004
Posts: 40 |
Quote: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.
I believe if you started your init with SEI like it is often the case, and then only you disable the CIA, there is a risk that a CIA interrupt condition raised in between and is now pending. It will trigger the interrupt as soon as you do the CLI. Since you probably don't do the lda $dc0d in your ISR, it will retrigger indefinitely (?) |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
That makes sense! |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
So again: no SEI, no need to ack any pending CIA interrupt, as there will be none after disabling them. =) |
| |
oziphantom
Registered: Oct 2014
Posts: 490 |
I mean you expect a guy who counted the number of clocks in a line wrong, off by 1, is going to count the number of pixels a border is.. again off by 1.. |
| |
Frantic
Registered: Mar 2003
Posts: 1648 |
...and 7 * 9 = 63
I suspect a conspiracy going on here. |
| |
Golara
Account closed
Registered: Jan 2018
Posts: 212 |
Quote: I mean you expect a guy who counted the number of clocks in a line wrong, off by 1, is going to count the number of pixels a border is.. again off by 1..
What are you talking about ? The 64 and 65 cycle NTSC machines ? |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
LDX #$FF
TXS perhaps?
Most self contained code will run fine with _any_ initial stack pointer. :)
I do use that construct myself though as I like to keep things tidy.
The question could be interpreted on the edge of making the most minimal code that will still run correctly. I guess most interrupt setup uses SEI/CLI for the intent of making extra sure in some way.
And note that trying to reduce code to the optimal case will require a lot more testing to prove it works. For interrupts you need to test for race conditions. For the SP you'll need to fuzz-test your stack pointer. |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: LDX #$FF
TXS perhaps?
Most self contained code will run fine with _any_ initial stack pointer. :)
I do use that construct myself though as I like to keep things tidy.
The question could be interpreted on the edge of making the most minimal code that will still run correctly. I guess most interrupt setup uses SEI/CLI for the intent of making extra sure in some way.
And note that trying to reduce code to the optimal case will require a lot more testing to prove it works. For interrupts you need to test for race conditions. For the SP you'll need to fuzz-test your stack pointer.
The extra SEI when taking over the kernel IRQ forces you to do the bit $dc0d though. Leave both out.
Anyway, thanks for Krill's OP. Already employing it:
had:
lda #$00
sta $d017
dec $d019
pla
rti
But since I don't use sprite 0 anyway I changed to:
lda #$1
sta $d017
sta $d019
pla
rti
:D 2 cycles is 2 cycles! |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Quoting tlrMost self contained code will run fine with _any_ initial stack pointer. :) Code using the KERNAL's interrupt handler breaks with very low stack pointers, as the BRK check code prior to jumping via $0314/5 is... not good.
http://unusedino.de/ec64/technical/aay/c64/romff48.htm
Quoting tlrI guess most interrupt setup uses SEI/CLI for the intent of making extra sure in some way.
And note that trying to reduce code to the optimal case will require a lot more testing to prove it works. I have yet to see a case where no SEI with proper interrupt disabling fails and SEI with all that ack stuff before CLI doesn't. =) |
| |
oziphantom
Registered: Oct 2014
Posts: 490 |
Quoting GolaraWhat are you talking about ? The 64 and 65 cycle NTSC machines ?
Yes |
| Previous - 1 | 2 | 3 | 4 | 5 - Next |
