The Combitron S was picked up Hi I remember writing programs for on of these to solve a statitical problem for data on a mass spectrometer. I recall waiting on power up while it loaded the data from the metal tape( sometimes it needed to be rebooted ). I'd love to find one of these. I alway wanted to see how they dealed with the different speeds of the metal tape and the memory. There was no exact speed control on the metal tape. It just ran from the spool speed with no capstan. Dwight _________________________________________________________________ Picture this ? share your photos and you could win big! http://www.GETREALPhotoContest.com?ocid=TXT_TAGHM&loc=us

Hi I don't think that would work. First, the calculator had no RAM other than the delay lines. The metal tape had 2 rows of holes, one was clock and the other was the data. The motor that ran the tape was just a free running DC motor. The only thing I could think is that it may have buffered just a few bits and then burst them into the delay line as the slot for them curculated around. I suspect that the delay line was slower than a single bit of the tape but faster than 4 or so bits of the tape. Remember, the delay line has a fixed delay. The tape had a variable delay. It ran faster as the tape got near the end. There was no speed control on the motor. I was curious about this at the time and confirmed it with an oscilloscope. Dwight _________________________________________________________________ Hotmail to go? Get your Hotmail, news, sports and much more! http://mobile.msn.com

Re: Getting Microcode off of Tape and Into Microcode Delay Line of Diehl Combitron Calculator There's been some discussion about how the data on the punched metal tape containing the microcode for the Diehl Combitron/Combiton/SCM 566PR ended up synchronized with, and stuffed into the delay line at the appropriate time, given that the punched metal tape was simply dragged through the reader without any speed regulation. The microcode delay line held microcode in 55-bit words. A microcode operation code was 5 bits long, therefore the could be up to eleven microcode commands in one word. Each 55-bit word had another corresponding 55-bits worth of operation data that matched up 5-bits each with the operation code word. Some of the microcode operation codes used two five-bit fields, one with the operation code, and one with a "count" field, that told the logic how many times to execute the previous instruction. The data word contained operational data for micro-instruction operations, in five bit fields. So, each microcode block consisted of 110 bits of data in the delay line. The operation code word and operation data word were interleaved, five bits at a time. There were two sets of five-bit flip flops, configured as shift registers. One serial-in parallel-out shift register received data from the punched metal tape, clocked in by the clock track of the tape. The other five-bit shift register read the data out of the first shift register in parallel once five bits had been read from the tape, and at the appropriate time, shifted the data bit-by-bit into the delay line. The delay line ran MUCH faster than the tape, so there was plenty of time between groups of five bits on the tape for the right place in the delay line to be reached, then the buffered data injected into the delay line. It is my belief (thought not confirmed at this point) that the first shift register (serial-in, parallel-out) actually had a dual purpose -- it's input & clock could be switched from the punched tape reader tracks (data & clock) to the "output end" of the delay line, and the clock coming from the master delay line clock. This way, one five bit shift register could serve as the buffer register for the tape loading sequence (done only at power-on or master reset), and the rest of the time, it was a buffer register for groups of five bits at a time as they came out of the delay line. This circuitry only applied to the "microcode" delay line. There was a separate delay line (though I believe both delay lines were housed within the same metal can) that contained the working registers of the calculator (accumulator, counters, memory register, etc.). Note that the term "word" and "field" are somewhat arbitrary for descriptive purposes, because as far as the delay line is concerned, it's just one big long series of bits. The delay line is essentially an electromechanical equivalent of a long series of flip flips configured as a serial-in/serial out shift register. These machines were notorious for not "booting up" properly at power up time. The tape would read, but the code that got loaded was incorrect, resulting in a calculator that was catatonic, or sometimes did weird things. The main cause of this was contaminants getting in the tape reader optics. The tape reader was optical, with a light source on one side of the tape, and two photodiodes on the other side. As mentioned, the tape had two tracks, one a clock track, and the other a data track. If dirt or dust, or oil from the mechanical printing mechanism got into the optics, it would cause mis-reads, either clock pulses would get missed (meaning missed bits in the microcode), or data bits would not be read properly, again resulting in a bad microcode load. Keeping the optics clean was a main maintenance point for these machines, along with proper lubrication of the very mechanical print mechanism. Reading the microcode took about one minute from power-on, until the calculator was ready for use. The delay line for the microcode operations and data words had to be a pretty long delay line in order to store all of the micro-orders and constant data needed to run the calculator. It's not clear yet how much data is available on the architecture of the Combitron. However, I am working with contacts to try to get as much information as possible. If enough data can be found, and an operational example of one of these machines can be found, it shouldn't be too hard to "dump" the microcode, and perhaps reverse engineer it. I'm sure that, given Stan Frankel's genius, that the microcode is a miracle of efficiency, and would be fascinating to study. Slightly off-topic, but still within the "Classic Computer" realm: I'm currently in the process of doing this for the Wang 720C calculator. I have successfully dumped the microcode out of the machine, and have written a simulator in Perl that simulates the hardware environment of the calculator, and executes the microcode. I've still got a few minor glitches in the simulation, but for the most part, everything works. The only problem I have at this point is that for some reason, the base 10 logarithm function gives a result that is the base e logarithm rather than the base 10 log. The base e logarithm function (clearly) works fine. The microcode appears to be heavily shared for these two functions, so there's probably something wrong with some implementation of the machine's logic in the simulation that causes a branch to be missed, or mis-interpreted. It's been a long, slow project, but it's my hope to be able completely document the microcode for the 720C, and perhaps, capture microcode from other Wang 700-series models (700A, 700B, 720B), and do the same. Since the Wang 700-series (along with the 500 and 600-series machines) utilize a very complex hand-wired wire-rope ROM to store 2048x44 bits of microcode, many machines which are otherwise healthy are dead because of a bad ROM. The ROMs are very difficult to repair, as the wires just somewhat larger in diameter than a human hair, and there are LOTS of them. But, with known-good ROM images, building a ROM emulator using current-day ROM technology should allow folks to resurrect machines which are suffering from bad ROMs. I have a Wang 700A which works mostly, except square root does not give correct results. It's my hope that once I get the emulator working 100% (it has switches to behave as a 700/720 and A, B, or C model) that I can dump the 700A's ROM, and figure out where it's going astray, and perhaps repair it. I'll post my findings on the Old Calculator Web Museum (http://oldcalculatormuseum.com) site once I get the last few bugs worked out. Rick Bensene

---snip--- ---snip--- Hi Rick I was going to mention that calculating logs is generally done the same way in calculators, regardless of the base. They usually calculate it in base 2 and then multiply by a constant to change to a different base. as an example: log2(n)*ln(2)=ln(n) log2(n)*log(2)=log(n) or if calculates the natural log first ln(n)*log(e)=log(n) or even log(n)*ln(10)=log(n) if it does decimal log first. I hope this helps some. Dwight _________________________________________________________________ http://liveearth.msn.com