SIDin #9 — Catweasel Mk4 follow-up: driver, hardware buffer, two 6581s and the filter (Stefano Tognon, 2006)

Tognon's second article on the catweasel Mk4 — a PCI card with two sid sockets — after the first one ended with "horrible" sound. He finds and patches a timing bug in Simon White's Linux driver, explains what the card's hardware buffer is for, measures how well known tunes play through his 6581, traces the missing voices of one tune to the filter with sid2midi dumps and a patched .sid, and repeats the test with a second 6581 — same result, so the fault is in the card, not the chip.

Key claims#

• Driver: two Linux kernel modules by Simon White — Head ("did not use the hardware buffer of the card (classic manage of the card)") and Experimental ("use the hardware buffer of the card (this is the best driver to use)"), to be merged. sidplay2 played "at hyper speed" while a patched VICE was right; adding debug output to libsidplay2 (which ate all the CPU) made the card "sound good". Cause found in the source: the experimental branch had "temporaly disable chip 1 timing and let it be synchronized with chip 0" — and his chip sat in socket 1. Patched, "now the sound is stable: sidplay2 plays at the right speed".
• What a SID card must do (the "hardware buffer" section): 1. clock the chip at the right PAL/NTSC speed; 2. "put a sid value in a sid register at the same time the real C64 puts it into the sid"; 3. have filter capacitors "like in C64, otherwise the filter (of the same chip) will have different behavior". The card does 1 and 3 in hardware; 2 is the problem, because each register write is an I/O operation through the PCI bus and the OS kernel, so "if the cpu is overworking … we should experiment sound timing problems". The hardware buffer takes a timed command list — "DELAY $xxxx / PUT $yy TO register $kk / DELAY $hhhh / PUT $dd TO register $ll" — produced by the player running ahead at full speed, and replays it with its own timing; only an empty buffer breaks the sound.
• How it sounded (6581 in the card): "good and horrible, depending from the tune!!" and always the same for a given tune. Ocean Loader 4 and 5 (jonathan-dunn) "almost 99% equals to the C64 listening"; Tusker (matt-gray) about 75% — timed notes: "0:20-0:24: Distortion (sound seems to go slow in one voices)", "1:35-1:44 Arpeggio is perfect, but the long sound is distorted"; last-ninja-2 "I think 40% right, the rest is horrible" — "0:06-0:20 Sound goes killed in volume in the voice that start", "1:08-1:30 Goes silent, inaudible sounds", "3:50-4:10 Goes up/down in volume" — though "the sid chip mounted in this card sound perfectly this tune is the C64 (I always test a C64 with this tune)".
• First hypothesis — the ADSR bug: the symptoms recalled his own Driller cover in Hubbard's driver, "full of ADSR bug (sound goes killed everywhere in volume)" from using Driller-like ADSR values "without a proper hardrestart"; a sidplay2 he had patched to flag ADSR-bug conditions had shown Matt Gray tunes "near the ADSR bug is some points". So: maybe tunes with hard restart play, and older ones without it hit the bug "due to a not precise timing from driver/card firmware?" (hard-restart, adsr-envelope).
• Test: xsidplay made to use the hardsid builder (swap reSidBuilder for hardsidBuilder in its wrapper — "It works perfectly"); VICE 1.18 compiled with hardsid support (Unix only, auto-detected) shows "Hardsid below Resid in the sid settings" — with the fixed driver the desktop can be used while the music plays. Quirk: pausing or quitting leaves the last note sounding on the card ("having the last note played could be very annoying"). CPU on his 266 MHz machine: xsidplay 30% with reSID (fast mode), 15% with hardsid; RSID tunes with samples still overloaded xsidplay but played in x64; Arkanoid played its samples yet "quite different" in the SID part — the hardware buffer "should give the best result with sample based music as here there are lot of volume settings per second" (chip-samples). The Head driver, retried: it detected his 6581 as an 8580 (fixed by White) and detected a chip in the empty socket 0 — because "exists two MK4 version and one like the mine did not have pull ups/downs in the bus" (fixed); it still froze the kernel.
• Analysis — Nulone (Starlost): nothing audible until 0:20, then one loud voice. sid2midi shows voices 1 and 2 starting B-1 (61 Hz) with waveform $40, ADSR 0fef/0f0e, pulse rising by 32 per frame and a low-pass cutoff sweeping $3a8 … $2e8 on filter switches 1__/12_; voice 3 (B-4, 0fe0) is unfiltered and is the voice heard. "Just change all 17 D4 to 17 E4 in the tune and test again" (redirecting the $D417 writes) — "now I listen voice 1 and 2 correctly. So the problem for this is filter related." Candidate causes listed: driver, a chip "broken in filter managing or its frequency working is out of a middle standard sid", filter jumpers (set per the manual), the card's capacitors. Matt Gray's tunes "did not make high use of filter", so the muting problem is a second issue.
• No Filter — Last Ninja 2: the dump shows no filter at all; voice 3 opens with a two-octave arpeggio F#4 377 → 1511 → 755 Hz ($10, ADSR 00a9), voices 1/2 enter at 0:03 with $40, 0f00 and a 32-per-frame pulse sweep; at 0:19 one instrument's ADSR changes (008d), later 00e0 with noise $80 — and the sound trouble starts before that. With sidplay2's console clock ("time 5 sidplay time 9") the problem begins "as soon as I'm around (real) time 5/6 seconds" when the simulated clock first slows — "could be a coincidence". An old Head driver with the chip moved to socket 0 sounds the same as the buffered driver, but costs "20% use of kernel for I/O operations (it was 1% with hardware buffer)" playing Arkanoid in x64, and notes get killed when windows are moved.
• Another 6581: the first chip, "of 84", checked in a C128 "sounds correctly" (Last Ninja 2 fine, "not so clean" — the other chip is "of 86"); in the card it shows the "Same muting/distortion problem" and "Low filter make mute the voices as the other chip" — "it is evident that there is an hardware issue regarding filter and maybe a software or hardware related issue about the muting problem". Output: the SID is mono; "chip 0 is passed into right sound card canal, while chip 1 is passed into left channel" — stereo with two chips, but one chip on one side only.
• Conclusion: a friend's Mk4 with an 8580 plays Last Ninja 2 correctly under the Windows driver, so the firmware (same version) is not the cause; Jens (Individual Computers) answered within 2 hours asking for photos and recorded samples — captured on Linux with amixer set CD cap, xsidplay through aRts and KRec, "how low is the sound volume level that come out from the sid in MK4"; White's merged driver rt_async (asynchronous stream) is "already stable", better than Head and comparable to Experimental, "even if hardware buffer gives always the best with sample music".

