Bad, vile and meaningless: More sidplay2 from Alan's clob

HardSID driver update

The Catweasel FPGA does not directly read the HardSID protocol as I previously thought. The protocol must be translated to a different bytecode stream. Here is a description of the protocol:

The hardsid protocol is 32 bit field with 16-bit delay, 3-bit reserved area, 5-bit address and 8-bit value. The delay occurs before the write command. There is no support for read operations, or a writeless delay in the hardsid protocol (but it's always possible to write to a NOP register such as 0x19).

Playing back sound

The Catweasel contains a 1024-byte FIFO that the kernel driver loads with the protocol described above. It is possible to read the FIFO fill state from one register and thus know when to stop writing to the FIFO. The catweasel firmware triggers an interrupt when the FIFO has been over 3/4 full, and it later becomes only 1/2 full. This interrupt is used to wake the kernel thread after filling the FIFO.

It is possible to split one command stream into several SID chips, but there are some important limitations to this. Firstly, something about the system is rather slow and some extra delays are mandatory or things don't work. A typical sign of the problem is that sounds play incorrectly or filter settings go wrong or sounds go missing. This is what happens when the SID ignores a write. It seems that the catweasel must wait at least 4 cycles after each write command to the SID or suffer the consequences. So, to write a stream to two chips, the command stream must use 5 cycles per chip, 1 to write and 4 to wait before switching to the second chip.

The SID hardware manuals indicate that the write only needs to occur for one cycle. There's no indication of recovery time, although a 4-cycle recovery may be implicitly assumed due to the fact that a 6502 write operation takes 4 clocks. If that were the case, though, then I'd only need to wait for 3 cycles, I think, and on the other hand I'm not even pumping the same chip with clustered writes! I just don't know why the delay is required. It'd make most sense if only 1-cycle delay or no delay at all was required. This matter requires further investigation.

The problem with waiting 10 cycles between a chip command is that there are probably players that issue writes faster to the SID chip. For instance, to issue the following:

LDA #$41
STA #$DC04

takes only 6 cycles, and it's possible to issue several writes like this in tight sequence, and thus the driver will lag behind the emulation and needs to catch up by cutting some of the longer delays short later.

Upon hearing this, someone might mutter that a few cycles' error doesn't matter, but I assure you that it is clearly audible. You see, the SID is an analog circuit that was routinely pushed to limits, and one of the most hated things about the chip was the difficulty in getting the ADSR envelope to restart properly. There are some internal status registers that apparently take few dozen milliseconds to properly clear up, but for that duration the sound channel is mute, which is not acceptable for all songs. So, musicians have used misfeatures of the chip and the reproducible, cycle-exact nature of the C64 processor together, knowingly or not, and have built songs that are very sensitive to timing issues as result.

I had a version of this driver that spent 12 cycles and Miami Vice no longer sounded correctly due to excessive waiting! Miami Vice plays just fine with 10 cycle waits, though. However, I've got a song such as David Dunn's Elite that has never played completely correctly, so I got my work cut for me.