In case you missed it, in December 2016, a software update to CoCoSDC and SDC-DOS was released. You can find it under “Latest Firmware” on this page:
http://cocosdc.blogspot.com/
SDC-DOS is now up to version 1.14 and includes the following changes:
AUTOEXEC. If “AUTOEXEC.BAS” if found on a mounted disk image, it will automatically run on startup. Holding down SPACE on startup will bypass this. (I think Kenton’s RGB-DOS did this?)
EXP. A new “EXP” command has been added. It will mount an image called “SDCEXP.DSK” and, if present, run “AUTOEXEC.BAS” from that image.
DEF DW. You can now specify DriveWire baud rates.
WRITE/COPY MEM. These commands can now write to flash pages $FExx on a CoCo 3.
RUN @bank. Code to select and execute one of the virtual ROM banks has been rewritten to make it more compatible with various ROMs.
DSKINI. Fixes a bug where drive motor could remain on when using a CoCoSDC and a real floppy controller at the same time.
The update comes with a .DSK image that you mount and then run a utility which will take care of the upgrade.
Nice! I just started setting my CoCo system back up, and will be trying this out soon.
2016/05/12 –This is a work-in-progress article I originally wrote on February 8, 2015, but never completed. The other night I was trying to look up my notes to help Curtis B. with a NitrOS-9 boot disk and I realized I never completed this. I will try to finish it when I have a moment.
Summary
To get DriveWire 4 server running on a Raspberry Pi, you will do the following:
Download the DriveWire server to the Pi and unzip it: wget http://sites.google.com/site/drivewire4/download/DriveWire4_4.3.3.zip unzip DriveWire4_4.3.3.zip cd DriveWire4_4.3.3.zip
Edit the config.xml file to default to your serial port on your Pi in <deviceType> and <serialDevice>. (i.e., “serial” and “/dev/ttyUSB0“)
Run the server with no user interface: java -jar DW4UI.jar -noui
On the CoCo, load the needed DriveWire modules from NITROS9/6x08L2/MODULES/RBF: dwio.sb, rbdw.dr, x0.dd up to x3.dd
Use the “dw” command to test things by creating a blank disk image: dw disk create 0 /home/pi/test.dsk format /x0 dir /x0
Customize your boot disk to include the modules you want and read the documentation to learn how to use all the cool virtual terminals, MIDI and other neat features.
And now, the long version…
Materials Needed
Raspberry Pi B (or B+, or probably the Pi 2 B). I did all these steps on a B.
USB keyboard (a mouse makes things easier, but I do not have one so all of these tips will just use a Pi, keyboard and HDMI TV/monitor).
Compatible* 8GB SD card (or larger).
Ethernet cable to hook the Pi to the Internet. (Required if you plan to do the network install of NOOBS LITE).
WiFi (with a supported USB dongle) or Ethernet is needed later for downloading the DriveWire software and updates, but there are ways to do all of this without any Internet access if you start with the full NOOBs installer.
Compatible* USB serial adapter (or TTL->RS232 converter for use with the built in UART pins of the Pi).
…
Preparation on Windows/Mac/Linux
Download the “NOOBS” installation for Raspberry Pi (currently 1.3.12). You can get the full NOOBS (780MB, just unzip and copy to the SD card and boot), or the NOOBS LITE (22.8MB) version.
NOOBS LITE can also be used. It is a much smaller download, but requires the Pi to be hooked up to the internet via Ethernet to download the rest of the OS files which is about 2355MB. http://www.raspberrypi.org/downloads/
Unzip the files, then copy them over to a freshly formatted SD card.
Preparation on the Raspberry Pi
Boot the Pi using this card. You will see a menu of operating systems you can install. Choose “Raspbian [RECOMMENDED]” at the top by using the arrow keys and SPACE to select. You may also wish to hit “l” for Language and set it to “English (US)” or your preference, and “9” for Keyboard and select yours. Once Raspbian is selected, press “I” for install. It will ask if you are sure you wish to overwrite the SD card. Select “Y” for yes.
NOOBS LITE: The Pi will then download the Raspbian image (2.3GB), then install.
NOOBS: The Pi will then install.
The Pi will (eventually) reboot and after a bit, you get a DOS-like screen for the raspi-config utility. Arrow over to Finish and press ENTER. You will not be at the Pi shell prompt. pi@raspberrypi ~ $
At this point, I like to do a full reboot to make sure everything is working properly: sudo reboot
On a reboot, you won’t go directly to a shell prompt. You will get a login prompt. The default account is: username: pi password: rasbperry.
Log in and you will get back to the shell prompt. You will be in the home directory for user “pi”.
Now we need to download the DriveWire 4 software. Note the filename will change when DriveWire is updated, so check the official site if this does not work. wget http://sites.google.com/site/drivewire4/download/DriveWire4_4.3.3.zip
After the zip file is download, you can extract it by typing: unzip DriveWire4_4.3.3.zip
DriveWire 4 is set up to run with a nice GUI with mouse control. This requires a keyboard and mouse, and the Pi to be set up with X-Windows running. Since I do not have a mouse, and plan to run the Pi headless with nothing hooked up to it but power and the CoCo, this is not an option for me. Instead, I need to manually edit the configuration file to tell it what Linux serial port I will be using. cd DriveWire4_4.3.3 copy config.xml config.xml.org (always keep a backup!)
pico config.xml
The editor will open, and you want to look for a few entries:<instance category=”instance” desc=”Autocreated 2013-03-24 23:57:53.831″ name=”TCP connection via TCP“>
…
<DeviceType category=”device” list=”serial,tcp-server,tcp-client,dummy” type=”list”>tcp-server</DeviceType>
…
<SerialDevice category=”device” type=”serialdev”>COM14</SerialDevice>The first entry is just the name of the connection. You could change that to “Serial Connection” or whatever. The second “tcp-“server” should be changed to “serial”, and the “COM14” entry should be changed to your serial port device. On my Pi, when I plug in a single USB RS232 adapter, it shows up as /dev/ttyUSB0 so that is what I use.
Save your changes back to the file (Ctrl-X, Y) and now you are ready to run the server without a user interface. (Getting the user interface to run requires installed two more additional packages, and I will make a tutorial for that soon, if anyone wants me to.) java -jar DW4UI.jar -noui
After a bit, Java will load and the DriveWire 4 server will start. Java is big, and the Pi is small, so it can be quite sluggish. Now, with the USB cable connected between the Pi and the CoCo, you can start testing.
Preparation on NitrOS-9
This tutorial is being written for someone who already has an active NitrOS-9 system and wants to add DriveWire support to it. If you have no customized
If you are using one of the default NitrOS-9 disk images for you system, it should have a NITROS9 directory, and inside of it will be various device drivers and descriptors, including the ones used by DriveWire. Ultimately, you would want to make a custom boot disk that includes these modules, but here is a simple way to merge them together and just load them when you want to use them. From OS-9:
If you are running a stock CoCo 3 with the standard 6809 processor, go here:
cd /dd/NITROS9/6809L2/MODULES
…and if you have upgraded your CPU with a Hitachi 6309, go here: cd /dd/NITROS9/6309L2/MODULES
The modules you want depend on what you plan to do. Here is the list:
drio.sb – this module handles all communication with the DriveWire server.
rbdw.dr – RBF device driver that uses DriveWire for disk access instead of disk hardware
ddx0.dd, x0.dd, x1.dd, x2.dd, x3.dd – device descriptors for the DriveWire disk drives (/x0 to /x3, with ddx0.dd being a /dd descriptor for DriveWire).
scdwp.dr – printer driver
p_scdwp.dd – device descriptor /p for scdwp.dr
scdwv.dr – virtual serial port driver
n_scdwv.dd, n1_scdwv.dd to n13_scdwv.dd – serial port descriptors. /n is the “next available” descriptor, similar to /w for windows. /n devices may also be used for MIDI.
midi_scdwv.dd – this is n14 but named /midi for MIDI programs that are hard coded to look for that name.
term_z_scdwv.dt, z1_scdwv.dd to z7_scdwv.dd – (??? not in the doc wiki)
For my example, I am only concerned about the disk drives, so I would merge the following modules together: chd RBF merge dwio.sb rbdw.dr x0.dd x1.dd x2.dd x3.dd >/dd/dw
This gives me a single file called “dw” I can load to get DW support instantly. First, I need to set the attributes to allow that: attr /dd/dw e
…then I can just load it when I want to use DriveWire: load /dd/dw
If this worked, you should now be able to use the DriveWire command, “dw”, to communicate with the server. Type “dw” and it should report back a list of commands: config disk log midi net port server
…and you can then type “dw config” or “dw disk” to see what all it can do.
Using DriveWire
Here is an example of creating an empty disk image and formatting it:
dw create 0 /home/pi/test.dsk
format /x0
dir /x0
If you look on the Pi, you will see a new file “test.dsk” there. You can now use this disk like any other OS-9 disk. In my test, I copied my NITROS9 directory over to it just for fun:
chd /dd/NITROS9 dsave /x0 ! shell
DriveWire’s performance is not as good as you’d get from a No Halt floppy controller like the Disto Super Controller 2 or a hard drive interface like the Cloud-9 SuperIDE or KenTon SCSI. As disk activity is going on, interrupts are masked while data is blasted out of the bitbanger port. Still, it did a remarkable job keeping up with my typing. Quite impressive for a cheap cable and a $35 computer with a serial port.
TO DO
Make the DriveWire 4 server auto-start.
Update the DriveWire 4 software from the command line (is this even possible?).
Update the Raspberry Pi software.
Problems
One issue I immediately ran in to was a bunch of ERROR #207 (Memory Full) errors. mfree still showed 352K free, and it wasn’t the #237 (RAM Full) that happens when there isn’t enough room left in the main 64K memory map.
2-20-2025 – Updated location of NitrOS9 project, and changing instructions to use “git” instead of Mercurial for that step.
Since I have to relearn all the steps, I thought I would post them as I go through them. The NitrOS-9 website has a tutorial on building it, but here are my steps with some specifically for Mac OS X:
Install the Command Line Tools for Mac OS X.
We need the command line versions of the Mac OS X compiler so we can build the tools that are then used to build NitrOS-9. If you have XCODE installed, you may already have them. An easy way to do this is from a Terminal prompt:
xcode-select --install
That will launch the Apple Mac App Store installer and get the tools for you. Cool.
Installing the Mac OS X command line tools.
Download Mercurial.
The NitrOS-9 repository now uses git as version control. You will need to download a git client, or use the GitHub Desktop app. I just learned about this change today (Feb 2025) so I need to update these steps.
Toolshed and LWTools use Mercurial, so you will need to download that as well. On macOS, you should be able to install it using “brew install mercurial”:
brew install mercurial
Download LWTools.
These are the cross-compiler tools used to build 6809 source code from Mac/Windows/Linux systems. From a Terminal prompt, find a directory you want to download the lwtools to. I chose a poor location — “CoCo” inside my Downloads folder:
pwd /Users/allenh/Downloads/CoCo
From this directory, use the “hg” command to obtain and build the tools. It will build the directory you specify from the command line (“lwtools”):
hg clone http://lwtools.projects.l-w.ca/hg/ lwtools cd lwtools make sudo make install cd ..
Build Toolshed.
Next we want to build Toolshed. This is a series of command-line utilities that operate on CoCo/OS-9 disk images (like those used with emulators and the CoCoSDC interface). Once again, I do these steps from my “Downloads/CoCo” directory:
hg clone http://hg.code.sf.net/p/toolshed/code toolshed cd toolshed sudo make -C build/unix install cd ..
(Note: I had to use “sudo make…” here to get it to build on my system.) The different build/make process shows the different styles of the various developers that made these tools. (Note: Mine seems to fail looking for a command “markdown” at the very end. Not sure what this is, but it seems to be building HTML documentation or something.)
Build NitrOS-9.
Now we are ready to download and build NitrOS-9. Once again, I start in my “Downloads/CoCo” directory, and issue the following git commands to download all the NitrOS-9 stuff:
git clone https://github.com/nitros9project/nitros9.git cd nitros9 make dsk
This will build absolutely everything, including tons of ports and disk images you likely do not want. After this, you will have all the sources, and have built all (or some) of the sample disk images for various types of hardware (CoCo 1/2, CoCo 3, 6809 or 6309, CoCoSDC controller versus floppy or IDE hard drive, etc.).
If you are only interested in a CoCo 3 6809 setup, why build all the CoCo 1/2 and Dragon versions, or any of the 6309 stuff? I always build everything, but you can also specify to build just a specific port. For my CoCo 3/6309 build, I could do this instead:
make dsk PORTS=coco3_6309
For stock 6809 CoCo 3:
make dsk PORTS=coco3
Updating NitrOS-9 and the Tools.
Later, if you want to update your sources, you can use this command from the “nitros9” directory:
git pull make ask
For updating LWTools and Toolshed, use this:
hg pull
hg update
…then the build steps, shown earlier.
NOTE: David Ladd has pointed out that you may want to clean out old files before rebuilding. For Toolshed, I needed to do this first:
hg pull hg update make -C build/unix clean make -C build/unix
I do this occasionally to get the “latest and greatest.” You can do this for the other tools, too, by changing in to their directory then issuing the “pull” and “update”, then the appropriate make command.
TODO: This next section was from when NitrOS9 was at SourceForge and used Mercurial. I have not had a merge conflict using git yet, so I don’t know what those look like. I will try to update this document later.
If you get a merge conflict because you changed something locally, you might see this:
hg update abort: outstanding merge conflicts
You can use this command to see what files have been changed on your local repository that conflict with the master files. This happens if, for instance, you tweak a makefile or build list or source code:
hg resolve -l
U 3rdparty/utils/tlindner/sdir.asm
This reminded me that I already Tim’s “sdir” source code (for CoCoSDC) so enable built in help and such. I have to revert those changes if I want to update, or learn how to use the merge too… I forgot!
These steps should get you everything you need to begin playing with NitrOS-9 on a real CoCo with the CoCoSDC interface, or an emulator. If you plan to use real floppies, you can use toolshed utilities to format and then copy disk image .DSK files over to the physical floppy, but I don’t have any way to hook a 360K Floppy drive to my Mac so I have never done this. CoCoSDC is the way to go there.
Tandy/Radio Shack TRS-80 Color Computer fans, take note. This weekend (April 23-24, 2016), the Glenside Color Computer Club will be hosting the 25th annual “Last” Chicago CoCoFEST! in Lombard, Illinois (near Chicago).
I attended the first “Last” CoCoFEST! there back in 1992, flying up from Lufkin, Texas with a CoCo friend of mine, Mark. That 1992 event was presented by Dave Myers of CoCoPro, and Glenside was the host club for it. Dave had gotten in to the CoCo convention scene in 1990 when he held his first CoCoFest in Atlanta, Georgia, with the Atlanta Computer Society as the host club there.
These CoCoFests were being started just as the long-running RainbowFests were winding down. Rainbow Magazine was the premier Color Computer publication, starting out as a photocopied newsletter and growing to a 300+ page monthly periodical. Rainbow had years where they held several events across America, but their last event was in Chicago in 1991.
Dave first stepped in to offer an event “down South” in 1990. Rainbow had held only one southern event in Ft. Worth, Texas. When the final RainbowFest was held, Dave decided to continue the tradition with a new event in its place.
Though CoCoPro would exit the convention scene after that 1992 event, the CoCo clubs continued. Atlanta Computer Society kept CoCoFests going there through 1995. The Glenside CoCo Club has continued to host events ever since the original CoCoPro event in 1992 (and they were host club for the RainbowFests before that). But this year is the last one. Again.
Dave chose the “Last” (in quotes) moniker for his first Chicago-area event knowing it could be the final event, and it become the “2nd annual ‘Last'” event the following year when Glenside took over.
Then the 3rd … and 4th … and 5th…
It’s hard to believe that was 25 years ago!
I last got to visit the CoCoFEST! in 2013. I would like to at least day trip to this one. Several long-time CoCo folks from the past are showing up (including our own monk, Brother Jeremy, and our Canadian pal L. Curtis Boyle). I have had several generous offers to provide lodging if I wanted to stay overnight, and even offers to fund my gas. These are some of the people I have called friends longer than just about anyone else I still have in my life.
If you can make it, and I am there, be sure to say hi. If I am not there, be sure to take photos and let me know what I missed.
Over the years, there were a number of cool ideas at Sub-Etha Software that I really wish we’d followed through on. Last year, I mentioned some unfinished software projects I uncovered when going through all my old floppies, but there were also a few hardware projects that never made it out of the idea or concept stage…
Reveal VM100 “voice mail” device for PCs.
For instance, once I found a low-cost gadget at Walmart that interfaced a telephone line to a computer. It was controlled by a serial port, and plugged in to the audio in/out ports of a sound card on a PC. It came with software to turn the PC in to an answering machine.
I bought one to hook it up to my CoCo, and had plans to create a simple CoCo answering machine. On a 128K CoCo 3, it would be possible to play a short greeting, and record a short message from the caller then save it out to disk. Sure, the audio quality would have been poor and it would probably be cheaper to just buy an answering machine, but wouldn’t it be fun?
VM100 ready to hook to a CoCo via cassette cable and RS232 pak.
Concept software was witten (in assembly) to record audio from the VM100 (using 1-bit cassette input, or 6-bit joystick input) as well as play back digital audio.
I was even wanting to do touch tone decoding in software and create a simple voice mail system with mailboxes. There was even a plan to create a “telephone adventure game” where a description would be read and the user could make a choice by pressing buttons on their phone. (Years later, the Tellme company did something similar with a version of blackjack you could play over their 1-800-555-TELL demo line. It was so cool, Microsoft bought them!)
Woulda, coulda, shoulda…
I will try to share some more of these “lost” projects in the future, but today I wanted to focus on a virtual reality project I was working on.
VR was a big buzzword in the early 1990s, and many thought it was going to be the next big thing. As we know know, it fizzeled out rather quickly, with Atari, Sega and Nintendo abandoning their home VR products.
The Sega VR project has a CoCo connection, since one of the launch titles was being worked on by legendary CoCo game programmer Steve Bjork**! I believe this is the game that Bjork was working on: Iron Hammer
Nintendo’s effort eventually came out as the failed Virtual Boy where, instead of wearing an immersive helmet over your eyes, you peered in to a 3-D viewer that remained stationary on a table. Hey, at least they tried!
But I digress…
In the pre-world wide web days, we had things called catalogs which were like paper versions of Amazon.com. One of the catalogs I received always had interesting items often at cheap liquidation prices. One such item was the VictorMaxx Stuntmaster VR helmet. The wiki page claims this was the very first commercial VR helmet made available.
TODO: I need to add a photo of my VR helmet, as soon as I figure out which storage box it is in.
The Stuntmaster wasn’t a real VR helmet, though. It did not provide a stereoscopic display, and did not have any head tracking capability for use with true VR games. Instead, there was an analog dial on one side that connected to a shaft which you clipped to your shoulder. As you turned your head left or right, the shaft would turn the dial, allowing a simulation of left/right head tracking.
You could plug this helmet up to a Sega Genesis game console and then play some games where you held the game controller to play, but used your head to turn left and right. It seems unlikely that this would have worked well with any games not specifically designed for this, but hey, it was the first.
Here is a video of it in all it’s glory:
Virtuality’s Dactyl Nightmare (I am shown here playing it in Dallas in 1994) had a helmet and a hand grip controller that featured a trigger and a thumb button.
When I saw this in the catalog, I immediately ordered one to see if it could be used with the CoCo. My plan was to send CoCo video and audio to the helmet, then wire the left/right control shaft up as a joystick. Taking a nod from the controls of the Dactyl Nightmare arcade VR game I played, I was going to use the two joystick buttons for “walk” and “shoot”. My thought was you could turn your head left or right, then walk in that direction using the button. I guess I was thinking we’d build a special pistol grip controller to work with the helmet.
I had become friends with Vaughn Cato*, who did the original bouncing ball demo when the CoCo 3 first came out. He had been writing routines to do bitmap scaling and such, and I was hoping to use some of this in some CoCo game projects.
3-D maze engine by Vaughn Cato. It ran under OS-9.
On of the coolest things he created was a 3-D maze engine that drew everything using lines (I guess we would call this a vector engine). It looked similar to Dungeons of Daggorath but you could move through it in all directions, like Wolfenstein 3-D or DOOM did.
I cannot remember why, but for some reason the demo executable was called toast. It would read a small text file that represented the maze, then you could walk through the maze in 3-D. Things never went much further than the demo, but I thought it would work well with the VR helmet as the basis of some kind of VR maze game.
I think I was planning to create something like Phantom Slayer VR (a tribute to the old MED Systems 3-D maze game by Ken Kalish). I certainly know I had worked on this concept before without VR in mind, as well as a 3-D Pac-Man game. The Pac-Man one was interesting, as I got as far as recreating the original Pac-Man maze in 3-D and had it populated with dots you could walk over to “eat.”
Woulda, coulda, shoulda…
I still have the helmet. Who knows . . . maybe some day CoCo VR might still get done, even if there is no longer a supply for helmets to make it a sellable product.
*Vaughn Cato may be the only former CoCo guy to accept an Oscar. He was working with a company doing motion capture and he was on stage to receive a 2005 Technical Achievement Award. That’s quite the trip from a bouncing ball demo on a TRS-80, don’t you think?
**Steve Bjork has also had encounters with movies. If I recall correctly, he was an extra in films like Rollercoaster and The Goonies, as well as working on movie related video games like The Rocketeer and The Mask. Oh, and his CoCo program Audio Spectrum Analyzer appeared in Revenge of the Nerds, and his CoCo Zaxxon program appeared in Friday the 13th Part 4.
2016/1/19 – Added reference to earlier article about more memory for BASIC (and an excerpt about why BASIC is that way). Also added reference to Juan’s comment on improving the program. Added link to Facebook CoCo group.
2016/9/2 – Removed a duplicate line in the 2nd listing. Maybe fixed a typo or two.
On startup, a cassette-based CoCo has 24871 bytes available for BASIC.
Recently, Richard Ivey became the latest person in the Facebook TRS-80 / Color Computer group to ask how to tell if an old Radio Shack Color Computer had 64K without opening the case. The problem has to do with backwards compatibility. When the original Radio Shack TRS-80 Color Computer was released in 1980, it was sold as either a 4K or 16K system. Later, a 32K model would be available, and the Microsoft COLOR BASIC would give about 24K of free memory (with the rest of the memory used by the video display, cassette buffers, BASIC input buffer, etc.).
Update: See this earlier article about getting more memory for BASIC. Here is an excerpt:
64K NOTE: The reason BASIC memory is the same for 32K and 64K is due to legacy designs. The 6809 processor can only address 16-bits of memory space (64K). The BASIC ROMs started in memory at $8000 (32768, the 32K halfway mark). This allowed the first 32K to be RAM for programs, and the upper 32K was for BASIC ROM, Extended BASIC ROM, Disk BASIC ROM and Program Pak ROMs. Early CoCo hackers figured out how to piggy-pack 32K RAM chips to get 64K RAM in a CoCo, but by default that RAM was “hidden” under the ROM address space. In assembly language, you could map out the ROMs and access the full 64K of RAM. But, since a BASIC program needed the BASIC ROMs, only the first 32K was available.
When 64K upgraded became available, the original BASIC would still only report about 24K free since it had never been modified to make use of the extra memory. Thus, typing “PRINT MEM” on a 32K CoCo 1 shows the same thing it does on a 512K (or greater) CoCo 3.
So how do you tell? One easy way is to just try to load a program or game that requires 64K and see if it works. But, if all you have is the CoCo, there is a short program you could type in to test. (NOTE: See a better listing later in this article.)
10 READ A$:IF A$="X" THEN END
20 POKE 20000+N,VAL("&H"+A$)
30 N=N+1:GOTO 10
40 DATA 34,01,1A,50,10,8E,80,00
50 DATA B7,FF,DE,EC,A4,AE,22,EE
60 DATA 24,B7,FF,DF,ED,A1,AF,A1
70 DATA EF,A1,10,8C,FE,FC,25,E8
80 DATA 10,8C,FF,00,24,0C,B7,FF
90 DATA DE,EC,A4,B7,FF,DF,ED,A1
100 DATA 20,EE,35,01,39
110 DATA X
Thanks to Juan Castro for passing this along. I reformatted it so no line would be longer than the 32 column screen, hoping it makes it a bit easier to type in (though it does make the program longer, needing more, shorter lines).
On a 64K CoCo, this program will copy the ROMs to RAM and then switch in to all-RAM mode. RUN it, then type EXEC 20000 to execute it.
I believe this is the classic “ROM TO RAM” (or ROM2RAM) program that appeared somewhere in Rainbow magazine back probably around 1983. Basically, it places the system in to 64K mode (where memory addresses &H0000 to &HFFFF are all RAM) and copies the COLOR BASIC and, if installed, the EXTENDED and DISK BASIC ROMs in to that upper 64K so the system can still work.
If you type this in on a CoCo 1 or 2, then RUN it, it loads a small machine language program in starting ad memory address 20000. After this, you can type “EXEC 20000” to execute that machine language program. If you typed it in correctly, it should just return to BASIC and nothing should seem any different.
But, at this point (if it worked), the BASIC ROM is now in RAM, which means you can POKE to those memory locations and make changes.
Juan suggests an easy hack of changing where the prompt “OK” appears. He says:
Now try POKE &HABEF,89 — OK should become OY.
It worked for me in the Xroar emulator (configuration to emulated a 64K CoCo 2):
The BASIC “OK” prompt is changed to read “OY” (after placing the 64K CoCo in to all-RAM mode).
Thus, if you can run this program without it crashing, and that POKE works to change something formerly in ROM, your CoCo is operating in all-RAM mode and must have more than 32K.
In the future, I will have to track down a simpler way to test for 64K. Until then, happy typing…
Update: In the comments, Juan suggested making the following changes, so the program will execute the machine language program for you:
10 READ A$:IF A$=”X” THEN 35
20 POKE 20000+N,VAL("&H"+A$)
30 N=N+1:GOTO 10
35 EXEC 20000:POKE &HABEF,89:END
40 DATA 34,01,1A,50,10,8E,80,00
50 DATA B7,FF,DE,EC,A4,AE,22,EE
60 DATA 24,B7,FF,DF,ED,A1,AF,A1
70 DATA EF,A1,10,8C,FE,FC,25,E8
80 DATA 10,8C,FF,00,24,0C,B7,FF
90 DATA DE,EC,A4,B7,FF,DF,ED,A1
100 DATA 20,EE,35,01,39
110 DATA X
With those changes, now all you have to do is type RUN and it will load the machine language program, execute it (to copy ROM in to RAM), then poke the “OK” prompt to say “OY”. Thanks, Juan!
I met Carl England at the very first Atlanta CoCoFest, I believe, back in 1990. If it wasn’t the 1990 one, it was certainly 1991. I have been a fan of his work ever since. His SuperBoot utility was on virtually every RS-DOS disk I owned that had stuff I wanted to run by typing “DOS”. He is also the guy that demonstrated a Tandy DMP105 printer with an add on that turned it in to a full page scanner. It’s a pity that never made it to market. It was way ahead of its time.
Today I found out Carl has also written a fiction book. He is looking for enouhg nominations on Amazon to get it published. If you don’t mind, take a look:
This evening, I saw a reference to something called an ESP8266. A quick web search revealed it was a $5 WiFi chip that was mentioned last August 2014 on Hackaday:
As of this writing it has only been about six months since the discovery. At the time, little was known about it beyond some documents in Chinese and some early attempts to write code to use it. Today, however, you can find this part on Amazon for $7.99 with Prime shipping, or much cheaper on e-Bay with slow shipping from China:
The chip can been hooked up to a UART (transmit and receive), or via SPI. This means, with a cheap TTL-to-RS232 adapter and a power supply, you could WiFi enable anything with an RS232 port with a bit of communications software.
The next time I have a few spare bucks, I plan to order one and see how easy it is to work with. It could be a fun way to WiFi-enable a CoCo or Arduino :)
And for those curious, here is a tutorial on using it I found:
Please leave a comment if you have worked with this chipset. It seems it might not take much to make a C library for Arduino that mirrored the official Arduino WiFi shield API, but used this inexpensive part.
Last year, I designed an adapter that would let me use original CoCo (or Tandy 1000) analog joysticks on a modern computer via USB. I also designed an opposite adapter, which would let a modern USB controller be used on an old CoCo or Tandy 1000.
I ordered all the parts for a prototype, and did some quick tests to prove that it worked… And then promptly moved on to other things.
Eventually I found some time and I dug out all of these parts and began wiring things up again. My hope was to have a few things available to sell at the Chicago CoCoFEST this past April 25 and 26, 2015. (Money is very tight here, so any thing I can do to generate some extra income is a good thing.) I was unable to go, so did no more work on the project.
Rather than collect dust, I thought I’d share my work so far in this article I originally started working on last February.
The hardware components I have will allow several things:
For the CoCo
Use modern USB joysticks/gamepads on the CoCo
Use modem Bluetooth wireless joysticks/gamepads on the CoCo
Use modern USB keyboards on the CoCo
Use modern Bluetooth wireless keyboards on the CoCo
For Mac/Linux/Windows
Use an original CoCo/Tandy 1000 joystick as a USB input device
Use an original CoCo/Tandy 1000 joystick as a wireless Bluetooth input device
Use an original CoCo keyboard as a USB keyboard
Use an original CoCo keyboard as a Bluetooth wireless keyboard
As you can see, there are two main goals (use modern stuff on a CoCo, or use old CoCo stuff on a modern computer), with a focus on USB or wireless Bluetooth. All of these are possible, with the cost of doing Bluetooth about the same (or maybe a few dollars less) than USB.
My current prototype reads a PC USB joystick and turns that in to a CoCo-readable analog joystick. I also wired up CoCo joysticks to use on my Mac (very direct and easy).
The keyboard stuff also interests me. I plan to order the Bluetooth part I need so I can embed it inside my CoCo, hooked to the keyboard connector, and use an external battery powered Bluetooth keyboard on my CoCo.
The other combinations are not high on my project list since I do not even own a wireless Bluetooth gamepad or controller (unless my OUYA console controller can be used). However, when I get to that point, I may be able to find someone I can borrow one from for testing.
My eyesight took a hit last year, and now I can no longer focus on things more than a few feet away so I probably won’t do much until I can afford a new set of glasses ;-) Mid-40s is trying to make me think I’m no longer in my mid-20s!
Sub-Etha Software is proud to announce plans for its latest bit of vaporware: The CoCoPilot DriveWire Server, or “CoPi” for short.
The CoPi is a tiny device (which is approximately the size of a Raspberry Pi in a case) that comes with everything you need to have a functioning DriveWire server without having to keep your Mac or Windows machine nearby and powered on just so you can type “dir /x0”.
Pricing is to be announced but hopefully it will be around $50. Kit versions will also be available so you can just buy the bits you need in case you already have some of the other bits.
CoCoPilot Configurations
Turnkey – This is a “plug and go” version, where all you have to do is install the DriveWire drivers for NitrOS-9, or load the appropriate RS-DOS software (like the special DriveWire version of HDB-DOS), and plug it in. It comes complete with the server hardware, power supply, server-to-CoCo interface device (often called an RS232 cable), and internal solid-state boot device (sometimes called an “SD card”).
BYOE – The bring-your-own-everything edition is shipped as a set of simple instructions that will let you transform a boring Raspberry Pi in to the amazing CoCoPilot DriveWrite Server. All you have to do is provide the Raspberry Pi, SD card, RS232 adapter and CoCo serial cable. And do a bunch of typing*. And downloading. And editing. And configuring. But the end result is you have everything that the Turnkey edition has at a fraction of the price.
Custom – Also planned to be available are various custom configurations. Already have a Pi? Don’t need another CoCo serial cable? Our custom configuration engineers are ready to custom tailor your order.
Pricing
We estimate complete pricing will be around $50. Or maybe $60. But probably not more than $75.Unless someone really wants to overpay for this.
Availability
The first working prototype was just turned on last night. Quit rushing us. We’ll announce availability when it is ready.
For more information, be sure to follow this blog.
(In case you didn’t get it, I started working with DriveWire on my Raspberry Pi. I will try to document all my steps to make things easier for you if you want to try it. And if you just want a Pi already setup, I’ll probably be able to do that as well.)
* Actually, it’s not really that much typing. I will have a full “from getting a Pi, to using DriveWire” tutorial next. But if you already know your away around the Pi, you pretty much can boot a freshly installed Pi, login and type:
wget http://sites.google.com/site/drivewire4/download/DriveWire4_4.3.3.zip
unzip DriveWire4_4.3.3.zip
cd DriveWire4_4.3.3
Then, you have to edit the “config.xml” file to tell it what serial port you are using. For instance, if you plug in a USB-RS232 adapter, it might appear as device “/dev/ttyUSB0”. You just edit the file and change two bits:
Tada! Now your DriveWire-enabled CoCo should be able to start issuing commands to the server.
However, DriveWire has many more features that you can only get to using the DriveWire GUI. If you have a display, mouse and keyboard hooked to your Pi, you can instead run the GUI like this:
startx
That will start up the X-Windows desktop GUI on the Pi. Now all you have to do is run the DriveWire GUI. One way to do this is by opening up a Terminal to get to a shell prompt (Ctrl-Escape -> Accessories -> Terminal).
But wait! The GUI requires a few elements that are not part of the default Pi Linux installation, so you need to add them first by typing:
Now you can do things like update the DriveWire software and many other things you cannot do without a mouse (apparently).
Check back later for a full, step-by-step article on taking a fresh out-of-the-box Pi and turning it in to a DriveWire server. (Or I can sell you one already configured.)
