Soldering Irony

Network SID Device Protocol

2012-02-03T10:52:00.014+01:00

The Acid64 player supports playback of SID tunes via a network protocol which allows cycle-exact playback in emulators like the jsiddevice or on a real chip like in this project. I'm planning to support this protocol with the SIDboard (there will be a wrapper translating the network packages into commands that are sent via the serial port) and also within the FlowSID composer.

The main reason why I am writing this post is that I finally found a detailed description of the protocol in the jsidplay2 sources. I've extracted it for convenience:

Authors: Ken Händel, Antti S. Lankila, Wilfred Bos

JSIDPlay2 SID-emulation integration protocol. It is possible to have JSIDPlay2 take over the duty of the SID playback for a C64 emulator/player. Every jsidplay2 instance tries to open port 6581 where they will listen to connections that describe SID activity with the following protocol.

GENERAL OVERVIEW

Version 2 of the protocol is structured as a request-response protocol:

Requests are variable length, with minimum packet size 4 bytes. There are 3 fields and an amorphous data blob:
- 8-bit unsigned as command.
- 8-bit unsigned as SID number.
- 16-bit unsigned as length of data attached to header in bytes.
- Data (if any)
All commands are ACKed with a response packet that takes one of the followingforms:
- OK means that the commands were accepted by server and can be discarded by client. No data will be appended to response.
- BUSY means that no part of the current command was accepted due to filled queue condition, and that client should wait and retry it later. 1 millisecond could be a suitable delay before retry. Queue length is limited both by number of events and maximum time drift between playback clock and client clock. No data will be attended to response.
- READ: successful read operation, one byte value follows that is the value read from SID.
- VERSION: response to VERSION operation. Version number will be appended to response.
- COUNT: number of SIDs supported by network device.
- INFO: info packet, which contains model code and zero-padded 20-byte UTF-8 encoded string representing model name.

Maximum packet length is 64k + header length. It is suggested that only short packets are transmitted, in the order of 1k and containing no more than about 1 ms worth of events. Otherwise the client-server desync brings jitter that may have unpleasant consequences. At the limit it's possible to simply send a fixed header that describes a single write with each packet, but this is probably measurably less efficient.

COMMAND OVERVIEW

Structure of data is specific to command. Some commands require data, others will not use data even if such was provided. Some commands require specific lengths for the data packets. If data length is not correct, results are undefined.

Known commands are identified by small integers, starting from 0:

FLUSH (0): destroy queued data on all SIDs, and cease audio production.
- sid number is ignored.
- data packet must be 0 length.
- should probably be followed by RESET (SID is in unpredictable state).
- always returns OK
TRY_SET_SID_COUNT (1): set number of SID devices available for writing
- sid number equals the count of SIDs wanted.
- data packet must be 0 length.
- returns BUSY until audio quiescent, otherwise OK.
MUTE (2): mute/unmute a voice on specified SID
- data packet must contain two 8-bit unsigned bytes:
  - the voice number from 0 to 2
  - 0 or 1 to disable/enable voice
  - this command bypasses buffer and takes immediate effect.
- always returns OK
TRY_RESET (3): reset all SIDs, setting volume to provided value.
- data packet must be a 8-bit unsigned value which is written to volume register.
- returns BUSY until audio quiescent, otherwise OK.
TRY_DELAY (4): inform emulation that no events have occured for a given count of cycles
- data packet must be 16-bit unsigned value interpreted as delay in C64 clocks. 0 is not allowed.
- allows audio generation in absence of other activity.
- returns BUSY if there is already enough data for playback, otherwise OK.
TRY_WRITE (5): try to queue a number of write-to-sid events.
- data packet must be 4*N bytes long, repeating this structure:
  - 16-bit unsigned value interpreted as delay before the write in C64 clocks.
  - 8-bit unsigned SID register number from 0x00 to 0x1f.
  - 8-bit unsigned data value to write
