All quiet on the Western front…

1 Reply

 

Things have been very quiet here. I started a new job a few months ago and have been having a blast doing embedded C firmware programming for power-over-ethernet LED light control systems. I am currently working on the CoAP protocol, as mentioned previously.

I have a few articles for this site waiting for me to get back to them:

  • Tiny BBS – A new take on my 1983 *ALLRAM* BBS for the Radio Shack Color Computer. A few years ago, I had ported my old MIcrosoft BASIC BBS program to Arduino C. I decided to do a new version of the system using things I have learned over the past 34 years. I had worked up a proof-of-concept version earlier this year which had a substantially larger message base in the same memory. I hope to find time to return to this. I think it would be fun to take a CoCo and a $3 WiFi-to-serial adapter and put a micro BBS online ;-)
  • const-ant confusion in C – I have another article in the works that will delve in to the const keyword in C, based on how I’ve been mis-using it most of my programming career. I learned quite a bit about it at a recent job, since we had it defined in our coding style guide. But, many of us there were still using it incorrectly.

But meanwhile, I’ll be chugging away at my day job, working on my Iowa Adventureland amusement park website, and doing various side projects to earn extra income so I can save up for something really cool for my child’s birthday.

To be continued…

More CoAP musings…

2 Replies

Last week I implemented a simple version of CoAP protocol at work, going by the main specification:

https://tools.ietf.org/html/rfc7252

CoAP seems to be similar to how a web browser works with a web server: GET some content, POST something back.

A CoAP server could report back the status of various sensors, and they would be given names similar to a web page. Instead of featching a web page using HTTP protocol like:

http://www.subethasoftware.com/bikelights

…you would use the COAP protocol to reference some resource:

coap://127.0.0.1/motionsensor

You can GET, PUT, POST or DELETE, which I am told mimics things web developers are familiar with. Instead of passing around huge HTML text packets using TCP, CoAP sends a very tiny and compact bit of binary data using the smaller and faster UDP protocol.

CoAP is only a few years old, so many items that I needed to implement were not part of the main specification. I had to consult a second RFC document to learn about the “Observe” option:

https://tools.ietf.org/html/rfc7641

Observe is a mechanism that allows being notified when a resource changes. For instance, if you were monitoring a motion sensor, you might GET the /motionsensor resource, and specify the Observe option. CoAP should respond with the status of the motion sensor, and any time the status changes, send a message with the update.

Fun.

I was able to quickly put together a simple version that could receive and respond to CoAP messages — at least the ones that we’d be needing. However, there are still many features of CoAP I have yet to tackle.

One such features is outgoing confirmable messages. The challenge with those is that all the important information has to be retained somewhere so it can be re-transmitted if the receiver doesn’t receive :)

When I first began researching CoAP, I found several CoAP implementations for memory constrained devices like Arduino. Now that I know more about the protocol, I thought I’d revisit them and see how they approached things like Confirmable messages and Observe.

It turns out, many of the features I have been kludging together are just not supported at all by the simple CoAP implementations.

Here is one called microcoap:

https://github.com/1248/microcoap

With a few small changes, I was able to compile it up for a Windows PC using the GCC compiler. It easily allows creating a new endpoint function that is called when the CoAP message is received, with all important information parsed out and presented as elements in a C structure. All one needs to do is deal with the payload (passed along as a pointer to it, and the length) and generate a response packet.

It does not handle Observe or Confirmable messages, but it does have enough framework to quickly parse incoming CoAP messages, run some code, and send back a response. Like many I have looked at, this version also seems to be geared just for listening and responding. If you have a need for CoAP on that level, it’s a good place to start.

Once I get my work project done, I expect to attempt a similar project, just for fun, that will run on an Arduino with 2K of RAM.  (microcoap has 8K of buffers set aside on startup!)

More to come, maybe.

CoAP – Constrained Application Protocol

2 Replies

Has anyone out there done any work with CoAP?

https://tools.ietf.org/html/rfc7252

And the Observe (subscription) extension proposal:

https://tools.ietf.org/html/rfc7641

I am implementing it for my day job for an embedded system. I am doing it from scratch using just the RFC for reference.

I am thinking of doing another implementation (not using any work code, of course) for the Arduino. I’ve found a few attempts to implement it, often with many missing features or missing many needed features.

Anyone out there a CoAP expert?

1985 unlicensed Dr. Who game for the CoCo

4 Replies

In 1985, a new game was advertised by Prickly-Pear Software for the Radio Shack TRS-80 Color Computer:

