• Please review our updated Terms and Rules here

Bendix G-15 Restoration

I forgot to mention that The Bendix Corporation sold its computer division to Data General in 1963, so some of the last few G-15s produced (including this one, #350) were badged as Control Data, but nothing is different underneath the hood.

G15_Control_Data_Minneapolis_paper_1963.jpg
 
I have a friend in Pleasanton that used to service them, along with CDC 160's as a CDC tech
That also reminded me he had a 160 that went to LCM, never to be seen again
 
Hey Stephen, tried emailing you privately but for some reason my email client doesn't like your address. Anyhow, one word of advice, and perhaps it’s already been addressed, but if it’s possible to raise the heads on the magnetic drum before transport, do so.

One word of advice, and perhaps it’s already been addressed, but if it’s possible to raise the heads on the magnetic drum before transport, do so.

I bought an LGP-30 some years ago and had it shipped, but I drove roughly 3000 miles to hand carry the drum (and Flexowriter), to avoid damage. The smartest thing I did once home was to back out the mounting screws securing the many head support bars, before attempting to give the drum a spin to check the bearings (and boy were they dry). After some very careful measurement with brass shim stock, I determined that the drum had in fact swelled by a few thousandths over the years, and the oxide was in direct contact with multiple heads which would have permanently destroyed the drum had I spun it. With all bars raised with washers as spacers, I could then tackle each bar, one at a time, getting the head gap correct as I went.

Hopefully yours won’t have this problem, but there’s an overwhelming urge to just give that drum a spin “just to see". I highly recommend not doing that : ) -C
 
eldofever said:
Hey Stephen, tried emailing you privately but for some reason my email client doesn't like your address. Anyhow, one word of advice, and perhaps it’s already been addressed, but if it’s possible to raise the heads on the magnetic drum before transport, do so.

One word of advice, and perhaps it’s already been addressed, but if it’s possible to raise the heads on the magnetic drum before transport, do so.

I bought an LGP-30 some years ago and had it shipped, but I drove roughly 3000 miles to hand carry the drum (and Flexowriter), to avoid damage. The smartest thing I did once home was to back out the mounting screws securing the many head support bars, before attempting to give the drum a spin to check the bearings (and boy were they dry). After some very careful measurement with brass shim stock, I determined that the drum had in fact swelled by a few thousandths over the years, and the oxide was in direct contact with multiple heads which would have permanently destroyed the drum had I spun it. With all bars raised with washers as spacers, I could then tackle each bar, one at a time, getting the head gap correct as I went.

Hopefully yours won’t have this problem, but there’s an overwhelming urge to just give that drum a spin “just to see". I highly recommend not doing that : ) -C
Click to expand...
Thanks for the heads up! I've only picked up the typewriter console so far. I'll pick up the rest of the components in November and will keep that drive warning in mind.
 
Progress has ground to a halt until warmer weather since we need to take the unit out of the garage and have it professionally cleaned / disinfected - mice!
 
Al Kossow said:
The big restoration problem with the G-15 is the drum, which lives near the bottom of the cabinet.
The timing chain for the computer is encoded on that drum. As far as I know, no one has archived
the drum's contents.

The LGP-30 has similar problems, and is a marvel in what they did with so few parts.
Click to expand...
The G-15 had three timing tracks on the drum. Two were simple clock tracks and were permanently recorded. They were duplicates of each other -- apparently a tube failure in the read circuitry could cause corruption of a track, hence the redundancy. The bad track could be restored in the field by a maintenance technician.

The third track was termed the "number track." It was used partially for instruction timing, partly as location information for words on a drum line (track), and a couple of other things. Because it could be modified during instruction execution, this track recirculated, i.e, it was rewritten on every drum revolution. Since it recirculated, its contents were lost during a power off. Therefore, one of the things that happened during power up sequencing was the 108 words of number track data were automatically read from paper tape and copied to the drum. You literally could not use the machine until that data was loaded, so it was common practice to include the number track data as the first block on program tapes.

The number track data has survived and is available as the first block of http://www.piercefuller.com/collect/bendix/bxtst.pt. That is a binary tape image. I have attached two formats of more readable text versions of the number track block. See http://bitsavers.org/pdf/bendix/g-15/G15_PaperTapeFormat_Jan58.pdf for a description of the text codes.
 

Attachments

  • NUMTRACK.PTI.txt
    866 bytes · Views: 4
  • NUMTRACK-Std.PTI.txt
    1 KB · Views: 2
commodorejohn said:
Curious what this means - are we talking about the basic control sequencing for the CPU or something of that nature? Interesting design choice if so, but I could see the logic behind it.
Click to expand...
Not quite. The G-15 operated bit-sequentially in synchrony with the drum revolution. There were a half-dozen bits from a timing track that marked certain boundaries in instruction words and signaled the necessary logic operations in the processor.

Unlike most drum-based systems, the G-15 did not have address-coincidence logic. Instead, the number track indicated the current rotational position of the drum. The G-15 used the difference between the current word location and the desired location to count its way to the desired location. See the discussion of the Command Register (CM) starting on page 40 and drawing 6 of http://bitsavers.org/pdf/bendix/g-15/60121600_G15_Theory_Of_Operation_Nov64.pdf.
 
Al Kossow said:
Has anyone been in contact with Paul [Pierce]? Did his G15 and the tape collection go to LCM?
It isn't at CHM. That paper tape collection was irreplacable. It contained the only known copies
of the G15 user's group tapes.
Click to expand...
I had some brief correspondence with him about a year ago when I was working on a G-15 emulator. I asked about the tapes. He said he still has them, but some have been in water and will need restoration before they can be read. He's interested in capturing their contents, but said it would probably be a while (years) before he could get to it. He said he also has tapes for the LGP-30 and RPC4000. I didn't ask, but I suspect that he may be amenable to someone coming in and either helping with this, or taking it over.
 
I've been working on a gate-level emulation of the G-15. So far, it reads a paper tape image, initializes the number track, puts the first block of code on the drum and is executing it. As I don't have an image of the PPR paper I'm not sure how close to functioning the emulation is to the G15. It's running a bit faster than the G15 even though there's a line of code for every logic gate in the computer that has to be evaluated on every clock cycle. I think this would be quite helpful for anyone bring up a real G15. Does anyone have the PPR (Program Preparation Routine) tape image?
 
An ASCII paper tape image of PPR is available at https://github.com/retro-software/G15-software/tree/main/PPR. This is preceded by the number track. See the README for provenance and a link to some documentation.

If you are working on an emulator, you will probably want to check out BXTSTS.PT on Paul Pierce's site at http://www.piercefuller.com/collect/bendix/. This is a pretty good diagnostic for the processor. That file is a binary tape image, but an ASCII image of it is available as BXTST.pti at https://github.com/retro-software/G15-software/tree/main/Diagnostics. Again, see the README for provenance and documentation.

I'd be really interested in learning more about your gate-level emulator.

I have written an emulator for a basic G-15D system (paper tape and typewriter I/O only) that runs in modern web browsers. It works mostly at the word-time level and attempts to run at the speed of a real G-15. You can run it directly from its hosting site at https://www.phkimpel.us/Bendix-G15/ or you can download the files from the project repo at https://github.com/pkimpel/retro-g15/ and set them up on your own server. See the Getting Started document in the project wiki.
 
Paul Kimpel said:
An ASCII paper tape image of PPR is available at https://github.com/retro-software/G15-software/tree/main/PPR. This is preceded by the number track. See the README for provenance and a link to some documentation.

If you are working on an emulator, you will probably want to check out BXTSTS.PT on Paul Pierce's site at http://www.piercefuller.com/collect/bendix/. This is a pretty good diagnostic for the processor. That file is a binary tape image, but an ASCII image of it is available as BXTST.pti at https://github.com/retro-software/G15-software/tree/main/Diagnostics. Again, see the README for provenance and documentation.

I'd be really interested in learning more about your gate-level emulator.

I have written an emulator for a basic G-15D system (paper tape and typewriter I/O only) that runs in modern web browsers. It works mostly at the word-time level and attempts to run at the speed of a real G-15. You can run it directly from its hosting site at https://www.phkimpel.us/Bendix-G15/ or you can download the files from the project repo at https://github.com/pkimpel/retro-g15/ and set them up on your own server. See the Getting Started document in the project wiki.
Click to expand...
I had just found those resources. That's a big help. Right now the emulator is failing (off by one) to compute a good checksum for the number track. But that's a lot working. The whole I/O system is pretty well exercised by reading in the paper tape to the number track and the first block of code into line 19. I put this project aside eight years ago when I realized just how hard it would be to debug. The original idea was to put the whole G15 into an FPGA... but that was even harder to debug. Transcription of the schematics into it's inherent logic was quite a chore too.
 
An excellent new series of videos of a Bendix G-15 restoration!

My new computer weighs 1,000 pounds!

Exploring 1950’s computer logic with the Bendix G-15!
 
stephenbuck said:
View attachment 1246850

I have a long-time friend who recently mentioned to me that he has an old computer in his garage that he’d like to find a good home for, preferably a museum.

“What type of computer is it?”, I asked.
“A Bendix G-15”, he answers.
“Oh cool”, I answered, having no clue what he was talking about.

I had to look it up and what I found was absolutely amazing.

The Bendix G-15 is a very early (1956) vacuum tube computer based on Alan Turing’s Pilot ACE. It was hailed as the first “personal computer” (meaning it only need one person to operate it) and was one of the very last vacuum tube computers produced. It’s an odd beast, unlike any other computer I know of. It has a 29-bit word length, a whopping 2,160 words of magnetic drum memory, and an almost indecipherable instruction set. All operations are performed 1 bit-at-a-time.
Click to expand...

Basically the first computer which was simple enough and cheap enough to be dedicated to one engineer as his/her calculating machine.

20 years later replaced in that role by the mini calculator.
 
I've got an Excel spreadsheet that substitutes for the G15 PPR (Program Preparation Routine) and writes out paper tape images suitable for use in Paul Kimpel's emulator. Anyone interested? I'm using it to help debug my gate-level emulation of the G15. Using the G15 emulator as a means of creating tape images is possible, but seriously heinous.
 
rbep said:
I had just found those resources. That's a big help. Right now the emulator is failing (off by one) to compute a good checksum for the number track. But that's a lot working. The whole I/O system is pretty well exercised by reading in the paper tape to the number track and the first block of code into line 19. I put this project aside eight years ago when I realized just how hard it would be to debug. The original idea was to put the whole G15 into an FPGA... but that was even harder to debug. Transcription of the schematics into it's inherent logic was quite a chore too.
Click to expand...
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.
 
You must log in or register to reply here.
Back
Top