- returns BUSY if there is already enough data for playback, otherwise OK.
TRY_READ (6): reads SID chip register.
- data packet must be a 4n+3 bytes long, where n >= 0. The protocol used for the first n packets is the same as the TRY_WRITE protocol, returning potentially BUSY if the delay implied by the READ, or the WRITEs can not yet be buffered.
- Read packet structure trails the write packet structure:
  - 16-bit unsigned value interpreted as delay before the read in C64 clocks.
  - 8-bit unsigned SID register number from 0x00 to 0x1f.
- returns BUSY if there is already enough data for playback, otherwise READ and a data byte, which is the read value from SID.
GET_VERSION (7): returns the version of the SID Network protocol.
- sid number is ignored.
- data packet must be 0 length.
- returns 2 bytes: VERSION and a data byte, which is the version of the SID Network protocol.
SET_SAMPLING (8): set the resampling method for all SID devices.
- sid number is ignored.
- data packet is 1 byte long and contains:
  - 0 for pure decimator (low quality)
  - 1 for low-pass filtered decimator (high quality).
- returns BUSY until audio quiescent, otherwise OK.
SET_CLOCKING (9): set the clock source speed for all SID devices.
- sid number is ignored.
- data packet is 1 byte long and contains:
  - 0 for PAL
  - 1 for NTSC
returns BUSY until audio quiescent, otherwise OK.
GET_CONFIG_COUNT (10): Query number of SID configurations supported by server.
sid number is ignored.
data packet is ignored and should be 0 length.
- always returns COUNT and a 8-bit unsigned value that is 1 larger than the maximum valid configuration.
GET_CONFIG_INFO (11): query the name and model of the SID configuration.
- data packet is ignored and should be 0 length.
- returns INFO and 8-bit unsigned-value and a string in ISO-8859-1 encoding with a maximum of 255 characters excluding a null terminated byte
  - INFO code
  - Model: 0 = 6581, 1 = 8580
  - Model name (max. 255 chars + 1 null terminated byte)
SET_SID_POSITION (12): set sid position on the audio mix
- data packet is 1 byte long and contains:
  - -100 to 0: audio is panned to left
  - 0 to 100: audio is panned to right
- always returns OK.
SET_SID_LEVEL (13): set SID level adjustment in dB
- data packet is 1 byte long and contains:
  - 8-bit signed dB adjustment in cB (centibels), 0 means no adjustment
- always returns OK.
SET_SID_MODEL (14):
- data packet is 1 byte long and contains:
  - 8-bit unsigned value between 0 <= value <= max_config-1
- always returns OK.

VERSION HISTORY

Version 1 contains all commmands up to 7 (VERSION). There were 8 SID devices where bit 0 gave 6581/8580, bit 1 PAL/NTSC and bit 2 RESAMPLE/DECIMATE mode of operation.
Version 2 contains commands SAMPLING and CLOCKING. There are 4 different SIDdevices, 3x 6581 and 1x 8580. The commands SAMPLING and CLOCKING can be used to setparticular SID kind.

NOTES

The delay values do not contain the time taken to write the value to SID chip, and a delay length of 0 between writes is impossible to achieve with a true C64 system, although this emulator will accept it and execute several writes on the same clock.

At start of connection, the SID starts from RESET state with volume=0 and empty buffer.

Suitable packet size for TRY_WRITE is about 20 ms long. If TRY_WRITE returns BUSY, then client should wait about 20 ms (same as the play length of one packet) before retry.

Future expansion:

stereo SID support
select filter type in dialog
route chips to left, right or mono.
implement protocol via UDP
combine read and write in one data packet

The SIDboard

2012-01-28T16:08:00.014+01:00

I've been working on a new hardware project. I had been successfully intefacing the SID soundchip last year. Now I'm building my own SID synthesizer. I know, there's the HardSID, Catweasel and many such projects on YouTube. However, this is for fun and for learning. This particular board will have the following features:

Support for up to 4 SID chips
Support for both, the old (6581) and new (8580) SID in all slots.
Jumper-selectable filter configuration
Serial Interface (including RTS/CTS flow control)
Full MIDI interface (IN, THRU and OUT)
3 x 16 character LCD
Real Time Clock
Extension Port

