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 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 > > > >
