[cctalk] Re: Bendix G-15 Restoration

[Paul Kimpel via cctalk]

*From:* Jon Elson via cctalk 
*Subject:* [cctalk] Re: Bendix G-15 Restoration
*Date:* Monday, October 10, 2022 at 7:35 AM
*To:* Christian Corti via cctalk 
*Cc:* Jon Elson 




On Sat, 8 Oct 2022, Paul Kimpel wrote:
modify a lot of the software. Timing dependencies aside, G-15 
instructions didn't have addresses -- they had "timing numbers" that 
effectively told the hardware how long to wait before reading or 
writing a word on the drum.


Well, No, I believe that each instruction had the address of the next 
instruction in it.  That allowed you to jump to another track for the 
next instruction in the sequence.  Instruction addresses were not that 
many bits.


Jon


Not quite. A G-15 instruction had two fields, T and N, each seven bits, 
that looked like sector addresses, and you could often think of them as 
sector addresses, but doing so carelessly could get you into trouble.


N is the easiest one to understand. That was the sector "address" of the 
next instruction to be executed, which except in the case of two 
instructions had to be in the same line (track) of the drum as the 
current instruction. The problem is that the field could hold values 
from 0-127, but the words around the drum were numbered 0-107, and it 
was perfectly valid (and sometimes even useful) to specify a value of N 
in the range 108-127.


What actually happened is that the processor subtracted the N value from 
the word number of the current instruction (termed L), stored the 
truncated difference in a seven-bit field of a hidden register on the 
drum named the Command (CM) register, and then as each word passed the 
read head of the drum, counted that field up until it overflowed its 
seven-bit size. At that point the drum was in the correct position to 
read the next instruction.


Actually, it was a bit more complicated than that, because the 
arithmetic in CM was being done modulo 128, but the word addressing was 
modulo 108. The processor handled that by adding an additional 20 to the 
CM field if the drum passed word 107 before the count overflowed. There 
was an additional complication in that the adjustment did not take place 
if you executed an instruction from word 107, in which case the 
programmer had to bias their timing numbers by 20 instead to accomplish 
the adjustment. It was a lovely machine to program.


You can read how the sausage was made in the Theory of Operation manual, 
section C-17, starting on page 40 (page 46 of the PDF):


http://bitsavers.org/pdf/bendix/g-15/60121600_G15_Theory_Of_Operation_Nov64.pdf

There were 20 108-word lines (0-19) and four 4-word lines (20-23) on the 
drum that software could access, but instructions could be executed only 
from lines 0-5, 19, and 23. A register in the processor determined which 
line was currently selected to execute instructions, so execution stayed 
on that line until it was changed by either a Select Command Line/Mark 
Exit or Select Command Line/Return Exit instruction. Those were the only 
ways to branch from line to line.


The T field in an instruction can be thought of as the operand address, 
and often effectively was, but you had to be careful with that idea, 
too. It was called T because it was the "timing number" for the 
instruction's execution. Instructions had two modes, Immediate and 
Deferred, determined by the I/D bit in the instruction word.


Deferred mode is easier to understand. Like N, the difference between it 
and L was stored in a field of CM and counted up until it overflowed. At 
that point the processor would access the word(s) under the read and/or 
write head on the line(s) selected by the S and D fields of the 
instruction. In this mode, T effectively told the processor how long to 
wait until the operand word(s) were in position, so it was very much 
like an operand address.


In Immediate mode for most instructions, however, the operand data 
started at L+1, the word number immediately after that of the 
instruction. T specified how many words the instruction would process, 
but in a weird way -- processing started with the word at L+1 but ended 
at T-1. A really lovely machine to program.


In Immediate mode for a few instructions (multiply, divide, the shifts), 
T actually specified the number of word-times the instruction would 
take, but instead of processing words from the storage lines on the 
drum, it processed them in the double-precision registers, which were 
also on the drum. For shifts, each two counts of T would shift one bit; 
for multiply and divide, each two counts of T would develop an 
additional bit of the result. See the ToO manual, section D-10, D-11, 
D-12, and D-13 starting on page 53.


So that's why I say the G-15 didn't have addresses. But then, it didn't 
really have op codes, either.


For some insight into how advantageous use could be made of non-obvious 
values for the N and T fields in G-15 instructions, see this blog post 
describing a program that would c

[cctalk] Re: Bendix G-15 Restoration

[Sellam Abraham via cctalk]

