| |
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. |
... 5 posts hidden. Click here to view all posts....
|
| Previous - 1 | 2 - Next |
