extending soundcard

11
Extending the soundcard for use with generic DC sensors Demonstrated by revisiting a vintage ISA design Smilen Dimitrov Aalborg University Copenhagen Lautrupvang 15 DK-2750 Ballerup, Denmark [email protected] ABSTRACT The sound card anno 2009, is an ubiquitous part of almost any personal computing system; what was once considered a high-end, CD-quality audio fidelity, is today found in most common sound cards. The increased presence of multichan- nel devices, along with the high-resolution sampling regime, makes the sound card desirable as a generic interface for acquisition of analog signals in prototyping of sensor-based music interfaces. However, due to the need for coupling ca- pacitors at a sound card’s inputs and outputs, the use as a generic signal interface of a sound card is limited to signals not carrying information in a DC component. Through a re- visit of a card design for the now defunct ISA bus, this paper proposes use of analog gates for bypassing the DC filtering input sections, controllable from software - thereby allowing for arbitrary choice by the user, if a soundcard input channel is to be used as an generic analog-to-digital sensor interface. Issues regarding use of obsolete technology and educational aspects are discussed as well. Keywords Soundcard, Sensors, ISA, DC 1. INTRODUCTION The ”humble” beginnings of the soundcard 1 as a dedi- cated part of a PC system intended to produce audible sound, could be seen in the use of a timer circuit Intel 8253, to generate pulses in the audible frequency range and drive a speaker, thereby producing audible sound [20]. Since then, the PC soundcard has become a multichannel A/D interfacing device, able to work at CD quality (16 bit / 44 KHz) rates and above. Devices offering more than two out- put channels are commonly used to drive multiple speak- 1 Ignoring earlier occurrences, such as the SID sound chip on a Commodore 64 (whose sound was provided as part of a TV output signal) and similar Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Copyright 2009 Copyright remains with the author(s). ers as part of surround sound home entertainment systems. Specialized soundcards with multiple inputs and outputs, and full duplex (playback while recording) capabilities, have found use in music recording in professional and home stu- dios. Soundcards interface as add-ins to PCs through several busses, serial (USB, FireWire) or parallel (ISA, PCI) in na- ture; although they are increasingly found integrated in PC motherboards. A slightly different type of devices become increasingly popular with the academic and DIY community as A/D interfaces for utilization of sensor signals. Programmable, micro-controller based devices such as the open-source Ar- duino [1], that offer both A/D conversion and PC connec- tivity (through, for instance, USB), provide a relatively easy way to interface with a variety of off-the-shelf sensors, from popular software development environments such as PD, Max/MSP, or Processing. However, these devices are also more limited in regard to sampling quality: for instance, the Arduino offers 6 multiplexed channels of 10 bit resolution, and the maximum serial transfer speed via USB is limited to 115200 bps - which results with a theoretical best-case upper limit of 1800 Hz sampling rate for all channels (given a 64 bit frame is used to transfer analog data of six channels @ 10 bits). Because of these limitations, a lot of prototypers and de- signers opt for a sound-card as a sensor A/D interface in- stead. This also relieves the designer of worrying about specifics of serial communication, and up-sampling the sig- nals so they match the audio domain processing rate, when sensor signals are to be applied to sound in software. How- ever, since a typical soundcard filters out frequencies outside of the audible 20Hz - 20KHz range, both on the input and the output, its use is limited with those sensing devices that produce output in this range. A soundcard has been in use by Leroy et al for capturing optical pickups [12], or as phys- ical computing interface in context of artwork production [10]; but its use can go beyond musical applications - such as chemical analysis [15] or medicine [17]. The DC filtering problem is most apparent with sensors that encode some useful information in the DC level (such as a force-sensitive voltage divider, which would provide pres- sure as a DC level, or an accelerometer, which would show the influence of gravity as change of DC level). A common way to circumvent this limitation is to use the DC signal to modulate a sinusoidal carrier in the audio range (using AM more often than FM), capture the modulated signal using a soundcard, and then demodulate in software [8]. In case of

Upload: dimitar53

Post on 24-Jun-2015

940 views

Category:

Education


1 download

DESCRIPTION

Extending sound card

TRANSCRIPT

Page 1: Extending soundcard

Extending the soundcard for use with generic DC sensors

Demonstrated by revisiting a vintage ISA design

Smilen DimitrovAalborg University

CopenhagenLautrupvang 15

DK-2750 Ballerup, Denmark

[email protected]

ABSTRACTThe sound card anno 2009, is an ubiquitous part of almostany personal computing system; what was once considereda high-end, CD-quality audio fidelity, is today found in mostcommon sound cards. The increased presence of multichan-nel devices, along with the high-resolution sampling regime,makes the sound card desirable as a generic interface foracquisition of analog signals in prototyping of sensor-basedmusic interfaces. However, due to the need for coupling ca-pacitors at a sound card’s inputs and outputs, the use as ageneric signal interface of a sound card is limited to signalsnot carrying information in a DC component. Through a re-visit of a card design for the now defunct ISA bus, this paperproposes use of analog gates for bypassing the DC filteringinput sections, controllable from software - thereby allowingfor arbitrary choice by the user, if a soundcard input channelis to be used as an generic analog-to-digital sensor interface.Issues regarding use of obsolete technology and educationalaspects are discussed as well.

KeywordsSoundcard, Sensors, ISA, DC

1. INTRODUCTIONThe ”humble” beginnings of the soundcard1 as a dedi-

cated part of a PC system intended to produce audiblesound, could be seen in the use of a timer circuit Intel8253, to generate pulses in the audible frequency range anddrive a speaker, thereby producing audible sound [20]. Sincethen, the PC soundcard has become a multichannel A/Dinterfacing device, able to work at CD quality (16 bit / 44KHz) rates and above. Devices offering more than two out-put channels are commonly used to drive multiple speak-

1Ignoring earlier occurrences, such as the SID sound chipon a Commodore 64 (whose sound was provided as part ofa TV output signal) and similar

Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a fee.Copyright 2009 Copyright remains with the author(s).

ers as part of surround sound home entertainment systems.Specialized soundcards with multiple inputs and outputs,and full duplex (playback while recording) capabilities, havefound use in music recording in professional and home stu-dios. Soundcards interface as add-ins to PCs through severalbusses, serial (USB, FireWire) or parallel (ISA, PCI) in na-ture; although they are increasingly found integrated in PCmotherboards.

A slightly different type of devices become increasinglypopular with the academic and DIY community as A/Dinterfaces for utilization of sensor signals. Programmable,micro-controller based devices such as the open-source Ar-duino [1], that offer both A/D conversion and PC connec-tivity (through, for instance, USB), provide a relatively easyway to interface with a variety of off-the-shelf sensors, frompopular software development environments such as PD,Max/MSP, or Processing. However, these devices are alsomore limited in regard to sampling quality: for instance, theArduino offers 6 multiplexed channels of 10 bit resolution,and the maximum serial transfer speed via USB is limitedto 115200 bps - which results with a theoretical best-caseupper limit of 1800 Hz sampling rate for all channels (givena 64 bit frame is used to transfer analog data of six channels@ 10 bits).