Awesome history, Rick!

Sellam

On Mon, Oct 10, 2022 at 9:35 AM Rick Bensene via cctalk <
cctalk@classiccmp.org> wrote:

>
> Paul wrote:
> >> modify a lot of the software. Timing dependencies aside, G-15
> instructions
> >> didn't have addresses -- they had "timing numbers" that effectively
> told the
> >> hardware how long to wait before reading or writing a word on the
> drum.
>
> To which Christian replied:
>
> > Oh really, that is then similar to the addressing scheme of the Diehl
> > Combitron (a marvelous design by Stanley Frankel).
>
> Indeed, the old drum computers generally had timing information in the
> instruction set that gave the optimal
> sector on the drum for the operand address, and the next instruction
> address.
>
> We had an old computer at our high school computer lab (1974-ish) that
> was designed in the mid-1960's by 3M (the scotch tape company) that was
> originally a real-time monitor and data reduction system for a natural
> gas distribution system and was donated to the school when it was
> retired.
>
> The machine had two CPUs that ran in tandem with the ability to detect a
> fault in one, and switch to the other.
> The CPUs had 24-bit words, and each had 8K words of magnetic drum
> memory.They were discrete transistor-based machines and were
> bit-serial in architecture.   An instruction like ADD that operated on
> an operand to add to the accumulator would have information in the
> instruction set reference that said "for optimal programming,
> operand=N+3, next instruction=N+6".
> The assembler (which was slow!), called SOAP, tried to optimize, but for
> a lot of things like list processing and such, it really couldn't do
> much to help.   Tables and lists had to be scattered all over the drum
> for the best speed, and that got kind of difficult because the operand
> address only had room for a sector number.  If the reference was on a
> different track, you had to prefix the instruction with a modifier
> instruction that would specify the block and track for the operand (and
> next instruction if needed).   There were no index registers, so the
> only way to do calculated data fetches or branches was to load the
> instruction base into the accumulator, then modify it using math
> operations to calculate the correct sector, then store the accumulator
> at the address specified by the next instruction address to execute it.
> It was crazy fun learning it, but in practice, even trying really hard
> to optimize the code, it could barely drive a Teletype 33ASR to full 10
> character-per-second maximum speed.It had a bunch of I/O stuff,
> including a Parabam transistorized real-time clock that could be read by
> the computer, a bank of thumbwheel switches that could be read in BCD
> form, and a whole rack full of A/D (discrete transistor) converters,
> digital counters, analog outputs, and digital relay outputs that were
> used for the original data acquisition I/O, but the cables going into
> them were just chopped off, and I never played with any of that other
> than to write code to click the relays in pseudo-random patterns to make
> a noise like the machine was "calculating".
>
> Speaking of the Diehl Combitron, it was indeed an amazing transistorized
> (with only something like ~130 transistors in total) calculator designed
> by the genius of Stan Frankel (who also designed the transistorized
> Smith-Corona/Marchant (SCM) Cogito 240/240SR calculator (which was way
> too slow due to SCM requiring the use of cheap slow-switching diodes),
> the Royal McBee/Librascope/General Precision LGP-30 vacuum-tube drum
> computer, as well as consulted in the design of the delay line-based
> Packard Bell PB-250.
>
> The Combitron was an amazing microcoded bit-serial processor designed in
> around '63-'64 by Frankel.  It was user-programmable (but not user
> microprogrammable, unless...).ROM for storing the microcode was a
> difficult thing back then, generally taking quite a bit of space (not
> really practical for a desktop calculator) and were labor-intensive and
> expensive to build.
>
> How did Frankel store the microcode for the Combitron?
>
> On a punched stainless steel tape that was optically read a bit at a
> time at power-up into a delay line.  Once the microcode was loaded, the
> tape would rewind and the microcode engine would start up reading its
> instructions out of the delay line.  Hence the addressing scheme  in the
> microcode to make it as fast as possible. The addressing scheme
> accounted for the delay time for processing a microcode function such
> that the next micro-instruction would be right at the output tap of the
> delay line when it was needed.
>
> It takes about a minute for the microcode to load when the machine is
> powered up.  The tape has two channels, one for the clock, and another
> for the microcode bits.
>
> By the way, an end-user could presumably write custom microcode for the
> calculator if they had the microcode documentation and a 

[cctalk] Re: Bendix G-15 Restoration

[Rick Bensene via cctalk]

Paul wrote:
>> modify a lot of the software. Timing dependencies aside, G-15
instructions 
>> didn't have addresses -- they had "timing numbers" that effectively
told the 
>> hardware how long to wait before reading or writing a word on the
drum.

To which Christian replied:

> Oh really, that is then similar to the addressing scheme of the Diehl 
> Combitron (a marvelous design by Stanley Frankel).

Indeed, the old drum computers generally had timing information in the
instruction set that gave the optimal
sector on the drum for the operand address, and the next instruction
address.   

We had an old computer at our high school computer lab (1974-ish) that
was designed in the mid-1960's by 3M (the scotch tape company) that was
originally a real-time monitor and data reduction system for a natural
gas distribution system and was donated to the school when it was
retired.

The machine had two CPUs that ran in tandem with the ability to detect a
fault in one, and switch to the other.
The CPUs had 24-bit words, and each had 8K words of magnetic drum
memory.They were discrete transistor-based machines and were
bit-serial in architecture.   An instruction like ADD that operated on
an operand to add to the accumulator would have information in the
instruction set reference that said "for optimal programming,
operand=N+3, next instruction=N+6".
The assembler (which was slow!), called SOAP, tried to optimize, but for
a lot of things like list processing and such, it really couldn't do
much to help.   Tables and lists had to be scattered all over the drum
for the best speed, and that got kind of difficult because the operand
address only had room for a sector number.  If the reference was on a
different track, you had to prefix the instruction with a modifier
instruction that would specify the block and track for the operand (and
next instruction if needed).   There were no index registers, so the
only way to do calculated data fetches or branches was to load the
instruction base into the accumulator, then modify it using math
operations to calculate the correct sector, then store the accumulator
at the address specified by the next instruction address to execute it.
It was crazy fun learning it, but in practice, even trying really hard
to optimize the code, it could barely drive a Teletype 33ASR to full 10
character-per-second maximum speed.It had a bunch of I/O stuff,
including a Parabam transistorized real-time clock that could be read by
the computer, a bank of thumbwheel switches that could be read in BCD
form, and a whole rack full of A/D (discrete transistor) converters,
digital counters, analog outputs, and digital relay outputs that were
used for the original data acquisition I/O, but the cables going into
them were just chopped off, and I never played with any of that other
than to write code to click the relays in pseudo-random patterns to make
a noise like the machine was "calculating".

Speaking of the Diehl Combitron, it was indeed an amazing transistorized
(with only something like ~130 transistors in total) calculator designed
by the genius of Stan Frankel (who also designed the transistorized
Smith-Corona/Marchant (SCM) Cogito 240/240SR calculator (which was way
too slow due to SCM requiring the use of cheap slow-switching diodes),
the Royal McBee/Librascope/General Precision LGP-30 vacuum-tube drum
computer, as well as consulted in the design of the delay line-based
Packard Bell PB-250.

The Combitron was an amazing microcoded bit-serial processor designed in
around '63-'64 by Frankel.  It was user-programmable (but not user
microprogrammable, unless...).ROM for storing the microcode was a
difficult thing back then, generally taking quite a bit of space (not
really practical for a desktop calculator) and were labor-intensive and
expensive to build.  

How did Frankel store the microcode for the Combitron?  

On a punched stainless steel tape that was optically read a bit at a
time at power-up into a delay line.  Once the microcode was loaded, the
tape would rewind and the microcode engine would start up reading its
instructions out of the delay line.  Hence the addressing scheme  in the
microcode to make it as fast as possible. The addressing scheme
accounted for the delay time for processing a microcode function such
that the next micro-instruction would be right at the output tap of the
delay line when it was needed.   

It takes about a minute for the microcode to load when the machine is
powered up.  The tape has two channels, one for the clock, and another
for the microcode bits.

By the way, an end-user could presumably write custom microcode for the
calculator if they had the microcode documentation and a way to punch
the stainless steel tape.  Possible, but not terribly practical.

Loading the microcode from a reel of punched metal tape made firmware
updates possible by replacing the tape.  I do not know if there were
different versions of the microcode for the Combitron 

[cctalk] Re: Bendix G-15 Restoration

[Jon Elson via cctalk]

On Sat, 8 Oct 2022, Paul Kimpel wrote:
modify a lot of the software. Timing dependencies aside, 
G-15 instructions didn't have addresses -- they had 
"timing numbers" that effectively told the hardware how 
long to wait before reading or writing a word on the drum.


Well, No, I believe that each instruction had the address of 
the next instruction in it.  That allowed you to jump to 
another track for the next instruction in the sequence.  
Instruction addresses were not that many bits.


Jon

[cctalk] Re: Bendix G-15 Restoration

[Christian Corti via cctalk]

On Fri, 7 Oct 2022, Chuck Guzis wrote:

I recall that the IBM 650 had an upgrade option where core was used for
some of the registers.  It was small--maybe 50 words.


The Z22 had a very small area of core memory, called "fast memory" 
(Schnellspeicher).
And then we have boards out of an LGP-21 (that we still lack in our 
collection) that replaced the on-disc registers with semiconductor shift 
registers. I don't really know why they did that.


Christian

[cctalk] Re: Bendix G-15 Restoration

[Christian Corti via cctalk]

On Sat, 8 Oct 2022, Paul Kimpel wrote:
modify a lot of the software. Timing dependencies aside, G-15 instructions 
didn't have addresses -- they had "timing numbers" that effectively told the 
hardware how long to wait before reading or writing a word on the drum.


Oh really, that is then similar to the addressing scheme of the Diehl 
Combitron (a marvellous design by Stanley Frankel).


Christian

[cctalk] Re: Bendix G-15 Restoration

[Cory Heisterkamp via cctalk]

> On Oct 7, 2022, at 6:14 PM, ben via cctalk  wrote:
> 
> Trying to hide the fact  the drum makes it slow.
> Did any one ever replace the drum with core memory, on the early serial 
> computers?
> Ben.
> 

While not in the interest of increasing throughput, “vintage” computers with 
drums that continued to soldier on well after their expiration date did require 
a more modern memory alternative. The LINK GP-4 that I posted about in 2016 at 
the Northwest Airlines Simulation Center was one such computer. Sadly sold for 
scrap, it had a “solid state drum emulator", loadable via 3.5” diskette. Pics 
here: https://goo.gl/photos/yb83SJSj67gS96n39 
-C

[cctalk] Re: Bendix G-15 Restoration

[Van Snyder via cctalk]

On Fri, 2022-10-07 at 18:17 -0700, Chuck Guzis via cctalk wrote:
> 
> I recall that the IBM 650 had an upgrade option where core was used
> for
> some of the registers.  It was small--maybe 50 words.

Until it moved from Sindelfingen to the IBM Tech Center in Böblingen,
the collection at Haus zur Geschichte der IBM Datebverarbeitung (House
of the History of IBM Data Processing) included a 650 in working order.
It belonged to a museum or university in Vienna and was returned when
the collection moved. I hope it survived the return journey. Hans
Spengler  was one of the staff who maintained the
650. He would likely know whether a core accessory had been available.

[cctalk] Re: Bendix G-15 Restoration

[Paul Kimpel via cctalk]

*From:* Jon Elson via cctalk 
*Subject:* [cctalk] Re: Bendix G-15 Restoration
*Date:* Friday, October 7, 2022 at 7:10 PM
*To:* ben via cctalk 
*Cc:* Jon Elson 


On 10/7/22 18:14, ben via cctalk wrote:

On 2022-10-07 1:09 p.m., paul.kimpel--- via cctalk wrote:
We'd all like to see the ALGO compiler, but be forewarned -- it's 
something like 14 passes on paper tape, with intermediate results 
punched on paper tape. I understand it's a bit more convenient to 
use if you have magnetic tape drives, but it's still going to be 
slow -- there's only so much you can do with 2K words of memory.


Trying to hide the fact  the drum makes it slow.
Did any one ever replace the drum with core memory, on the early 
serial computers?

Ben.

Tghe G-15 was a serial computer with an 90 KHz bit clock.  The entire 
organization of teh computer revolved around the drum (pun intended).  
There was an optimizer that organized instructions around the drum so 
that the next instruction came up on the read head just as the last 
instruction finished.  Without tearing the entire machine apart and 
redesigning the logic, core would not make it faster.


The PDP-8S did have core memory, and for a bit serial computer, it was 
fairly fast.


Jon


With respect to timing, it depends what you mean by "bit clock." The 
drum rotated at 1800 rpm and there were 3596 bits recorded along its 
circumference (124 words of 29 bits), so that works out to 107,880 
bits/s. That is a bit period of 9.3 µs, which is what the G-15 Theory of 
Operation manual calls a "pulse period." A pulse period, however, was 
divided by the clock chassis into phases of 1 µs, 6.3 µs, and 2 µs, so 
the internal frequency of the logic was higher, if somewhat irregular.


That said, Jon is absolutely right about replacing the drum with some 
sort of random-access memory -- you would need to extensively redesign 
the logic of the machine to take advantage of the new memory. You would 
also have to modify a lot of the software. Timing dependencies aside, 
G-15 instructions didn't have addresses -- they had "timing numbers" 
that effectively told the hardware how long to wait before reading or 
writing a word on the drum.


Paul

[cctalk] Re: Bendix G-15 Restoration

[paul.kimpel--- via cctalk]

Paul Pierce in Portland, Oregon has a copy on paper tape, but the tapes have 
been water-damaged and will require restoration. He told me that is on his list 
of projects, but it will be a while until he can get to it. There may be other 
copies, but I don't know of them at present.

[cctalk] Re: Bendix G-15 Restoration

[Dave Wade G4UGM via cctalk]

> -Original Message-
> From: Jon Elson via cctalk 
> Sent: 08 October 2022 03:10
> To: ben via cctalk 
> Cc: Jon Elson 
> Subject: [cctalk] Re: Bendix G-15 Restoration
> 
> On 10/7/22 18:14, ben via cctalk wrote:
> > On 2022-10-07 1:09 p.m., paul.kimpel--- via cctalk wrote:
> >> We'd all like to see the ALGO compiler, but be forewarned
> >> -- it's something like 14 passes on paper tape, with intermediate
> >> results punched on paper tape. I understand it's a bit more
> >> convenient to use if you have magnetic tape drives, but it's still
> >> going to be slow -- there's only so much you can do with 2K words of
> >> memory.
> >
> > Trying to hide the fact  the drum makes it slow.
> > Did any one ever replace the drum with core memory, on the early
> > serial computers?
> > Ben.
> >
> Tghe G-15 was a serial computer with an 90 KHz bit clock. The entire
> organization of teh computer revolved around the drum (pun intended).  There
> was an optimizer that organized instructions around the drum so that the next
> instruction came up on the read head just as the last instruction
> finished.  Without tearing the entire machine apart and redesigning the logic,
> core would not make it faster.
> 

I know the Ferranti Pegasus which is/was a serial machine everything was 
clocked to the drum. If the drum failed there was a special set of hardware to 
re-write the clock track.
Whilst replacing the clock would not have been hard, I don't think adding core 
would have helped there because everything was so integrated.
.. it used delay lines for registers which ran at the same speed so everything 
just worked...

> The PDP-8S did have core memory, and for a bit serial computer, it was fairly
> fast.
> 

For calculation, I believe the G-15 was fast. I can't believe any one would 
seriously run a high level compiler on such a machine.

> Jon

Dave

[cctalk] Re: Bendix G-15 Restoration

[Jon Elson via cctalk]

On 10/7/22 18:14, ben via cctalk wrote:

On 2022-10-07 1:09 p.m., paul.kimpel--- via cctalk wrote:
We'd all like to see the ALGO compiler, but be forewarned 
-- it's something like 14 passes on paper tape, with 
intermediate results punched on paper tape. I understand 
it's a bit more convenient to use if you have magnetic 
tape drives, but it's still going to be slow -- there's 
only so much you can do with 2K words of memory.


Trying to hide the fact  the drum makes it slow.
Did any one ever replace the drum with core memory, on the 
early serial computers?

Ben.

Tghe G-15 was a serial computer with an 90 KHz bit clock.  
The entire organization of teh computer revolved around the 
drum (pun intended).  There was an optimizer that organized 
instructions around the drum so that the next instruction 
came up on the read head just as the last instruction 
finished.  Without tearing the entire machine apart and 
redesigning the logic, core would not make it faster.


The PDP-8S did have core memory, and for a bit serial 
computer, it was fairly fast.


Jon

[cctalk] Re: Bendix G-15 Restoration

[Chuck Guzis via cctalk]

On 10/7/22 16:14, ben via cctalk wrote:
> On 2022-10-07 1:09 p.m., paul.kimpel--- via cctalk wrote:
>> We'd all like to see the ALGO compiler, but be forewarned -- it's
>> something like 14 passes on paper tape, with intermediate results
>> punched on paper tape. I understand it's a bit more convenient to use
>> if you have magnetic tape drives, but it's still going to be slow --
>> there's only so much you can do with 2K words of memory.
> 
> Trying to hide the fact  the drum makes it slow.
> Did any one ever replace the drum with core memory, on the early serial
> computers?

I recall that the IBM 650 had an upgrade option where core was used for
some of the registers.  It was small--maybe 50 words.

--Chuck

[cctalk] Re: Bendix G-15 Restoration

[Paul Koning via cctalk]

> On Oct 7, 2022, at 7:14 PM, ben via cctalk  wrote:
> 
> On 2022-10-07 1:09 p.m., paul.kimpel--- via cctalk wrote:
>> We'd all like to see the ALGO compiler, but be forewarned -- it's something 
>> like 14 passes on paper tape, with intermediate results punched on paper 
>> tape. I understand it's a bit more convenient to use if you have magnetic 
>> tape drives, but it's still going to be slow -- there's only so much you can 
>> do with 2K words of memory.
> 
> Trying to hide the fact  the drum makes it slow.
> Did any one ever replace the drum with core memory, on the early serial 
> computers?

I don't know about replacement; that would be tricky because the serial nature 
of the memory might well be embedded all over the logic design.

There are some hybrids, though.  One I know of is the Dutch ARMAC (1956).  
That's a machine with drum main memory (3584 34-bit words), but it has two 
32-word core memory units, one is a 32-word general purpose memory, and one 
holds the most recently referenced track of the drum.

This is the machine on which Dijkstrao wrote the first implementation of his 
Shortest Path algorithm, familiar to all networking people.

paul

[cctalk] Re: Bendix G-15 Restoration

[ED SHARPE via cctalk]

GE PROCESSS CONTROL COMPUTERS WENT TO A THIRD PARTY LARGE CORE STORE TO REPLACE 
SOME OF THE VERMONT RESEARCH DRUMS.
SMECC SAVES ANYTHING RELATED TO GE PROCESS CONTROL COMPUTERS. AND ALSO  GE DATA 
SYSTEMS  EMAIL  US WITH ITEMS FOR SALE OR?
GE COMPUTERS. A PRODUCT  OF ARIZONA 
THANKS ED SHARPE ARCHIVIST FOR SMECC 

Sent from the all new AOL app for Android 
 
  On Fri, Oct 7, 2022 at 4:14 PM, ben via cctalk wrote:  
 On 2022-10-07 1:09 p.m., paul.kimpel--- via cctalk wrote:
> We'd all like to see the ALGO compiler, but be forewarned -- it's something 
> like 14 passes on paper tape, with intermediate results punched on paper 
> tape. I understand it's a bit more convenient to use if you have magnetic 
> tape drives, but it's still going to be slow -- there's only so much you can 
> do with 2K words of memory.

Trying to hide the fact  the drum makes it slow.
Did any one ever replace the drum with core memory, on the early serial 
computers?
Ben.

  

[cctalk] Re: Bendix G-15 Restoration

[ben via cctalk]

On 2022-10-07 1:09 p.m., paul.kimpel--- via cctalk wrote:

We'd all like to see the ALGO compiler, but be forewarned -- it's something 
like 14 passes on paper tape, with intermediate results punched on paper tape. 
I understand it's a bit more convenient to use if you have magnetic tape 
drives, but it's still going to be slow -- there's only so much you can do with 
2K words of memory.


Trying to hide the fact  the drum makes it slow.
Did any one ever replace the drum with core memory, on the early serial 
computers?

Ben.

[cctalk] Re: Bendix G-15 Restoration

[Stephen Buck via cctalk]

Does anyone know if there are any copies of this miracle of software? It would 
be fascinating to see it in action.

[cctalk] Re: Bendix G-15 Restoration

[paul.kimpel--- via cctalk]

We'd all like to see the ALGO compiler, but be forewarned -- it's something 
like 14 passes on paper tape, with intermediate results punched on paper tape. 
I understand it's a bit more convenient to use if you have magnetic tape 
drives, but it's still going to be slow -- there's only so much you can do with 
2K words of memory.

[cctalk] Re: Bendix G-15 Restoration

[Stephen Buck via cctalk]

That's amazing! I'll add a link to the emulator on the blog. I'd love to see 
any new software for the G-15, especially the Algo compiler, since I think 
that's something more people can relate to.

[cctalk] Re: Bendix G-15 Restoration

[paul.kimpel--- via cctalk]

I would also be interested in receiving a copy.

[cctalk] Re: Bendix G-15 Restoration

[paul.kimpel--- via cctalk]

I recently completed an emulator for the G-15. It supports the basic machine 
configuration -- just paper tape and typewriter I/O -- but I'm interested in 
implementing other peripheral devices as software that uses them becomes 
available. The emulator attempts to run at the speed of a real G-15, which is 
pretty slow. It successfully passes the one diagnostic test I have.

The emulator is web-based and should run in reasonably recent versions of any 
of the popular web browsers. I've tested it with Firefox, Google Chrome, Apple 
Safari, and Microsoft Edge. You can run the emulator directly from my hosting 
site at https://www.phkimpel.us/Bendix-G15/ or you can download the files from 
GitHub and run it from some other web server. Once the emulator loads into the 
browser, there's no further interaction with the server.

>From the link above there are additional links to the GitHub repo, the wiki, 
>and additional resources. Issues concerning the emulator can be posted on the 
>GitHub repo.

I don't currently have much software for the emulator, but am working with Rob 
Kolstad to curate a large stash that recently became available. What software I 
do have is available on a separate GitHub repo at 
https://github.com/retro-software/G15-software/. Additional contributions are 
welcome.

[cctalk] Re: Bendix G-15 Restoration

[Stephen Buck via cctalk]

Thanks Mike!

[cctalk] Re: Bendix G-15 Restoration

[Stephen Buck via cctalk]

Thanks Wayne, I'll do some more digging. Anything helps.

[cctalk] Re: Bendix G-15 Restoration

[Stephen Buck via cctalk]

Thanks Jon, I'll save his name and try to look him up. I'm slowly working on a 
simulator as well, but the paper tapes are real treasures!

[cctalk] Re: Bendix G-15 Restoration

[Stephen Buck via cctalk]

I'd love to have a copy of it. I'm slowly working on a G-15 emulator, and it 
would be interesting to see one for Intercom 1000 as well.

[cctalk] Re: Bendix G-15 Restoration

[Stephen Buck via cctalk]

Thanks Rich! Keith did contact me, and I expect he will be of great help along 
the way.
Steve

[cctalk] Re: Bendix G-15 Restoration

[Rich Alderson via cctalk]

> Date: Thu, 6 Oct 2022 19:25:38 +
> From: Mike Begley via cctalk 

> The folks at the Living Computer Museum + Labs in Seattle were working on a
> restoration of one of these, or another, similar Bendix machine.  They remain
> closed (who knows if they will ever reopen), but there might be a way to find
> some of the people who were doing the work.

Hi, Mike,

I forwarded the original post to Keith Perez, the engineer who did the
restoration at LCM+L, when it arrived in my mailbox.  I haven't heard from him
to know if he contacted the poster.

Keith had the machine working very nicely.  In addition to the actual
restoration, he created a device which fit into the tube (Brit. valve) holders
to report the health of the tubes (which are not visible when the computer is
assembled) and report via edge-visible LEDs; these were easily 3D-printed and
cost effective.

We actually had two G-15s; Keith worked on getting the second into running
condition as well.

Rich

[cctalk] Re: Bendix G-15 Restoration

[Van Snyder via cctalk]

On Thu, 2022-10-06 at 19:25 +, Mike Begley via cctalk wrote:
> There's a Rob Kolstad in Colorado Springs who actually used a G-15
> many ages ago, and has created a simulator for the G-15. He has some
> info on internals as he was hoping to eventually find one to
> restore.  I think he has a bunch of software on punched tape.


I wrote an emulator for Intercom 1000. Happy to send it to anybody who
wants it.

[cctalk] Re: Bendix G-15 Restoration

[Mike Begley via cctalk]

The folks at the Living Computer Museum + Labs in Seattle were working on a 
restoration of one of these, or another, similar Bendix machine.  They remain 
closed (who knows if they will ever reopen), but there might be a way to find 
some of the people who were doing the work.

-mike

-Original Message-
From: Jon Elson via cctalk  
Sent: Thursday, October 6, 2022 11:40 AM
To: Jon Elson via cctalk 
Cc: Jon Elson 
Subject: [cctalk] Re: Bendix G-15 Restoration

On 10/5/22 22:00, Jon Elson via cctalk wrote:
> On 10/5/22 16:14, Stephen Buck via cctalk wrote:
>> Hi All,
>> I wanted to let the group know about a Bendix G-15 Restoration 
>> project I just launched:
>> https://headspinlabs.wordpress.com/bendix-g-15-restoration/
>> It's a pretty intimidating restoration (do no harm and all), so I'm 
>> reaching out to related sources, such as this group, for any 
>> suggestions or interest.
>
> WOW!  I worked on one in 1973 or so, but it had dust get in and wreck 
> the drum surface.
>
> Certainly an ambitious project, and even their schematics are QUITE 
> unfamiliar looking.

There's a Rob Kolstad in Colorado Springs who actually used a G-15 many ages 
ago, and has created a simulator for the G-15. He has some info on internals as 
he was hoping to eventually find one to restore.  I think he has a bunch of 
software on punched tape.

Jon

[cctalk] Re: Bendix G-15 Restoration

[Jon Elson via cctalk]

On 10/5/22 22:00, Jon Elson via cctalk wrote:

On 10/5/22 16:14, Stephen Buck via cctalk wrote:

Hi All,
I wanted to let the group know about a Bendix G-15 
Restoration project I just launched:

https://headspinlabs.wordpress.com/bendix-g-15-restoration/
It's a pretty intimidating restoration (do no harm and 
all), so I'm reaching out to related sources, such as 
this group, for any suggestions or interest.


WOW!  I worked on one in 1973 or so, but it had dust get 
in and wreck the drum surface.


Certainly an ambitious project, and even their schematics 
are QUITE unfamiliar looking. 


There's a Rob Kolstad in Colorado Springs who actually used 
a G-15 many ages ago, and has created a simulator for the 
G-15. He has some info on internals as he was hoping to 
eventually find one to restore.  I think he has a bunch of 
software on punched tape.


Jon

[cctalk] Re: Bendix G-15 Restoration

[Don R via cctalk]

To think that IBM Model B typewriter/terminal has no exposed wiring.

It’s in the picture so it must be true! ;)

