Jump to content

playing sids


Guest arjanver
 Share

Recommended Posts

  • 2 months later...

This is what I managed to find out about the protocol (got some info from Elektron) and it seems to be consistent with the SysEx's that ASID and Sidplay/w send.

http://sammal.ton.tut.fi/~paulus/asid_protocol.txt

I don't have the needed MIOS programming experience to implement it (at least at this point), so I'll just provide this info. The protocol seems quite simple, so maybe it could be implemented as an additional feature to the normal SidBox? E.g. menu item "Play .sid" and then the system would go to a state where it would just play the data received from computer. Or recognize the "start playing" SysEx-command and enter the playback mode. Or some other scheme, these just came to my mind.  :)

Link to comment
Share on other sites

Hi Jouni,

thanks for this great input! :)

I just wrote the appr. SysEx parser, but it seems that your re-engineered spec is not complete. The order of <data> is not clearly defined.

Example:

at the beginning, SIDPLAY sends following SysEx command:

 F0 2D 4E 7F 7F 7F 0F 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 0F
00 00 00 F7

I guess that this command should set all 25 registers to zero - except for the volume register (address 0x18 ) which should be set to 0x0f. The "featured" double-writes to the waveform registers 0x04, 0x0b, 0x12 (<mask4>, bit 7-5) are flagged to zero, which seems also to be ok.

Assumed that the data is sent in ascending order (like your spec could be interpreted), the volume register (0x18 ) will be set to 0

Assumed that the data in this example is sent  in following order of address offsets:

6, 5, 4, 3, 2, 1, 0, 13, 12, 11, 10, 9, 8, 7, ...

it will be set to 0x0f, so this order seems to be correct - or not?

WIth the first conversion rule the SID plays mostly nothing, with the second one I mostly hear some rhythmic sounds, but they are still incorrect  (wrong parameters)

So, I would like to know about which parts of the document you are 100% sure, and which parts are assumptions.

Best Regards, Thorsten.

Link to comment
Share on other sites

Hmm.. Of course it possibly couldn't be so simple. :)

Seems that the register indices are a bit messed. The regs 4, 11 and 18 are skipped and they are inserted to the <mask4> and <msb4>. As far as I could decode the data, there may be two consecutive writes to these 3 registers in one data packet. I wonder is this correct...

I updated the .txt file and there is now a table which should tell the correct location of bits for each register. I clarified the lsb/msb thing a bit, too.

There is still some oddities at least in the filter register values. I'm working on that .

And the 100% sure thing... I'm not 100% sure about anything in the spec.  :D That's why it'd be nice to get some feedback if it works or not.

Link to comment
Share on other sites

  • 1 year later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

×
×
  • Create New...