The Blubb2 Soundcard

Some time ago, we (namely Markus Hadwiger and Andreas Varga) set ourselves to developing our own soundcard for PCs and Compatibles using the beloved SID 6581 tone-generator which had been the very heart of famous C64's highly praised sound-generation capabilities.
First, we want to tell you a little bit about the history of the so called Blubb2 soundcard (originally short for Blubb-Blubb; wondering how non-native German-speakers are gonna pronounce that properly - in German we call a bubbling sound "blubb" and we've always liked rather childish names for electronic devices :-), and thereafter dive into some serious implementation details...

Here goes:
Back in the year 1992, when both of us were attending a school for communications and electronics in Vienna (Austria, Europe), we had to come up with an idea for a two-years project to do in the fourth and fifth grade (which were our last two years at school and hence it ought to have the character of a graduation-project). Since we were both skilled at digital electronics and assembly language programming and had been interested in electronic music and sound for quite a long time, we finally decided to design and build our own soundcard for PCs and Compatibles. But as the Soundblaster series was already widely in use at the time we didn't want to build some sort of a boring clone. Well, we had also been longtime C64 enthusiasts and had already considered using the SID 6581 for music on the PC some time earlier on.
So we settled on using the good old SID as tone-generator on our forthcoming soundcard-project. But we didn't want to stick with three-voice mono sound and therefore planned to use two 6581s - one for the left, and one for the right channel, respectively.
The next decision we made after having decided to build an 8-bit ISA card using two SIDs (we'd never quite wanted to use the parallel port for attaching a sound generating device because it didn't seem very flexible and clean to us, so the choice of the ISA bus had been an easy one), was whether we should try to map the 6581's registers directly into the PC's (I/O-)address space. Considering the problems with this approach regarding the vastly differing timings of the whole 65xx family of ICs and the ISA bus (which we would have had to use to map the registers directly) we were after something else. Moreover, we wanted to emphasize the hardware and embedded systems programming aspect of the project and hence didn't want to use the 80x86 for playing music. Thus, we decided to incorporate a complete microprocessor-system which should manage communication to PC applications software and be completely responsible for playing music and sound. Guess what! Of course we took the obvious approach to avoid potential timing conflicts and hours of hardware-debugging and used a 6502 as CPU which had exactly the timing specifications we needed to control our two SIDs (btw, a big thanx to Chuck Peddle for this hell of a CPU!). Anyway, a little bit 6502 coding after quite a while of doing x86 stuff should be rather refreshing! Furthermore, a big advantage of our approach was that we wouldn't need the PC's processor-time for sound output at all. The only drawback emerging from the use of an independent processor-system was that we had to transfer complete song-data into the card's proprietary memory prior to playing a song. But what the heck! I haven't mentioned the biggest advantage yet. Hadn't we used a 6502 compatible CPU we would have had to write an 6502 emulator running on the host to enable our card to play back the loads of cool C64 sounds we all have come to love, and the problem of mapping the 6581's registers directly would have kicked in again! Not only that this emulator would have used precious x86 processor time, I guess we never would have heard familiar 64 tunes while running Windows(tm) :-)
By the way, I've already mentioned that we wanted to emphasize the hardware-related part of the project and so our solution seemed very sensible to us. After one year of hard work :) we had managed to build a first prototype version of the Blubb2 soundcard and, surprisingly enough, it worked reasonably well! (although we won't deal with the black art of hardware debugging and the debugging of embedded systems software without the proper tools here...:-)
The second year of the project went into refining and adding features, as well as fixing some nasty problems (ever tried to reset a 1MHz CPU that needs a reset pulse of at least three cycles using the ISA RESET#-line without precautions??). Along the way of refining the hardware we also found a little time for writing a kernel somewhat worth its name (the prototype used systems software only capable of doing what was absolutely necessary to get the card up and running) and putting together some documentation stuff. Unfortunately, a very much improved version of the interface to the ISA-bus didn't quite make it into a PCB (printed-circuit-board) because we weren't able to figure out a cheap way of producing a second PCB (and the prototype's PCB did a rather good job anyway).
Btw, one of the most delighting experiences during these two years has been the first time when the prototype actually did something which made sense to us :-) We had hooked logic analyzer probes all over the PCB and were single-stepping through the boot procedure (and I'm talking hardware-tracing here!). Can imagine the feeling when we saw the address lines properly referencing the first few addresses of the boot-code, proving that the processor-system worked entirely??!! Alright, come to think one has to experience this on his own to know what I'm talking about ;-)

Well, thus far concerning the history of our little project. It seems to me that some implementation details would be in order right now, so here we go: And here's a block diagram of the card:


The ROM contains the Blubb2 kernel which communicates with PC applications software, manages onboard-memory and system-resources, and - above all - runs the sound-routines playing SID music.
When the card is reset for the first time, the boot-code initializes the 6526 to provide a 50Hz tick-interrupt utilized as timebase for music-routines. Communication is done using a single port (although as much as four ports are decoded for expansion purposes, see below). Reading this port provides status information; write access uses a proprietary protocol for controlling the card's operation and transferring data to it.
Usually one has to transmit a single block containing the player-routine as well as the music/sound data prior to playing sound. Player-routines have to use a standardized header format to enable the kernel to use them. Having transferred everything needed, one uses the PLAY MUSIC command to provide the routine with the 50Hz tick-interrupt.
Commands supported by the card generally belong to one of the following categories: The second version of the card (post-prototype) utilizes a 40-pin connector to allow daughterboard's interfacing to card-internal signals. This feature provides the means to mapping additional devices into the card's address space and using its I/O channels. Three of the four PC I/O-ports decoded by the card's address decoding circuitry are available to be used by extension-boards (e.g. a MIDI interface). But of course hardware alone doesn't suffice to extend the card's possibilities and hence a kernel extension feature has been implemented, allowing the user to extend the basic (rather generic) kernel in a documented way. For this purpose a TRANSMIT KERNEL EXTENSION MODULE command is available as well as various hooks into the kernel itself are provided.

Yep, that's enough for a brief summary I deem, but apologize in advance for having stayed rather superficial most of the time due to time and space constraints.

Comments on this page and the Blubb2 soundcard project appreciated at e9425555@stud1.tuwien.ac.at (Markus Hadwiger)
If you are interested in performance programming utilizing 100 percent assembly language, games programming, developing sound systems, hardware design, embedded systems design and programming (not necessarily in this order) or anything you think might be of interest to me, then please don't hesitate to drop me a line.


This text copyright (c) 1995 by Markus Hadwiger
Blubb2 design, hardware, firmware and related material copyright (c) 1992-1994 by Markus Hadwiger and Andreas Varga
All Rights Reserved.

go back