Finally finished some software I started nearly 30 years ago, and I don’t mean Planimate!. Drum8 is a drum machine written in assembly language for Apple IIs with a DAC board.
When I bought an Apple //e in the mid 80s (replacing a very hacked Apple ][+) it came with a small card with a speaker on it called “SAM – Software Automatic Mouth” which allowed the Apple to talk.
The SAM card was an 8 bit DAC, implemented with a latch, DAC chip and amplifier for the speaker. I’d connected it to my sound system and discovered I could get pretty good crunchy 8 bit sound playback (less noisy than the Mac+ I also had at the time, no dither noise).
Around the time I’d written a drum sequencer that triggered a real 70’s era analogue drum box through the 4 game port annunciator outputs. One of the Mac music programs had some drum samples and I tried playing them using the SAM card. It worked great and in 1987/88 I ended up writing a 16 channel / 4 simultaneous voice mouse driven drum machine for the Apple II+ and //e.
Unfortunately the SAM card got left behind in a move and its a rarity on eBay. Recently after researching a few DACs and even an R-2R ladder option, I found an interesting chip that had promise, the AD558. This is pretty much a one chip solution. Internally calibrated, running on a single 5V supply, direct CPU bus compatibility and with a buffered output, it can be configured for a 0 to 2.8V output, perfect for a line level audio out.
From the AD558 datasheet and Apple II reference manual, I came up with this circuit:
The only additional passive components are:
- 0.1uF power decoupling capacitor – unpolarised greencap, 25V rating would have been enough, the one I had was double that.
- 6.8uF electrolytic capacitor. This blocks the DC offset in the 0-2.8V output, giving a ±1.4V output, which should be plenty as its going into my mixer.
- 20kΩ resistor, this is there to let current charge the blocking capacitor if the output isn’t connected (avoiding a transient on connection), I’d originally thought 10kΩ but settled on it after finding it first, its value is not critical.
I used an Apple II prototyping board which are still available here, an Apple II slot card which includes solder pads yet breaks out all the port pins to a wire wrap header. I initially planned to wire wrap it all, but I hadn’t ordered a wire wrap socket (and the pins might not have easily fit through the plated-through holes anyway), so I used one of the spare 20 pin sockets I’d recently bought to fix my mouse card, carefully ignoring the extra holes as the AD558 has 16 pins!
With the 8 data inputs on the AD558 arranged neatly in a sequence that corresponds to the data bus on the Apple slot connector, I directly soldered them to the connector using stripped wirewrap wire which, being silver plated, is a breeze to solder. For me it involved a lot of bright lights, looking through a number of magnifying glasses and some patient assistance from my wife, Oak.
Keeping the solder from running up the length of the slot connector was not easy, I eventually discovered that gravity can be your friend. For each of the 8 data bus wires I attached the slot end first then stretched the fine wire to its pin on the socket, (which I’d soldered in first) so it was just a case of heating a pin up so its corresponding wire could be slipped next to it, then the remaining wire cut off.
I took these photos as part of inspection, you can see the 8 fiddly data wires at the bottom right. Ignore the solder along the top edge of the board, its just strain reliefs for the line out cable.
On the row opposite the data pins on the AD558 (pins 9-16), a few adjacent pins need to be bridged. I ran a wire across them, trying to avoid touching the board itself as all the slot pin have traces criss-crossing to the wire wrap header (on the right on the photo below). If the thin insulation on the board was breached by solder, things would get unpleasant. I took particular care to keep away from the 12V line (pin 50 on the slot connector) as really bad things happen if that gets into TTL chips. I know from childhood experience.
Looks real classy doesn’t it.
The proto board’s half solder/half wire wrap design is really not ideal for building much on the board itself. I think it was intended to have a daughter board (eg: Arduino) hang off it. I would have preferred either bigger holes just for wirewrapping or a board without the wirewrap header and associated traces across most of its area, other proto boards have little pads for soldering to at the slot connector.
I did use wire wrap and the wire wrap header to connect to the device select, read/write and power lines. I’d bought the tool and wire after all, and wanted to stay away from the slot connector after my experience with the data lines.
Mounting the capacitors and resistor was uneventful and I ran the audio to the shielded audio cable at the top of the board with little consideration for what its crossing along the way, fully expecting I’d deal with noise later, once I’d tested the board.
With the card in slot 5, writing alternating 1, 0, 2, 0, 4, 0, etc to $C0D0 generated progressively louder clicks. Both the SAM software and my drum machine worked perfectly first time.
The audio output is surprisingly quiet given the unshielded wires and cross-crossing bus on the board. Plus I’m running without any special power supply regulation for the DAC, the AD558 has its own internal reference. What a great chip, glad I bought a few as I’ll have to do something for the Arduino with one or two.
My Apple //e mouse card was not being detected, and looking at its ROM (at $C400 when in slot 4), there was clearly a problem, the top 2 bits were random whereas the bottom 6 matched a ROM dump (apple2.org.za is a great resource).
I suspected a bad PROM, a common problem in equipment of this era. I arranged a replacement, a 2716 EPROM is compatible and Stephen from http://www.hobbyroms.com promptly burnt one and posted it to me.
Unfortunately it did not fix the card. Looking more closely at the hex dump, I realised the top 2 bits were being flipped to one OR zero, whereas bits in an aged PROM usually revert to 1 (confirmed by Stephen).
This didn’t leave much to fail, the card was being properly addressed for 6 of 8 bits to be working and continuity for all the data lines was good.
The one possible culprit was a 74LS245 bus transceiver, and of course it was the odd chip that wasn’t socketted.
Desoldering it from a double sided board with plated through holes was very tedious (big thanks to Oak given my vision). I took the approach of cutting the chip off first then working on each leg individually from both sides of the board. I cant say I recommend this, I was really worried given the through holes and fine tracks on the component side, but it measured intact after the holes were cleared.
The chip was replaced with a 20 pin socket and, thankfully, each pin had good continuity to its destination, no wirewrap wire hacks needed.
With a chip installed, the card has come good, I’ve left the new EPROM in there too.
During the break I spent some time playing with my Apple //e, recently set up after some 25+ years of neglect. Last year I replaced the PSU mains cap (common failure) and explored the excellent Apple ][ Disk Server and the Game Server – who could have imagined the cassette port transferring at 9600 bits per second! I didn’t have a joystick, which ebay has since solved, but given my vision I won’t be making any high score tables.
The //e is connected via composite video to my Samsung 27″ monitor/TV. I was very disappointed with the clarity of text, 80 column mode was unreadable even with the monitor on maximum sharpness. I remembered a far better display on the tube tele in the 80s.
The computer has a “text mode” switch on the motherboard. This cleared it up, but I don’t want a monochrome //e. I also noticed the monitor did give a clear picture for one second when I connected the video signal.
I figured I was suffering from chroma signal bleed through, forcing my monitor to interpret the signal as colour, and I’d need the color killer mod. This seemed confirmed by the picture clearing up if I snubbed out the PAL colour chroma oscillator with my finger.
My //e is a PAL version and I played with the 2 PAL chroma pots which adjust the background tint as a side effect of balancing the colour signal. I noticed they had no effect in text mode. Yet the text was equally blurry in text or mixed text/graphics mode.
Before the mod, I decided to at least set the chroma trimpots properly (for a black background in graphics mode) and I also tweaked the chroma frequency capacitor trimmer (this affected the moire patterns but not much else). I did this in mixed text/graphics mode with some text at the bottom.
To my surprise, as I approached the optimal position for the two chroma trimmers, the text sharpened up better than it had ever appeared on this monitor.
More importantly, in full text mode, it still looked great, as well as in 80 column mode and even 80 column + graphics. The chroma pots were still having an effect in text mode, even though the background colour didn’t reflect their setting.
I suspect that balancing the chroma signal properly prevents some noise reduction system in the monitor from kicking in, leaving a full bandwidth display in both text and graphics modes. In graphics mode the individual colour pixels are distinct, the best I’ve ever seen a PAL Apple ][ do (having never experienced a pure NTSC set up, let alone RGB).
So now no color killer mod needed.