XMODEM Baud Rate Mod for RC2014

Many users of the RC2014 retro computer have had difficulty getting XMODEM file transfers to work. At least part of the problem seems to be that the standard baud rate of 115200 bps is way too fast for the 7.3728MHz Z80 processor to handle. Unfortunately neither the MC68B50 ACIA used on the original RC2014 Serial I/O module nor the Z80 SIO used on the current Dual Serial SIO/2 module has an internal baud rate generator. Both boards simply feed the bus clock to the chip to generate a fixed baud rate of 115200 bps. This mod shows how to change the baud rate for one common RC2014 configuration, using the Dual Serial SIO/2 with the Dual Clock module.

The Dual Clock module generates two clocks. The CLOCK signal on pin 21 of the standard bus is used by the processor and related peripherals. The CLOCK2 signal on pin 21 of the enhanced bus is available for other uses. Each clock can be jumper-selected to a variety of rates, including divide-downs of the fast 7.3728MHz clock corresponding to standard baud rates down to 4800.

The Dual Serial SIO/2 module supports two serial ports. Port A is the primary port, wired to the RX and TX pins on the standard RC2014 bus, while Port B is wired to RXB and TXB on the enhanced bus. Port A is wired to always use the CLOCK signal from the standard bus. Port B uses the CLOCK2 signal from the enhanced bus. If the system doesn’t have a clock source connected to the enhanced bus, jumper JP1 on the Dual Serial SIO/2 module can be used to connect the two bus clocks together.

If we have both the Dual Clock module and the Dual Serial SIO/2 module, we can easily vary the baud rate of Port B by moving the clock rate jumper for CLOCK2 on the Dual Clock module. Unfortunately, lots of software (and some hardware, such as the Pi Zero Serial Terminal) assumes that Port A is the console port and also used for file transfer, so it doesn’t really help that we can set the baud rate on Port B. We can also vary the baud rate on Port A, again by moving the corresponding clock rate jumper on the Dual Clock module. Unfortunately, this changes the CPU clock as well, so as we slow down the baud rate we also slow down the CPU by the same factor. That doesn’t help with the problem that the CPU can’t keep up with the baud rate. We need to be able to lower the serial baud rate without slowing down the CPU clock. We will have to modify the wiring of the Dual Serial SIO/2 module to make this possible.

The SIO chip has five clock inputs. Pin 20 is the bus clock, which must be the same as the Z80 CPU clock. Pins 13 and 14 are the receive and transmit clocks for Port A. Pins 28 and 27 are the receive and transmit clocks for Port B. We need to separate pins 13 and 14 from pin 20, allowing pin 20 to remain connected to the CPU clock on the standard bus. Then we will need to connect pins 13 and 14 to some slower clock source.

We could choose to add a new baud rate generator for Port A. If we copied the divider circuit from the Dual Clock module, we’d need three ICs and a 2×10 header, which would be a lot of circuitry to bodge onto the Dual Serial SIO/2 board. Other circuit designs might be smaller, but still painful to add to the board. Let’s just use the existing clocks already available from the Dual Clock module. We could choose to simply use the CLOCK2 signal from the expanded bus, which is already available on the serial board. That would mean that Port A and Port B always used the same baud rate. If that’s a problem, we could instead run a flying lead from the clock select jumper pins on the Dual Clock module to Port A on the serial module. This mod accommodates either option.

On the Dual Serial SIO/2 circuit board (as of version 1.0), the wiring that connects pins 13, 14, and 20 is on the component side of the board, and is hidden under the IC socket for the Z80 SIO2. I didn’t want to remove that 40-pin socket to cut traces. Instead, I lifted pin 20 of the chip out of its socket and jumpered it directly to the CLOCK signal on the standard bus, right on the bus pin. Then I cut the trace from the bus pin to the rest of the board. That isolates the traces that connect pins 13 and 14 of the chip and also one side of JP1, the jumper that was intended to bridge CLOCK2 to the standard bus CLOCK. See photos.

IMG 8101

IMG 8103

Now we can install a jumper at JP1 to connect Port A’s clock inputs to CLOCK2, and run both Port A and Port B at the baud rate corresponding to CLOCK2. Or, we can run a flying lead from any baud rate we choose from either clock rate jumper header on the Dual Clock module to the Port A side of JP1 on the Dual Serial SIO/2 module, and run them at different baud rates.

IMG 8104

IMG 8127