Because of these limitations, a lot of prototypers and de-signers opt for a sound-card as a sensor A/D interface in-stead. This also relieves the designer of worrying aboutspecifics of serial communication, and up-sampling the sig-nals so they match the audio domain processing rate, whensensor signals are to be applied to sound in software. How-ever, since a typical soundcard filters out frequencies outsideof the audible 20Hz - 20KHz range, both on the input andthe output, its use is limited with those sensing devices thatproduce output in this range. A soundcard has been in useby Leroy et al for capturing optical pickups [12], or as phys-ical computing interface in context of artwork production[10]; but its use can go beyond musical applications - suchas chemical analysis [15] or medicine [17].

The DC filtering problem is most apparent with sensorsthat encode some useful information in the DC level (such asa force-sensitive voltage divider, which would provide pres-sure as a DC level, or an accelerometer, which would showthe influence of gravity as change of DC level). A commonway to circumvent this limitation is to use the DC signal tomodulate a sinusoidal carrier in the audio range (using AMmore often than FM), capture the modulated signal using asoundcard, and then demodulate in software [8]. In case of

Page 2: Extending soundcard

resistive voltage dividers, they can be driven directly by anAC signal (conveniently, a sound-card can generate a sinu-soidal signal for the purpose), in which case the output willconform to the soundcard input limitations. Arguably, therewould be some loss of information when using this method -especially if the modulating signal has a spectrum extendingabove half the the carrier frequency; also, software resourcesare spent in demodulating a high-speed audio signal, in ad-dition to applying the demodulated signal as a control signalin the application.

On the other hand, direct modifications to commercialsound cards - intended to bypass input sections and allowsampling of DC signals - have also been proposed [14]. Insimilar fashion, this paper proposes that by using software-controlled analog gates, filtering sections at soundcard in-puts can be bypassed - thereby allowing for user-configurablepossibility of designating chosen inputs as ”sensor” inputs.This relatively simple architectural change, would allow forboth high-fidelity acquisition of DC signals, as well as reuseof common software tools made to interface with sound-cards. To test this assumption, a vintage ISA (IndustryStandard Architecture) design has been implemented, alongwith a corresponding C program - discussed further on inthis paper.

2. PROBLEM OUTLINEA simplified input channel section of a sound card is shown

in Fig. 1:

Input CR

ADC

Filter

Soundcard

Figure 1: Simplified diagram of a sound-card inputchannel.

In Fig.1, a basic CR high-pass filter schematic is takento represent a simplification of input filters usually found insoundcards, in order to emphasize the filtering of DC sig-nals. To illustrate this influence, a simple experiment canbe performed: a stereo mini TRS connector can be pluggedin a microphone2 (or line-in) input of a soundcard, and theground and a channel wire can be used to connect to a 1.5Vbattery. If we try to capture the resulting input data us-ing audio recording software (such as Audacity), we wouldobtain a capture like the one shown on Fig. 2

Instead of obtaining a constant (DC) level in the time pe-riod between approx 1.3s and 4.5s on Fig. 2, what is shownis a typical signature of a high-pass filter in the time do-main - a positive spike at the moment when the battery is

2Note that most recent PC microphone inputs are designedto interface with electret microphones, which means that oneof the channels of a stereo jack is in fact used to supply 5V tothe electret mic; so the input is effectively mono - althoughsome sound cards can sense the device being plugged in,and switch from electret regime to stereo. Here a built-inmicrophone input of an Asus EEE PC900 netbook was used.

Figure 2: Capture of a battery being connected (at1.5s) and disconnected (at 4.5s) to a sound card mi-crophone input in Audacity software.

connected, and a negative one when it is disconnected. Thispaper proposes that obtaining DC signals could be achievedby implementing a voltage controlled switch, ultimately con-trolled by software, that bypasses the entire input filter sec-tion, as shown on Fig. 3:

Input CR

S

Control

Soundcard

ADC

Filter

Figure 3: Simplified diagram of a sound-card inputchannel, with a controllable switch bypassing theinput filter.

A theoretical ideal switch would manifest resistances ofeither 0 or infinity Ohms, depending on the control signal -and could thus ideally decouple the input filter section. Areal switch will of course have finite maximum and mini-mum values for the resistance, and therefore some filteringof the input signal will still be present from the input filtersection. In addition, one should be careful, as not all digi-tally controlled switches can be used for the purpose - manydigital switches will also function as comparators (i.e. willaim to reconstruct a digital signal); since in this case, ana-log signal is being switched, analog a.k.a. bilateral switches(gates) will be appropriate for the purpose.

3. TESTING PLATFORMIn order to test the assumption given in the problem out-

line, a hardware platform needs to be chosen, that behavesessentially like a sound-card - but also allows for demonstra-tion of activating added analog gates via software. Primarilybecause reverse-engineering an off-the-shelf soundcard de-vice to behave as imagined would have been problematic,but also due to potential educational benefits - a DIY im-plementation of a soundcard design was sought instead.

Although the Internet does offer some information andtutorials on building basic extension cards for a PC - inter-faced through either USB, ISA or PCI buses - it is difficultto find an available design, which is specifically intendedto represent a sound card (or even a high-speed A/D con-verter). The only one found appropriate for the purpose, isthe design for a ISA extension card by Joe D. Reeder [18]

Page 3: Extending soundcard

- a now abandoned product, that was intended for learn-ing the essentials of software-controlled hardware. Since theschematic and the basic software code, related to this card,are still available on the website associated with this prod-uct (www.learn-c.com), it was this design that was taken asa starting point for development.

The schematic for this “Learn-C” ISA card was reim-plemented as a double-sided PCB, with an added CD4066

CMOS quad bilateral switch. Since the ISA bus is now ob-solete and cannot be found in modern PC systems, an olderPC based on an Elitegroup ECS P6VAP-A+ (or P6VAP-AP)motherboard was acquired. This motherboard from 2000features a single ISA slot, however the age of this PC as awhole caused some specific problems, which forced an in-quiry into alternatives for the booting process for the ma-chine. Code in C language from [18] was used to implementtest software, and Agilent 54621a oscilloscope was used tocapture signals on board - using the open-source agiload

package for transferring oscilloscope traces to a PC as rawdata. The experiment finally consisted of using a vintageWavetek model 145 signal generator to produce an approx.440 Hz sinusoid voltage with a DC offset level, and captur-ing this voltage with the “Learn-C” card and test softwareon disk. As the test software allowed for user-controlledactivation of the bilateral switches, these were alternatelyturned on and off during capture - and the captured signalwas observed in the open-source Audacity software.

3.1 ISA bus principlesLet us reiterate some basic principles of the ISA bus inter-

facing, before proceeding with the implementation details.In essence, we can distinguish between serial and parallelhardware interfacing modes; RS-232 being an example ofconceptually simple serial protocol, and IEEE 1284/Cen-tronics of a parallel one. A serial protocol transmits one bitat a time, and electrically needs at least three wires: onefor transmission, one for reception and ground. A parallelprotocol will use individual wires to represent a single bit -and can hence carry more than one bit at a time, but needsas many wires as there are bits in the word, plus a groundwire. In some dialects of C, interfacing with either type ofprotocol could have been achieved with commands like void

outportb(unsigned short port, unsigned char data).When outportb executes, the address given by port will

eventually activate the corresponding interface circuitry, andthe value data will be “written to the port”. Roughlyspeaking - in case of serial, this would mean alternating thevoltage between low and high levels (say -12V and 12V) onthe transmit wire, with a rate specified by the serial trans-fer speed, such that a BCD binary representation of data

