Overview

The NetPi-IDE project is essentially an IDE disk emulator based on a Raspberry Pi Zero module with a custom bridge board – allowing it to meet timing and performance targets defined in the ATA/ATAPI T13 specification which governs how IDE drives operate.  It is designed to emulate an IDE master, IDE slave, or a combination of both using raw image files stored on the Pi’s main micro-SD card.  It also provides additional features through IDE/ATA vendor commands that open up additional functionality such as network connectivity and bridging to a variety of other peripherals connected to the Raspberry Pi over USB ports.

The development effort at this point should be considered very alpha and several months away before a group buy/build, crowd funding production run, or general availability to the vintage/retro computing community.  The project is 100% open source and tentatively released under the GPLv2 license for all software and hardware components.  This means others may use, modify, or even derive works from this project as long as the GPLv2 license is carried forward, all resulting material carries forth this license, and attribution is properly assigned.

Genesis

The NetPi-IDE project started out as a discussion about how to best add wireless support to an IBM PC Jr running an existing Jr-IDE expansion interface on Mike’s PC-Jr forums.  Two directions emerge based on philosophical fundamentals.  Direction A, or a minimalist approach, suggested we built a module with as close to period hardware as possible.  While this seems like an oxymoron with wireless networking functionality, it generally means design hardware at a schematic and register transfer level only; eg. no high level microprocessor or micro-controller running at clock rates that could eclipse (literally) millions of times the processing capability of the PC Jr itself.  This would essentially involve a CPLD or FPGA providing a rudimentary bridge over an interface like SPI or SDIO to a commodity wireless module.   The wireless module may unavoidably have a higher level processor as long as it presents a basic external interface and it’s capabilities are not evident or generally exploitable.

The second direction B focuses on the ‘easy’ road – throw endless MHz, GHz, MIPS, and massive memory and storage at the problem.  Some consider coupling a modern co-processor with orders of magnitude more capability than the vintage machine itself while providing menial functionality ‘perverse’.  However the primary goal of projects like this is to facilitate usability of the machines, conserve them for future generations, and augment older failing technology.  To this end, direction B was chosen.  The Raspberry Pi Zero was specifically chosen for it’s price point.  It’s not a spectacular platform.  The most revolutionary thing about it is the $5 price tag!  However the ever-growing eco-system of hardware and software contributors now set it apart from the competition as much as the price point.

Hardware

The fundamental architecture consists of few simple components:

When the IDE command register is written, the busy bit is automatically set and an interrupt is thrown to the Pi.  The Pi may then read the IDE register file, update the IDE register file, fill the incoming data FIFO with data, or read data from the outgoing data FIFO – all over SPI.  In this way the behavior of ATA commands is entirely defined by a user space daemon running on the Pi in Linux user space.  Currently only PIO modes up to 4 are supported.  However plans for higher UDMA modes are in the works.

The current IDE interface clock runs reliably at 38 MHz and synthesis reports suggest it can run up to 100 MHz which could easily support ATA33 speeds of more modern PATA systems.  The SPI interface is direct clocked rather than over-sampled in the FPGA.  The expectation is the FPGA could handle up to the maximum SPI clock supported by the Raspberry Pi which is 125 MHz.  It is currently limited to 16 MHz or 2 MBytes/s which is fast enough for most vintage systems.

Volunteers

Given the current state of the project, I’m looking for volunteers to help moving things along; particularly those willing to do some DOS utility development.  Please email me at alan at alanlee d org for more information.

Features and Status

Disk Emulation

The greatest advantage of virtual IDE disk emulation is the ability to manipulate the images outside the scope of the host machine the emulator is connected to.  One may keep a menagerie of image files representing dozens of configurations, boot disks, application use cases, or special use scenarios.  Those images can be selected statically when the Pi process is launched or even changed during run-time when the emulator senses an IDE reset pulse or a ‘Read Identification Sector’ command from the host.  Image files can be backed up via Linux facilities (ssh, rsync, ftp, etc).   Image file content can be manipulated on the Pi via loop-back mounts, mtools, or even x86 emulators built for ARM.