I tested with the version of XMODEM for CP/M that is named XM.COM in version 2.9.1 of RomWBW. On the host side, I was running minicom 2.7 under Raspbian on the Pi Zero Serial Terminal board. I found that XMODEM transfers from the host to CP/M were perfectly reliable at 9600 baud, yielding a transfer rate of about 870 bytes/second (to RAM disk or to CompactFlash), about 90.6% efficient, on large files. I found that XMODEM transfers didn’t work at all at 19200 baud with this configuration.

Here’s a video of XMODEM working at 9600 baud on the RC2014: (YouTube)

RC2014 Remote Reset Mod

I usually operate my RC2014 Z80-based retro computer using the Pi Zero Serial Terminal module. This RC2014 module hosts a Raspberry Pi Zero and connects the Pi’s main serial port to the serial RX and TX lines on the RC2014 bus. It is intended to be used with PiGfx, a bare-metal ANSI terminal emulator. The idea is you’d hook up a monitor and a USB Keyboard to the Pi Zero, and use it locally as a standalone dumb terminal. It’s a brilliant solution, especially since actual terminals are getting hard to find.

I don’t use it that way. I prefer to run Raspbian on the Pi Zero and use a terminal emulation program (typically minicom) to talk to the RC2014. In local mode, Raspbian makes much prettier text on the screen (as of the version of PiGfx I tried), even using the composite video output. What’s more, Raspbian supports networking so I can use the RC2014 without sitting right in front of it. Raspbian of course supports all flavors of the Raspberry Pi, so I can use a Raspberry Pi Zero W instead of a plain Zero, and get built-in WiFi networking. PiGfx doesn’t yet support the Zero W, though it is on their TODO list.

So my typical working configuration has me sitting across the room from the RC2014, at a Mac with several large monitors, connected to the Zero W via ssh over WiFi, running minicom to communicate with the RC2014. There’s a problem with this setup, though. Given the parlous state of most of the software I’m trying to run (or write) on the RC2014, it’s just not that unusual that I need to push the reset button. Getting up and walking across the room to push the reset button seems inelegant. It’s also enough of a pain that I will waste time trying to find a way to un-stick the Z80 from the serial console to avoid doing it. I need a reset button I can activate remotely.

Luckily there are plenty of unused GPIO pins on the Pi, and it’s pretty easy to interface one of them to the /RESET signal on the RC2014 bus. That’s what this mod does. We’ll use GPIO4, because it’s mechanically handy and not shared with any other functions on the Pi. Note that it is not OK to hook these signals up directly, since /RESET is a +5V signal and the Pi is only rated for +3.3V.

Reset mode schematic

The transistor pulls the /RESET signal down to ground when GPIO4 is high. When GPIO4 is low, the transistor does nothing.

2N3904 pinout

Unplug the Raspberry Pi from the Serial Terminal module. We’ll be installing the components on the Serial Terminal module underneath the Pi.

There’s lots of room on the module circuit board that’s not used. Hold it up to the light to see that there isn’t even a ground plane over most of the area of the board. Drill five holes as shown below. I used a #66 drill bit, but the diameter of the hole isn’t critical. The lower three holes in a triangular pattern are for the transistor. The upper two are for the resistor; the right hole is near the base of the transistor, and the left hole is approximately over the fourth pin from the left of the Raspberry Pi connector. The two resistors shown here are standard parts on the Serial Terminal module. I drilled the holes freehand. Just get them close.

IMG 7956

Install the components on the front of the board. Make sure the transistor is oriented with the flat side toward the Raspberry Pi connector, as shown. You’ll need to bend the transistor’s leads out a little to reach the holes. Make sure the transistor sits reasonably close to the board, so it won’t interfere with the Raspberry Pi.

component placement

Make the connections on the back side of the module board. One side of the resistor and the base of the transistor are adjacent, so just bend the leads together, solder, and trim. The other side of the resistor should be able to reach the Raspberry Pi connector; bend it over and solder it to the GPIO4 pin, which is the fourth from the end. Use some wire if it doesn’t reach. The emitter of the transistor is close to the end of the pre-existing 22K resistor that just happens to be GND, so bend that lead over to touch the existing pad, solder, and trim. Add a piece of thin solid wire (I used 24 gauge telephone wire) between the collector of the transistor and the /RESET pin on the RC2014 main bus. /RESET is two pins over from the +5V pin, which has traces connected to it. There’s no particular need to insulate or strain relieve any of these connections, but you might want to drop a bit of superglue on the two longer leads. Re-install the Pi.

Connections on the rear side

Now we just need a bit of software to function as our reset button. Here’s what I came up with. Name it rcreset.py


import RPi.GPIO as GPIO

GPIO.setup(4, GPIO.OUT)
# no extra delay required; the pulse is about 10 uS naturally