is reproduced; in case of parallel, this could mean that eachof the wires of the parallel bus is set to a low or high volt-age (say 0V and 5V), corresponding to which bit in the BCDrepresentation of data a given wire represents. A commandlike unsigned char inportb(unsigned short _port) couldbe used to “read from a port” into a variable instead.

The ISA bus (like the current PCI) is a parallel peripheralbus. It has occurred as either PC/XT-bus, an 8-bit bus imple-mented physically as 62 pin port; or PC/AT-bus, a 16 bit bus,physically containing a PC/XT slot’s 62 pins and additional36 pins (total of 98 pins). The operation principles can bediscussed only using the PC/XT slot. The PC will addressdifferent devices on the ISA bus, by setting up correspond-

ing voltages on the 20 address pins of the ISA bus, usuallymarked as A0-A193. The PC notifies devices when they canact on the given address, by lowering its Address Enable line(usually marked AEN4). Using an address decoder circuit onthe card, the card can produce a single digital trigger, when-ever voltages corresponding to its own address are presenton the bus (not all 20 address pins are necessary for this,though). So, whenever the card’s address is present on theaddress line, and the AEN signal is taken low, the card is torespond by checking whether the PC wants to read or write- and act accordingly; in all other cases, the card must ap-pear electrically as a high-impedance circuit to the ISA buscircuitry. The PC notifies that it wants to read by takingISA’s Input/Output Read pin (marked IOR5) low; intent towrite is provided by taking ISA’s Input/Output Write pin(marked IOW 6) low. Typically, if a digital line is activatedby taking it to a low electric level, it is known as “activelow”.

These signals (A0-A9, AEN, IOR and IOW) are in fact“the minimum set of signals that must be used in an inter-face design[13]”. Exchange of data between the PC and thedevice occurs through the 8 data pins of the bus, D0-D77.Besides an address decoder, a minimal ISA interface cardwould also need a data transceiver circuit, for electrical de-coupling of circuits on board from the ISA bus - as well astarget digital devices, such as A/D or D/A converters, thatthe PC ultimately communicates with through the bus [23].

3.2 ISA hardware implementationThe original schematics for the “Learn-C” ISA card found

in [18] was rebuilt using open-source KiCad software (Fig. 4);the same software was also used to produce the PCB layout.

Figure 4: KiCad schematic of the ISA card; em-phasized dashed lines indicate connections of bipolarswitch (In electronic PDF version, zoom in for more detail).

The design on Fig. 4 relies only on the ISA bus powersupply pins 1, 3, 5, 7, 9, 10, 29, 31 (GND, +5V, -5V, -12V,+12V, GND, VCC, GND) as well as ISA pins 2, 13, 14, 20,33-40, 42, 53-62 (RESET, IOW, IOR, OSC, D0-D7, AEN,A9-A0). The pin RESET goes high during power-on, and isused for device initialization, whereas OSC is the ISA systemoscillator, typically at 14.318 MHz. ISA address pins A0-A2are first buffered using a 74LS244 (3-state octal buffer/-

3pins 62-43, or 31-12 on the bottom side4pin 42, or 11 on bottom side5pin 14 - on top side6pin 13 - on top side7pins 40-33, or 9-2 on the bottom side

Page 4: Extending soundcard

line driver) circuit, and then used for selecting a particularchannel from the ADC from software. Address decoding ofA3-A5 is performed using 74LS138 (3-to-8 line decoder/-multiplexer), and used to select among the different deviceson the card (the DACs or ADC, for instance). Addressdecoding of A6-A9 is performed using 74LS688 (8-bit mag-nitude comparator), comparing these pin voltages to a stateset by a DIP switch - which allows for manual setting of thecard address using the DIP switch.

Additionally, 74LS245 (3-state octal bus transceiver) takescare about buffering D0-D7 for use by the ADC or DACs,depending on whether the PC is not in a read operation, byproviding the correct impedance for each direction (towardsor from the PC); a 74LS393 (dual 4-bit binary counter) di-vides the OSC system oscillator signal frequency, providing1/16th of the frequency (about 894 KHz) as a clock signalfor the ADC. Most of the logic circuits are from the 7400 se-ries, working with TTL signal levels (0 and 5V). Besidesthe two DAC0832 (8-bit µP compatible, double-bufferedD/A converters) and ADC0809 (8-Bit µP compatible A/Dconverter with 8-channel multiplexer) ICs, a 8255 (generalpurpose Programmable Peripheral Interface (PPI)) is alsopresent - and used in this test setup as a simple digital out-put switch, which eventually activates the CD4066 analoggate. Finally, an input, “mic” analog preamplifier/filter ispresent for the input signal; as well as output amplifiers/fil-ters for the DAC outputs.

As shown on Fig. 4, most of the original design of the“Learn-C” ISA card has been reproduced, although withsome differences. For instance, a socket for the CD4066switch was added, and not all wired connections were im-plemented on the PCB (for instance, headers were left un-connected, as well as most of the I/O port pins of the 8255PPI). On the other hand, both DAC0832 digital-to-analogconverters were implemented8.

To avoid problems with over-etching thin tracks, the lay-out was deliberately taken to feature thicker tracks - this,however, made it very difficult to implement the entire de-sign as a double-layer PCB. Hence in some instances (like thedigital input pins of the DACs), holes were left on the board,intended to be connected with parallel wire. The board wasthus easy to etch, but somewhat difficult to solder - as plentyof wire had to be soldered by hand. In addition, IC socketswere used, to avoid possible problems with soldering ICs di-rectly; however, since IC sockets to not expose enough pinmetal for double layer soldering, pins were obtained fromadditional IC sockets9, and added as an extension to theused socket pins. This solved the double layer IC solderingissue, however it also further complicated the geometry andaccess to the card. The implementation of the card is shownon Fig. 5.

The PCB layout had unfortunately some errors as well(like missing tracks), which additionally complicated the im-plementation phase. However, once found, these errors wererelatively easy to correct on the board itself (due to the de-liberate design with larger tracks, which allowed for directuser intervention).

3.3 Host PC and booting processThe PC booting process would normally not be an issue

8although only a single one is actually used.9only open-frame, round-pin type sockets can be used forthis purpose

Figure 5: Left: image of the wired card; right: cardin ISA slot of motherboard of test PC.

in a project like this - and initially, it wasn’t. The PC usedfor testing, apart from the P6VAP-AP motherboard, offereda Pentium III 750 MHz processor, a broken floppy drive, aworking IDE hard-disk, a working but slow CD-ROM, and aworking network card. The hard disk contained Windows XP

operating system, which was initially used for development- since the original source code in [18] is meant to run underMS-DOS.

Unfortunately, in the middle of the project, the hard-diskbecame unusable, apart from the very first sectors - and atthe same time, it was impossible to obtain a replacementquickly. This turned the test PC into a, essentially, disk-less machine, which cannot reliably boot a full desktop op-erating system in the standard manner (from a local harddrive). Therefore, several alternative booting procedureswere looked into. The final setup is shown on Fig. 6:

Figure 6: Boot setup between the diskless test PC(hosting the ISA card), and a tftp server PC. Thetest PC starts the boot from CD, and then proceedsto boot an OS image from the server PC.

