Recovering a slightly broken Vocore

OK, I managed to mess up the network settings on my Vocore. Oh well, it happens. It's not too bad... the device was still booting up and running... but was not accessible by Wi-Fi or by plugging in a network cable. So it's back to a good old serial connection. This is what I have done:

I've used a USB to Serial 3.3v TTL cable that I already had, and then just poked some jumper wires into the right places. Surprisingly it seems good enough. Anyway, in case I need to do this again, I thought that it would be worth taking a photo. I'm using PuTTY on a Windows box as the terminal. The settings I'm using are:

  • Speed: 57600
  • Data bits: 8
  • Stop bits: 1
  • Parity: None
  • Flow control: XON/XOFF

I connected the USB-to-serial cable first, then opened the connection using PuTTY. You then have a blank terminal screen. Then I connect the power to the Vocore, and you get to see all the logging information as the device boots. After a couple of minutes I press enter in the terminal and end up with the usual OpenWrt startup screen. After that you can use the console like normal. Anyway, it's handy to have that written down somewhere, because I'll probably break it again at some point. But I can report that I was able to fix the network config and things are back to normal now. Phew.

Vocore: mounting USB drives

So my next piece of work on the Vocore was to mount the filesystem from a USB stick. I found some instructions here. So I started adding all the necessary kernel modules, hoping that it would be as simple as getting the USB soundcard to work. It wasn’t quite that easy. I thought that I had done everything, but just got strange messages when I tried to mount the disk. Then I found this helpful link.

It described exactly what I was seeing. In short, you can’t rely on the error messages being returned by mount on OpenWrt. So to diagnose the problem, the most important thing was using the logread command to get some ideas why the USB drive was not mounting. In my case (I was mounting a vfat formatted thumbdrive) I needed to add support for Codepage 437 and ISO 8859–1 into the kernel. So when building OpenWrt, I needed to go into Kernel Modules -> Native Language Support, like this:

But both those character set problems were quite clear from the log entries, so working out what I needed to do wasn’t that difficult … once I knew that I should not trust the error messages being returned by mount.

And I did find some more detailed information about filesystems and character set problems here … albeit for a different type of device, but I think the principle is the same.

Anyway, as soon as I added the extra modules for the correct character sets then everything came to life and I could mount the USB disk. Happy days. So now I can play audio files from USB storage, which works great.

This is a journey into sound...

So I decided to try and get some sound out of my Vocore tiny linux box. It doesn’t come with any audio support, so I decided to add a USB sound card. I bought one of these, which I knew worked on the Raspberry Pi, so I knew had Linux support. They’re also pretty small:

I simply followed these instructions describing how to add USB Audio support to OpenWrt. At first, I chose to install sox as the player (I originally intended to use Madplay, but I don’t think it is supported on current versions of OpenWrt anymore).

I did not have much success playing mp3 files straight away, I kept getting sox WARN alsa: under-run messages when I tried to use the following command:

sox myfile.mp3 -d

Although sound was coming out … in chunks, so it was a partial success. But when I added a “-G” parameter to use temporary files (supposed to guard against clipping) like this:

sox myfile.mp3 -d -G

…then it worked fine for some lower quality mp3 files, but with a considerable delay before playing anything out the speaker. If I tried to play some better quality mp3 files then it was still stuttery. So then I started to experiment with reducing the sound quality, which sox can do easily. So I tried this:

sox myfile.mp3 -r 8000 -e unsigned -b 8 -c 1 test.raw

…which results in a raw file that can be played with the aplay command that comes with the ALSA soundcard drivers (specifically, the command above gives mono unsigned 8 bit with a rate of 8000 Hz). Whilst this results in a poor quality file, I found that the Vocore would happily play these raw files. In some ways it was kinda cool to hear my original mp3 file playing with a hiss in the background. But then I decided to see what happens if I create a file in “CD” quality, so I tried this:

sox myfile.mp3 -r 44100 -e signed -b 16 -c 2 test.raw trim 0 00:30

Note, that to save space on the Vocore I used the trim parameter to just convert the first 30 seconds. Playing that “CD” quality file on the Vocore also worked perfectly, with this command:

aplay test.raw -f cd

Passing the parameter -f cd means 16 bit little endian, 44100 Hz, stereo and is the same as passing -f S16_LE -c2 -r44100. Here’s a screenshot of a CD quality raw file playing on the Vocore with the aplay command.

So… what I’m doing now is using sox on another Linux box to convert the mp3 files and then just using aplay on the Vocore to play them. It should mean that sox is not actually required on my Vocore. It also means that playback is immediate and the quality is good. I will need to find a means to store the files, because they’re much bigger than mp3, but that’s a problem for another day… I’ll probably see if I can mount a USB stick or something.

Retro clock LED driver plugin

I thought that I'd lost this code, but now I've found it in a dusty corner of my hard disk. It works with the USB LED Driver that I wrote some time ago. It's a different clock plugin, where each digit scrolls into view as if the clock had four rotating wheels for displaying the numbers.

If you're using my driver, then you might like to give this a try, I certainly like it.

All you need to do is extract the .cs file from the zip here and put it in the folder where the driver is installed (usually C:\Program Files\Hobbsindustries\LED USB Matrix Driver). The next time you start the driver you should see the extra option as an available plugin. Enjoy.

Emulating from DR-DOS on a memory stick

I decided that it would be cool to have an emulated PDP that was bootable from a memory stick.  Then I could simply boot from a USB pen drive straight into a PDP-11.  To do this, I decided  to use a different emulator than SIMH - Ersatz-11.  It's free for hobbyist use.  Not only does Ersatz-11 have a good DOS based emulator (meaning that you don't have to boot into Windows first) but I believe that it will give access to the physical COM ports, althought I have not tried that feature yet.  I tried to get it to run under FreeDOS, but whilst Ersatz-11 would start; I could not get it to read any disk images.  So in the end I switched to DR-DOS, which was harder to install... but ran the emulator without any errors.

Here are some brief notes on how I got it working (from a Windows 7 machine):

- Make an empty FAT formatted USB pen drive bootable into FreeDOS with unetbootin
  Just select FreeDOS 1.0 under 'Distribution', and then select your pen drive at the bottom and click OK.
  This was the easiest way I found to make a DOS type boot disk, but we don't actually want FreeDOS.
- Now, make a DRDOS folder on your pen drive and save the DR-DOS binaries in there
  [I'm using version 7.01.06]
- Make a DRSYS folder on the pen drive and save the DR-DOS varant of FreeDOS SYS binaries in there
- Download and copy the Ersatz-11 DOS files onto an E11 folder on the pen drive
- Copy your own PDP-11 boot disk image to your pen drive

Now we can reboot and start FreeDOS from the pen drive.  When asked, boot into FreeDOS as a simple LiveCD, we don't need more than that.  It should boot to drive A: and your pen drive will appear as another drive (for me, it was drive C).  Now try the following (WARNING! this assumes your pen drive is now C, change the drive letter if your one is different, don't blame me if you mess up your hard disk):

 C:
 cd DRSYS
 sys C:\DRDOS C:\
 cd \

 copy C:\DRDOS\*.* C:\
 del C:\*.img
 del C:\ub*.*
 del C:\*.cfg
 del C:\*.c32

The pen drive should now be bootable in DR-DOS rather than FreeDOS, so reboot and start from the pen drive again.  [There will be a LDLINUX.SYS file left over from FreeDOS that we can't delete right now.  If you want to, come back and delete this file by plugging your pen drive into another machine with a better OS.]

You should now be able to start Ersatz-11, with something like this:

cd E11
E11
MOUNT DU0: C:\boot.dsk
BOOT DU0:

That's it!  You should be able to emulate a PDP-11 under DR-DOS.  In Ersatz-11, hit <SHIFT>+<ENTER> twice to stop emulating, then type 'exit' and press enter to quit to DOS.  If you put the 'mount' and 'boot' commands into a file called E11.ini inside the E11 folder and create an autoexec.bat file in the root of the pen drive to start the emulator, the pen drive should automatically boot into the emulation from now on.