| |
Krill
Registered: Apr 2002
Posts: 2825 |
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....
|
| |
Golara
Account closed
Registered: Jan 2018
Posts: 212 |
Quote: Quoting GolaraWhat are you talking about ? The 64 and 65 cycle NTSC machines ?
Yes
Is there any story behind it ? Is the first VIC problematic for some screens to display or something ? I knew there are 2 VICs in NTSC but never knew the reason |
| |
oziphantom
Registered: Oct 2014
Posts: 478 |
Al stuffed up, counted the wrong number of cycles. The first C64s where thrown out the door.. then he noticed and hence fixed it so it worked properly ;) It was mentioned in one of the interview I'm pretty sure probably the one he did with Bob. |
| |
Krill
Registered: Apr 2002
Posts: 2825 |
The problems of 64-cycle per line NTSC VIC-IIs and why 64 cycles happened in the first place are explained here https://spectrum.ieee.org/ns/pdfs/commodore64_mar1985.pdf on page 54 of IEEE Spectrum, March 1985 (page 7 in the PDF).
And yet, 64-cycle NTSC C-64s aren't that rare, as the fixed VIC-II revision was rolled out only about 5 months into production. |
| |
Golara
Account closed
Registered: Jan 2018
Posts: 212 |
Quote: The problems of 64-cycle per line NTSC VIC-IIs and why 64 cycles happened in the first place are explained here https://spectrum.ieee.org/ns/pdfs/commodore64_mar1985.pdf on page 54 of IEEE Spectrum, March 1985 (page 7 in the PDF).
And yet, 64-cycle NTSC C-64s aren't that rare, as the fixed VIC-II revision was rolled out only about 5 months into production.
Cool, didn't know that. Only 5 months and you say it isn't that rare, interesting. The computer itself is not that rare maybe, but how many people use it today and have that as their only (or main) c64 ? Cuz I understand having that as a collector item, but not for "daily" use, as it also has that flicker |
| |
Krill
Registered: Apr 2002
Posts: 2825 |
Quoting GolaraCool, didn't know that. Only 5 months and you say it isn't that rare, interesting. 5 months worth of production is probably a lot of machines to be sold.
Quoting GolaraThe computer itself is not that rare maybe, but how many people use it today and have that as their only (or main) c64 ? Cuz I understand having that as a collector item, but not for "daily" use It's not worth supporting in new productions, if that's what you mean.
Quoting Golaraas it also has that flicker What do you mean? The "sparkle" issue? That isn't related to VIC-II but the chargen ROM. |
| |
Golara
Account closed
Registered: Jan 2018
Posts: 212 |
Quote: Quoting GolaraCool, didn't know that. Only 5 months and you say it isn't that rare, interesting. 5 months worth of production is probably a lot of machines to be sold.
Quoting GolaraThe computer itself is not that rare maybe, but how many people use it today and have that as their only (or main) c64 ? Cuz I understand having that as a collector item, but not for "daily" use It's not worth supporting in new productions, if that's what you mean.
Quoting Golaraas it also has that flicker What do you mean? The "sparkle" issue? That isn't related to VIC-II but the chargen ROM.
Yeah but both issues were fixed about the same time didn't it ? |
| |
Krill
Registered: Apr 2002
Posts: 2825 |
Quoting GolaraYeah but both issues were fixed about the same time didn't it ? "About" is pretty relative.
Sparkle: "The problem was fixed before Charpentier left the company in September 1982. [...] Only the first few hundred thousand units shipped with the defect."
64 cycles: "The error, which was corrected sometime after Charpentier left the company [...]"
So, there seem to be quite a few 64-cycles C64s without the sparkle bug. At least i've never noticed that problem on my Canadian model. =) |
| |
oziphantom
Registered: Oct 2014
Posts: 478 |
surely this is limited to Silver Label NTSC models. Couldn't be more than 500,000 of them. 1/36th of the units. |
| |
Raz
Account closed
Registered: Aug 2003
Posts: 16 |
Really nice discussion thread here. I have to admit, I was not aware of the just set bit 0 for ACK of IRQs. I have always done ALS $d019 out of habit.
Reading through the comments, one thing I have realized, is that I have changed my coding style somewhat, after my long break from c64 coding (and coding a lot of scientific software in "real life"): Now I think a lot about readability vs. size/speed in non time critical parts of the code. I don't shy away from doing:
LDA vic_register
AND mask
ORA things_to_set
STA vic_register
If it's just some setup code, but I certainly just do LDA/STA if it matters (and I've, btw, started to do much more timer-critical code, which was otherwise never my strong side back in the day).
Cheers
-Raz |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1370 |
Here's another one.
"You can avoid the ADSR bug by using a specific register write order, independent of instrument design"
Um, just no. You can certainly avoid breaking many well behaved instruments by not deviating from the write order they were designed for, but if you're porting instruments from a routine that used a different ordering there's a fair chance you will break them by switching to your favourite.
The advice given just seems to work because
a) many routines already use the same order.
and
b) writing register 04 after register 05 at start of note avoids changing attack just after setting the gate bit, which can be an issue if the preceding note had a long attack and you don't want to stall a fast one. (A functional HR can also avoid this issue)
The important thing is not using a register write to switch from a slow (high register value) rate to a fast one, unless you desire or can tolerate a 33ms freeze.
It makes no difference whether the rate change comes from switching the value for the current envelope phase (eg changing attack after setting gate), or from toggling the gate bit (eg setting gate to change from decay rate to attack rate). |
| Previous - 1 | 2 | 3 | 4 | 5 - Next |