The easiest, and increasingly popular, alternative wouldbe to attempt a boot into MS-DOS (which would still allowfor running of the card’s test programs) from a USB thumbdrive. This would allow for testing of the card software com-piled elsewhere, in spite of the test PC lacking the possibilityto compile programs. Unfortunately - unlike most moderndesktop PCs - the P6VAP-AP does not natively (from BIOS)support booting from a USB device10.

So, since the initial sectors of the hard-disk were still inorder, Mandriva 2008 was installed on this hard-drive froma live CD, in spite of getting a corrupt installation as a re-sult - simply to get the GRUB boot-loader software installed.The GRUB could then chainload (further boot into) the PLoP

[28] boot manager software, which can detect bootable USB

10not even with the latest BIOS update for this motherboard,released in 2003.

Page 5: Extending soundcard

drives on older machines, even if their BIOS cannot - andfurther chainload (boot) from them. This unfortunatelydoes not work with all USB flash drives - PLoP couldn’t bootfrom a TakeMS 4 GB USB memory key, while it could bootfrom a generic brand 128 MB memory stick. However, evena working USB thumb drive doesn’t seem to last long - af-ter a series of copying operations, the 128 MB stick stoppedbeing bootable from PLoP on the older test PC (although itremained directly bootable from newer PCs), and it had tobe reformatted.

The boot managers can usually be sensitive to CHS (cylin-ders/heads/sectors) disk geometry entered as part of theformatting process - even though no such organization ex-ists on a physical level in a flash drive. Using Gparted toformat a drive as FAT32 with ”cylinder rounding” is oneof the safer methods; however, it is difficult to get such aUSB thumb drive directly bootable as a MS-DOS drive after-wards11. Here a different approach was used instead: QEMU,an open-source processor emulator, was used to virtuallyboot from an MS-DOS floppy image, and to virtually mountthe USB thumb drive as a hard drive of the virtual machine.This can be achieved with the following command in a LinuxOS:

sudo qemu -L /usr/local/share/qemu/ -fda /path/to/WIN98SEC.IMG -usb -hda /dev/sdc -boot a

Then the entire USB thumb drive can be formatted andmade bootable from within MS-DOS - and this seems to en-sure both successful booting into MS-DOS from managerssuch as PLoP, and usage of the entire free disk space of thethumb drive12. In the end, this method proves tedious too,especially for development - since MS-DOS typically doesn’toffer network connectivity, the only way to transfer exe-cutable files to the test machine requires that the thumbdrive is removed (and therefore the test machine rebooted)each time a new file is to be tested.

Finally, the booting method settled on a network boot,also known as Preboot Execution Environment (PXE), asmost convenient. The test PC’s network adapter is 3COM3C905-TX, which features an empty slot for an add-onboot ROM. If it had a PXE boot ROM, the test PC couldhave booted over the network without any need for addi-tional software, since the P6VAP-AP supports network bootdirectly from BIOS - but only if the network adapter sup-ports it too. Therefore, the test PC was set to boot fromCD-ROM, and a rewritable CD was “burned” with the open-source gPXE [6] network bootloader image. Of course, net-work booting demands a server as well - a Windows XP ma-chine was used to host the open source tftpd32 [22] server,which in turn was used to serve an image of an MS-DOS net-work disk (built using the Build Floppy Disk BFD [26] soft-ware). Once the test PC is booted in a networked MS-DOS

environment, it is relatively easy to mount a remote Win-dows share on the server through the net command:

net use X: \\mypc\myshare

11In such a case, Grub4DOS can be installed as a boot-manageron the flash drive, which has the capability to boot a MS-DOSfloppy disk image (stored on the flash drive) directly to mem-ory.

12in this case around 120 MB - other methods for achievingthe same can “force” the USB flash drive to behave like adiskette, along with only 1.44 MB as entire capacity of thedisk

and then compile the executables on the server machine,copy them to the share, and execute new versions on thetest machine - without the need for a reboot.

Some issues around the network boot were: the need tohave both test PC and server connected to the same net-work switch; the need for the tftpd server to assign IP ad-dresses in the same range as the IP address the server PCitself obtains from a master DHCP server; and the need forfolder sharing under password-less accounts under Win XP(since the net command on the BFD disk image does not sup-port Windows XP account password authentication). Thenetwork boot method could be, in principle, used to serveany bootable image, not just an MS-DOS one; for instancethe open-source FreeDOS might be an alternative - unfortu-nately it lacks a free equivalent of the net command, andhence cannot establish network connectivity on its own. An-other alternative is to use a Linux bootable network disk.

For the Linux operating system, initially the nanobox

linux [25] network boot disk was tried out. Using the de-fault floppy disk image of nanobox can be easily served witha tftpd server - however, it lacks the smbmount command,which is closest in functionality to DOS’s net use. Thereare resources available on the web page for producing a ver-sion with smbmount - however, that still does not make thisOS suitable for test of the card. Linux systems are basedon different supporting libraries; whereas typical Linux sys-tems are built on glibc (GNU C library), nanobox is builton a small embedded C library known as uClibc. Thismeans that the software source code must be recompiledfor the corresponding C library of the OS (or supply themissing objects, risking compatibility problems). As it canbe difficult to set up the, needed for compilation, uClibc

build toolchain on a nanobox system with only a remotedrive mounted via smbmount - an easier solution was foundin using a Damn Small Linux (DSL) [4] distribution. Thisdistribution (based on KNOPPIX Linux distribution), whileoffering a GUI, is only 50 MB in size, which makes it suit-able for a network boot (since the entire operating systemimage is generally loaded in RAM in such cases); addition-ally, there are Internet resources specifying the booting ofKNOPPIX based systems using tftpd server; and finally, al-though small, Damn Small Linux is extensible with prebuiltpackages, including the GNU C compiler gcc and debuggergdb - and these can also be used from a local network loca-tion. Thus, it becomes relatively easy to compile the cardsoftware, and run it under a DSL distribution.

The most typical problem with these Linux OS’s on a disk-less machine, is accessing Windows network shares. Typi-cally, the smbmount command can be used with the followingsyntax:

mount -t smbfs //mypc/myshare /local/mount/dir

where mypc is the computer name under Windows of the re-mote PC. However, using this name is not always successful(especially if the domain information is not set in the LinuxPC); in most cases, using the IP address of the PC instead,helps. In DSL Linux, installing its samba package will alsoprovide a graphical LinNeighborhood program which allowsfor automatic discovery of PCs and shares on the local net-work; however, the exact user-name, password and domainas the current Windows logged-in user are needed in orderto access a share on a Windows PC.

Page 6: Extending soundcard

3.4 SoftwareAs mentioned previously, the source code for the “Learn-

C” ISA card given in [18] is C code, originally intendedto run under MS-DOS (as part of this project, portions ofthat code were ported to Linux as well). The “Learn-C”example programs can also run in the command promptshell of Windows XP - however, they cannot be directlycompiled with modern Windows C compilers. The reasonfor this is that the code relies on C commands like inportb

and outportb (or inp and outp), which represent direct I/Oport access13; however direct I/O port access is disabled forWindows architectures newer than NT [19].

Nonetheless, older compilers can be employed in order tocompile the test programs for the ISA card - so they run evenunder Windows XP. Currently, Borland’s historical compil-ers Turbo C v2.01 and Turbo C++ v1.02 are provided at nocost - both of them can be installed under DOS or Windows,and can compile the ISA card test programs. However, thereis another option as well - the open-source DJGPP compiler[5]; although there are some subtleties in switching from aBorland to a DJGPP compiler, the process is almost straight-forward.

