| |
Sasq
Registered: Apr 2004
Posts: 156 |
SID streaming
I am experimenting with recording SID writes from Vice and replaying them as a stream, and so the question on how to compress the stream comes up.
The naive way is to record value (8bits), sid offset (5 bits) and cycle delta (~16bits). This can then be compressed in various ways.
But I am more interested in the assumptions you can make because of how the SID-chip works. With writes can you reorder for instance? Is there in fact a safe fixed order you can used for single speed songs?
Also is there writes you can skip which have no effect? |
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
i'd have individual streams for all registers, and then apply a combination of delta- and RLE encoding on them.
as for the order, unless you are dealing with some very old tunes (who sometimes do odd stuff like writing several times to the same register in one frame) you should copy your buffer into the SID registers in reverse order.... see eg goattracker instructions. |
| |
Sasq
Registered: Apr 2004
Posts: 156 |
Also, which registers are safe to not update if the same value is written to then?
@groepaz separate streams would be problematic as most registers do not need writing every frame. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
its not a problem at all, if you delta pack them (infact, its an advantage)
also i wouldnt bother about finding out what doesnt have to be updated - just depack your stream(s) into a buffer and copy that to the SID every frame. |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
I did an implementation of this a while back. I didn't care about the exact cycle timing, rather just what is set up per frame call. Like groepaz says, individual streams and delta is the way to go although RLE is a little too weak for my taste. ;) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
of course you can always replace RLE by something that packs better, but uses more CPU :) |
| |
Sasq
Registered: Apr 2004
Posts: 156 |
But there are some registers that are almost never written, would be waste of space to store a delta for them every frame? But other than that, huffman or similar with just 1 bit for indicating zero delta would make it pretty effecient.
But for samples another approach is also needed I guess, where a few set of registers are updated very often? |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
RLE of delta = 0 (or any constant delta) costs basically nothing per frame for that stream.
But, I'm interested in what your goal is? Is it being able to compress anything including cycle timing, like samples and stuff?
I assume you want it to play natively on the c64. Do you need it to fit in ram?
Like gpz says there is quite a compromise to be made between space vs. the amount of cycles needed to decompress the stream.
I went a little more towards the space side of things I guess. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
its even pretty efficient with just RLE ... if the delta is 0, then effectively you only store how many frames it takes until a change happens - using simple RLE that gives you like 5 seconds for each byte that never changes.... you should worry more about how to efficiently pack the bytes that DO change :)
for samples i'd use something completely different, for that you'll have to come up with a decoder that is very fast in the first place. |
| |
Mixer
Registered: Apr 2008
Posts: 452 |
There are so many playroutines that only way that works for every case is to save writes and the cycle delta inbetween.
Sid registers are written in sequence after all, not all at the same time.
Write order is an issue if there are several writes to same register within one play routine call. The packer needs to catch these. As discussed elsewhere, the ADSR write order depends on what the ADSR values were and will be after the call and what state change will take place. This includes GATE bit of control register. Therefore, i'd manage ADSR+GATE so that the write order stays. For other registers the order is not as important as proximity of the writes, so that the writes happen during same "call".
Volumesamples need the correct cycle delta between writes.
8-bit samplestuff and other methods need cycle exact handling of control register and other manipulated registers. For those both cycles and write order are important. |
| |
Sasq
Registered: Apr 2004
Posts: 156 |
I plan to use it on a real C64 yes... possibly streaming from SD-card or over TCP/IP. |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
If you get your data from some external high-speed source like those you mention, then go for very light compression or even just the raw writes. Stay off unaligned bit coding if you can.
The cycle delta does not need to be 16 bits. For long deltas you can just stack multiple dummy ones. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
for streaming i'd just send a 16bit timer value plus register+value. not sure if i'd go through the trouble of trying to make it work with (any kind of) samples though - that seems kindof hard for the generic case. when streaming via net or even reading from sd card, i somehow doubt you can keep up with the timing requirements (with those modern sample player things almost all CPU is burned by the sample player already) |
| |
Soren
Registered: Dec 2001
Posts: 547 |
Remember this order of storing in sid registers, for the following registers of each voice:
Sustain/Release, Attack/Decay, Wave.
Atleast to my knowledge that's the least buggy way of doing it.
Another thing, you could create a tune that has the same ADSR settings throughout the whole piece, so you only need to set those once... Or stable pulse (perhaps square)and do the same thing... |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
Soren, it really depends on the sequence being programmed. If the original player assumes gate is written before ADSR then swapping to ADSR first could easily trigger the ADSR bug.
For example, if the player's done a hard reset by clearing gate then setting attack and release to zero for two frames, it's perfectly safe to set gate before setting an ADSR of (eg) $00d8, as the rate limit counter will switch to using the attack rate before the release rate is changed.
Set ADSR before gate, and the rate limit counter will be free to escape (it will be using the release rate in the time between setting SR and setting gate, and probably rise past eight). Bam, no note start for another frame and a half. |
| |
Soren
Registered: Dec 2001
Posts: 547 |
ok :) |