Practical takeaways#

• Judging a SID-on-PC card: the three conditions above — right clock, cycle-exact write timing, C64-like filter capacitors — are the checklist; a hardware command buffer is what decouples timing from the host OS.
• Diagnosing "missing voices" on unfamiliar hardware: dump the tune (sid2midi / siddump), look at which voices are routed through the filter and at what cutoff, and patch the $D417 writes out of the file to confirm — Tognon's method.
• Tunes with hard restart survived his card; tunes without it did not. Whatever the cause, the adsr-envelope bug is where imprecise register timing shows first.
• One 6581 differs from the next: a 1984 chip is "not so clean" beside a 1986 one even in a C128, and low cutoff settings that work on one C64 can go silent elsewhere (filter-programming).

Notable quotes#

"You must put a sid value in a sid register at the same time the real C64 puts it into the sid."

"Well: good and horrible, depending from the tune!!"

Relevance to the wiki#

The hardware facts for catweasel; chip-variation and filter findings for sid and filter-programming; the hardware-buffer idea and the ADSR-timing observation for sid-player-routine and hard-restart; VICE/xsidplay/sidplay2 hardsid support for vice; a hardware bullet for commodore-64.

To verify#

• (unverified) "Jens" is not given a surname; Individual Computers' owner is Jens Schönfeld — model knowledge.
• (unverified) The "17 D4 → 17 E4" patch reads as changing STA $D417 into STA $E417 (a harmless write into ROM space), which removes every filter-routing write; Tognon does not spell out the mechanism.

Pages touched#

catweasel · sid · filter-programming · hard-restart · adsr-envelope · commodore-64 · vice · sid-player-routine · chip-samples · last-ninja-2 · matt-gray · jonathan-dunn · sidin