The first piece of test software run, was the C code ex-ample from [18] (experiment 8 ) which controls a DAC, andoutputs a triangular wave analog sound. The core of thecode is relatively simple:

disable ();while (!kbhit ())

for(x=0; x <256; x++) outp(da1 ,x); for(x=254; x>0; x--) outp(da1 ,x); __asm__ ("sti"); // required by DJGPP

enable ();

Listing 1: DAC code

In essence, as long as no keyboard presses are detected,the code will loop two for loops, that generate a ramp of all8-bit values - from 0 to 255 and then back - and write thosevalues to a DAC. Here is one difference that can be seenbetween DJGPP and Borland compilers: DJGPP for some rea-son cannot detect a keyboard press, if the kbhit commandis encapsulated between enable and disable commands -unless the assembler command __asm__("sti") is added atthe end of the loop [7]. Also, whereas Borland compilerswill produce executables some 15 KB in size, the DJGPP com-piler generates 117 KB executables for the same source code.Finally, “raw” executable from DJGPP will complain about“cannot open swap file c:\cwsdpmi.swp”, although thesoftware will run - the way to work around this is to usethe exe2coff, cwsdstub and cwsparam programs from theDJGPP distribution, to explicitly set the swap file used by theexecutable to none.

It is interesting to observe the frequency of the eventuallyproduced analog signal - since there are no explicit timing

13These C commands are in fact interface for the assem-bler commands IN and OUT, which otherwise represent corecommands in the Programmed Input/Output (PIO) trans-fer mode [23]. Since PIO (as opposed to Direct MemoryAccess (DMA)) involves the processor in every transaction ofdata between the PC and the peripheral devices on the bus,it suffers from performance issues, which is why it is beingphased out where fast devices are involved [27].

considerations taken in the software, and additionally, theDACs do not depend on a clock signal - we can expect thatthe test PC will simply try to write the ramp values, assoon as it can, to the ISA card DACs; without previousexperience, one could speculate that this could result evenwith a hypersonic wave being generated by the DACs. Toconfirm this, the output analog signal was captured with anoscilloscope (shown on Fig. 7).

Figure 7: Agilent oscilloscope screen capture of theoutput DAC signal, after amplification (obtained us-ing agiload software).

The DAC output signal on Fig. 7 is well in the audi-ble range (which can be shown by connecting a speaker tothe output, and hearing the output). The agiload soft-ware can also obtain a scope capture, like on Fig. 7, as alist of 2000 floating point voltage values; this list can beused to obtain more precise locations of local minima, andthus more precise period. Using this method, we arrive ata period of approximately T=876.5 µs (or f=1140 Hz DACfrequency), which means that the time between consecutiveoutp(da1,x) commands in listing 1 (which involves check offor loop condition, increase of counter x value, and the ac-tual outp command) is about 1.7 µs. Since the same tempo-ral granularity occurs for test programs under both MS-DOS

and Linux environments, and is somewhat similar regardlessof interrupt disabling - it is likely that this limit is imposedby a more fundamental problem (such as incompatibilitybetween bus requests timing, and relaxation time of the theDAC chip or similar device - similar to the 8530 latencyproblem described in [9, pg. 809]).

4. TESTING PROCEDUREThe testing procedure consisted of two distinct steps. The

first was to use a known signal to determine the samplingrate of the ADC; and to check whether this rate is cor-rect (by auditorily comparing a capture from the ISA card’sADC to the known signal). The second step (the actualexperiment) consisted of sampling and capturing a known,DC-lifted, sinusoidal signal; turning the analog switch onand off during capture; and looking for presence of a DClevel recording when the switch was active in observationsof captured data.

4.1 Determining the ISA card sampling rateAs the DAC sampling rate discussion hints, determining

the ADC sampling rate will also involve some work. Aknown reference signal - a 440 Hz sinusoid - was generatedusing Audacity with the maximum amplitude, and repro-

Page 7: Extending soundcard

duced using a sound-card headphone output; this signal wasapplied directly to the ADC’s first input (pin 26). Sincethe headphone output spans from -1.65 to 1.65 Vpp, andADC0809 operates ratiometrically against a voltage referenceset to 5V - obviously only the positive semi-period of the si-nusoid will be captured. This distortion, however, would notaffect the fundamental frequency seriously – which meansthat the captured signal’s pitch should remain audibly closeto the pitch of the original sinusoid.

The starting point was again code from [18] (experiment9 ). Auditory comparison requires that the test softwareis able to record captures on disk, which is done relativelyeasy by adding the fputc C command to write the 8-bitdata (obtained from the ADC) to disk - as soon as it isavailable. However, initial captures for several seconds ofcapture time were only few thousand bytes in size - whichmeant something was wrong with the ADC sampling rate.

Let’s briefly review the principle of work of the ADC: wealready mentioned that the ADC chip is addressed through10 bits of the ISA address line: A9-A6 determine the card,A5-A3 determine the ADC chip (through the 74LS138 de-coder) and A2-A0 determine the input channel on the chipto read from; the base address is this case was 0x200(1000000000). If the PC does a write (outport) on this ad-dress, IOW line is activated. In that case, pins of 74LS02 areset to: 74LS02/p1=”1” and 74LS02/p4=”0”. 74LS02/p1being high enables lines START (ADC0809/p6) and ALE (ad-dress latch enable, ADC0809/p22), to notify the ADC toprocess analog input channel based on the brought A2-A0lines. 74LS02/p4 being low disables line OE (out enable,ADC0809/p9). Thus, analog-to-digital conversion in thechip starts during a write operation, but the chip’s digitaloutput pins are not yet enabled at that moment. If the PCdoes a read (inport) on this address, IOR line is activated.In that case, pins of 74LS02 are set to: 74LS02/p1=”0” and74LS02/p4=”1”. 74LS02/p1 being low deactivates START

line (however this does not stop an already started ADCprocess) and ALE; and 74LS02/p4 being high enables lineOE, which makes ADC0809 output the last finished sam-pled result. Once started, the ADC works in sync with theOSC/16 (about 894 KHz) clock signal, finishing with the EOC

(END OF CONVERSION) signal. Upon EOC, we shouldhave the digital sample value ready, laid out on BD0-BD7pins of ADC0809.

So, from the PC side, we always have to do an outport

to start the ADC process, then wait for the EOC signal, andthen an inport to obtain the digitized value. Waiting forthe EOC signal is implemented by reading from the baseaddress plus 0x18 (0000011000), which sets address linesA3-A4 to ”11” and thus makes the decoder select the lineEOC/SWITCH SELECT (74LS138/p12) instead of lineADC SELECT (74LS138/p15). This eventually causes the74LS244 to map the EOC signal to BD7, which is then routedto the D7 data pin of the ISA bus through the 74LS245transceiver. So, from software, we would simply wait - un-til the value, read from base address + 0x18, gets its 8th

bit set to 1 (which is easily done by bit-masking with 0x80(010000000)). Hence, a more precise way to obtain the sam-pling rate, would be through determining the period of theEOC signal. However, initial observations of the EOC signalshowed problems, shown on Fig. 8 left.

Figure 8 (left) shows that EOC is not periodic; addition-ally, IOW never fires. However, by removing extraneous com-

Figure 8: Oscilloscope screen captures of EOC (top)vs IOW (bottom). Left: 100 µs of non-periodic be-havior; right: 1 ms of periodic behaviour.

