Yeah it would require to emulate 6502 CPU 😒

matze79 wrote on 2021-09-29, 20:30:

Yeah it would require to emulate 6502 CPU 😒

Speaking of which:
I recently found this thing here: https://github.com/Galfodo/SIDdecompiler
Could we pair that with assembly language translation to create a 6502-to-8086 recompiler for SID files?

FreddyV wrote on 2021-09-29, 11:37:

I started to look at the .SID file format, but the files include C64 assembly code, so I giveup the idea to support this one day

Yes, SID music is always intertwined with machine code on the C64. So at the very least you need to have a partial C64 emulator running, which interprets the 6510, and sometimes even has to emulate the C64 more fully (interrupts, timers etc)

The format description is here:

https://gist.github.com/cbmeeks/2b107f0a8d36f … ebb056e94b2f4d6

While it would be nice to support it, I think it's not feasible. However it would be nice if we could make up our own tracker and format, independent of the C64. Or have it work similar to the Adlib captures of DosBox et al. where you simply record the register values, making the 6510 emulation obsolete.

root42 wrote on 2021-10-11, 08:08:

Or have it work similar to the Adlib captures of DosBox et al. where you simply record the register values, making the 6510 emulation obsolete.

You mean like SIDDump? That sounds like the easiest solution.
A recompiler based on the SIDdecompiler mentioned above would involve a lot more work.

Benedikt wrote on 2021-10-11, 09:32:

root42 wrote on 2021-10-11, 08:08:

Or have it work similar to the Adlib captures of DosBox et al. where you simply record the register values, making the 6510 emulation obsolete.

You mean like SIDDump? That sounds like the easiest solution.
A recompiler based on the SIDdecompiler mentioned above would involve a lot more work.

Yes! I see it actually exists:

https://github.com/cadaver/siddump

That would be something useful. The files would be much larger than a typical .sid file I guess, but maybe it could be compressed to a reasonable size.

There was some guy who made a ISA SID Card which had Dual Ported RAM?? and a 6502 CPU and SID ICs.
Not sure what its Name was.

root42 wrote on 2021-10-11, 09:55:

Yes! I see it actually exists:

https://github.com/cadaver/siddump

That would be something useful. The files would be much larger than a typical .sid file I guess, but maybe it could be compressed to a reasonable size.

The people in this Kiwi forum thread have come up with a somewhat more compact binary format for SID register dumps:
Kiwi - a 68k Homebrew Computer • SID dump file format

It basically uses bit masks for changed registers and then only stores the changed values.

We could improve on that by adding a possibility to skip empty frames and put everything in a RIFF container that mimics something between WAV and RMI.
The WAVE format technically has everything we need, but you cannot really define your own codecs, so using the chunk identifier "WAVE" could cause problems.
RMI uses "RMID", so the obvious choice would be "RSID", but because that can be confused with the SID format's subtypes ("RSID" and "PSID"), something like "SSID" for sampled SID is probably better.

http://www.sidmusic.org/sid/blubb1.html

Little Information about Blubb Soundcard

Benedikt wrote on 2021-10-12, 19:26:

The people in this Kiwi forum thread have come up with a somewhat more compact binary format for SID register dumps: Kiwi - a 68 […]
Show full quote

root42 wrote on 2021-10-11, 09:55:

Yes! I see it actually exists:

https://github.com/cadaver/siddump

That would be something useful. The files would be much larger than a typical .sid file I guess, but maybe it could be compressed to a reasonable size.

The people in this Kiwi forum thread have come up with a somewhat more compact binary format for SID register dumps:
Kiwi - a 68k Homebrew Computer • SID dump file format

It basically uses bit masks for changed registers and then only stores the changed values.

We could improve on that by adding a possibility to skip empty frames and put everything in a RIFF container that mimics something between WAV and RMI.
The WAVE format technically has everything we need, but you cannot really define your own codecs, so using the chunk identifier "WAVE" could cause problems.
RMI uses "RMID", so the obvious choice would be "RSID", but because that can be confused with the SID format's subtypes ("RSID" and "PSID"), something like "SSID" for sampled SID is probably better.

One question I have is: Does the fact that the value didn't change mean that the register doesn't need to be written again, or might there be things like "note retriggered"? I figure that maybe simply replaying register values might not lead to an exact reproduction. However the idea of only storing changed values and maybe using a simple compression algorithm might be "good enough" to make it so small a real mode DOS program could play back the file (maybe even in a streaming manner).

matze79 wrote on 2021-10-12, 22:48:

http://www.sidmusic.org/sid/blubb1.html

Little Information about Blubb Soundcard

Interesting, but not particularly relevant, because we already have our hardware.

root42 wrote on 2021-10-13, 13:34:

Benedikt wrote on 2021-10-12, 19:26:

The people in this Kiwi forum thread have come up with a somewhat more compact binary format for SID register dumps: Kiwi - a 68 […]
Show full quote

root42 wrote on 2021-10-11, 09:55:

Yes! I see it actually exists:

https://github.com/cadaver/siddump

That would be something useful. The files would be much larger than a typical .sid file I guess, but maybe it could be compressed to a reasonable size.

The people in this Kiwi forum thread have come up with a somewhat more compact binary format for SID register dumps:
Kiwi - a 68k Homebrew Computer • SID dump file format

It basically uses bit masks for changed registers and then only stores the changed values.

We could improve on that by adding a possibility to skip empty frames and put everything in a RIFF container that mimics something between WAV and RMI.
The WAVE format technically has everything we need, but you cannot really define your own codecs, so using the chunk identifier "WAVE" could cause problems.
RMI uses "RMID", so the obvious choice would be "RSID", but because that can be confused with the SID format's subtypes ("RSID" and "PSID"), something like "SSID" for sampled SID is probably better.

One question I have is: Does the fact that the value didn't change mean that the register doesn't need to be written again, or might there be things like "note retriggered"? I figure that maybe simply replaying register values might not lead to an exact reproduction. However the idea of only storing changed values and maybe using a simple compression algorithm might be "good enough" to make it so small a real mode DOS program could play back the file (maybe even in a streaming manner).

The idea would be to replay register write accesses, not register values.
If the dotted lines in a SID dump mean that nothing has been written, that should be easy.