On Oct 5, 2022, at 20:00, Jon Elson via cctalk <cctalk(a)classiccmp.org> wrote: On 10/5/22 16:14, Stephen Buck via cctalk wrote: 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

On Oct 5, 2022, at 8:00 PM, Jon Elson via cctalk <cctalk(a)classiccmp.org> wrote: On 10/5/22 16:14, Stephen Buck via cctalk wrote: 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

On 10/5/22 16:14, Stephen Buck via cctalk wrote: 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.

Date: Thu, 6 Oct 2022 19:25:38 +0000 From: Mike Begley via cctalk <cctalk(a)classiccmp.org>

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.

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.

On 2022-10-07 1:09 p.m., paul.kimpel--- 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?

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.

-----Original Message----- From: Jon Elson via cctalk <cctalk(a)classiccmp.org> Sent: 08 October 2022 03:10 To: ben via cctalk <cctalk(a)classiccmp.org> Cc: Jon Elson <elson(a)pico-systems.com> Subject: [cctalk] Re: Bendix G-15 Restoration On 10/7/22 18:14, ben via cctalk wrote: 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

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

Paul wrote: instructions told the drum. To which Christian replied: 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 to fix bugs, but it certainly was a possibility that was enabled by this microcode loading mechanism. The tape is relatively easy to replace, and could be done in the field by a service tech if needed. Stainless steel was used for longevity of the tape, given that it had to be read every time the machine was powered on. I have one of these machines in the Old Calculator Museum's collection that is fully operational. The tape transport mechanism required work to get it running properly. The printer has a couple of columns that print very lightly, which I haven't been able to figure out how to fix yet. The printing mechanism is an exquisite work of art in itself, the creation of some brilliant German mechanical engineers, probably adapted from one of Diehl's earlier mechanical printing calculators. I haven't yet written the exhibit for the machine yet...among the many things I have on my to-do list, but it's quite a great story how the machine was developed. Frankel built the original prototype for the machine in his kitchen in a relay rack as an exercise to test out his theories. He had to use as few transistors as possible, because they were expensive and he built the prototype using his own funds, resulting in an extremely efficient design. He had two telephone dials that were used to enter the microcode instructions, one dial for the number of sequential zeroes and another for the number of sequential ones that would be loaded into the microcode delay line (essentially run-length encoding). The old pulse-style dialers were perfect for injecting the pulses into the delay line to represent the microcode words Needless to say, it took a while to load the microcode this way. One mistake, and you'd have to start over. The prototype design worked well, so he decided to try to market it, and Diehl in West Germany bought the rights to it. Frankel went to their factory to assist with the actual calculator design and trained the engineering and manufacturing folks on how it worked and how to build it, as well as assisting in writing all of the documentation for end-users as well as service techs. A number of follow-on calculators were marketed by Diehl using the architecture Frankel created, including some advanced machines with scientific and statistical functions. Rick Bensene The Old Calculator Museum https://www.oldcalculatormuseum.com