mands (such as printf or fputc) from the ADC reading loopcode, IOW started firing and EOC stabilized its frequency -which is shown on Fig. 8 right. The execution of C com-mands thus visibly influences the sampling rate of the ADCprocess. Eventually, it turns out that this can be resolved byintroducing a short delay between the outport and the firstinport command in the reading loop, as shown in listing 2:

unsigned base; unsigned adcport; base = adcport =0x200; //1000000000

if ((fp = fopen(FILENAME,"w+b")) != NULL) while(!kbhit())outp(adcport, 0); // start channel 0 conversion , by

writing whatever value to address adcport

iz = del; while (iz > 0) iz--; // fake delay , ’ del ’

increments

while(!(inp(adcport+0x18) & 0x80)); // wait for EOC

ready : 0 x18 = 000011000, 0 x80 = 010000000

x = inp(adcport); // read ADC value into variable x

fputc((char)x,fp); // since value is 8− bit anyways ,

just cast to char and save to disk

Listing 2: ADC reading loop code

Additional code made it possible to interactively changethe value of the del variable, and thus the duration of thedelay. It was discovered that for values of del greater than8102, the EOC signal settles its period as on Fig. 8 right - andfurthermore, in this case, commands like printf or fputc

didn’t seem to affect the EOC period as seriously. This needfor a delay occurs for test programs running both underWindows and Linux environments (and it’s likely it is re-lated to timing inconsistencies between the bus and the cardhardware). Using the data captures of oscilloscope traces,the period of the EOC signal while capturing to disk was de-termined to be around 78.583 µs, which gives around 12725Hz sampling frequency. As listing 2 indicates, the recordedfile is simply a stream of 8-bit characters. This file can beimported in Audacity as raw data, and the sampling fre-quency is set upon import; the resulting waveforms can beseen on Figure 9.

The multi-track capabilities of Audacity also allow theoriginal 440 Hz source signal, and the ADC captured sig-nal from the ISA card, to be played simultaneously in spiteof differing sampling rates; their respective pitches can beheard as audibly close. It was difficult to determine by hear-ing whether the obtained 12.725 KHz sampling rate trulyproduces a pitch closest to the original source signal, asAudacity doesn’t offer a way to modify the sampling rate ofan audio file interactively while the sound is playing.

Page 8: Extending soundcard

Figure 9: Display of captured ADC signal importedin Audacity, interpreted as signed (top) or unsigned(bottom) 8-bit data. The portion on the right showsa temporally zoomed slice.

4.2 Test of analog switch functionalityAs mentioned previously, a CD4066 was used to imple-

ment an analog switch, which bypasses the input preamp/-filter section of the ISA card. This chip offers four analogswitches - only a single one was used, defined by pins 1 and2 and switch connectors, and pin 13 as voltage control. Us-ing a pocket digital multimeter, the resistance of the channel(between pins 1 and 2) was measured. With the PC poweredoff, 25.6 KΩ were measured; however, with the PC poweredand the program running, this resistance was measured at 0Ω for closed switch, and greater than 2 MΩ for open switch;which is a good sign that the device will behave close to anideal switch when in use. Of course, there is the question ofhow to target the voltage control pin of the bilateral switch(CD4066/p13). The 8255 PPI on the ISA card was usedfor the purpose, as it offers three ports (A, B and C) of 8pins each, which can be configured to act as either digitalinputs, or digital outputs; it additionally has an 8-pin dataport, through which all the communication with the chip isperformed. Just a single output pin is needed from a singleport, configured as output, in order to control the analogswitch; pin 7 of port A (8255/p37) was chosen for the pur-pose, and was connected to CD4066/p13. The 8255 offersthree different modes of configuration of the three ports;here any mode that configures port A as output will do,and the function set up ppi from [18] was used to quicklyconfigure the ports.

The ISA bus address lines A0, A1 are eventually routedto the two address pins of 8255 (p8 and p9), which are usedto choose which internal 8255 register is targeted throughthe data pins. The control register is accessed when A0=1,A1=1 (or, the base address of the 8255 + 3 appears on theISA bus), and can be used to configure the PPI; the port Aregister is accessed when A0=0, A1=0 (or, the base addressof the 8255 appears on the ISA bus), and can be used toread from port A - or turn individual pins on and off ifconfigured as output. Eventually, this was coded within theADC reading loop, so as to allow 8255/p37 to be turnedhigh or low at the press of the button. The key elementsof the code, integrated with code on listing 2, are shown onlisting 3:

// make port A an output and port B an input −Aout CUin Bin CLin = 0x1C0

set_up_ppi(0x1C0);//0 x200 = 1 000 000 000

unsigned base; unsigned adcport; base = adcport =0x200;

// 1 000 000 000 + 0 000 100 000; A0=0, A1=0

unsigned ppi_porta = base + 0x20;int ch = ’p’; int outval = 0; int ov = 0; int

targetpin = 0x80;

if ((fp = fopen(FILENAME,"w+b")) != NULL) while( (ch == ’p’) ) if (kbhit()) ch = getch(); //windows only , conio . h

if (ch == ’p’) outval = !outval; // toggle value

ov = targetpin * outval; // shift

printf("outval is now %d (0x%X=%d).\n",outval, ov, ov);

outp(ppi_porta, ov); // write value to PPI

outp(adcport, 0); // start channel 0 conversion

... // [ snip rest of code ] ...

// end while , reading loop

Listing 3: Toggling PPI pin 37 via press of key ’p’

Listing 3 allows that a press on key ‘p’ toggles the out-put voltage of 8255/p37 between 0 and 5V, which in turnturns toggles the analog switch on or off via CD4066/p13.Otherwise, the switch terminal CD4066/p2 is connected toADC0809/p26; and CD4066/p1 is connected to input ofthe mic preamplifier (input pin of capacitor C1 on Fig. 4).Thus, using the analog switch, the entire input preamplifiercan be bypassed by a key press - while the software recordsthe ADC samples to a disk file. Then, if a signal with a DClevel is present on the preamplifier input, the toggling of theswitch should be visible on a recorded capture.

5. RESULTSThe procedure described in section 4.2 was used to capture

a DC offset sinusoidal signal. This signal was generated by avintage Wavetek model 145 signal generator, which doesn’tprovide for fine-tuning control of the AC amplitude and theDC offset separately. Eventually, a signal spanning between0.5V and 1.66V, set at approximately 450 Hz, was used asthe input signal for ADC capture. The signal arriving at theinput pin ADC0809/p26, without and with the influenceof the switch, is shown on Fig. 10.

Figure 10: Oscilloscope screen captures of the in-put signal brought to ADC0809 IN0 (left) withoutthe influence of analog switch; (right) while analogswitch turned on

It should be noted that the input section of the ISA card,features a small voltage divider, formed by VR1 and R3 (Fig. 4),used to offset an input signal (and thereby avoid clippingof signal with no zero offset). This voltage offset was setto zero by tuning the VR1 potentiometer, in order to em-ulate accurately the DC filtering behavior of input sectionof soundcards. Additionally, the amplification factor of thepreamplifier section is fixed, and set by the ratio of resistorsR2 (4.7 MΩ) and R1 (3.9 KΩ) - which results with some 1200times amplification. Such an amplification will clip the DC-offset input signal rather quickly, hence a 3.9 KΩ resistor