DR. WHO

Here is the ad found on page 68 of the the December 1985 issue, typos and all:

Dr. Who ad in the December 1985 Rainbow magazine.

As a kid who had watched Doctor Who on the local PBS station in Houston, Texas, I just had to have this game. I had just moved from Houston to the tiny town of Broaddus (population 225) and no longer could receive a PBS station, so this would be as much Doctor Who as I would get while living there.

I do not think I even had a disk drive of my own yet, since I recall ordering this on cassette.

In those days, us kids would go down to the post office and buy a money order and mail it to the company, then wait for them to mail back the software. This really helped build up anticipation.

Finally, the game arrived:

Dr. Who by Larry Lansberry, as sold by Prickly-Pear Software.

It came with a manual, which I have yet to locate. When I find it, I will scan it and upload it to the Color Computer Archive. Fortunately, it at least has some instructions:

Dr. Who instructions, page 1.

Dr. Who instructions, page 2.

And, the promise of many levels of difficulty:

Dr. Who difficulty levels.

I was a bit disappointed to find that the game was written in BASIC. It also included one machine language program called “CTRYROAD.BIN.” This was a multi-voice music file that played John Denver’s Country Roads hit from the 1970s. And it played it while displaying the instructions, so you had to sit there for several minutes until the song was complete.

After this, the game would present some side scrolling text explaining what keys did what. Thank goodness for the manual! The text went by pretty quick.

After several minutes of generating data for the game, you were presented with the main game screen:

Dr. Who main game screen.

And, you also had the map view:

Dr. Who map view.

There were also animated scenes that showed the TARDIS descending to the planet’s surface, but without the manual, I cannot remember how to even get to the planets.

But … the effect was less than impressive. It was a very disappointing purchase from a cosmetic and user-interface standpoint.

HOWEVER, the actual game was quite good. It reminded me of the Star Trek-style games where you moved around a galactic grid in search of starbases and Klingons.

I must have written Prickly-Pear Software because somehow I got in touch with the author, Larry Lansberry, and we exchanged some letters. I recently found some of these letters, so I need to re-read them and see what we discussed. I know he explained the music choice and why the animation style was done like it was.

I always thought this game would be fantastic with a facelift. Perhaps now that it has been unearthed, someone may consider doing an update/remake of it.

You can try it yourself in a CoCo 1/2 emulator. The disk image is available here:

http://www.colorcomputerarchive.com/coco/Disks/Games/Dr.%20Who%20(Prickly-Pear%20Software).zip

And, just for fun, an old Doctor Who music demo I wrote has also been posted:

http://www.colorcomputerarchive.com/coco/Disks/Demos/Dr.%20Who%20Demo%20(Allen%20Huffman).zip

Doctor Who music demo.

Side Note: I don’t think Zigwald X. Malushi was a real person, and if he was, he had nothing to do with this demo. I used to see that name pop up on random pieces of software, often of the “questionable” nature. Since I was posting a copyrighted tune, I did not want to post it under my name so I used that one. I should find some of the other “Zigwald” programs and make a collection of them. I wonder how many used that name.

Enjoy!

Getting started with Roger Taylor’s “CoCo on a Chip” FPGA CoCo 3

Leave a reply

NOTE: This is a work-in-progress. Check back for updates. I will note any revisions at the top of this article.

Updates:

  • 2017-03-19 – Fixed a typo (thanks, Roger), and minor clean up.

Cyclone CoCo – Roger Taylor’s FPGA CoCo on a Chip

In July 2015, Roger Taylor began the process of recreating a CoCo 3 system in an FPGA (field programmable gate array). Using a low-cost (less than $80) Terasic DE0-Nano development board and a custom I/O add-on board, he quickly got a virtual CoCo running. He has been continually improving the system and adding more features. His “CoCo on a Chip” Facebook group has documented this every step of the way.

Last year, I had acquired one of these DE0-Nano development boards and the RGB22VGA add-on board from Ed Snider. I was planning on using it to hook my old CoCo 3 up to a borrowed VGA monitor. But, at last year’s 25th annual CoCoFEST! near Chicago, Mark Marlette of Cloud-9 was selling his all-in-one version of this RGB to VGA adapter. I picked on of those up, and never used the DE0-Nano.

Roger recently sent me one of his add-on boards so I can finally put together my own FPGA CoCo. Let’s see how it goes…