# don't call GPIO.cleanup(), we want the pin to stay low.
# That's why we turn off warnings above; when we run this
# program a second time it would warn that we were already
# using the pin.

I chose to use Python because Python. I chose Python 3 instead of old-fashioned Python because 2019, though this script would probably work the same either way. I chose RPi.GPIO instead of gpiozero because the startup time for gpiozero seemed excessive. This script runs in about 650ms, which is fast enough. There are lots of other ways this script could be written.

As noted in a comment in the script, the pulse generated is usually about 10 microseconds long. Raspbian is not a realtime operating system, so it could be longer. The Z80 data sheet calls for the reset pulse to last for at least three full clock cycles, so this pulse will work for any Z80 clock faster than about 400 kHz. If your clock is sometimes slower than that, you might want to insert an appropriate delay into the script. Reset won’t work at all if the clock is stopped.

You’ll need to adjust the permissions of the Python script:

chmod +x rcreset.py

You’ll probably want to place it somewhere on your regular search path, such as /usr/local/bin.

Finally, we need to deal with how GPIO4 behaves when the Raspberry Pi starts up. By default, it starts out as an input with a weak pull-up, and stays that way until the boot process is nearly complete, and then switches to a high impedance state. The initial state holds the RC2014 in reset for many seconds, and then the high-impedance state leaves it vulnerable to spurious resets due to noise. We could use a similar Python script on startup, but that won’t run until rather late in the boot process, and if we happen to be using the local console we’ll be stuck waiting for the Raspberry Pi to boot up for no good reason. Instead, let’s use some magic words to get GPIO4 configured early in the boot process. Make sure you’re running a version of Raspberry Pi firmware that’s newer than March 18, 2018, and add these lines to /boot/config.txt:

# Drive the GPIO pin used by RC2014 reset as early as possible

With those magic words, GPIO4 goes low within a second or two of power-up, and stays that way. Much better.

So now when I’m sitting across the room and the RC2014 locks up on me, I open another ssh session to it and type


I could also use a local command on my Mac or Linux host. This could be assigned to a hot key or other shortcut to eliminate all the excess typing:

ssh pi@rc2014.local /usr/local/bin/rcreset.py

This works best if ssh has already been set up to authenticate to the Pi without requiring a password. Like this.

One final note. If you also use the RC2014 Dual Clock and Reset module, there’s a potential issue with contention on the /RESET line. I have a mod for this, too, which I recommend you install before installing the remote reset mod. See my previous post for details.


P.S. The reset script can be run from inside minicom, so there’s no need for a separate session.

1. On the Pi, create a directory to contain minicom scripts, if you don’t already have one. I named mine .minicom and put it in the home directory.

2. Create a script file inside that directory. Name it something like rcreset and put this in it:

! /usr/local/bin/rcreset.py

3. Run minicom. Ctrl-A O to open configuration. Choose Filenames and paths. Choose C to enter the script directory path. Enter /home/pi/.minicom or whatever you called your script directory. On the way out of the configuration menu, choose Save setup as dfl to make the change permanent.

Then to reset the RC2014 in minicom, hit Ctrl-A G to run a script. The first time, you’ll need to hit C and type in the name of the script (rcreset). Then hit enter to run it. Thereafter in that session you can just hit Ctrl-A G Return to reset the RC2014.

/RESET Mod for RC2014 Dual Clock and Reset Board

One of the modular components of the RC2014 Z80-based retro computer system is the Dual Clock and Reset Module. This board (as of version 2.1) actively drives the /RESET signal with a 74HCT04 inverter. This means that if any other component wishes to reset the system, it has to contend with that gate and short its high output to ground. For example, the Backplane Pro has a hard switch for /RESET, which literally shorts the signal to ground. While you can get away with this sort of thing most of the time, it’s theoretically possible to blow up the 74HCT04 this way.

I could have just disconnected the 74HCT04 from the /RESET signal and used the button on the Backplane Pro for manual resets. However, the button on the module is more conveniently placed. What’s more, the reset circuit on the module generates a power-on reset, which is very handy. I wanted to preserve these functions of the module. Here is what I came up with, showing the relevant part of the module’s schematic as modified.

Dual Clock mod schematic 01

We do disconnect the 74HCT04 U1 from /RESET, but we replace it with a 2N3904 NPN switching transistor. This acts as an inverter, just as U1B did, but it only drives actively when it’s pulling the signal low. For mechanical convenience, we pick up both the input and the output signals from P1, a 3-pin header intended for selection of either RESET or /RESET to connect to the RESET2 signal on the extended bus. I don’t use RESET2 and never installed that header. If you use this header, you’ll have to come up with a different mechanical arrangement.

