NEC Multispeed Disk Upgrade

Reverse Engineering

It was clear that, given the instruction set timing, the SD card interface would need to be capable of transferring at least a byte at a time in order to give acceptable performance. One option might be the connector for the modem card. Although a proprietary interface, at least mechanically, I wondered if it might be possible to design a board that could communicate with this port. Examination of the slot showed it had a 2x20way 2.54mm pitch header socket. The most obvious thing for the designers to have done would have been to provide a standard ISA slot on a custom connector. However, even an 8-bit ISA slot has 62 pins, so clearly it wasn't just a case of a different connector.

Another interface possibility would be to make a module that plugged into one of the ROM sockets, and use a memory-mapped approach. So I plugged some old EPROMs containing some random data into the sockets, and set about trying to read them. The manual details that there is a DIP switch to set depending on the ROM size, but the memory map (helpfully provided in the manual - you don't get anything like that these days!) clearly showed that there was some sort of bank switching involved. Sure enough, attempting a PEEK at address 0xD0000 from QBasic gave the same result, regardless of whether or not the ROMs were in the sockets.

Memory map

So, it was necessary to determine how the bank switching was controlled from software. As previously mentioned the Multispeed has a number of applications in inbuilt ROM. These are mapped into the same memory window as the external ROMs, so it was reasonable to assume that loading one of these applications would switch the bank back to the inbuilt ROMs, which would hopefully provide a clue as to how to select the external ROMs.

Each of the ROM programs is provided with a 'stub' loader program on the boot disk. Disassembly of one of these (they are all virtually identical, except for the program name), showed that it simply checked some system memory locations (the ROM programs can be enabled or disabled in the BIOS setup, this was clearly what was being checked), and then called a software interrupt 0x82 into the operating system. There was no mention of this being connected to anything relevant in the Interrupt List, so it looked like I was on my own.

I loaded up the NOTEPAD.COM stub loader for the inbuilt text editor in DEBUG, and with the output redirected to a file, ran the "trace" command. This command runs the program, and after each instruction, prints the contents of the registers (including the instruction pointer), and a dissasembly of the next instruction.

The trace command slows down the program execution by several orders of magnitude, and over the course of many minutes, I saw the screen clear character-by-character, followed by the drawing of the screen border for the NOTEPAD program.

At this point, I stopped the capture. The output file had already grown to over 2MB, so it was fortunate that I had already got the parallel port SD card interface working, as this would be far too big for a floppy disk. After copying the file back onto a modern machine, I stripped out the register information (Stand Back! I know regular expressions!), and then manually indented the code according to the function call hierarchy.

Examination of the output showed that the stub loader first jumped into the operating system in the F0000 page, then executed a lot of repetitive code for writing characters to clear the screen. Eventually, the code was seen to jump to an address in the CC00 page. While this was not into the D0000 page as expected, the address still ended up being in the bank switched ROM, due to the overlaid segments.

Looking back over the trace, a few instructions prior to the jump was an "out e0, e0" instruction. This seemed a likely candidate fo the instruction that controlled the bank switching hardware. I therefore tried writing different values to this port while examining the D000 page using DEBUG. Writing E1 caused the data to change to one of the other inbuilt applications. This confirmed that the port was used for bank switching.

Therefore, according to the memory map, writing E2 should allow access to the 32kB EPROMs that I had installed. However, this page contained yet more data for the internal applications. Writing E3, to access the last page, gave a repeating data pattern, indicative of unpopulated memory. After some experimentation, I found that there was an error in the manual - DIP switch #3 had to be off to address 256kbit EPROMS, not on as it states. Also, the memory map appears to be wrong, in that the EPROMS are mapped to page 3, not page 2.

Configuration switch information from the manual. Note that the description for SW3 appears to be wrong.

However, setting the switch to off, and writing E3 to port E0 allowed the EPROM to be read, starting from address D000. The data I was reading was quite corrupted (apparently part of a Phoenix BIOS ROM), but I put that down to the EPROM having sat around uncovered in ambient light for an indeterminate period. The pair of EPROMS are treated as a 16-bit wide ROM, with their bytes interleaved.

So, it looked like using a memory mapped peripheral would be one feasible way of getting data into the machine. I then decided to go back and have another look at the modem port.

Attempting to communicate with the absent internal modem (the Multispeed has a number of applications, including a communications terminal program, in ROM) showed it attempting to open COM2 (with COM1 being the serial port on the back panel). It was therefore reasonable to assume that the internal modem would have something like an 8250 UART, connected to the processor bus. Reading through the details of the ISA interface (http://hardwarebook.info/ISA ) showed that 40 pins would be enough of a subset of the bus to communicate with an 8250 UART (Only the lower 10 address lines are used for I/O space accesses, saving 8 pins. Only a single interrupt line would be necessary, saving another 5 pins. Furthermore, the memory read/write, DMA control lines, and probably the -5V rail would be unnecessary, saving a further 9 pins, bringing the total down to 40.)

To investigate the possibility of using the port, it was first necessary to determine the pinout of the 40 pin connector. To do this, I disassembled the machine to gain access to the connector and the main circuit board. As a first step, I checked for continuity between each of the connector pins and the pins of the V30 processor. As the pinout of the latter is known (same as an 8086), this would allow some signals to be identified. I managed to identify the 5V and 0V supply pins by this method, but it was no help for the rest, no doubt due to the multiplexed address/data bus scheme used by the 8086.

In an older generation PC, it probably would have been possible to use a similar approach and trace the pins to the demultiplexer chips. However, in this case, following the signal pins showed that they were directly connected to some programmable logic arrays,for which no meaningful pinout data would be available. Therefore, a different approach would be necessary.

I fired up the machine (which was fortunately still possible while it was disassembled), and examined the signal on each of the pins with a logic analyser. This identified the +/- 12V supply rails (actually more like +/- 10V), the -5V rail, a 4.77MHz clock, a number of pins with active data, and some others stuck at 0V or 5V.

Probing the modem port signals.

The first task was to identify the address bus. I ran DEBUG, and filled a page of memory with 0x90, the 'NOP' opcode using the 'f' command. (Without a good understanding of the MS-DOS memory management system, I just picked a page somewhere in the middle of the 640kB of memory, in the hope that it would be free). The code segment was set to this page, and then it was executed using the 'g' command. With a program of this nature, the address bus lines will just count in a binary sequence, as the microprocessor sequentially executes every instruction in the page (except while servicing interrupts or performing DRAM refresh), wrapping around at the end.

It was then fairly easy to identify the address bus pins with the scope, as they had a series of square waves, each half the frequency of the last. Fortunately, the bus pins turned out to be laid out sequentially,from pin 5 up to pin 14. Note that this is not the full complement of address lines, but is enough to decode the 10-bit I/O address space up to 0x3FF (This is a separate address space to the main memory, and is distinguished by using 'in'/'out' instructions instead of 'mov'. A bit convoluted, but this is the way that x86 processors work.) I had though that possibly some of the address lines might have been pre-decoded on the motherboard, since the slot was only designed for a single peripheral, but this turned out not to be the case.

I then looked for a sequential set of pins containing the data byte 0x90, which led to pins 15-23 being identified as the data bus. Next, I wrote some assembly programs using DEBUG that would perform an 'in' or an 'out', or a load/store to RAM in a loop, in an effort to identify the control signals. This pointed to pin 24 being 'I/O read', and pin 25 being 'I/O' write. Reference to the ISA bus timing diagrams in the Hardware Book allowed pin 26 to be identified as BALE (Bus Address Latch Enable). Pin 15 had a periodic signal approximately every 15us, which I assumed was something to do with the DRAM refresh, and so I tentatively identified the pin as AEN (Address Enable).

With this done, all of the pins with active data on the connector has been identified. To identify the reset line, it was simply a matter of monitoring the logic levels on the remaining pins, and finding the one which changed when the reset button was pressed, which turned out to be pin 27.

My initial idea for interfacing with the modem port was to use an 8255-based circuit, and I had identified a design for an ISA GPIO card in the November 1996 issue of "Electronics Australia" which used this chip, and that I thought could be adapted to provide an SPI interface by hanging some shift registers off its outputs. (While availability of the 8255 is a bit uncertain at present, I had found a couple in my stash of old PCBs, so I would have enough for a one-off.) The EA design only uses the address and data buses, and the AEN, /IOR, /IOW and RESET lines, so I had identified enough of the pins to be able to interface this circuit.

As far as the remaining pins go, I would guess at least one of pins 4, 29, and 31 is an IRQ line for the modem's UART. Also, seeing the volume control cutout of the cover plate for the slot reminded me that the modem would have had an audio output, and it is possible that this audio signal would have been run to the Multispeed's speaker via another one of the pins (unless the modem card had a second internal speaker). (This was confirmed when I later connected an extender ribbon cable to the port. The increased crosstalk resulted in "computer" noises from the speaker when the machine was busy.)

But this still leaves up to 6 pins unaccounted for. I tried triggering the scope in single shot mode from these pins, but none of them moved during the computer's bootup sequence (which would have exercised most of the peripherals). The "memory read/write" signals do not appear to be present, which unfortunately precludes the possibility of using memory-mapped I/O (though this would be difficult anyway due to not having a full complement of address pins). Possibly, some of the pins are something to do with DMA. Or, they could be for wait state control, but it appears that wait state control is not possible for I/O space operations, so there would be no real need for these pins.

At this point, I felt that I had Identified enough of the pins to move forward with a hardware design. So, after taking measurements of the mechanical position of the connector, and the size of the PCB slot, I put the machine back together, and then set about designing a suitable circuit for the SD card interface.

On to Part 3 - Adapter Card Development.

Back to Part 1 - Parallel Port SD Card Interface.

Up to Introduction.

This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.

loopgain.net