Hardware Required

  1. Terasic DE0-Nano Development and Education Board. These list for $79 on the manufacturer’s website ($61 for academic purchasers). It comes with a retractable USB Mini cable, which will be used to program the FPGA.
  2. Roger Taylor’s Terasic DE0-Nano Upgrade Daughter Board. He sometimes has these available completely assembled for around $99 (via his e-Bay store). You can also just buy the bare boards and build one yourself.
  3. SD memory card. Currently, the project does not support SDHC cards, so you have to find an older, smaller capacity SD (SDSC) card like a 2GB. I picked up a Transcend 2GB card on Amazon for about $7.
  4. PS/2 Keyboard (and optional mouse). I have never owned anything that used PS/2, so I didn’t have an old keyboard to use. I found a cheap Logitech Classic Keyboard K100 on Amazon for $11.99.
  5. VGA Monitor. I have one I borrowed to use with my CoCo, but I think VGA ports can still be found on some modern monitors.
  6. USB Power Supply for the DE0-Nano. You can use the included USB Mini cable and use a USB power port, or use a similar USB charging cable with a Mini connector.

A cheap PS/2 keyboard, 2GB SD card, DE0-Nano and Roger’s add-on card.

About Roger’s Terasic DE0-Nano Upgrade Daughter Board

Roger’s add-on board has RAM, two PS/2 style ports, a 1/8″ audio output jack, and VGA port. There are header connectors for plugging in a module that handles the SD card, and ones for WiFi and Bluetooth. My unit has The SD card and WiFi installed. I will be ordering a Bluetooth module for wireless serial ports (they are very cheap).

The card has writing along the bottom indicating which direction it should be plugged up tot he DE0-Nano: “Faces DE0-Nano USB connector –>>”:

Writing on the board points the way to proper installation…

You can also tell orientation by the cutout in the board, which lines up with some small 2-pin connector on the DE0-Nano below:

Cutout in the board allows access to a connector below.

Software Needed

  • Roger recommends installing the Quartus II programming app. (Smaller than having to install the full Quartus II IDE).
  • You will also need to install the USB Blaster device driver, which will be found in the install directory of the programming app.
  • You also want the latest Cyclone CoCo firmware from his Facebook group. He calls it Cyclone CoCo, for reasons that will become obvious once you start using it :)

Installing

It seems the first step will be to install the Terasic software, and then hook the DE0-Nano up and load Roger’s firmware. The software is only available for Windows and Linux. Since I am a Mac user, I will either have to run it via virtualization (I use Parallels Desktop and Windows 10) or find a PC to use. I have several Raspberry Pis running Linux, so maybe that is an option as well.

After that, you will have to install a driver, and lastly you will be able to load Roger’s firmware on to the device and turn it in to an FPGA CoCo. Here are the steps I took:

Step 1: Install the free programming app.

Download it here:

https://www.altera.com/downloads/software/prog-software/121.html

I am using the Windows version, so my screen shots will be from that version.

Installing the Stand-Alone Quantus II Programmer from Altera.

This will make available a program called “Quartus II 12.1 Programmer” in the Altera 12.1 Build 177 folder.

NOTE: Your version number may be different if you are using later or earlier versions than I have. If you are setting up one of these, I’m sure you can figure that out.

Step 2: Install the USB driver.

When you plug in the DE0-Nano to the computer, Windows should prompt you for a driver. My Windows 10 did not, so I had to manually install it. If yours does, you can skip the next step and go straight to how to browse to the driver.

First, I had to open the Device Manager and find the USB-Blaster in the Other devices section:

Device Manager showing the USB section, missing the driver.

Double clicking on USB-Blaster brings up information about the device:

USB-Blaster needs a driver.

Select “Update Driver…” and then choose “Browse my computer for driver software“. You have to manually tell it where the driver will be found (inside the programmer install directory):

Select the second option so you can browse to where the driver is located.

On my system, I used the default install location and the driver was located here:

C:\altera\12.1\qprogrammer\drivers\usb-blaster\

Browse to the drivers directory inside of the programmer software directory.

Your directory names may be different, depending on what version of the software you install. Browser there, and then click Next:

The system should find the driver and install it.

Step 3: Program the DE0-Nano

Plug in the DE0-Nano to a USB port using the included cable, then launch the Quartus II 12.1 Programmer application.

Quartus II 32-bit Programmer showing No Hardware.

If your Hardware Setup box says “No Hardware”, click the Hardware Setup button and select “USB-Blaster“:

Select the USB-Blaster device.

After you close that windows, you can use File->Open to browse to and load the FPGA firmware image you downloaded from Roger’s Facebook page:

Load Roger’s firmware image.

When it is loaded, you will need to check off “Program/Configure” and (probably optional) “Verify” to enable the Start button:

Firmware loaded and ready to program.

Once those two buttons are checked, you can then click Start to begin programming. After a few moments, you should see “100% (Successful)” in the top right green box:

Programming in progress. It only takes a few moments.

Congratulations! You now have an FPGA CoCo!

Hello, FPGA CoCo!

After these steps, I plugged the device up to a VGA monitor and plugged in my PS/2 keyboard to the left port, and powered it up. It should instantly come to life with a familiar green screen, but if you have not prepared the special SD card for it yet, it will hang, trying to boot from that card.

You can hold down ESCape when you power up to bypass that, and find yourself at a nice virtual CoCo:

Hello, FPGA CoCo!

In the next part, I will figure out how to configure the SD card so I can actually load some software on it, and save any programs I create.

Until then … wow. This was easy! I can’t wait to see what all it can do. Thanks, Roger!

Sir Sound prototype, version 2.

Leave a reply

Now working without the crystal. This is using a Teensy and one of the pins to generate a 4mhz signal. I will post a video in coming days, hopefully, as soon as I have some CoCo BASIC code talking to it.

The green and black wires running off of it wold go to a headphone jack that the cassette cable sold plug in to so you could feed Sound back to the CoCo without needing to use an external speaker. AUDIO ON!

Introducing the Sir Sound CoCo Sound Card

2 Replies

NEW “PRODUCT” ANNOUNCEMENT

The team that brought you* the CoCoPilot DriveWire Server is proud to announce their latest innovation:

“Sir Sound”

Sir Sound is a solid-state multi-voice audio synthesizer that operates over a serial transport mechanism**. It provides arcade-quality*** sound with up to three independent tonal voices plus one white noise channel all in an external module that doesn’t require voiding your warranty to install. In fact, you won’t even need tools!

Pricing is to be announced but hopefully it will be around $50. Or maybe $30. Or cheaper. Or less if you build it yourself. Heck, we’ll probably just make kit versions available since we don’t really like to solder.

Sir Sound Configurations

  • Turnkey – This is a “plug and go” version where you just plug it in and go. No special drivers are needed, as they are already built in to both BASIC and OS-9.****
  • BYOE – The bring-your-own-everything edition is shipped as a set of simple instructions containing a parts list and how to run wires between the parts.
  • Custom – Also planned to be available are various custom configurations, like what color of case it comes in.

Pricing

We estimate the thing is gonna cost us, like, ten or so bucks to make using off-the-shelf parts ordered in small quantities from China. But, to make it a product, we really should have an integrated circuit board and a case made, which will run the costs up dramatically. Rest assured, we’ll pass those unsavings along to you!

Availability

The first prototype is in the process of being tested. Quit rushing us. We’ll let you know when it’s done.

Specs

Basically it’s a Texas Instruments SN76489 sound chip hooked to a tiny Arduino micro-controller with a TTL-to-RS232 adapter. Here’s the prototype John Strong of StrongWare sent me:

SN76849 sound chip hooked to an Arduino Nano on a neat 3-D printed platform from StrongWare.

You kinda have to use some micro-controller since the sound chip turns on and starts making sound. Something has to issue the “shut up” instruction to it. If you just had hardware to translate a serial byte in to the command, and made the CoCo do all the work, the CoCo would have to load and run a program to shut the thing up every time you powered up. Fortunately, a custom-built Arduino that handles this can be done for like $5. There are cheaper PIC chips that could do it for less.

Then, you add a MAX232 type chip that goes from the TTL signal levels of the Arduino to RS232 signal levels, or using one of these $3 (or less) boards that’s already wired:

TTL-to-RS232 adapter.

Lastly, add a CoCo serial cable (4-pin DIN to DB9), and you are set.

Prototype “Sir Sound” sound module for the CoCo (or anything with a serial port, actually).

A small program on the Arduino will monitor the serial port for bytes and then relay them to the sound chip.

By doing some POKEs in BASIC to set the baud rate, you could make music by doing things like this:

REM PLAY MIDDLE C
PRINT #-2,CHR$(&H8E);CHR$(&H1D);CHR$(&H90);

FOR A=1 TO 1000:NEXT A

REM VOLUME OFF
PRINT #-2,CHR$(&H9F);

The notes always play, so you shut them off by setting volume off. There are different channel values for each of the four channels.