Note that this assumes there is a pull-up resistor somewhere on the /RESET signal. All of the official RC2014 backplanes (the Backplane Pro, the Backplane-5, and the Backplane-8) provide such a pull-up.

Prepare a 1K resistor and a 2N3904 transistor as shown below. Solder one end of the resistor to the base (center lead) of the 2N3904. Bend the emitter lead out to one side.

Resistor connected to center pin of transistor

That’s a quarter-watt resistor, but if you have a smaller one handy, it would fit better. The value is not critical at all. Any NPN switching transistor would probably work fine, too, as long as you get the pin assignments right. This shows the pin assignment for a 2N3904:

2N3904 pinout

Now drop the assembly into the Dual Clock and Reset board, as shown below. The free lead of the resistor goes into pin 3 (RESET) of the P1 header, and the unbent collector lead of the 2N3904 goes into pin 1 (/RESET) of P1. The bent emitter lead picks up ground from pin 1 of the extended bus connector. Solder and trim both leads on the bottom of the board, and solder the emitter lead to the nearest pin on the extended bus connector and trim. Make sure the exposed base-resistor junction doesn’t touch any other exposed lead. Nothing is connected to pin 2 (RESET2) of P1.

mod assembly installed in module board

Finally, remove U1, the 74HCT04, from its socket, gently bend pin 4 up about 90 degrees, and reinstall U1 in its socket. Here’s what that looks like.

completed modification

That completes the modification. Put the board back into your system and test that reset still works. You shouldn’t notice any change in power-up behavior or behavior when you press either the reset button on the backplane or the one on the module. Rest easier knowing that resets don’t short out the 74HCT04 anymore.

Purposing a Makesmith CNC

Back in May of 2014 I was a Kickstarter supporter of the Makesmith CNC, which was an attempt to build an extremely inexpensive CNC router. The project was 822% funded, and they shipped all the kits in November, almost on time. Yay!

I began to put mine together right away. They had pretty good video tutorials on how to do it, but not much in the way of written documentation, and there were some holes in the tutorials. I made a post or two on their forum about my experiences. There were a few minor updates to the videos, made as overlaid titles, but nothing very substantial. I set the project aside to wait for the rest of the community to catch up and participate in improving the design.

Over a year later, in December 2015, I picked it up again. I found no improved documentation and relatively little more in the forums, so I just completed the assembly of the mill using my own best guesses. After jumping through some hoops to get their Macintosh software running, I was able to run some initial tests. I wasn’t impressed. As expected, it was really slow, but it’s hard to appreciate how slow without seeing it in person. Also as expected, its axes were pretty wimpy, barely powerful enough to overcome their own friction. One of the cost saving measures that makes the design feasible is that they don’t really try to prevent lost motion, they just measure it with a closed-loop feedback system and try to compensate. All this is more or less as advertised.

My particular mill had worse problems. It had a tendency to get stuck in the X and Z axes. This is undoubtedly due to alignment problems with the rails, which arise from some combination of the low-budget design and the assembly procedures I used. Because of the low-budget construction, though, there is no easy way to adjust the alignment after assembly and gluing. I’m sure there’s some way to make the mill work to expectations, but at this point it became clear to me that this mill was going to be frustrating to use. It was just too compromised to reduce cost.

By that time it was clear that Makesmith was never going into production with these machines, either. They filled the Kickstarter orders, and stopped. The software hasn’t been updated, and the user forum looks abandoned (overrun by forum spam). Maybe Makesmith reached the same conclusion: that the Makesmith CNC just wasn’t viable. They ran a new Kickstarter project in November 2016 to make a much larger CNC router at a very low cost point. I hope they and their Kickstarter backers have better luck this time.

Anyhow, I decided to give up on using the Makesmith CNC. It was fun to build and educational, so I got my money’s worth (more or less), even though I never even mounted a spindle (i.e., a Dremel tool) on the mill. I began researching commercially available mills and a few months later ended up buying the Tormach PCNC 440 with all the goodies for about 55 times the cost of the Kickstarter Makesmith CNC. Needless to say, it’s in a whole different class.

All of which is just a long explanation for why I have the carcass of a Makesmith CNC sitting around, capable (barely) of X-Y-Z positioning, but without a purpose. I also had a cheap USB microscope, which was adequately functional but which came with a nearly useless articulated-arm stand. Recently it occurred to me that the Makesmith would work as a positioner for the microscope. With a solid stand and relatively precise orthogonal positioning axes, the microscope would be transformed from a toy into a tool. Holding a lightweight plastic microscope and positioning it interactively under manual control is far less demanding for the Makesmith chassis than working as a milling machine.