Don Resor

Sent from someone's iPhone

> On Oct 5, 2022, at 8:00 PM, Jon Elson via cctalk  
> wrote:
> 
> On 10/5/22 16:14, Stephen Buck via cctalk wrote:
>> Hi All,
>> I wanted to let the group know about a Bendix G-15 Restoration project I 
>> just launched:
>> https://headspinlabs.wordpress.com/bendix-g-15-restoration/
>> It's a pretty intimidating restoration (do no harm and all), so I'm reaching 
>> out to related sources, such as this group, for any suggestions or interest.
> 
> WOW!  I worked on one in 1973 or so, but it had dust get in and wreck the 
> drum surface.
> 
> Certainly an ambitious project, and even their schematics are QUITE 
> unfamiliar looking.
> 
> Jon
> 
> 

[cctalk] Re: Bendix G-15 Restoration

[Wayne S via cctalk]

There was another list member that undertook the same project starting about 2 
years ago. He posted regular updates for awhile then stopped. Sorry,  but i 
don’t remember his name but his posts would be archived.


Sent from my iPhone

> On Oct 5, 2022, at 20:00, Jon Elson via cctalk  wrote:
> 
> On 10/5/22 16:14, Stephen Buck via cctalk wrote:
>> Hi All,
>> I wanted to let the group know about a Bendix G-15 Restoration project I 
>> just launched:
>> https://headspinlabs.wordpress.com/bendix-g-15-restoration/
>> It's a pretty intimidating restoration (do no harm and all), so I'm reaching 
>> out to related sources, such as this group, for any suggestions or interest.
> 
> WOW!  I worked on one in 1973 or so, but it had dust get in and wreck the 
> drum surface.
> 
> Certainly an ambitious project, and even their schematics are QUITE 
> unfamiliar looking.
> 
> Jon
> 

[cctalk] Re: Bendix G-15 Restoration

[Jon Elson via cctalk]

On 10/5/22 16:14, Stephen Buck via cctalk wrote:

Hi All,
I wanted to let the group know about a Bendix G-15 Restoration project I just 
launched:
https://headspinlabs.wordpress.com/bendix-g-15-restoration/
It's a pretty intimidating restoration (do no harm and all), so I'm reaching 
out to related sources, such as this group, for any suggestions or interest.


WOW!  I worked on one in 1973 or so, but it had dust get in 
and wreck the drum surface.


Certainly an ambitious project, and even their schematics 
are QUITE unfamiliar looking.


Jon