Schematics:

I've already designed a PCB. I couldn't fit it all on a single PCB so I split it into two boards that will be put on top of each other like a sandwich. This helps to separate digital and analog circuitry and keeps the bus lines short.

6581 SID Chip

2011-07-29T10:53:00.002+02:00

Yesterday I ordered this:

http://www.touched-by-sound.com/de/Vintage-37031-Commodore_SID_Chip_6581.html

Looks like I'm gonna have a lot of fun at Chaos Communication Camp 2011 :)

Video: Making PCBs with solder resist

2011-06-03T08:08:00.002+02:00

Ever wanted to make PCBs that look like the real thing and are easy to solder, even with SMD parts? With green solder resist and all? I'ts possible! Here's what you need:

UV lamp
PCB base material with photoresist
Transparencies for printing your layout (and a printer of course)
Sodium Hydroxide (NaOH)
Sodium Persulfate (Na2S2O8) or your favorite PCB etchant
Hot roll laminator with hot and cold settings
Dynamask or similar solder resist laminate
Sodium Carbonate (Na2CO3)
A soft brush (you could also use your fingers)
Containers for the chemicals
Timer or stopwatch

And here's how to do it:

Video: My Workshop

2011-05-11T20:10:00.000+02:00

Here is a Video of my new workshop, my workbench and some tools:

You might ask what the hole in the middle is for. I am going to place a garbage bag right under it so I can easily keep my workspace clean.

Update

2011-05-06T09:08:00.002+02:00

For the record (no one seems to read this anyways):

I managed to produce high-resolution double-sided PCBs with solder resist mask.
The Pill Reminder got a redesign using SMD parts and the hardware has been built. The PCB fits behind the pill box now.
I got a workshop and therefore more space. Currently I am building a workbench. The landlord needs to fix electricity, though.
I am still after that cyborg thing. I already got the most important parts and some basic tests went well.

More posts (including pictures and videos) are about to come when I got electricity in the workshop.

Cyberpunk glasses

2011-02-13T08:42:00.007+01:00

Yesterday I got a package containing a "personal media viewer". The "converter" which contains the battery and a charger circuit was broken. I opened it and verified that the signal lines from AV in are just passed through to the HMD. Then I hacked down the glasses. Thumbs down to the manufacturer for the power supply wire colors: They used black for positive and yellow for negative. Thumbs up though, for using robust hardware that survives wrong polarity. I then mounted everything on the frame of my glasses. The result looks really cyberpunk-like:

Yes, this is a composite video input. What a blast from the past! However, it works. It is even quite comfortable since I removed all unnecessary weight.

I will order a beagleboard as soon as it is available again. Furthermore I found a pretty cool glove keyboard solution: Thumbcode. It is easy to implement in hardware and looks easy to learn and efficient. Stay tuned for more to come.

We do what we must because we can

2011-02-09T11:29:00.014+01:00

Today I am posting about a new project that I just started. It's not something new, actually. Steve Mann has been doing this since the 1980s but now it seems to be possible with low-cost hardware and some DIY skills. I'm going to build a wearable computer. And I am going to document this in a way that you can make your own. I may even produce and sell these as cheap as possible. I think this may have a great impact on society, just look at a few ideas of what I would implement (hardware side):

Head-mounted display
First-person camera
Pupil/Gaze tracking "mouse"
Pinch glove "keyboard"
UMTS internet uplink

And what would be possible:

Hands-free access to the web all time
Copy and paste text from reality into the Google search bar
Catalogue of all people you ever met, combined with face recognition
Instant recording and replay of every moment in your life
Tweeting what you see wherever you are
Decipher QR codes by looking at them

And I guess you can continue that list with a lot of ideas of your own.