I wanted interactive control of the positioner, independent of any computer software, so I bought a joystick on a breakout board and wired it up to spare I/O pins on the Arduino Mega 2560 that serves as the brains for the Makesmith CNC.


I then discarded the Makesmith firmware and wrote a dead-simple Arduino program that reads the joysticks and moves the axes, without any of the complexities of feedback or G-code interpretation or much of anything else. The software is on Github. I also added a power cable so that the Arduino was powered from the Makesmith’s power supply, instead of from the host computer’s USB port. Here’s the final lashup:


The microscope is a cheapie, but it gives decent results. My test subject here is a Raspberry Pi board. Here’s the view at minimum magnification, at 640×480 pixel resolution:

Wide small

For scale, the big black chip is 9mm square. Here’s the view at maximum magnification and maximum resolution:

Narrow big

We see just a few of the pins on one side of the same chip. Near the middle of the image is a via, a tiny hole that routes the circuit to the other side of the board. Those little white specks inside the via are formed by a silk screened annotation on the back side that happens to overlap with the hole. At this magnification, the depth of field is pretty shallow, so the top of the chip and of C78 are quite out of focus.

The motion of the Z axis is quite sufficient for focusing the microscope, even at maximum magnification. It could use more vertical travel for working on larger subjects, but that’s true of every positioner in the world. The X and Y axes are still slow, but even at minimum magnification they move the image about as fast as you’d want them to. The speed only becomes an issue when you need to move the microscope to a whole different area. Often it’s easier to just move the subject around on the platform.

The microscope can capture video, too, but the motion isn’t really smooth enough for that to be impressive. I’m using miXscope software to control the microscope from a MacBook Air. That software has a number of useful features for technical microscopy, but it’s a bit long in the tooth and a bit crashy on current versions of macOS.

The next obvious application for a microscope with a positioner is to automatically photograph a grid of overlapping images at different X-Y offsets, which can then be stitched together to create a larger high-resolution image. To do this I’d need to add back some of the complexity of the control firmware, so it’s on the back burner for now. Another variant would be to take multiple exposures at different Z offsets, which can then be merged to increase the effective depth of field. More projects!

This was a quickie weekend boondoggle, except for waiting for the joystick board to arrive. Well worth the effort to add an improved tool to the lab.

Dongles considered harmful

Helping to search for a missing copy-protection dongle (for embroidery software) reminds me just how awful that kind of copy-protection is.

I can understand why software publishers are tempted to use it, especially for niche market titles that command relatively high prices. The arithmetic might even work out in the publisher’s favor for hardcore engineering software used almost exclusively by corporate minions on big-budget projects. I imagine that some of the users of the embroidery software are commercial users doing embroidery for customers, and those users pretty much have to pay whatever the publisher demands. The commercial-grade embroidery machines certainly aren’t cheap; the software doesn’t materially alter the capital budget even when it’s grossly overpriced.

But there are also prosumer embroidery machines aimed at advanced hobbyists. Those machines aren’t exactly cheap either, but the price of the software really does drive the cost way up. Probably with the software so expensive, and hobbyists using it “just for fun”, there would be some who would use the software without paying, and some of those wouldn’t be technical enough to circumvent the dongle copy protection. The license fees these customers pay are the upside of copy protection for the publisher.

The downside, of course, is that all the other customers are treated like thieves. They are inconvenienced every time they run the software, for the sole benefit of the software publisher to whom they have already paid a wad of money. When the dongle goes walkabout, as it inevitably does at the worst possible time, they are prevented from doing any work until the dongle can be located or replaced. It sure doesn’t help the customer feel affection for the software or its publisher. Word of mouth suffers. Bad dongle experiences (not to mention high prices) poison the potential community of users. Great software that could have been a runaway favorite ends up feeling like a necessary evil.

Ugh. So far, we still haven’t found the dongle, so we may get a chance to find out how well the publisher and its local dealer are at customer support.

DLNA is not a total loser

I doomed myself by saying that streaming from my Mac Pro to the Sony Playstation 3 was working extremely well. A few days later, it was completely broken. Here’s the story.