I envision having a “raw” mode where the device just translates the bytes from serial to the sound chip, and a “smart” mode where you could use an API and just send note values (like 1-88 of a piano keyboard, or MIDI note values).

“Smart” mode could simplify the control so it might look like this:

REM ALL DATA: PLAY CHANNEL 0, NOTE 10, AT VOLUME 15
PRINT #-2,CHR$(&H00);CHR$(&HA);CHR$(&HF);

REM NOTE ONLY: PLAY CHANNEL 0, NOTE 10
PRINT #-2,CHR$(&H01);CHR$(&HA);

REM NOTE ONLY: PLAY CHANNEL 1, NOTE 10
PRINT #-2,CHR$(&H11);CHR$(&HA);

REM VOLUME ONLY: CHANNEL 0, VOLUME 5
PRINT #-2,CHR$(&H20);CHR$(&H5);

And, I could also add a “super smart” mode where it could parse PLAY command-style strings, then spool them in the background while you do other things:

REM PLAY COMMAND, CHANNEL 0
PRINT #-2,CHR$(&H30);"CDEFGAB";

And, a “super super smart” mode could let it store string sequences, and play them by triggering with a simple byte:

REM STORE NOTE SEQUENCE 0
PRINT #-2,CHR$(&H40);"CCDCECFECCDCECFE";CHR$(0);

REM PLAY NOTE SEQUENCE 0
PRINT #-2,CHR$(&H50);

REM PLAY NOTE SEQUENCE 0 FIVE TIMES
PRINT #-2,CHR$(&H55);

…or whatever. You could sequence them together, like MIDI sequencers do, and have complex patterns that could play in the background while the program does other things.

There are lots of possibilities. We could even see about using the Carrier Detect line as a way to tell if the sound card was still playing something (rather than needing routines to read data back from the device, which would be doable but not from BASIC without assembly language code).

If this “sounds” fun to you, leave a comment…

Until then…

Notes:

* If you call making a blog post “bringing it” to you.

** It plugs in to the Serial I/O port. “Sir” sounds like “Ser”, get it? Marketing thought SerSound wasn’t friendly enough.

*** This part is true. The same sound hardware is used in the arcade mega-hits Congo Bongo and Mr. Do, among others.

**** PRINT#-2, yo.

Building a Better BASIC Input, revisited

19 Replies

Well, here we go again with a few more tidbits from comments to a previous installment…

Lowercase to Uppercase

John Klassek once again provides some interesting tips. He looked at my Building a Better BASIC Input article example:

30 LN=INSTR(“YyNn”,A$):IF LN=0 THEN PRINT”YES OR NO ONLY!”:GOTO 20
40 ON LN GOTO 100,100,200,200

…and suggested this:

40 ON (LN+1)/2 GOTO 100,200

…and noted:

…and you don’t have to keep the line numbers twice in ON…GOTO.

Well that makes sense. The extra bytes taken to do the math would be smaller than all the doubled line numbers. But does doing the math take more time than parsing through the extra line numbers? Let’s fine out:

5 DIM TE,TM,B,A,TT
10 FORA=0TO4:TIMER=0:TM=TIMER
20 FORB=0TO1000
30 LN=INSTR("YyNn",A$):IF LN=0 THEN PRINT"YES OR NO ONLY!":GOTO 20
40 ON LN GOTO 100,100,200,200
70 NEXT:TE=TIMER-TM
80 TT=TT+TE:PRINTA,TE
90 NEXT:PRINTTT/A:END
100 GOTO 70
200 GOTO 70

This produces 866.

John’s suggestion:

5 DIM TE,TM,B,A,TT
10 FORA=0TO4:TIMER=0:TM=TIMER
20 FORB=0TO1000
30 LN=INSTR("YyNn",A$):IF LN=0 THEN PRINT"YES OR NO ONLY!":GOTO 20
40 ON (LN+1)/2 GOTO 100,200
70 NEXT:TE=TIMER-TM
80 TT=TT+TE:PRINTA,TE
90 NEXT:PRINTTT/A:END
100 GOTO 70
200 GOTO 70

…jumps up to 1214! So, smaller code, but at a speed penalty. (See: Size versus Speed.) Brute force is often faster.

However, I also discussed converting characters to UPPERCASE so you only had to compare uppercase. That came with quite the speed penalty:

0 DIM A$,C:A$="*"
5 DIM TE,TM,B,A,TT
10 FORA=0TO4:TIMER=0:TM=TIMER
20 FORB=0TO1000
40 C=ASC(A$):IF C>=97 AND C<=122 THEN A$=CHR$(C-32)
70 NEXT:TE=TIMER-TM
80 TT=TT+TE:PRINTA,TE
90 NEXT:PRINTTT/A:END

