This file pcie360_0_1_20120413.zip contains the VHDL code for the FPGA implementation of the 2065 emulator (incomplete, but capable of some elementary operations from the console panel). Here's the description from the top-level file (pcie360.vhd):
This is the design for an FPGA implementation of an IBM 2065 CPU emulator. As I have insufficient documentation on the IBM 2065, and because I don't have a copy of the ROS contents of the 2065, this is really an IBM 7201-2 CE emulator with 7201-specific bits stripped out.
Major subcomponents are:
cpu - actual CPU emulation
blinken - interface to an IBM 2065 console panel w/shift registers
corememory - 256 KB of main memory (dual-ported between cpu and ioce)
ioce - interface for the IOCE emulator running on the PC
pcie - PCIE endblock to communicate with the PC (*)
This design is intended to be implemented on the Xilinx ML509 / XUPV5 developer board.
(*) A Xilinx PCI Express Endpoint Core example design needs to be added for this design to work. I cannot include that here because of copyright restrictions.
I realised that I'd need some extra hardware to connect the PCIe card to the console panel. The I/O pins on the Xilinx board operate at either 2.8 or 3.3 volts, and my console panel circuitry operates at 5 volts. So, what I need is some level shifters. I got four of these 4-way level shifters, and put them on a piece of veroboard with connectors for the Xilinx board and a 50-pin ribbon cable.
The 50-pin ribbon cable terminates in an HD50 connector (commonly used for narrow SCSI applications) on a PCI bracket. The panel has been fitted with the same connector, so a SCSI cable can be used as an interconnect between the PC and the panel.
A new probem is that the PCIe card doesn't fit the computer case. The pc is housed in a 4U high 19" case. Even though there's a good deal of space, the Xiling card is just too tall. A few connectors and the CompactFlash card stick out.
For now, I've put the top cover on four standoffs. I just daren't put any real load (like the console typewriter) on top of it now.
I'm going to create some extra space in the top of the case by replacing the video card and cpu cooler with low-profile ones. I can then mount the Xilinx card horizontally above those components, using a flexible PCIe extender, similar to this.
Over the past few weeks, I've decided that there are a two things I don't like about the current 2065 emulator. These are:
In the real 2065, several things would happen at once every 10 ns sub-cycle. The software emulator is necessarily much more sequential;
The blinkenlights console doesn't get updated frequently enough.
Rather radically, I have therefore decided to change the emulator from a software emulator into a hardware emulator. Inspired by Lawrence Wilkinson's model 30 emulator on an FPGA, I'm going to implement the 2065 emulator on an FPGA as well.
The idea is to have the 2065 CPU and memory, as well as the logic to control the console panel on the FPGA board. For now, I'm not going to implement channel I/O on the FPGA, in stead, the FPGA will be interfaced with a PC running a software emulator of the channel and other I/O hardware.
The interface between the FPGA and the sioftware I/O will need to be able to support the following actions:
- The FPGA tells the software to execute an IPL, START I/O, TEST I/O, HALT I/O or TEST CHANNEL command;
- The software has read and write access to main memory implemented on the FPGA board;
- The software signals interrupt status to the FPGA board;
- The FPGA board signals interrupt completion to the FPGA board.
The interface needs to be reasonably fast and reliable. I found that FPGA development boards are available that fit into a PCIe slot. I've selected the Xilinx XUPV5 board pictured above for this project, as it has ample logic, a PCIe interface, and I/O pins that don't use exotic connectors.
Next thing to do is to build a small interface to connect the XUPV5 to the shift registers that drive the console panel.
Today I did a little work on the console printer/keyboard to-be (a Tekade teleprinter used by the German armed forces). The power supply had a problem in the main 5v regulator. This consists of two LM317's in series with an op-amp driven feedback loop. I found out that both LM317's and the op-amp were broken (culprits shown right); possibly an over-current issue. I replaced those parts, and got the juice running again.
The teleprinter is running again (at least, in local mode). To connect it to the pc, I'll either need to build an RS232 to current loop converter, or try to find the V.10 interface card that was an option on these machines.
On the inside, these machines are a pleasure to work with. All functional units (power supply, keyboard, printer) can be removed by unscrewing 2-4 screws. The electronics are contained in a card-cage (three intel 8749 microcontrollers, CMOS logic, and high power transistors to drive the mechanical parts).
Functionally, it's equivalent to a Teletype ASR, with a paper tape punch and reader:
After Chris Bigos (www.ibm360.info) put large parts of the 7201-02 Field Engineering Diagrams Manual online, I had enough information to get a little further again.
I estimate that the cpu emulation is now about 70% complete. (out of 513 uops, 346 have been implemented completely and correctly, another 36 have been implemented and are probably correct, 32 are partially implemented, and 114 have not been implemented). Of course, the remaining 30% is the toughest part, though some of the uops probably will never get used because they're specific to the 9020's CE (7201-02) inter-processor communications and FAA special instructions.
I've had to use a few kludges, such as inserting uops into the microcode, keeping track of what the instruction counter should be, and faking the division and multiplication instructions, because some of those details are still vague. They should become less vague now that Chris has also put up the Field Engineering Theory of Operations Manual.
I've modified the "plain" Hercules emulator to write register values and a memory checksum to a text file after each instruction, and I'm doing the same in the M65 emulator. By comparing the text files, discrepancies between the emulators show up. The M65 emulator generates a second (huge) textfile that show the uops that get executed. I find the offending instruction in that second file, and try to figure out what causes the behavior to be wrong.
This way, I'm now getting correct behavior IPL'ing OS/360 MFT up to the first message being written to the console. The console is an emulated 1052. The printer/keyboard has been replaced with a serial terminal in this emulation.
I would like to connect a 1052 to the emulator; that would make the interaction a lot more realistic. However, I think getting my hands on a real 1052, and somehow interfacing it to a PC is going to be difficult. I do have a german teleprinter (Telex), so I'm thinking of building a converter between RS232 and current-loop to hook that up to the pc running the emulator. I'll need to fix the teleprinter's power supply first though.
I have some very exciting news to share. The emulator connected to the console panel has just run a rudimentary IBM 360 program.
Chris Bigos has provided me with ROS listings and control field definitions for the IBM 7201, an improved version of the model 65 used in the IBM 9020 complex, which was developed for the FAA for air traffic control.
Based on that information, I've put together a partial (very incomplete) emulator that is capable of running a simple 2-instruction program that counts up from 0. The program can be toggled in from the console panel. I will try to post a video tomorrow.
I've put a first version of the beginning of the emulation code on the Wiki at http://ibm360-console.wikispaces.com/emulation. Based on the information Chris has provided so far, I think I have a fair idea of what the emulation loop needs to look like. Only a few of the many micro-orders, and none of the actual ROS contents have been filled in.
I've updated the microachitecture Wiki with some information that Chris Bigos provided me with at his site. He provided me with scanned sections of some of the field engineering docs. I was able to add information to the microarchitecture, ROS and working registers entries. A big thank-you to Chris.
So here it is, the plans for the software that I promised on New Year's Eve.
Rather than writing an emulator from scratch (something I've done a few times before, see ES40 and FreeAXP for examples) I'm going to modify an existing emulator, the Hercules System/370, ESA/390, and z/Architecture Emulator. Whew, that's a mouthful! It emulates an IBM 370 or later rather than a System/360, but as the 370 was downwards compatible, OS/360 will run on Hercules.
I like using Hercules with an add-on application called Jason. Jason is a graphical front-end to Hercules, that provides you with a view of the (virtual) devices attached to the emulator. It allows you to change a tape, or load a deck of cards using the mouse on the devices, rather than typing commands at the Hercules prompt. Having a Jason display running on an LCD panel next to the console panel seems to be a good way to show the rest of the 360 environment.
I'll make two modifications to Hercules. The most obvious change will be to equip Hercules with an interface to the real console panel. The more subtle change will be to replace the emulated 370 CPU with an emulated 360 model 65 CPU. The feasibility of doing this depends on my ability to find the proper documentation on the model 65's microarchitecture (see the Wiki for an overview of the microarchitecture).
The emulated cpu will no longer execute one entire System/360 instruction at a time, but one ROS microprogram instruction. Depending on the setting of the console panel switches, after pressing the START button, the system will keep executing instructions, execute a single System/360 instruction, or execute a single microprogram instruction.
Just when I thought the hardware part of this project was finished, as I turned to the software part of it, I discovered that the Velleman IO kit I used is way too slow for what I'm trying to do. It takes around 1whole second to read and write all the data (24 bytes in, 40 bytes out). This is way too slow; it means that a change in the switch settings will be reflected by the lamps up to two seconds later. It also means that pushing a pushbutton for less than a full second might not be picked up. Grr....
So, over to plan B, which is to use an arduino. With the proper cables, it should just plug into the electronics kit like the Velleman K8060 did. I'll use it with the Ethernet shield, so the console pannel can use a network connection to the emulator pc rather than USB. With the Arduino, I believe I can get the response time down to 1 millisecond.
First of all, hapy new year to all fellow tinkerers, collectors and enthousiasts.
I've set up a Wiki at http://ibm360-console.wikispaces.com/ with information about the model 65 microarchitecture. Hopefully, I can find the information to keep adding to it to build a complete picture of the model 65 microarchitecture. If you're familiar with 360's, or have suggestions as to what certain bits might mean, feel free to join the wiki and contribute.