Page 9: Extending soundcard

was soldered in parallel with R2, in order to bring the am-plification close to 1 - and keep the amplitudes of the inputin both test cases equal. As per Fig. 10, that didn’t turnout to be a total success, yet it is close: the filtered signalhas an amplitude of 1.14 Vpp, whereas the switched signalshows 1 Vpp.

This input signal was captured using the procedure givenin section 4.2, as the analog switch was turned on and offduring capture using keyboard key presses. The data cap-tured by the ISA card can be verified through an import inAudacity, depicted in Fig. 11.

Figure 11: Top: Six second capture of an inputsignal with DC, with the switch activated in mid-capture; Bottom: temporal zoom at moments of ac-tivating (left) and deactivating (right) the switch.

As it is obvious from Fig. 11, activating the switch allowsthe DC level of the signal to be captured by the card’s ADC;and the waveforms obtained in Audacity remain relativelyfaithful to the original input signal shown in Fig. 10.

6. DISCUSSIONThis paper indicates that analog switches bypassing the

input preamplifier section of sound-card inputs, would be arelatively simple change to perform on existing sound-carddesigns, thereby expanding their purpose to high speed A/Dinterfaces for generic sensors. Similar change could be im-plemented for output sections, thereby allowing sound-cardsto be used as generic signal generators. The DC blocking ca-pacitors are present in a sound-card, of course, for a purpose- primarily to protect speakers from constant DC biasing,and thereby prolong their lifetime [24]. The design changeproposed here, would ideally leave that regime unchangedfor audio purposes - and simply introduce a different one,more suitable for sensor data acquisition, when the user re-quires it.

Unfortunately, the card’s implementation is of rather lowquality, which results with a noisy input and output - obvi-ous even from the oscilloscope traces provided in this paper.Therefore it is difficult to make any claims beyond a simpledemonstration of the concept - such as frequency character-istic of the preamplifier sections with a switch for both onand off states, or distortion introduced by the switch. How-ever, the paper also shows that once a platform is available,it is relatively easy to suggest modifications that would beworkable in practice - and that even vintage designs can beused for the purpose. Still, many factors would still need tobe considered, before a final conclusion is made regardingimplementation in modern sound-cards: for instance, howto preserve the bipolar voltage sampling capabilities whenin audio mode, while adjusting to the ADC input range (if

needed) for strictly positive voltages when using an activeswitch.

This project started by looking for a hardware platform,that behaves essentially like a sound-card. Arguably, theISA platform used here cannot be even considered a soundcard, until it can be used by typical audio software (likeplayers or editors) from the application level in an operatingsystem. Although the ISA card could be extended to playback audio (encoded for the measured DAC frequency) - atthe state presented here, it behaves more like a generic signalgenerator and sampler, than a modern soundcard. Findinga modern open hardware platform, that allows for the typeof research as in this project, is still problematic; althoughFPGA based designs, such as the ones described in [11], arevery promising as a base for miltichannel, high-speed, hybridaudio/sensor interfaces.

Whereas it is utopistic to expect that this paper couldsignificantly influence industry in such a manner, that simi-lar modifications become a standard for future sound-cards- it certainly aims to inspire designers working in the elec-tronic music instrument field, to focus at the intricacies ofdigital interfacing with analog signals; and to consider us-ing older, historic designs for appropriate purposes - whilebeing aware of potential obstacles. Mostly, one has to dealwith hardware availability, although software can be an is-sue as well. However, in the case of ISA, the paper showsthat currently there is still a palette of tools that can tar-get such machines and corresponding functionality, many ofthem free and open-source; yet, one has to be prepared fora time investment for straightening out potential glitches.

Although the “Learn-C” ISA design was sufficient to illus-trate potential use of analog gates, it is pointless to attemptto turn it into a full sound-card, primarily since the ISA busis in itself obsolete. However, it may be interesting to lookat the practical obstacles to it. The biggest problem withthis design, and possibly with any design based on PIO modecontrol of an ISA sound-card, is the difficulty in obtainingconsistent and predictable timing. Neither the ADC input,nor the DAC output design outlined here haven’t taken aparticular timing goal into account; in both cases the sam-pling rate had to be determined after the device was builtand used. As an experiment, during development an at-tempt was made to develop a PD object under Windows XP,that would eventually be able to transfer digital audio datastreams played within PD to be passed and reproduced onthe ISA card. PD objects are based on a so-called “perform”function, which gets called by the OS repeatedly; the gran-ularity of this perform function calls is about 1 ms. Whena perform function is triggered, it has access to input andoutput sound buffers, which contain a number of samples,corresponding to about a millisecond of audio. Hence, all aperform function would do, is simply write these values tothe DAC of the ISA card as soon as possible; the DAC wouldalso reproduce them as soon as possible, and then hold thelast value for about a millisecond, until the perform func-tion gets called again. Thus, this particular ISA card designsimply cannot be driven by a standard PD object, in such away that audio is reproduced at the DAC output; becauseof the slow, millisecond, call rate of the perform function -and the need to access the hardware directly via in and out

commands during its execution 14.

14This would be quite possible, if the ISA card had compo-

Page 10: Extending soundcard

In fact, Windows, apart from prohibiting PIO access viainport and outport commands15, also has millisecond gran-ularity built into the operating system [21]. Essentially,standard Microsoft C and C++ programs cannot be guar-anteed timed access beyond a millisecond granularity, unlessthe Windows Driver Development Kit16 is used [3], which re-quires a Microsoft paid subscription. Although Linux “is nota real-time system, it has some features, already included inthe mainstream source code or distributed as patch files, de-signed to provide real-time to Linux” [2]; and since it allowsfor free development of device drivers, it could be seen asa viable alternative for work with designs, such as the onediscussed in this paper.

Arguably, the ISA design used as a test platform here,doesn’t even come close to issues in contemporary sound-card production. However, it is an excellent educationaltool to introduce general issues related to design of sound-cards and corresponding software. Namely, it is often diffi-cult for beginner engineers to come to a practical example,which is both relatively simple to understand as introduc-tory material (and thus easy to relate to theory) - and canbe practically implement to serve a purpose, already knownfrom a user perspective. So in spite of the obsolescence ofISA, this design can still be useful educationally - considerthat 8255, used as a central component of the now obsoleteparallel PC port, in modern times finds implementation aspart of VLSI circuits; similarly address decoders and similarlogic circuits are likely to be found as components in FPGAdesign. One positive point of using discrete components inthe card implementation, is the possibility to measure theirsignals individually with an oscilloscope and thus observethe interdependence of different signals on the physical, elec-tric level - something that becomes arguably difficult, if thecomponents are part of a single VLSI chip.

7. CONCLUSIONIn conclusion, the project managed to demonstrate the

possibility to use analog switches, for software controlled by-pass of input filters of a sound-card device; thereby, in princi-ple, allowing it to interface with generic sensors that produceDC-offset voltages. However, claims cannot be made on thefeasibility of implementing such a change in an existing com-mercial sound-card design. The project also illustrated thespecific problems encountered with usage of a card design forthe now obsolete ISA bus; while demonstrating how it canbe used to emulate modern hardware (at least to a degree,sufficient to expose the problem at hand). Additionally, thesimplified analysis of particular issues, aims to serve as aneducational introductory example for designers starting withdigital hardware design; in line with this aspect, the sourcefiles for schematics and code, as well as the full list of on-line references (too numerous to include here) relevant tothe topic discussed in this paper, is provided on the projectwebpage [16].

