The Hardware Emulation Project is an attempt to build a complete DPS8/M Mainframe on an FPGA. The final goal is to implement the following:
- CPU (starting with one but eventually at least a dual-CPU system)
- SCU (System Control Unit with at least 12 MWords of RAM, 36-bit words)
- IOM (Input Output Multiplexer)
- MSS (Mass Storage System, hard disk emulation using modern HD/SSD drives)
- Tape Drive(s) (emulated with USB sticks)
- Unit Record Devices (Card Reader/Punch and Line Printer, emulated using USB sticks and, possibly, USB printer for line printer)
- Datanet 6678 Front-End Network Processor (supporting serial lines and TCP/IP connections)
- Project Lead: Dean S. Anderson
- A former employee of Honeywell Underseas Systems, Dean began his career in 1980 as a Computer Operator at Gelco, Inc., working on a Honeywell 66/60 dual-processor system running GCOS III. Over the years, he progressed through the Computer Operations Group, gaining extensive experience with Honeywell mainframes, and ultimately contributed by developing and implementing several custom modules within the GCOS III (4JS2) kernel.
- Charles Anthony
- Charles, together with Harry Reed, played a central role in the development of the DPS8M software simulator, which enables Multics to run on modern systems. His contributions to the DN355 software simulator and the TCP/IP implementation for the Direct Interface Adapter (DIA)---allowing communication with an external Front-End Network Processor (FNP)---have been invaluable to the preservation and continued operation of Multics today.
Also:
- Eric Swenson and Jeffrey Johnson -- Provide invaluable emotional support and encouragement, helping to sustain momentum and foster collaboration among the team.
- There has been some discussion around the best way to implement the rest of the system. There are two primary options:
- Create a version of the DPS8M software simulator that runs on an ARM Core on an FPGA Development Board (such as the DE-10 Nano) and then start moving parts of it into the FPGA, probably starting with the SCU/RAM).
- This is the "inside out" approach.
- The advantage here is that very high speed communications are possible with the internal ARM core connecting directly to the FPGA.
- The disadvantage here is that getting the DPS8 simulator working on the ARM core looks like it could be a difficult task.
- Start adding more peripheral device emulation using the DE-10 Lite to communicate with the software simulator (running on a Raspberry PI) in a manner similar to the FNP emulation.
- This is the "outside in" approach.
- The advantage of this approach is that simpler components are implemented first and grow in complexity as implementation proceeds providing a nice "ramp up" in FPGA skills and expertise.
- The disadvantage is that an external, high-speed communications method is required between the Raspberry PI and the DE-10 Lite board. The initial thought is to create a 9-bit parallel bus between the PI and DE-10 for the simulated peripherals. This will certainly be fast enough for unit record devices and probably tape drives but when you add mass storage devices, will it be fast enough?
- Based on the above, this phase will consist of creating the 9-bit parallel bus between a Raspberry PI and the DE-10 Lite and adapting the FNP FPGA emulation to use this bus to communicate with the simulated IOM running on the Raspberry PI.
- Speed and throughput testing will be done to determine maximum data transfer rates and throughput using a set of "test harness" programs running on the PI and FPGA independent of the DPS8 simulation/emulation.
- The follow-on phases will be determined once the above testing is complete.