Well, I am a technology enthusiast. I do this because it is possible. I am aware that this may have unforseen consequences. But this is not going to make me stop, no that is even making the whole thing more interesting. This morning I met Steffen Kurpierz, my former ethics teacher. I told him about my ideas and about how it could change everything. He asked the question that I had not thought about until then: Do we want those changes to happen? However, I think that we cannot stop the development anymore. Also it looks like the Japenese would love such a thing. Very dystopian, isn't it? ~~Let me remind you that there is a company in Japan working on this right now and they are planning to make this available as a consumer product in 2020.~~ Looks like that video is actually part of a viral marketing campaign for the Iron Man 2 movie. All other developments that I know are targeted at industrial or military use. But I am sure there are people working on this as a consumer product. If not, at least I am. We cannot stop it anymore but maybe we can influence the direction this goes. I recommend you to read this article (two parts, german) with wearable hardware in mind.

Well, while I've been writing this I got an email that the package containing the wearable display I ordered has been shipped. I will order the beagleboard as soon as it is available again. I am so excited.

Making PCBs: Ideas for improvement

2010-12-17T10:40:00.009+01:00

As you might have seen in my videos about the Pill Reminder Project, my self-made PCBs look rather unprofessional and soldering is a mess. This is due to the method I currently use. It's cheap, fast and easy, but also limited:

Print the layout on glossy paper using a laser printer.
Place the printed side on the copper surface of the board, fix with (non-plastic) tape.
Use a regular iron on maximum heat to transfer the toner to the copper surface. (Don't remove the paper yet!)
Place the whole thing into warm water, add some soap. Wait.
Carefully(!) remove the paper using your fingers, without damaging the toner layer. If the toner comes off, you didn't press hard enough when ironing.
Etch using your favorite etchant. I use sodium persulfate.
Remove the toner with a circular brush tool.

The main problems are:

High clearance needed because tracks increase in witdh due to squeezing.
Lots of corrections needed because toner tends to flake off during etching.
Due to the high number of repairs that need to be done manually, a solder resist mask cannot be used.

I used this method because it could be done without buying extra equipment. I will continue using it for prototypes because it is fast. Also it allows for corrections everywhere, such as adding parts, because there is no solder resist mask. However, I plan to make a second version of the pill reminder where the PCB, due to the use of SMD parts, fits entirely under the pill box. Squeezing and lack of solder resist are inaccaptable for SMDs, though.

That's why I am going to implement the standard photoresist process plus cemical tin coating and solder resist through laminating. However, I need to buy or make some equipment to do so:

UV Lamp
Laminating machine
Inkjet transparencies
Solder resist lamination stuff (e.g. Dynamask)
Various chemicals (for developing, etching and tin-coating)

So stay tuned for some videos and posts about how I make all the stuff I need. (The laminating machine probably needs to be modiefied to eat PCBs). When I got everything in place I will make a tutorial on how to make PCBs using my new process. (Note that most of my viedeos aren't meant to be instructional videos. They just show how I solved the problems that I had. However I may make real instructional videos from time to time)

Pill Reminder Project #001

2010-12-15T11:55:00.009+01:00

I uploaded new videos on my current project. It is an alarm clock combined with a pill box. LEDs in the pill box show the number of pills that should be left for each day. A blinking LED indicates the pill that should be taken.

The soldering looks quite messy. I haven't got the stuff to make a solder resist mask yet. But I'll try and use one next time. Also I need a new tip for my soldering iron. But electrically everything is connected the way it should be and I'm going to put the whole thing into a pretty case anyways.

Part one:

Part two:

Programming the ATtiny2313 Microcontroller

2010-12-10T15:52:00.016+01:00

This is my first post on this new blog. I was inspired to do this by Jaimie Mantzel who makes YouTube videos about all the cool stuff he makes. I'm going to make videos, too and post them on YouTube and also in this blog, together with further explanations, links and discussions.

So this first thing is about the ATtiny2313 from Atmel. The programmer circuit I built is basically a clone of Brian Dean's Programmer. I used 470 Ohm resistors to limit the current through the parallel port. Pins 2, 3, 4 and 5 are used as power supply pins. Some medium-sized capacitor (47µF should be enough) is used as a buffer for VCC.

Now, see for yourself: