Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
 Welcome to our latest new user stepz ! (Registered 2020-10-24) You are not logged in 
CSDb User Forums


Forums > C64 Coding > C-64 coding cargo cults
2020-01-14 13:33
Krill

Registered: Apr 2002
Posts: 1539
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....
 
2020-01-16 10:13
Golara

Registered: Jan 2018
Posts: 207
Quote: Quoting Golara
What 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
2020-01-16 11:04
oziphantom

Registered: Oct 2014
Posts: 409
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.
2020-01-16 13:34
Krill

Registered: Apr 2002
Posts: 1539
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.
2020-01-16 18:20
Golara

Registered: Jan 2018
Posts: 207
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
2020-01-16 19:03
Krill

Registered: Apr 2002
Posts: 1539
Quoting Golara
Cool, 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 Golara
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
It's not worth supporting in new productions, if that's what you mean.

Quoting Golara
as it also has that flicker
What do you mean? The "sparkle" issue? That isn't related to VIC-II but the chargen ROM.
2020-01-16 19:17
Golara

Registered: Jan 2018
Posts: 207
Quote: Quoting Golara
Cool, 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 Golara
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
It's not worth supporting in new productions, if that's what you mean.

Quoting Golara
as 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 ?
2020-01-17 00:37
Krill

Registered: Apr 2002
Posts: 1539
Quoting Golara
Yeah 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. =)
2020-01-17 10:38
oziphantom

Registered: Oct 2014
Posts: 409
surely this is limited to Silver Label NTSC models. Couldn't be more than 500,000 of them. 1/36th of the units.
2020-02-08 22:22
Raz

Registered: Aug 2003
Posts: 10
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
2020-02-10 06:24
ChristopherJam

Registered: Aug 2004
Posts: 1084
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
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
Sokrates
Mason/Unicess
JCH/Vibrants
Optic Freeze/G★P
Ghost/Excess
X-Raffi/X-Rated
Guests online: 116
Top Demos
1 Uncensored  (9.7)
2 Edge of Disgrace  (9.6)
3 Coma Light 13  (9.6)
4 Memento Mori  (9.6)
5 Comaland 100%  (9.6)
6 Unboxed  (9.6)
7 The Shores of Reflec..  (9.6)
8 Lunatico  (9.5)
9 Remains  (9.5)
10 C=Bit 18  (9.5)
Top onefile Demos
1 ECM Water  (9.6)
2 Crystal Gazer  (9.5)
3 Dawnfall V1.1  (9.5)
4 Smile to the Sky  (9.5)
5 Daah, Those Acid Pil..  (9.5)
6 Rewind  (9.5)
7 Postcard from Earth 2  (9.5)
8 Instinct  (9.4)
9 The Night It Snowed  (9.4)
10 Tribute to Ben - Las..  (9.4)
Top Groups
1 Booze Design  (9.4)
2 Censor Design  (9.4)
3 PriorArt  (9.4)
4 Oxyron  (9.3)
5 Triad  (9.2)
Top Graphicians
1 Mirage  (9.7)
2 Archmage  (9.7)
3 Razorback  (9.6)
4 JonEgg  (9.6)
5 Jamon  (9.6)

Home - Disclaimer
Copyright © No Name 2001-2020
Page generated in: 0.053 sec.