Of all the vintage chiptune machines out there, the Commodore 64 is the most famous. Even 30 years later, there are still massive gatherings dedicated to eeking out the last cycle of processing power and graphics capability from the CPU and the infamous synth-on-a-chip, the SID. [Bob] wanted to build a SID jukebox. A C64 is capable of the job, but if you want to have every SID composition on an SD card and connect that to a network, a Raspberry Pi is the way to go.
The SID chip, in its 6581 or 8580 versions, is controlled directly by poking registers on the chip through the address and data busses. This means a lot of pins, too many for the original Raspi expansion header. That’s not a problem that can’t be solved with a few shift registers, though. The rest of the circuit is an LM386 audio amplifier, an LCD that displays the current song, and a can crystal oscillator for the SID.
Right now everything is wired up on a breadboard, but making this a Raspberry Pi hat would be a rather simple proposition. It’s only a matter of finding a SID with working filters, and if you can manage that, it’s a pretty easy build to replicate. Video below.
26 thoughts on “A Raspberry Pi SID Player”
Nicely done. I look forward to seeing whether or not [Bil Herd] will comment on this.
Has anyone reverse engineered the SID? Even a register values to frequency, period, attack, sustain, decay, period???
I am working on a retro computer and SID hardware emulation would be great (when I get that far).
There are ‘microcontroller SID clones’, but they’re all missing the filter. Seeing as how SIDs with a broken filter are a dime a dozen, it’s still not the same.
First person to make some SIDs on an old silicon line is going to make a fortune.
What makes it so hard to produce the filter part? Can’t it be done using some sort of modern process tech?
From what I understand, the SID was hastily designed and pushed into production. As a result, the filter contained some flaws which were soon used as features, to produce sounds outside of the official spec. As these flaws were analog in nature, emulating them properly in software or any digital process has proved difficult. Even some of the later revisions of the SID itself don’t sound right under control of software originally designed to take advantage of these flaws (like sampled audio playback dropping to 10% of its former volume).
SwinSID (http://www.swinkels.tvtom.pl/swinsid/) is designed to be a drop-in replacement and has a filter which sounds very similar to the 8580 SID, as well as some extra features like additional waveforms and high-quality sample playback, all while maintaining backwards compatibility.
I would be thrilled to see a direct silicon clone though. There has already been a great deal of reverse engineering based on high-res images of the decapped chips, and the patents have expired, so maybe someone with the ASIC chops will have at it. Sounds like it would make for a hell of a kickstarter.
Good luck finding a foundry that still make NMOS and having the necessary CAD files to modify for their process.
Were those CAD files all hand drawn? What even happened to them?
Early chips were made by hand cutting strips of rubylith: https://wiki.rit.edu/display/smfl/Rubylith
Not sure this applies to the SID chip, but still gives you an interesting perspective on early chip design.
Early schematics were hand drawn. We systems guys switched over to CAD systems around the C128 era. PCBs were hand taped up until that time as well. The chip group had switched over to CAD (Mentor Graphics) for circuit design years before. Chip layout moved to CAD systems pretty early on, but the original 6502 and other early chips were taped in rubylith.
Looks like the Cypress PSoC series might be an angle to give this a go. I just have to find accurate specs. Could possibly be don in FPGA to.
There are plenty of SID like software emulations for all kinds of hardware such as Arduino, it has even been emulated on 8bit atari and Coco3, so there is a ton of information about.
Hey, I actually saw C64s with SD cards and networking… don’t ever underestimate the mighty C64 :-) But this is still pretty cool. Make sure you give the SID its proper analog supply (+12V for the 6581, +9V for the 8580, as I recall… it has been 30 years…)
Well DainBramage, [Bil Herd] hasn’t checked in yet, but [Dave Haynie], also a Commodore veteran, has. I raise an adult beverage to both.
Nice work on the SID player.
This is very impressive!
…but eep, the playback speed is wrong! https://www.youtube.com/watch?v=nf29ShkoAiA
Hey, Bob here,
You’re right about the tempo. This is due to a few reasons:
1) Raspberry Pi GPIO access times in general are very slow (see how much they differ by library here): http://codeandlife.com/2012/07/03/benchmarking-raspberry-pi-gpio-speed/
Based on this article I have written both the wiringPi and the standard GPIO implementations (in C), both of which I had issues with timing. I currently don’t have access to my oscilloscope, so I was having a hard time gauging the settling time being too long or too short, as it was producing sort of a ‘clicking’ effect. In my python implementation, the GPIO access was actually just slow enough not to have to add delays between calling “set pin high” and “low” on the /CS line, or for any of the shift registers, so it wasn’t a problem. It’s an interesting bug, and I will certainly be revisiting my C solution in the near future once I have my scope again.
2) Other applications can cause issues; It’s very easy to slow down the Pi. I’m curious to test my player on the newest Pi model once it’s available, and see how this performs.
I have previously worked on this project on Arduino, which allowed very precise timing control. I could very easily calculate 25 addresses per 50/60 frames per second, and very precisely control tempo without other programs causing interrupts. I wanted to port the project to the Pi to provide more ease of access, without having to swap out micro SD cards and such, so it was certainly a good lesson in trade-offs between the two platforms.
tldr; What I do at this point is use a value (around the actual calculated delay time between frames, modified due to the speed of GPIO and general sluggishness) to delay which sounded good enough for me.
Thanks for taking the time out to listen and compare!
Hey, thank*you* for taking the time to not only build and describe your project, but to explain this to me! You’re awesome!
Have you tried using Linux’s scheduling priority system (http://linux.die.net/man/1/nice) to try to prevent other processes taking your timeslice? If you need even better accuracy, you might be able to get realtime priority too, but I’ve never done that so I don’t know how to do it.
Beware: I’m pretty sure if a maximum-priority realtime process enters an infinite loop or otherwise never yields to the rest of the OS, the Pi will not handle any other tasks at all.
Failing that, if you’re feeling confident, you could write a kernel module and disable interrupts yourself. But then the Pi really really can’t do anything else until your code yields to the rest of the OS. Unless your code yields often(ish), no SSH (or TCP!) keepalive packets will be sent and the connection will drop when you do yield, which will kill your process unless you tell it to ignore SIGHUP…
Perhaps even a hardware FIFO could be used to buffer ahead and have a hardware timer clock it out exactly … but by then it’s waaay too complicated.
And oh, I’ve heard that song an unhealthy number of times, it’s pretty well encoded in my memory :)
there’s also SIDcog for propeller or retrocade for papilio one if you don’t want to spend $50 on a SID chip
not a big deal for a linux computer. even it can play hd h264 movies.
Yes IF it was emulating the SID
A Pi can only do that because it has a proprietary accelerator on the chip… the performance of the Arm on the Pi itself is abismal. Even on the new one… its still pretty bad compared to the alternatives.
The new one should be pretty good, for an embedded-class system, CPU-wise anyway. That’s a quad core Cortex A7, which should be computationally equivalent to a quad core Cortex A9, at about 1/3 the power. This was a high-end smartphone a couple of years ago. Actually, my just retired Galaxy Nexus, three years old, was only dual core A9 system.
Emulating a SID chipset require quite a lot of CPU power, HD264 video full HD is hardwired inside video Chipset nearly no CPU is used for this.
The schematic here seems to be a lot simpler: https://github.com/papawattu/SidPi . Does your design add any features?
Yep, its a pretty small difference:
I use shift registers in order to reduce the number of GPIO pins necessary to drive the SID. Address & data lines naturally occupy 8(data) + 5(address) = 13 lines, using shift registers reduces this number to 6 pins. This leaves more IO open for other hardware. In my case, I added the LCD to display song data.
Also, the circuit provided above also doesn’t show any audio amplification, but again, that’s not 100% necessary either.
This looks like a really cool project,
I have a question though, at what kind of crystal oscillator did you use?
Namely what speed?
Hope this thread isn’t dead lol.
And i hope to hear from you soon
Please be kind and respectful to help make the comments section excellent. (Comment Policy)