VOGONS


Say "Hi!" to the Renovation SSI-2001!

Topic actions

Reply 140 of 149, by matze79

User metadata
Rank l33t
Rank
l33t

Yeah it would require to emulate 6502 CPU 😒

https://dosreloaded.de - The German Retro DOS PC Community
https://www.retroianer.de - under constructing since ever

Co2 - for a endless Summer

Reply 141 of 149, by Benedikt

User metadata
Rank Oldbie
Rank
Oldbie
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?

Reply 142 of 149, by root42

User metadata
Rank Oldbie
Rank
Oldbie
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.

YouTube and Bonus
80486DX@33 MHz, 16 MiB RAM, Tseng ET4000 1 MiB, SnarkBarker & GUSar Lite, PC MIDI Card+X2+SC55+MT32, OSSC

Reply 143 of 149, by Benedikt

User metadata
Rank Oldbie
Rank
Oldbie
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.

Reply 144 of 149, by root42

User metadata
Rank Oldbie
Rank
Oldbie
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.

YouTube and Bonus
80486DX@33 MHz, 16 MiB RAM, Tseng ET4000 1 MiB, SnarkBarker & GUSar Lite, PC MIDI Card+X2+SC55+MT32, OSSC

Reply 145 of 149, by matze79

User metadata
Rank l33t
Rank
l33t

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.

https://dosreloaded.de - The German Retro DOS PC Community
https://www.retroianer.de - under constructing since ever

Co2 - for a endless Summer

Reply 146 of 149, by Benedikt

User metadata
Rank Oldbie
Rank
Oldbie
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.

Reply 147 of 149, by matze79

User metadata
Rank l33t
Rank
l33t

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

Little Information about Blubb Soundcard

https://dosreloaded.de - The German Retro DOS PC Community
https://www.retroianer.de - under constructing since ever

Co2 - for a endless Summer

Reply 148 of 149, by root42

User metadata
Rank Oldbie
Rank
Oldbie
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).

YouTube and Bonus
80486DX@33 MHz, 16 MiB RAM, Tseng ET4000 1 MiB, SnarkBarker & GUSar Lite, PC MIDI Card+X2+SC55+MT32, OSSC

Reply 149 of 149, by Benedikt

User metadata
Rank Oldbie
Rank
Oldbie
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.