A new version of Drum8 supporting 8 simultaneous sounds and multi-channel audio output has been released.
Yeah its been quiet on this site lately. Between releasing the much anticipated Planimate 8 and starting on Version 9, supporting finalising our Supply Chain Sim product, working on a new project that combines Azure, Docker, Dotnet and Linux, finally building myself a new preamp for my bass (still to be written up) and other electronic repairs, I’ve hardly had the time to write anything here.
My current desktop computer is an Intel 5i7RYH NUC with 16GB RAM and 2 SSDs in it for a total of about 700GB of internal solid state storage.
Its got enough speed (2 cores, 2 hyperthreads each) for my needs and best of all, it generally runs very cool and quiet, using a magnitude less power than a desktop. Its basically a laptop without the screen, keyboard and battery.
There was one thing though. Since I bought it in mid 2015, I found it surprisingly prone to lock up / crash. I expected a lot better from an Intel own product.
I went through phases of blaming Windows 8 and the various Windows 10 releases, the Realtek sound drivers and even power management, since upping the minimum CPU speed in advanced power settings to 30% seemed to improve it (clue here). Throughout 2016 it was tolerable, and I blamed crashes on the fact that I abuse the little thing by running multiple VMs doing compiling, editing, simulation and video playing simultaneously.
The sound got my attention because a few times it crashed on the onset of video playback, resulting in a fragment of the sound looping until I power-button-reset it. Using Realtek’s drivers seemed to work for a while.
After the 2017 Windows 10 Creators Update though, it started to get unbearable, crashes and lockups started happening daily. I’d kept the BIOS and drivers up to date (and reset it after upgradde), disabled drivers I wasn’t using, ensured I was on the most recent VMWare (since that is all the host system runs), and checked logs for useful errors.
Around this time I was interested to read about Intel’s Hyperthreading issues with 6th and 7th generation CPUs. My NUC has a 5th generation processor – could it have a similar issue? I turned off Hyperthreading in the BIOS.
The machine was horrible to use after turning HT off, I couldn’t do much while a big compilation was going. That CPU hog, Teams, would bring it to a crawl if anything else was going on while you typed a message. But no matter how hard I pushed it, with stuttering audio playing while compiling, it never crashed once for a fortnight.
I certainly didn’t relish keeping HT off and thought I’d explore the abundant BIOS options Intel provides in the thing. Plenty of adjustment on speed stepping and voltages.
Increasing the core voltage by 0.15V didn’t help. Nor did disabling the Turbo Boost. It didn’t take long to find out what didn’t work.
In my research, I came across an old article which mentioned spikes in voltages as frequency changes kicks in causing problems. I’d already tried running in Windows’ “High Performance” power mode where the CPU never clocks down and that didn’t help.
I noticed the Processor Core Voltage Mode setting has a dropdown, defaulted to “Offset Only”.
And since then the NUC has been solid through some really crazy usage, like simultaneously compiling Planimate under Windows and Linux while docker containers build, with some HD video streaming in an alternate desktop so i can listen to it.
And no, a Windows update didn’t fix anything, I established the improvment during a quiet time for updates.
Intel went to the trouble to include so many tweaking options for this little machine. Could they have missed out on choosing the best defaults, or is this setting covering up a latent fault or cheap RAM? I suspect the latter.
So a badly implemented USB-C cable fries a phone if you charge if after a laptop.
I predicted this kind of failure as cables and controller chips age, but to have a new cable do it because of bad design proves how ill-conceived the variable voltage capability of USB-C really is.
It occured to me to look into the USB-C spec. A USB-C device can negotiate up to 20V @ 5A which is 100 watts of power. Compare this to USB 2’s 5V @ 500mA = 2.5W and even USB 3’s paltry 5V @ 900mA = 4.5W.
This means USB-C can potentially output 4 times the voltage at 5 times the current = 20 times the power of USB 3. Has anyone stopped to think of the failure modes here? It didn’t take me long.
Failure 1 – Intermittent Cable
What’s going to happen when you plug in your USB-C power guzzler which negotiates the port to 20V/5A. Then the 3 year old cable that’s become mangled, pinched and chewed partially shorts out? 100W will generate a lot of heat real quick (try holding a 100W incandescent light bulb).
Failure 2 – Loss of Voltage Regulation
USB 1 and 2 are a fixed 5 volts. This is most likely derived from a power rail supplying many other components, a fixed 5 volts carefully regulated by the system power supply.
USB-C offers negotiated variable voltage which will be generated by a local power converter (each port would need its own). The negotiation occurs when a device is connected to set the voltage/current limit. I sure hope they put a good checksum on that negotiation.
So, what is your USB drive or battery charger (which happily negotiated 5V upon connection) going to do when the inevitable g-g-glitch, power spike, electrostatic discharge or silicon failure ramps the port to its potential 20V limit (which is still ‘valid’ for the port)? What about unplugging a 20V device and the port not realising it (or latching up) before you plug in a 5V device?
With all those available amperes of current, the result will be spectacular. Voltage-overloaded devices love more amperes.
Maybe the “Safely Remove Hardware” option will take on a new importance.
Well publicised recalls of dodgy USB-C cables have already occured, and these are problems out-of-the-box. As hardware ages in the real world, I predict stories of fireworks and a market for bogus USB-C circuit breaker dongles.
The other evening I cranked my somewhat old HT system to test out a new USB optical audio interface. Next day I noticed a lack of treble in the left speaker. Hmmmm.
The main speakers are Yamaha NS200s, over 15 years old. At first I thought I’d blown the tweeter but continuity was OK and swapping with the right speaker’s was conclusive. Pulling the woofer from the bad speaker, I discovered a capacitor in the crossover had blown its end off. I cut it free.
Its a 160VAC 2.7uF paper capacitor. Without getting all fancy, I figured a 250V 2.7uF metal film polypropolene should be a suitable replacement. At my age I’m hardly a golden ear and modern polys seem to have a good reputation in crossovers.
I didn’t want to take the crossover out, its glued and stapled in place and mechanical things give me the shits. So I left a lot of the original leads in place and used barrier screw terminal blocks to attach the replacement cap, which is smaller and has radial instead of axial leads. Glued everything down (including the terminal block screws), with two screws per connection I figure it will be adequate given the speaker isn’t doing the deep bass anyway.
This shows the front of the HT setup, the room is huge so the 40″ TV (6 year old LA40B650) looks comically small but we usually watch TV from beanbags so its adequate.
The TOSLink SPDIF interface is a Turtle Beach Audio Advantage Micro II.
Its working extremely well feeding 5.1 audio to my Yamaha RX-V595 amplifier. The amp only supports standard AC3 and DTS, none of this modern 24bit 96kHz stuff. When that becomes a problem I’ll set up an external decoder or get a new amp, instead of downconverting it in the HTPC.
One note with the Audio Advantage – you need to install the driver from Turtle Beach’s website as the default that Windows 10 installs doesn’t offer the digital out. You can force Win10 to use the TB driver and that creates a separate digital out sound device. With that selected for my media player, all I had to do was enable SPDIF passthrough in my audio decoder (LAV Audio Decoder) and my amplifier’s display and AC3/DTS test files absolutely confirm that each speaker is being individually driven.
[EDIT:January 2018 Drum8 now supports 8 voices and stereo!]
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.
I got it working with the RainbowDuino software after some changes but
found it a bit slow, so I wrote my own library/driver for it which I’ve called “ARGB” as it does alpha blended graphics at good frame rates with up to 3 chained panels (though with 3 memory is pretty short given there is only 2K of RAM and my library works best with double buffering).
Here is my library in action, including the “disco clock” I’ve built for myself.
As the video was taken at 25Hz, it doesn’t do some of the effects justice as the panel refreshes far faster.
The ARGB library features fast line/box/circle/text drawing with RGB colour plus transparency, flicker free double buffering, fast data transfer to the panel (so more time for animation, text overlays) and real time clock timekeeping (useful so long as your Arduino has a crystal).
I’ve put the library (includes a simple demo) on github:
The display is refreshed at 125Hz with a line refresh rate of 800Hz. I’ve made my effects update at half the panel refresh rate, 62.5 Hz is fast enough for smooth colourful animations.
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.