Lately, I have been “playing” with the current version of Microware’s OS-9 realtime operating system. It is still very familiar to what I last knew when I left RadiSys/Microware in 2007, but with many interesting updates.
It took me a bit to remember how to use Ultra-C (Microware’s strict-ANSI compiler) and native operating system calls:
After doing the initial test using printf(), I decided to bypass the standard I/O library and see how much smaller the code would be. (From 12K to 2K, for those asking.) Nice. Though I’m still not sure why C produces such big code for such simple things ;-) Shouldn’t this just load a few registers and jump to an OS hook?
But I digress.
I expect I’ll start posting articles about OS-9, including high-level overviews of its architecture and things that make it unique. There are lots of things it offers that Linux doesn’t, though obviously, Linux wins hands-down when it comes to system support and full blown apps.
I ask of you: Should I post my OS-9 articles here, or should I split them out and make a blog on my old www.os9al.com site? Or maybe I just get rid of that site and archive those pages here, then point that domain to Sub-Etha Software?
In my previous DMX-RT post, I listed some of the problems I’d encountered. Today, I’m going to solve one of them.
I went through four DMX-RT units before I got one that worked. The first one was “dead on arrival” (no menu). The second one worked fine for a while (using a Kingston Class 10 MicroSD card), then died. The third had problems accessing any MicroSD card I gave it (reporting “no F”). Finally, the fourth unit appeared to work as expected, though I would find the loops would stop playing every now and then.
I exchanged numerous e-mails with Chauvet technical support during all of this, and wanted to pass along their recommendation about which MicroSD cards they “know” work in the unit. I tried Kingston, Sandisk, and a few others, but here is one they use:
I would hope that the 16GB Ultra PLUS would also work, but I wanted to get exactly what support was using to test my DMX-RT out. I let it run a loop overnight and it was still looping the next morning.
There is also a step up from this card — SanDisk Extreme PLUS — which is supposed to be a bit faster. I picked one of those up as well and ran some benchmarks.
First, here is the Kingston Class 10 Canvas Select card I was trying to use:
Kingston Canvas Select 16GB via Amazon (affiliate link). These are high rated and cheap ($3.54 as of this writing, as an add-on item). I have several of these I am using in Raspberry Pis with no issue.
In the above AJA System Test benchmark, nonie that the write speed (the blue line) jumps around. This could be a problem when recording DMX streams. The read speed seems okay, but dropped off at the end. Maybe this is why my unit would stop looping when using this card?
I also had an older SanDisk card that I tried:
SanDisk Ultra 32GB (not the PLUS model)
Notice that the read speed is only a bit faster than the Kingston, but the writes are a bit more flaky. I did not have success using this card in the DMX-RT.
SanDisk Ultra PLUS 32 GB – This is the card suggested by Chauvet for me to use.
Write speed is a bit faster, but read was a bit slower than the normal ULTRA and had performance dropouts. Interesting, considering this card seems to work fine.
SanDisk Extreme PLUS 32GB – This one I just tried for fun. It’s only a few dollars more, and it claims to be faster.
Wow! Look at those write speeds. They may be jittery, but they are fast. Read speeds were only a tad faster than the older Ultra card I had.
I don’t really know if any of this is useful. I’m happy just buying the card that Chauvet suggests, but I thought it might be fun to look at the others I tried to see if I could spot why they failed. (I do not have benchmarks for a few cards that seemed to die on me during the testing process.)
Coming up next will be a video showing off the Halloween project I am using the DMX-RT for.
When I do extensive searching on some topic, and can’t come up with any satisfactory results, I will often do a blog post with the results of my research. This helps it at least get indexed by the search engines for others following the same path.
You may disregard this post, unless you came here through such a search.
The Chauvet DJ DMX-RT DMX recorder/playback device is a cool little gadget.
2019-05-10: Added a link to CoCoWiFi article, and uppercased DELUXE.
TLDNR: See the video at the end.
In 2015, Sub-Etha Software rocked the retro world with the announcement of CoCoPilot. (And by “announced” I mean “posted a blog article about how to install DriveWire on a Raspberry Pi. And by “rocked” I mean “posted a block article about how to install DriveWire on a Raspberry Pi.)
In 2017, Sub-Etha Software raised the bar again by announcing SirSound, the serial port multi-voice sound “card” for the CoCo. (And by “raised the bar” I mean “posted another blog article”.)
In early 2018, Sub-Etha Software released details on CoCoWiFi, and showed you how to build your own for under $10 instead of waiting for Sub-Etha Software to actually manufacture them. (And by “released details” I mean “posted yet another blog article”.)
In late 2018, Sub-Etha Software shocked the CoCo Community with the proposal to end all proposals: PreciousPak. (And by “shocked” I mean “posted a block article about something I think would be really cool but don’t have the hardware skills necessary to make happen so I hope someone else will do the work for me, please and thank you”.)
And now, in 2019, Sub-Etha Software is proud to announce…
CoCoPilot DELUXE is the result of dozens of man-minutes of thought on the subject of “what should I do with all the Raspberry Pi stuff I have on my desk?”
Much like how PreciousPak solves all our problems when it came to CoCo cartridge add-ons, CoCoPilot DELUXE strives to solve all our problems when it comes to CoCo bitbanger serial port add-ons. (And by “solves all our problems” I mean “wouldn’t this be fun to play with?”)
With CoCoPilot DELUXE plugged in to your CoCo’s built-in Serial I/O port, you will have:
WiFi Modem – Use any existing CoCo terminal program, and be able to telnet, ftp, etc. to internet servers just as easily as you used to call in to dial-up BBSes in the 1980s.
SirSound – Use the simple BASIC “PLAY” command strings that you already know and love, except add a “#-2,” and change PLAY to PRINT, and then you can play multi-voice background music while your BASIC program does other things.
DriveWire Server – Use NitrOS-9, SDC-DOS or the special DriveWire version of HDB-DOS to access virtual floppies over the serial port. Under NitrOS-9, you also have access to other DriveWire features such as virtual printing, virtual MIDI, and virtual reality. Except maybe not that last one.
Print to PDF – Print from any CoCo program (including graphics programs such as CoCoMax, ColorMax, Max-10 and Max Headroom) and have the dot matrix output be rendered as a PDF file you can then print on a modem printer. It can even print the old green bars and fake tear-off strips with the holes in it, just like the olden days!
CoCoPi Emulation – This portable device can also be expanded with an option USB keyboard, USB mouse, and HDMI monitor to act as a virtual CoCo running various Color Computer emulation programs.
In this list, there are a few “new” things we can’t currently do. Printing from CoCoMAX 3, Tandy Home Publisher or any other graphical print software is not currently possible (is it?). A new layer would be written to interpret common printer “driver” codes (Tandy, IBM, Epson, etc.) — including color — and render the incoming data to an image that represents all the dots the printer would have printed. (Heck, we could even emulate the old plotter printer thing.)
SirSound could work the same as the hardware SirSound (API compatibility), but could be expanded to do more voices, and use better sounds. The Pi has simple libraries that can product multi-voice music.
WiFi Modem would be similar to the CoCoWiFi (Zimodem) project, but the “AT” Hayes Smartmodem commands would be different since we’d just use one of the many “serial to network” programs/scripts readily available.
All we need is a bunch of software, an RS-232 interface for the Pi, and some switches to select which mode you want the CoCoPilot DELUXE to be in.
This was shown off last weekend at the Chicago CoCoFEST! Remember that this is a 1986 computer with no sprite hardware, no sound chip, and only 16 colors on screen at a time (out of a palette of 64), and running at 1.8mhz. And Simon breaks all of these rules.
2019-05-03: I’ve had a report of my build not allowing you to type. I have seen this before, and am investigating this. Anyone else having issues? Also, I missed something in my merge which may have affected over-the-air updates (AT&U). I am pushing out a new build. Also, added a screen shot showing 3.5. Also, note about no ESP32 build.
2019-05-04: I started over with Bo’s unmodified source code, then did my changes to zimodem.ino and zcommand.ino. I am still seeing the issue where, via USB serial connection, I can’t type of my TTL-to-RS232 adapter is hooked up. Without it, it works fine. I need to do some testing via the CoCo with it’s bitbanger and RS-232 Pac ports to see what behavior I get. In the meantime, I appreciate your feedback.
Yesterday I updated my fork of Bo Zimmerman’s ZiModem. My custom fork is 100% his code, with only some configurations changed to make it default to standard RS-232 signals instead of inverted like the Commodore uses. (Basically, it’s what his “Guru modem” firmware defaults to, and the over-the-air update changed to point to builds on my service. Guru modem only builds for ESP32, so eventually I just need to figure out how to modify the project so it builds Guru modem for ESP8266, I think.)
NOTE: I only built for the NodeMCU-12E ESP8266 module and the generic ESP8266 (whatever that is) module. I did not have ESP32 libraries installed so there is no build for that currently.
If you want to pull the source code and build it directly through the Arduino IDE, you can find my fork here:
NOTE: If you have the ESP8266 wired up to a TTL-to-RS232 adapter, you may find that firmware updates will not work. On my device (using the full-signal TTL adapter and a NodeMCU ESP8266), I had to unplug the 3.3V power wire that goes from ESP8266 pin to the TTL-to-RS232 board. That was enough to make firmware updates work. I’m still not sure why having the TTL adapter hooked up affects loading firmware over USB, but apparently it does.
A final option is to use the ZiModem built-in over-the-air update capability, which we haven’t gotten to test yet since this is the first time I’ve updated firmware for the CoCoWiFi fork. That is done through the command:
That should grab the latest build on my server. I believe it reads a .txt file from my server to get the version number and builds the filename out of that, then downloads that filename. You can also specify the version manually. Currently, there is a 3.4 build and a 3.5 build available on my site.
Please let me know if this works for you. You should see the startup banner (1200 baud) show 3.5:
Original instructions on this WiFi modem for $10 can be found here:
I am hoping to find time to update my fork of ZiModem firmware for the CoCoWiFi project, and also dig out some more goodies to donate to the Glenside Color Computer Club for their fundraising auction. If nothing else, maybe I can get those items there with some others that will be passing through Des Moines on their way.
NOTE: I do not own an Arcade1Up, but I have a friend who has the Centipede version. I am posting this article to give some extra exposure to research he and others are doing on the trackball problems.
Arcade1Up is a 3/4-sized 80s arcade cabinet for home use. They have several units available, with most playing four classic arcade games (and one special edition with 12 games).
The Centipede unit has a vertical monitor and comes with Centipede, Missile Command, Millipede and Crystal Castle.
After first playing my friend’s unit, we both agreed that Centipede played very poorly. This led him to dig into the problem, and he found this Do-It-Yourself solution on YouTube:
The trackball is a rotary encoder where, as it spins, a little wheel turns and is either blocking or allowing light to flow through and be detected by a light sensor. The software counts the pulses and determines how far the wheel has spun. (Here’s the Arduino playground on them.)
The stock encoder wheel has 30 spokes, and this D-I-Y solution shows how to make one with 24. My friend decided to try it and designed one on his 3-D printer. After installation, Centipede does indeed play much, much better, and the other games seem to still play as well as they did before (they were mostly fine, so I can’t tell if there was any significant improvement without doing a side-by-side comparison with an unmodified cabinet).
I think we could convince him into making these replacement parts available at a low-cost for folks who don’t want to DIY. Comment to this post if you might be interested.
Until then… There is an active discussion on Reddit about various problems, solutions, and modifications to the Arcade1Up machines. Be sure to drop by there check it out.