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.
Well, 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 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 class (which were our last two years at school and hence it ought
to have the character of a graduation-project). As 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 using two 6581s, one for
the left and one for the right channel.
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 communications to PC
applications software and be completely responsible of 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, 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. 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 hence our solution seemed
very feasible to us. After one year of hard work :) we had managed to
build a first prototype version of the Blubb2 soundcard and surprisingly
it worked reasonably well! (altough 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 this 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:

    8-bit ISA card
    6502 8-bit/1MHz CPU to keep everything up and running
    6526 for various I/O purposes including managing communications to
    PC applications software and providing the tick-interrupt for
    music-output
    Two 6581 tone-generators yielding six-voice stereo output
    32KB static RAM (yes, we really didn't want to cope with dynamic
    refreshing!)
    16KB ROM (EPROM of course) divided into two banks to save 6502
    address-space
    Lotsa TTL gates for everything else (we weren't quite able to use
    ASICs at the time)

And here's the block diagram of the card: (see BLUBB-2.GIF)


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. Communications is done using a single port (altough 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:

    Music Control Commands like playing, pausing or stopping
    music-output. 
    Transfer Commands like transferring musicdata or kernel extensions.
    Miscellaneous Commands like requesting status or firmware version
    number. 
    Initialization Commands like resetting the card or querying its
    presence. 

The second version of the card (post-prototype) utilizes a 40-pin
connector to allow daughterboards 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 original (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/programming (not necessarily
in this order) or anything you think might be of interest to me, then
also don't hesitate to drop me a line.
But please bear in mind (as concluded from the aforementioned address
:) that I'm a student and thus don't have much time to mess around!


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