Image files are stored in a read/write partition of the Raspberry Pi’s micro-SD card used to store the operating system (Raspbian).  A user may store as many image files as space allows.

Currently master, slave, or master and slave drive emulation is fully working.  One may specify, via config file, the full path to an image file, optional CHS drive geometry to report to the host, IDE disk label, and other attributes.  A variety of sizes from 10M to 8GB have been testing thus far.

DOS Redirector Service

MS-DOS 3.3 introduced what is called a ‘redirector’ service (Int 2Fh/AH=11h).  It was overhauled in 4.01 with a major interface change.  And in 5.x was reverted back to the 3.3 interface and enhanced.  Essentially it is a file I/O remote RPC handler.  When a redirector registers with DOS, it is given a DOS drive letter such as E:.  All file level I/O operations for that drive letter such as list directories, open or create files, read/write files, and directory manipulation is passed to the redirector service for handling.  MS-DOS uses this most notably for MSCDEX to support CD-ROM file systems that bare no relationship to FAT.

Part of the NetPi-IDE project is a utility called PIMOUNT.COM.  Pimount allows the mounting of any arbitrary directory on the Raspberry Pi’s file system as a DOS drive letter.  This opens up enormous possibilities as that mount point could be an auto-mount path for a USB mass storage stick.  It could be a Window’s remote file share via SAMBA.  It could be a path the Pi is exporting over the network via SAMBA or NFS.  Or it could be a parent directory containing all three!  The ability to transfer files to your vintage machine just by dragging and dropping files on a modern Windows 10 box through thin air opens up mind-blowing expansion opportunities!

Currently the redirector takes up less than 3KB resident space when running making it a much lighter alternative to traditional network stacks and drive sharing in DOS.

The redirector service operates by forwarding the file I/O requests from DOS over the IDE interface via vendor specific commands to the user space daemon running on the Pi.  Status is send back via the same mechanism.

The redirector code is still early in development.  It will only support DOS versions >= 5.x for the time being as well as only one drive letter/Pi path.  My intent is to bring the redirector to functional completion by May then work on bugs, quirks, ghosts in the machine.

Virtual Network Interface

Pursuant to the original project goals, the idea is to add a ‘virtual network interface card (NIC)’ to the host system fulfilled by passing raw 802.1 Ethernet frames through the IDE interface using vendor commands.  Initially this will take the form of a packet driver on the DOS side and a virtual tun/tap networking interface on the Pi side.  The Linux network interface can then be either traditionally IP routed to the rest of the known network or bridged to provide a transparent frame-level interface to other available wire or wireless MACs.  An initial packet driver implementation should allow TCP/IP stacks such as mTCP or PC-TCP to provide services such as telnet, ftp, irc, and others to the host.  At some point it would ne nice to also write an RNDIS driver to allow Microsoft LAN Manager and PC-NFS to also run on the host.  No development has started on this feature yet.

Serial Console

The most basic interface on the Raspberry Pi that will always operate independent of any other configuration is the Linux serial console.  To this end, the console serial UART is routed to both a debug header and to a UART block inside the FPGA.  The UART data and status registers are placed inside the IDE register space at unused locations.  A PICON.COM utility provides basic access to the UART for debugging, diagnostics, and configuration of the Pi network interfaces when all else fails.  Currently terminal emulation support is provided via DOS console and ANSI.SYS.  This utility needs a lot of work and is one of the primary volunteer areas of interest.

Other Features

Various DOS utilities and potentially other utilities for machine platforms and architectures (eg, Apple, Atari, etc) need to be developed in many areas:

• Network configuration
• NTP/RTC clock setup
• Wifi SSD selection and management of access credentials (essentially wpa_supplicant.conf maintenance)
• Virtual hard disk image creation, management, and selection
• Quite a few I haven’t thought of yet.

Theory of Operation

TBD

Raspberry Pi and Image Setup

TBD

Checkout and Build

TBD

ATA Spec Compatibility

TBD

Performance & Host Compatibility

TBD

Major To-Do List