Off the Ground?
Because x86 laptops can run desktop Linux distributions, most DIY DPF instructions start by booting a distro's CD-ROM, then continue the installation at the laptop's keyboard. Alas, the 560Z lacks a CD-ROM, a floppy drive, and a network jack; it can't even boot from a USB memory stick. This is a classic chicken-and-egg problem familiar to embedded systems developers: How do you get code in there without removable, bootable media?
Most current laptops can boot into a kernel fetched from TFTP/PXE servers and, indeed, an Advanced Port Replicator with Advanced Thinkjet ($21, eBay) adds that trick to the 560Z. Unfortunately, the Replicator's broken PXE code requires tedious server-side workarounds that I was unwilling to implement.
The typical fallback requires popping the laptop's boot device (hard drive or CF+IDE adapter) into another laptop that can boot from a CD, installing on that laptop, then swapping back to the DPF laptop. That's certainly feasible, but it seemed like a lot of work, far too much typing on an uncomfortable keyboard, and, besides, my token Windows laptop was tied up doing something else.
Assuming you get past that, most laptops use low-level configuration programs requiring DOS or, yick, Windows. The 560Z's DOS-based config program comes wrapped in an EXE file that insists on writing its contents to an actual floppy drive: You can't redirect it to a disk file. Indeed, I booted DOS from a floppy (on my only box with a floppy drive!), whereupon the config program grumped about the DOS version.
I faced a cascading series of problems even before starting the DPF part of the project and, if the 560Z wasn't a nearly ideal DPF, I'd pick a different laptop. That, too, is a typical embedded-systems trade-off: low power and a small form factor versus easy development. Trying to use the same box for development and deployment generally doesn't work, particularly for deeply embedded systems lacking the usual user-interface amenities.
The canonical embedded-system solution involves cross-development: Creating and compiling code on one box (the host, my desktop PC) that will run on another (the target, the 560Z), with remote debugging through a serial or network interface. In the general case, the host and target have different CPUs, system architectures, memory layouts, and peripherals, all of which require specific configuration tweaks. Linux can handle such cross-development projects with aplomb, albeit with careful attention to matching the compilers, libraries, headers, and assorted utilities to the target.
In my case the host is a 64-bit, dual-core Pentium D and the target is a Pentium II, so they really are different CPUs. Keeping disparate x86 tools and libraries apart on a single x86-oid box poses a challenge, as using the wrong piece in any step tends to generate code that almost works, with little indication of what went wrong. Worse, you can mung your host by installing a target tool in what it insists is the right spot.
Sorting all that out seemed rather tedious, so I opted for a lower-effort approach: Develop the target code in a virtual machine with an adequate assortment of virtual hardware. This introduces a third system into the process, a "development box" that's distinct from the target, but it also eliminates the entire cross-development headache by making the development and target systems nearly identical.
When the code's done, I can transfer a disk image to the CF card, pop it in the laptop, and fire it up. Some configurations require the laptop's physical hardware, but most of the heavy lifting happens in the VM.
Sound interesting? Here's how to get it going.