The ingredients: two houses with home theater equipment, a collection of movies on DVD, a variety of computers available, an Apple TV, and a PS3. The discs can’t be in both places at once, so I ripped them to hard disk for use in one house, and stored all the discs at the other house for playback there. I am interested in the extras found on many DVDs, not just the feature, so I was careful to rip all the video selections on each disc. I kept them organized with a folder for each product (one disc or multiple). For TV series collections, I’d include an episode number in each filename so they could be retrieved in chronological order. The extras for each product I’d gather together in a folder named Extras and give them sensible filenames. The idea was to bypass the awkward silly menu structure imposed by the DVD authoring and just have access by reasonable names to each significant piece of video.

The resulting collection filled up most of two terabyte external Firewire drives, after re-compression. There was no settop box available with that much storage, at least none at a reasonable price. So, I needed a way to play the video from the external drives. I leave my Mac Pro on all the time, so the obvious solution was to leave the drives mounted on the Mac Pro and stream the video to the living room on demand.

OK, it’s a Mac, and Apple generally does a superb job of getting user interfaces right. So the obvious solution was an Apple TV, streaming from iTunes on the Mac Pro. Total and complete disaster. iTunes was happy to import everything from my complicated directory structure, and to serve it up on demand to the Apple TV. As a flat list. One, single, very long flat list in ASCIIbetical order. That meant that under ‘M’ in the list I had six separate things named “Mission Overview” (yes, I have all the Star Trek series on DVD). Episode 01 of every season of series sorts together in the list, before any of the Episode 02 files. Just a hideous mess.

Waiting through a couple of major revisions in Apple TV software didn’t help. Take Two, then 3.0, still lame. Now, I’m sure this is the right design for some class of user. If you have a few dozen titles and you keep only the main movie from each disc, maybe this is very nice. But it doesn’t match my requirements.

Going down the Apple TV route, I could either keep waiting for Apple to change its design to suit my needs (which seems increasingly unlikely as Apple TV converges on a design that seems more and more oriented toward the iTunes Store), or hack the Apple TV with third-party software. I know there are options available from third parties, and as a reasonably serious computer guy I’m not too intimidated by the prospect of a complicated conversion process. I could make it work, but I never did. For one thing, I wasn’t looking forward to devoting the time it would take to evaluate the various third-party options. For another, I do like the way the Apple TV handles music, and I didn’t want to screw that up. Nonetheless, I was just about ready to dive in, because I needed a way to have convenient access to all that video.

Somewhere in the middle of this drawn-out process, Blu-ray happened, and I bought a Sony Playstation 3 as a Blu-ray player. I was distracted from the DVD archives for a while by newly-purchased Blu-ray movies, and didn’t pay too much attention to the other capabilities of the PS3.

A few weeks ago I happened to upgrade the software in the PS3, just because there was new software available. After installing the upgrade, I again perused the menus to see if there was anything new and cool. I didn’t find anything new of interest, but I did notice again that the PS3 had a way to look for a video server on the network. Hmm! I wondered if it was any less lame than the Apple TV. I didn’t think it was likely, but it might be worth a try.

A quick research session on the Internet taught me that I needed a DLNA server, and that a well-respected one for the Mac was MediaLink from Nullriver. And hey, I already had it licensed and installed on my machine, from some previous experiment with video streaming. I fired it up and pointed it to the two external drives, and went back downstairs to see what it looked like on the PS3.

There it was! The PS3 had already automagically detected the MediaLink server and tagged it Potato, the host name of my Mac Pro. If I just clicked on that, I’d find out just how awful a job the PS3 software would do with my media. Click. It showed me the names of the two drives. Click on one of those, it showed me the top-level directories on that drive. In fact, the whole directory hierarchy I’d painstakingly laid out — and Apple TV promptly flattened — was there to browse. That’s exactly what I wanted. The browsing was even pretty snappy, over my wired Ethernet.

What’s more, the video playback worked, without much annoying delay or any glitches. Even fast forward was smooth and predictable, so I could skip the horrendous theme music when watching episodes of Enterprise. Life was good. And then I made the mistake of saying so, and the very next time I tried to stream video, it failed utterly to work.

Maybe this was a problem introduced by the new PS3 software, and with a little luck Sony had already fixed it. I checked for another new version. Sure enough, there was another update. I let the PS3 update itself and tested again. Still busted.

Maybe this was a known problem with MediaLink — I was running an old version, after all — and Nullriver had already fixed it. I downloaded the latest version of MediaLink, 2.0b1 (a beta release) and installed that, after figuring out that it installs as a preference pane and not as a regular application. Another test, another complete failure.