nents that would allow the card to receive data from the PCquickly, store this data in memory, and eventually control itsreproduction on the DAC chip; however, such a data trans-fer implies use of a direct memory access (DMA) method, analternative to the PIO method.

15Although, historic compilers and DJGPP still support them,and a workaround is possible using a commercial libraryNTPort [29].

16(WDK, earlier known as DDK)

8. REFERENCES[1] Arduino. Arduino homepage, http://www.arduino.cc/.

World Wide Web electronic publication.

[2] D. Beal, I. Ripoll, P. Pisa, L. Abeni, P. Gai, andA. Lanusse. Linux As a Real-Time Operating System.Metrowerks Corporation–A Motorola Company,OCERA, 2003. World Wide Web electronicpublication,http://www.freescale.com/files/soft dev tools/doc/-white paper/CWLNXRTOSWP.pdf.

[3] M. Cherepov, M. Hirst, C. Jones, and M. Zimmerman.Hard Real-Time with Ardence RTX on MicrosoftWindows XP and Windows XP Embedded. Technicalreport, Ardence, Tech. Rep. Also athttp://msdn.microsoft.com/en-us/library/ms838340(WinEmbedded.5).aspx,2002.

[4] damnsmalllinux.org. DSL information - What is DSL?(Damn Small Linux). World Wide Web electronicpublication, http://damnsmalllinux.org/, LastAccessed: 12 April, 2009. DSL (Damn Small Linux)homepage.

[5] D. Delorie. DJGPP - Homepage. World Wide Webelectronic publication,http://www.delorie.com/djgpp/, Last Accessed: 12April, 2009.

[6] etherboot.org. start - Etherboot/gPXE Wiki. WorldWide Web electronic publication,http://etherboot.org/wiki/index.php, Last Accessed:12 April, 2009.

[7] groups.google.com. Problem with tight kbhit() loop -comp.os.msdos.djgpp. World Wide Web electronicpublication,http://groups.google.com/group/comp.os.msdos.-djgpp/browse thread/thread/18aa27bae2b98485/-cecf3d9dfed4ee28, Last Accessed: 12 April, 2009.forum post.

[8] M. H. Puts, J. Pokorny, J. Quinlan, and L. Glennie.Audiophile hardware in vision science; the soundcardas a digital to analog converter. Journal ofNeuroscience Methods, 142(1):77–81, 2005.

[9] P. Horowitz and W. Hill. Microprocessor SupportChips. In The Art of Electronics. CambridgeUniversity Press, 1989.

[10] K. Jo. Audio Interface as a Device for PhysicalComputing. Proceedings of Audio Mostly 2008 - aConference on Interaction with Sound, pages 123–127,2008. Also athttp://www.jojporg.dreamhosters.com/public dav/-paper/audiomostly08-audiointerface-jo.pdf.

[11] S. Kartadinata. The Gluion advantages of anFPGA-based sensor interface. In Proceedings of the2006 conference on New interfaces for musicalexpression, pages 93–96. IRCAM-Centre PompidouParis, France, France, 2006.

[12] N. Leroy, E. Flety, and F. Bevilacqua. Reflectiveoptical pickup for violin. In Proceedings of the 2006conference on New interfaces for musical expression,pages 204–207. IRCAM-Centre Pompidou Paris,France, France, 2006.

[13] F. Looft. Isa bus - a brief description and io devicedesign. World Wide Web electronic publication,

Page 11: Extending soundcard

http://web.archive.org/web/20070222231336/-http://ece.wpi.edu/∼wrm/Courses/EE3803/Labs/isa/,Last Accessed: 12 March, 2009. Last Modified:03/23/1997 01:43:54.

[14] S. Molloy. How to Modify a PC Sound Card to AllowD.C. Voltage Measurements. World Wide Webelectronic publication,http://web.archive.org/web/20080108175023/-http://www.mandanet.net/adc/adc.shtml, LastAccessed: 7 April, 2009.

[15] D. Nacapricha, N. Amornthammarong,K. Sereenonchai, P. Anujarawat, and P. Wilairat. Lowcost telemetry with PC sound card for chemicalanalysis applications. Talanta, 71(2):605–609, 2007.

[16] name(s) omitted for submission. Extending isasoundcard webpage. World Wide Web electronicpublication, http://link.omitted.for.submission, LastAccessed: 20 March, 2009. Last Modified: 03/20/200908:27:02.

[17] K. Reddy, J. Bai, B. George, N. Mohan, andV. Kumar. Virtual Instrument for the Measurement ofHaemo-dynamic Parameters UsingPhotoplethysmograph. Proc 23rd Int ConfIEEE,IMTC-2006, pages 1167–1171, 2006.

[18] J. D. Reeder. Tutorial - controlling the real world withcomputers. World Wide Web electronic publication,http://learn-c.com/, Last Accessed: 12 March, 2009.Last Modified: 03/21/2005 22:53:00.

[19] D. Roberts. Dr. Dobb’s - Direct Port I/O andWindows NT. World Wide Web electronic publication,http://www.ddj.com/184409876?pgno=3, LastAccessed: 12 April, 2009.

[20] T. Savell. 23.3 Digital Audio Processors for PersonalComputer Systems. Linear Algebra and OrdinaryDifferential Equations, 1993.

[21] technet.microsoft.com. Inside Windows NT HighResolution Timers. World Wide Web electronicpublication, http://technet.microsoft.com/en-us/sysinternals/bb897569.aspx, Last Accessed: 12April, 2009.

[22] tftpd32.jounin.net. TFTPD32 : an opensource TFTPserver/service for windows : TFTP server. WorldWide Web electronic publication,http://tftpd32.jounin.net/, Last Accessed: 12 April,2009.

[23] B. Trumbic. How to make your own at card. WorldWide Web electronic publication,http://web.archive.org/web/20011008162116/-http://www.fesb.hr/∼btrumbic/atcardTR12.htm,Last Accessed: 12 March, 2009. Last Modified:02/23/1998 13:29:28.

[24] www.maxim ic.com. APPLICATION NOTE 3979 -Overview of DirectDrive R© Technology. World WideWeb electronic publication, http://www.maxim-ic.com/appnotes.cfm/an pk/3979/, Last Accessed: 12April, 2009.

[25] www.neonbox.org. nanobox linux. World Wide Webelectronic publication,http://www.neonbox.org/nanobox/index.html, LastAccessed: 12 April, 2009. home page.

[26] www.nu2.nu. BFD - Build Floppy Disk. World WideWeb electronic publication, http://www.nu2.nu/bfd/,

Last Accessed: 12 April, 2009.

[27] www.pcguide.com. Programmed I/O (PIO) Modes.World Wide Web electronic publication,http://www.pcguide.com/ref/hdd/if/ide/modesPIO-c.html, Last Accessed: 12 April,2009.

[28] www.plop.at. PLoP - Home. World Wide Webelectronic publication, http://www.plop.at/, LastAccessed: 12 April, 2009.

[29] www.zealsoftstudio.com. NTPort Library - Inport,Outport, Inp, Outp functions, direct I/O ports access.World Wide Web electronic publication,http://www.zealsoftstudio.com/ntport/, LastAccessed: 12 April, 2009.