![[NEC Multispeed laptop computer]](images/multispeed.jpg)
Lately, I have been working on an interesting retrocomputing project. This was with the first computer ever purchased by my family, an NEC Multispeed laptop. This was acquired around 1986-1987 or thereabouts, for bookkeeping for my parents' business.
This machine featured an MDA compatible LCD screen, 640k of RAM, an NEC V30 processor (8086 compatible), and two 720kB 90mm (3.5") floppy drives, and ran MS-DOS 3.2. It came with an office suite named "ABLE-1", which was really the only software we had for it. I can remember wanting to learn computer programming from a very early age, but I had neither suitable software, nor a source of information on how to use it. It was not until several years later that I managed to get hold of a copy of QBASIC that ran on the machine, and taught myself how to program from reading the online help. (Or at least, I thought the machine didn't have any programming tools at the time. I eventually discovered that it had "all I needed" to get programming in the form of the DEBUG utility. But if teaching myself QBASIC with no outside help was hard enough, learning to use assembly and DEBUG would have been just about impossible! Even if I had known what to look for, there was no mention of DEBUG in the manual, and the program itself had no online help.)
Starting up the now 35+ year old machine, it initially refused to boot. Looking inside showed a leaky PCB-mount NiCd battery, which was presumably used to keep the system clock and the machine's nonvolatile RAM disk operating. Measuring the battery showed that it was down to zero volts, and figuring that it might be dragging a supply rail down, I snipped it out of circuit. After this treatment, the machine would now boot (fortunately, I had a copy of the original boot disk), and there didn't seem to be any damage to the PCB from the leaking battery, so I left it at that.
So now, I thought it would be good to get some real development tools running on the machine, and see what it could do. I copied Borland's excellent Turbo C onto a disk (the essential components just barely fit on one 720k disk). and started it up. The IDE loaded OK, and after several minutes of the disk grinding away, I managed to compile a "Hello World" executable. This proved the point that the machine could be used for C development, but it really highlighted the machine's limitations: Having just two 720k floppy drives, and no hard drive, was really just not enough storage for a lot of applications that would otherwise be usable with the machine. (The Multispeed can be configured to use part of its nonvolatile RAM as a C: drive, up to a whopping 128kB, so that was obviously not much use.) I was also concerned about the long-term reliability of the mechanical parts in the floppy drives if I wanted to be able to use the machine in the future.
I therefore started to think about the possibility of upgrading the machine's disk storage. This would not be an easy task, as the machine was not designed with this possibility in mind, and while it is IBM-compatible, it is quite limited in terms of the number of expansion ports present. On the back, it has a parallel printer port, an RS-232 serial port, and a 15-pin "external floppy drive controller" connector. There were also two internal ports for the two floppy drives, a proprietary expansion port on the side for a modem, and a couple of vacant EPROM sockets under a removable cover in the base of the machine.
The external FDC connector seems the obvious place to start, but this is a dead end. The port is not for attaching external drives to the machine, but for attaching the Multispeed to a desktop PC, to allow the PC to use the Multispeed's disk drives as external drives! This is perhaps not quite so crazy as it first seems, since 3.5" floppies were relatively new at the time the machine was designed, and lots of desktop PCs would only have 5.25" drives, so data exchange might have been problematic. Nevertheless, I do wonder if many people actually ended up using this port on the machine at all.
I was aware that, in the present day, USB/SD card adapters are available, that "appear" as a standard floppy disk drive to the host computer. However, I was unsure if the interface used by the Multispeed's drives was 100% standard. Also, while these adapters do allow for increased storage capacity, whatever capacity drive is used has to be broken up into floppy-sized "chunks" for the original operating system to interface with, which is inconvenient. I therefore rejected this option.
While the RS232 port does provide a nice standard interface, I decided that the 8250 UART would just be too slow to be practical.
While I was fairly sure that the parallel port was just the "standard" (non-bidirectional) design, even this has the capability for input as well as output, using some of the handshaking lines. I hoped that even a bit-banged implementation could be reasonably fast.
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.
loopgain.net