Oh, the PS3 could still see the MediaLink server. It still showed up tagged Potato. But when I attempted to browse the server, the PS3 claimed “There are no titles” and in the upper right corner, a message box appeared heralding “DLNA Protocol Error 7531”. Wow, what a user-friendly error message. For a translation, I turned again to the Internet, but I didn’t find much in the way of specifics. A lot of people were having random-seeming problems with DLNA protocol errors, including number 7531, but nobody seemed to have much of a clue what exactly it meant or how to fix it.

Well, no problem, right? I can just look up the DNLP specification and find out what that error code is defined to mean. No, I can’t, because the DNLA protocol specification isn’t public. It costs $5000, and I can only imagine what kind of agreements I’d have to sign before I’d even be permitted to pay. In any case, I doubt there’s a lot of precision in the definition of error codes even in the full spec.

With the spec unavailable, I gleaned what I could from various articles discussing DLNA. One particularly useful post was Why do I hate DLNA protocol so much? by Ben Zores, author of GeeXBoX, an open-source Linux-based media center software distribution. From Ben’s rant I learned that at the bottom of multiple layers of directory service and connection management cruft, all that’s really happening is that the server is providing the client with an HTTP URL from which to stream the media.

Armed with that information, I fired up Wireshark to trace the network packets going between Potato and the PS3. Every 60 seconds, I saw a short TCP transaction, a single query and its response. Here’s the query from the PS3 to Potato:

GET /MediaServer/DeviceDescription.xml HTTP/1.1
Date: Sat, 12 Dec 2009 08:20:37 GMT
User-Agent: UPnP/1.0
X-AV-Client-Info: av=5.0; cn="Sony Computer Entertainment Inc."; mn="PLAYSTATION 3"; mv="1.0";

This makes a lot of sense. The PS3 is identifying itself, and asking for something called /MediaServer/DeviceDescription.xml — a generic-sounding name, so it’s probably straight out of the protocol spec. Notice that Potato’s IP address is You can’t see it here, but the PS3’s IP address is, so both are on the same subnet with a netmask of

The response from MediaLink on Potato to the PS3 consisted of a similar header followed by a 55-line XML document. Here’s the header:

HTTP/1.1 200 OK
Content-Type: text/xml; charset="UTF-8"
Content-Length: 2229
Connection: close
Date: Sat, 12 Dec 2009 08:20:36 GMT
Server: Mac OS X/10.x.x, UPnP/1.0, Nullriver HTTP Server/3.0

So far, so good. The Mac OS X server is responding and is going to send a 2229-byte XML response. Here’s the first few lines of the XML:

<?xml version="1.0"?>
<root xmlns="urn:schemas-upnp-org:device-1-0">

Whoa. Look at that IP address given as a hostname in the URLBase tag. It’s That’s not Potato’s IP address, and it’s not even on the same subnet. If MediaLink is telling the PS3 to get its media from that address, it’s no wonder it fails to work!

So, where the heck did that address come from? Googling that particular IP address didn’t reveal anything special. I tried putting that URL from URLBase into my browser, not really expecting to get a response since I knew there was no route to any such subnet on my network. But there was a response, and it was just the kind of terse and somewhat cryptic response you might expect from a server that’s expecting to respond to a specialized client program. I tried trimming off the filename part and submitting just the IP address to the browser, and got the standard Apache web server response for an unconfigured server. Some computer, somewhere on my network, was somehow being reached by this URL and responding!

When you already have Wireshark open, every networking problem looks like a job for packet tracing. So I set up a Wireshark capture filter to log packets to and from the mystery address, and set the trace in motion. Nothing. I repeated the browser access to the mystery server. The access succeeded again, but still no packets were logged by Wireshark. I threw the Wireshark capture filter wide open and tried again. Still, no packets to or from were logged.

OK, that leaves just one thing. When you start a Wireshark trace, you have to specify which physical interface is to be traced. Potato has only one physical network interface active, the first wired Ethernet port en0, so naturally I was tracing on en0. The mystery host must be on some other interface, somehow. The command to list network interfaces is ifconfig, and that’s the next thing I ran.

That told the story: ifconfig showed an interface called vmnet8 that was using the IP address In fact, vmnet8 was listed before en0. I speculated that MediaLink was enumerating the IP addresses of the available ports, and choosing the first one it found.

Another resort to Google quickly revealed that vmnet8 is a virtual networking port installed as a kernel extension (kext) by VMWare Fusion. VMWare doesn’t try to dynamically load it as needed, it just leaves it installed forever to clutter up your kernel. The VMWare Fusion on Potato was a long-expired demo version I didn’t need, so I simply uninstalled it. The vmnet8 port disappeared, without even a reboot. Repeating the trace of packets between the PS3 and Potato, I could see that the URLBase in the XML file had changed to, Potato’s IP address on en0, as expected and desired. (If you’re having this problem and need to keep VMWare Fusion around, I don’t know what to suggest other than to complain to MediaLink for a way to specify which interface or IP address it tries to use.)

