• Please review our updated Terms and Rules here

Bendix G-15 Restoration

Currently, I'm hitting some issues with the divide logic. The PPR is loading, but I need to code up a Flexowriter emulation to get the user interface up and running.
I would certainly be interested in a copy of the PPR spreadsheet! Can you post it to this thread?
Here's the "work-in-progress" Excel version of the PPR. The three buttons are to generate the binary, punch a block, or do a combined punch of all the contiguous sheets prefixed by a number track. It follows standard G15 practice of uvwxyz instead of abcedf hexidecimal. The arcane L numbers are filled in for the line31 opcodes if left blank. Jumps to vacant locations and code with no antecedent are flagged. I'm using it a lot to write test routines to debug my gate level simulation. The punched tapes load into the Kimpel emulator just fine. Let me know if there are any bugs to fix.


  • G15_PPR.zip
    80.6 KB · Views: 7
I've brought back to life an old project of mine, a SystemVerilog implementation of the Bendix G-15. The core G-15, that is the circuitry housed in the main cabinet including the CPU and I/O processor, are complete except for debugging. This portion of the project can be synthesized or simulated. It's relatively small, when synthesized occupying <25% of an Artix A15. Individual drum tracks are implemented as large (3132 bits for long tracks) shift registers.

For simulation purposes, I've implemented a SystemVerilog paper tape reader including relay control logic. Likewise, I've implemented a power-on sequencer that steps the core through start-up. So far I can read the first block of Paul Pierce's 'bxtst.pt' into M19, but find that the sign bit of every word in the track is set. I chased that for a day until I found that flip-flop OS never gets reset after the first 'minus' character on the tape. It turns out that G15 tapes must have a 'tab' or 'cr' character paired with each 'minus' character to reset flip=flop OS, but the 'bxtst.pt' tape contains no 'tab' or 'cr' characters.

So, I'm thinking that 'bxtst.pt' lost those characters somewhere along the line, possibly in the conversion process from physical paper tape. Today's project is to re-insert those characters as required producing a "fixed" 'bxtst.pt'.
This is an update to my previous post. I looked more closely at the 'bxtst.pt' tape image and have found that although it contains extraneous 'minus' characters, it does load correctly after fixing a small bug in my HDL.

The G-15 paper tape input occurs up to 4 29-bit words at a time and follows one of two methods:

1. A string of 29 hex digits forming a 116 bit binary value that contains the 4 consecutive 29-bit words. Each 29 digit string ends with a 'reload' character that transfers the 116 bit binary value from M23 to M19 via MZ. The final group ends with a 'stop' character that performs the same function as a 'reload' and also stops the paper tape reader.

2. 4 strings, one for each 29-bit word formatted like this: SXXXXXXXT where S is a 'minus', a 'blank' or omitted, X is one of 7 hex digits forming the 28 bit magnitude of the word, and T is a 'tab' character. A 'S' character of 'minus' sets the OS flip-flop. The 7 hex digits are precessed into M23. The 'tab' character causes OS to be precessed into M23 and resets OS.

In the case of 'bxtst.pt', the first method is followed. For some unknown reason the tape also contains a 'minus' preceding any 4 word group where any word in the group contains a negative number. Since the tape contains no 'tab' characters, the extraneous 'minus' characters set flip-flop OS which is neither precessed into M23 nor cleared. At the end of the block, the 'reload' or 'stop' clears the OS flip-flop.

I've been following the Usagi Electric restoration project with interest. In fact, it's what motivated me to revisit my G-15 FPGA project.
I've got my model working (under simulation) through loading of both the number track block and the boot block of "bxtst.pt". Switching on <GO> attempts to load the first instruction, but quickly winds up in the weeds. Interestingly, model simulation using Vivado on an older i7-10700 runs about the same speed as an real G-15 would.

For anyone who'd like to follow along at home here's the GitHub repo: eightycc/g15_fpga