That benchmark was 960.

John then presented a much faster approach by using strings and the INSTR command:

0 DIM A$,C,Z:A$="*"
1 AL$="aAbBcCdDeEfFgGhHiIjJkKlLmMnNoOpPqQrRsStTuUvVwWxXyYzZ"
5 DIM TE,TM,B,A,TT
10 FORA=0TO4:TIMER=0:TM=TIMER
20 FORB=0TO1000
40 Z=INSTR(AL$,A$): IF Z>1 THEN C=64+Z/2 ELSE C=ASC(A$)
70 NEXT:TE=TIMER-TM
80 TT=TT+TE:PRINTA,TE
90 NEXT:PRINTTT/A:END

That drops it a bit lower to 920. For a custom input routine, every bit helps make it keep up with faster typing. Nicely done! (He also notes that this assumes the character string is non-empty, which we’d ensure is the case if using an INKEY$.) And, remember that we could speed that up even more by changing the decimal numbers to HEX.

He also suggests using AND instead of my “C-32” subtraction:

In case of a conversion with A$=CHR$(ASC(A$)-32) this could be a slightly faster: A$=CHR$(ASC(A$)AND M) but only with a predefinition of M=223 (with constant 223 it would be slower!) which masks bit 5 (value 32) in the character code representation.

Challenge accepted:

0 DIM A$,C,M:A$="*"
1 M=&HDF '110111115 DIM TE,TM,B,A,TT
10 FORA=0TO4:TIMER=0:TM=TIMER
20 FORB=0TO1000
40 C=ASC(A$):IF C>=97 AND C<=122 THEN A$=CHR$(C AND M)
70 NEXT:TE=TIMER-TM
80 TT=TT+TE:PRINTA,TE
90 NEXT:PRINTTT/A:END

This returns 963 while my original using subtraction returned 960. It looks like AND is slower. HOWEVER, if you know the input is already ONLY “a-z”, you can just do the AND without the check. So, there is a use-case if you were scanning for “yYnN” and just AND the result and compare only uppercase….

It’s fun to think outside the box.

Any other suggestions?

Until then…

 

Arduino and the Texas Instruments SN76489

1 Reply

You may have never heard of the Texas Instruments SN76489, but if you are reading this article, there’s a good chance you have heard it.

The SN76489 is a sound chip which, according to the Wikipedia entry, was used in systems such as:

…and in arcade games such as:

…and many more. I am just naming the machines and games I have heard of or seen/played.

Side Note: The Wikipedia entry also claims the Sega Genesis used one, but it had far fancier sound. A quick search shows the Genesis did not use this chip, so other systems may also be incorrect. Ah, Wikipedia…)

This chip is able to produce three tones and one white noise at a time, which sounds an awful lot like the audio capabilities of my first computer, the VIC-20.

The chip has none of the fancy synthesizer features found in other chips, such as the famous Commodore 64 SID chip. The only thing you can do is adjust the volume level of each channel of sound. Clever software uses this to produce bell sounds and other effects. (If Congo Bongo is really using this chip, it’s doing some fancy things to make those bongo sounds!)

Thanks to StrongWare‘s John Strong, I now have one of these chips to experiment with. It is wired up to an Arduino Nano clone. (NOTE: I had issues getting this clone recognized on my Mac, due to it using a different serial chip. I found the solution, and wrote about it earlier this week.)

SN76849 sound chip hooked to an Arduino Nano on a neat 3-D printed platform from StrongWare.

John pointed me to this short tutorial on how to use the chip:

http://danceswithferrets.org/geekblog/?p=93

Using sample code there, I was able to get the device making tones, and then expanded it to play a sequence of tones to make a tune.

The next day I added more code so it could do a multitrack sequence.

I thought it might be fun to share what I have learned the first two days of playing with the device, and share the code I have come up with.

I will do a full article on the chip and how it works (summarizing some overly complex explanations I have been reading), but until then, here is my sample project:

https://github.com/allenhuffman/MusicSequencerTest

It contains routines to poke bytes to the SN76489, plus a work-in-progress multitrack music sequence that currently plays the 2-voice intro music to Pac-Man :)

I’ve been fixing up the comments and squashing some bugs, so check back for the latest. I still have to add real/better support for the “noise” channel, but it works right now for playing simple tunes.

More to come…