I ran downstairs and found that I could again browse the server file hierarchy on the PS3. I declared victory and went straight to bed, it being long past bedtime by then.

The next day when I had a bit of time on my hands, I decided to take advantage of my newly repaired video streaming to watch an episode of Enterprise. It didn’t work. The PS3 couldn’t even see the server. OK, maybe I had left the server shut down in my groggy state the night before. I went upstairs and restarted it. Now the PS3 could see the server and browse the hierarchy again, yay. So I fixed some lunch and sat down to watch. Hit Play and nothing happened for a few seconds. Then the PS3 changed the title of the video I wanted to watch to “Corrupted Data” and returned to the hierarchy browser. Nothing would play. Arrgh. This time the error in the upper right corner was “DLNA Protocol Error 2110” or “DLNA Protocol Error 2101”.

This time Google found me a specific answer when I searched for error 2101. I learned that there was a new problem with the alpha version 2.0a1 and beta version 2.0b1 of MediaLink, having to do with sending thumbnail images to the PS3. It crashes the background program MediaLinkHelper.app, which is the actual DLNA server program, which I confirmed by examining the system log in Console.app. Once the server crashes, of course nothing works. The solution given is to delete the plug-in that tries to handle thumbnail art, /Library/PreferencePanes/MediaLink.prefPane/Contents/Resources/MediaLinkHelper.app/Contents/PlugIns/AlbumArtTranscoder.mltranscoder. I did that and tested again.

My episode started to play, hurray! After the teaser was over and the theme music began to play, I hit fast-forward, as usual. The picture froze and went silent. That’s not how the fast-forward looked and sounded before, and it’s not an improvement. I hit play. I expected to get video, either with or without having skipped ahead by the amount it should have been fast-forwarding. Instead, I continued to hear silence and see a frozen screen, for quite a few more seconds. Before I did anything else, it eventually did start playing, having fast-forwarded ahead about the right amount.

Failing to find anything about this problem with Google, I assumed it was a bug in the beta version of 2.0 that I had “upgraded” to. I foolishly did not save the version 1.54 (I think) that I was originally running. Fortunately, Nullriver makes available version 1.72 for customers who are running Tiger, since the 2.0 versions require Leopard. I downloaded version 1.72 and replaced the beta version with it, and got back the nice, smooth fast-forward behavior I had before.

Once again I have declared victory, and I was able to watch my episode of Enterprise without any additional problems. So far.

TinyURL Considered Harmful

Back in late 2006 I wrote the following as a letter to the editor of Motorcycle Consumer News. They printed it, and stopped using TinyURLs! One small lurch forward.

To: editor@mcnews.com

I wish you wouldn’t use tinyurl.com in the magazine, for a number of reasons.

First, any error in a tinyurl code makes the link completely useless. This might be a printing error in the magazine, or a typing error on the subscriber’s part. Either way, there’s no way to guess where the link was intended to go.

Second, a careful computer user is very reluctant to visit a web site “blind” without any idea of where he’s going. Tinyurl makes that sort of reckless behavior mandatory. Even if we completely trust the magazine to vet web sites for safety, any typing error and we could end up anywhere on the web.

Third, the reader may not be sitting in front of the computer as he reads the article. If there’s a real URL on the page, he at least has a chance of remembering what web site was mentioned, so he can find it later when he’s at the computer. Likewise, when reading the magazine he may recognize the URL as one he’s already visited, saving a trip to the computer entirely. There’s no chance of remembering or recognizing a tinyurl.

Fourth, occasionally the writer will succumb to the temptation to give a tinyurl without ever even mentioning the actual company or product he’s referring to. This renders the whole reference completely useless unless the reader is at a computer and able to type in the tinyurl correctly.

Fifth, tinyurl.com could disappear without notice, or turn evil somehow, and where would that leave you? All the tinyurl links in a subscriber’s collection of back issues would be obsolete.

I realize that full URLs are too big to fit nicely in narrow text columns in the magazine. I would suggest that there’s a perfectly good standard solution to problems like this one: footnotes. Instead of a tinyurl, put something like [Link 1] in the text, and put the link at the bottom of the page. You can let it span multiple columns in order to minimize line breaks within the URL. The footnote reference is even more compact than the tinyurl, and the full URL at the bottom of the page avoids all of the disadvantages mentioned above.

Thanks for listening.