Re: CDC 6600 display character generation
> This reminds me of every TV show and movie I've seen where consoles begin > exploding on a space ship during a battle. All of this time, I thought that > was entirely a Hollywood fabrication! Given all the jenky engineering in the tube circuits inside a DD60, I am surprised more of them did not get all sparkly. -- Will
Re: CDC 6600 display character generation
> On Jun 6, 2018, at 11:50 PM, Rick Bensene via cctalk > wrote: > > Believe me, the console did spit out a lot of sparks and little blobs of > molten metal, along with quite a bit of smoke. I still have a small > scar on my left leg where one of the little blobs of metal burned me > after burning through the material of my slacks. This reminds me of every TV show and movie I've seen where consoles begin exploding on a space ship during a battle. All of this time, I thought that was entirely a Hollywood fabrication! -- Mark J. Blair, NF6X http://www.nf6x.net/
Re: CDC 6600 display character generation
> On Jun 7, 2018, at 3:21 AM, Lars Brinkhoff via cctalk > wrote: > > Paul Koning wrote: >> I have converted the "chassis tabs 12" wire lists to a VHDL model, >> which you can find on my Subversion server. Run on GHDL, it >> demonstrates the behavior of the circuit and reproduces the documented >> waveforms. >> >> I have also attempted to create a SPICE model of the DD60 deflection >> signal path. > > I wish more terminal emulators had this attention to detail! Thanks! The SPICE model isn't in the display emulator. I was thinking that if I could make it look correct, I'd measure the impulse response and use that for an FIR filter that would go in the emulator, replacing the current hand-hacked IIR filters. The emulator does have some attention to detail. It uses the controller's stroke shapes, adjusted by those IIR filters. Then I apply a Gaussian distribution to mimic the CRT spot (width controlled by the focus control). The resulting shapes are saved. Then to plot a character, I add that into the pixel map, with saturation and decay. The idea of simulating the decay was lifted from Phil Budne's work in SIMH. Yes, that pretty nicely simulates the actual display, about as accurately as you might hope to do in software. It could be done better in an FPGA, that would be an interesting project for LCM (6000 channel in, HDMI out). paul
Re: CDC 6600 display character generation
> On Jun 7, 2018, at 2:50 AM, Rick Bensene via cctalk > wrote: > > ... > > Believe me, the console did spit out a lot of sparks and little blobs of > molten metal, along with quite a bit of smoke. I still have a small > scar on my left leg where one of the little blobs of metal burned me > after burning through the material of my slacks. I definitely believe that. There's quite a lot of stored energy in that device: 2 kV power supplies with a pair of 4 uF filter capacitors, if things short out you will definitely get some excitement. > I remember keenly one of the CDC field guys saying that one of the big > driver tubes had shorted. There were quite a slew of other parts > (including some smaller vacuum tubes) that ended up being replaced, as > well as the left CRT tube which had a phosphor burn right in the center. > ... > > Whatever the cause of the failure, it was something that surprised the > CDC guys. Maybe the shorted tube was an artifact of the failure, and > not the cause...hard to remember exactly. But, I do know that two of > those big ceramic and metal tubes were replaced, as well as the left > CRT, and a whole slew of other parts. And I do clearly remember them > saying that the driver tubes had to be replaced in pairs. If the final drive tube shorts plate to grid, you'd get 2 kV working its way back into the previous stage. Those tubes are only rated for a few hundred volts on the plate. Not to mention that 2 kV feeding back into the previous stage power supply would be a problem also. As for replacing in pairs, it's a differential signal path and it would not be surprising if they required matched pairs. paul
Re: CDC 6600 display character generation
Paul Koning wrote: > I have converted the "chassis tabs 12" wire lists to a VHDL model, > which you can find on my Subversion server. Run on GHDL, it > demonstrates the behavior of the circuit and reproduces the documented > waveforms. > > I have also attempted to create a SPICE model of the DD60 deflection > signal path. I wish more terminal emulators had this attention to detail! There's one called cool-retro-term which looks nice, but it's only mimicing superficial appearance.
RE: CDC 6600 display character generation
Paul wrote, concerning my "fireworks" show on the DD60 console of Tektronix' Cyber 73 system: >That's really weird. Here's why. The DD60 only has a single set of X/Y drive chains. It's all differential, so there are four of everything, ?>ending up at the pair of X and pair of Y plates of the CRTs. The X/Y amplifiers connect to both tubes. The reason you see two separate >displays is that the tubes have separate unblank circuits. So the same character waveforms go to both, but at any given time only one >of the two tubes has its beam turned on. Also, focus and astigmatism controls are separate for the two. See the schematics. >I can try to explain what happened in front of you by broken wires or things like that, but it sure is hard to figure how that would cause >fried tubes (other than the CRT, of course). This happened probably somewhere between 35 and 40 years ago. I'm going from memory, and, as we know, memory over that long can be sketchy, so it's possible that I some bits were dropped or flipped over the ages. Believe me, the console did spit out a lot of sparks and little blobs of molten metal, along with quite a bit of smoke. I still have a small scar on my left leg where one of the little blobs of metal burned me after burning through the material of my slacks. I remember keenly one of the CDC field guys saying that one of the big driver tubes had shorted. There were quite a slew of other parts (including some smaller vacuum tubes) that ended up being replaced, as well as the left CRT tube which had a phosphor burn right in the center. What I observed, I remember quite clearly, although a lot happened in a short time, and it's entirely possible that the right tube may have also had something weird going on while I was watching what was going on with the left tube. I happened to be looking at the display up on the left tube when the failure occurred, so my attention wasn't directly on the right tube. I remember glimpsing quickly at the right tube noting that its display had disappeared as I was pushing the wheeled chair away from the console with my feet. Whatever the cause of the failure, it was something that surprised the CDC guys. Maybe the shorted tube was an artifact of the failure, and not the cause...hard to remember exactly. But, I do know that two of those big ceramic and metal tubes were replaced, as well as the left CRT, and a whole slew of other parts. And I do clearly remember them saying that the driver tubes had to be replaced in pairs. Anyway, all told, it was an interesting adventure. I loved those days...I have a photo of myself sitting at the console of that machine back in the day...probably some of the happiest times in my work career were those days at Tektronix. -Rick
Re: CDC 6600 display character generation
On 06/06/2018 05:39 PM, Paul Koning via cctalk wrote: > Yes. "Same length wire" is how I first heard it. When I started reading the > 6600 wire lists I discovered that the reality is far messier. The PPUs > aren't too bad, that is a 4 phase clock, where consecutive stages are clocked > usually at 50 or 75 ns apart. For example, the consecutive stages of the > barrel are clocked (mostly) at 75 ns difference. My project manager at the time was Mike Miller, who related that as an EE fresh from the U of Minnesota, his first job at CDC was measuring the coils of wire on the 6600 to which Seymour had attached a tag that said "tune". Some who had done early work as CEs related the differences between SN 1 and the regular production runs. Apparently, the floating-point divide unit gave results that weren't duplicated by any other 6600. Rick's story makes me wonder why nothing like that ever happened to the DD60s at Sunnyvale. Since the systems were essentially full of QSEs owned by Special Systems, a lot of dedicated block time for OS development was available. I've witnessed coffee and coke spilled into the things--and the ever-present ash tray on the side. We used to be invaded by masses of crickets when the weather got cooler--SVLOPS was surrounded by onion fields and bugs would find their way inside. You could find crickets happily camping in your desk drawers--and they got into equipment by the hundreds. A couple of the CEs had a pet mouse that lived under the raised floor--I don't recall his name. --Chuck
Re: CDC 6600 display character generation
> On Jun 6, 2018, at 8:01 PM, Rick Bensene via cctalk > wrote: > > Speaking of CDC 6x00/Cyber 70-series consoles... > > I had a bit of a scary but memorable experience of sitting at the console of > a Cyber 73, many years ago. > > ... > Anyway, I was sitting at the console one morning, and noted that very > suddenly, the left tube's image coalesced into a single vertical line > centered in the tube. At the same time, I heard a quiet cracking noise > coming out of the area of the console where the CRTs and final drive circuity > was located. The cracking noise very quickly increased in intensity, and > then the vertical line of the left display (the right display stayed normal), > ... > > We had onsite CDC service engineers, and they responded immediately. It > turned out that one of the big driver tubes had failed in such a way it > shorted, and that caused a cascade failure that eventually took out the other > tube, and caused some pretty severe stress in other components in the high > voltage power supply that ended up drastically overheating, resulting in the > shower of sparks and some hot metal. > > One of the CRTs (the left one) had to be replaced. When the beam went to > dead center, it burnt the phosphor out at that point. > Both of the big final-stage driver tubes had to be replaced (even though only > one had failed, they apparently had to be replaced in pairs). Some smaller > vacuum tubes, wiring harnesses, circuit boards and IIRC, a transformer that > were cooked also had to be replaced. Also, a few of the circuit modules in > the base cabinet of the display were replaced. That's really weird. Here's why. The DD60 only has a single set of X/Y drive chains. It's all differential, so there are four of everything, ending up at the pair of X and pair of Y plates of the CRTs. The X/Y amplifiers connect to both tubes. The reason you see two separate displays is that the tubes have separate unblank circuits. So the same character waveforms go to both, but at any given time only one of the two tubes has its beam turned on. Also, focus and astigmatism controls are separate for the two. See the schematics. I can try to explain what happened in front of you by broken wires or things like that, but it sure is hard to figure how that would cause fried tubes (other than the CRT, of course). paul
Re: CDC 6600 display character generation
> On Jun 6, 2018, at 6:30 PM, Jim Manley via cctalk > wrote: > > ... > Seymour Cray was a genius because he observed that the fastest possible > circuit is a wire, and that if you use the same length of wire for each bit > in a word in cables between stages in a computer that you want to go as > fast as possible, all of the bits will arrive at the next stage at the same > time. That was important for computers that took up entire rooms, with > circuit boards and racks far enough apart that upwards of a dozen > nanoseconds could elapse as bits passed from stage to stage. Yes. "Same length wire" is how I first heard it. When I started reading the 6600 wire lists I discovered that the reality is far messier. The PPUs aren't too bad, that is a 4 phase clock, where consecutive stages are clocked usually at 50 or 75 ns apart. For example, the consecutive stages of the barrel are clocked (mostly) at 75 ns difference. The CPU is much worse. It sometimes has 4 clock phases, but some parts look more like 6 or 7. If you study the block diagrams you'll see clock signals annotated by their offset from the zero reference, in increments of 5 ns. Not quite all of the 20 possible offsets are used, but more than half are. And it matters, as I found out the hard way while trying to get a VHDL model to work. The model includes the nominal gate delay (5 ns) and the rounded wire delay in 5 ns multiples for "long enough" wires. That mostly works. Replacing the clock tree by explicitly coded 5 ns multiple clock signals makes it better. Sometimes the documented value isn't quite right and you need to move things by 5 ns. Sometimes the same document gives two different timings for the same clock signal on different pages. Oh yes, then there are amazingly nutso things like flip-flops (which in the 6600 are R/S flops) where the R and S inputs are asserted at the same time, with pulses that both rise and fall roughly at the same time. I can fudge that. But it makes me wonder why the 6600 ever worked in the wild. For example, in the instruction issue and instruction stack logic I can get an "eq *-2" to work the first time and the second time but not the third: "not in stack" works, "in stack" works the first time because the "inch" is still underway, but by the second time the inch has stopped and my timing is off by 5 ns and things go utterly haywire. By tweaking nanoseconds I can move the problem but I have not yet made it go away. One place that does offer a fair amount of sanity is cross-cabinet connections; the coax cables are all the same and the nominal delay including driver and receiver is 25 ns, which nicely matches the semi-standard 4 phase clock. So tracing signals around a pile of cabinets works pretty well. Some of the data paths are quite amazing, because the memory fan-in and fan-out is routed through several other cabinets and the control signals are routed separately yet again. Tracking the signals for an exchange operation, for example, is quite an impressive dance of actions being launched fairly long in advance so they get to the memory latches at just the right time. paul
RE: CDC 6600 display character generation
Speaking of CDC 6x00/Cyber 70-series consoles... I had a bit of a scary but memorable experience of sitting at the console of a Cyber 73, many years ago. My job as a systems operator basically involved watching the console for magtape mount/dismount requests, printer service requests (e.g., out of paper), as well as in general monitoring the loading of the system, and assuring that all was running smoothly. The machine was running the KRONOS timesharing OS, with MODCOMP front-end communications processors providing serial terminal services. There were two MODCOMP machines (not sure of the model, but would recognize them) that provided literally 100's of serial ports for terminal access through, in the earlier days, various port-selector equipment, and later, through a Sytek LAN-based terminal server networked together with thin coax strung around the buildings. Anyway, I was sitting at the console one morning, and noted that very suddenly, the left tube's image coalesced into a single vertical line centered in the tube. At the same time, I heard a quiet cracking noise coming out of the area of the console where the CRTs and final drive circuity was located. The cracking noise very quickly increased in intensity, and then the vertical line of the left display (the right display stayed normal), suddenly collapsed into very bright dot in the center of the screen, then all at once, there was a loud BANG, the dot on the screen faded away quickly, the right screen went blank, and I was greeted by a shower of sparks and molten metal that spit out the slot underneath the tubes where the deadstart switch was located, and smoke coming out of the cooling slots in the cabinet. Then, there was a clunk (someone throwing the power switch for the console), and everything settled down fairly quickly, other than there was a lot of stinky smoke in the air. This whole sequence of events occurred in about 2 seconds. I had just enough time to push my feet against the electronics bay underneath the console, and shove myself away from the shower of sparks. I ended up with a small chunk of molten metal that landed on my left leg and burnt through the fabric of my slacks and burned my skin pretty good. There was a lot of acrid smoke that also came out of the console for a little while after the power was off. We were concerned that there was a fire in there, but as it turned out, fortunately, there wasn't. Other than the burn on my leg and a little hole in my slacks, I was unscathed. But, I was a bit stunned by what happened, and it took me a few moments to realize what had happened. The other people in the data center reacted quickly. One that was dismounting a tape on one of the drives that were situated behind the console by about 10 feet, ran to the master power switch on the console and shut it off. Another ran to me, and was checking me out to make sure I was OK. One of the other folks started up a magic program on the Cyber from a Tektronix 4023 terminal in the data center that effectively provided the same displays as the Cyber console, except only one of the displays could be viewed at a time. The display was updated using the addressable cursor of the 4023 terminal, though it wasn't nearly as "real-time" as the actual console displays. Commands could also be given in the same form as they could be keyed on the console keyboard.This served as the alternate console while the main console was dead. The smoke detection system in the data center triggered the fire suppression system (Halon in those days), and the klaxons went off indicating we had 30 (maybe it was 45, can't remember for sure) seconds to get out of the room before the Halon dumped and all the oxygen was flushed from the space. There was an abort switch on the back wall of the data center, and one of the other folks ran and hit the abort to keep the Halon from dumping (which was rather expensive to recharge). The fire department showed up almost immediately, because they were A) located at one corner of our business campus, and B) their station was tied into the fire systems in the data center, and were notified when the smoke sensors triggered. They came and checked everything out to make sure no lingering hot spots could spark fire. After the ruckus settled down, I resumed monitoring the system with the 4023 terminal, and operations proceeded normally. The outage of the console had no effect on the operation of the Cyber -- everything ran along just fine during the chaos. End users generally didn't even know it happened. We had onsite CDC service engineers, and they responded immediately. It turned out that one of the big driver tubes had failed in such a way it shorted, and that caused a cascade failure that eventually took out the other tube, and caused some pretty severe stress in other components in the high voltage power supply that ended
Re: CDC 6600 display character generation
Using all of those gates to do brute-force logic for character vector generation is pretty brilliant. Edison was truly a genius because he invented and sold the electric light so that people could stay up late at night to listen to his phonograph invention that he also sold. The electric lights also eliminated the risk of coal tar condensing on the phonograph cylinders from coal gas lights on the walls. Seymour Cray was a genius because he observed that the fastest possible circuit is a wire, and that if you use the same length of wire for each bit in a word in cables between stages in a computer that you want to go as fast as possible, all of the bits will arrive at the next stage at the same time. That was important for computers that took up entire rooms, with circuit boards and racks far enough apart that upwards of a dozen nanoseconds could elapse as bits passed from stage to stage. IBM "solved" this synchronization problem in the 6600's contemporary, the Model 3090 (Stretch), using delay lines to hold bits arriving on shorter cables until bits arriving on longer cables could catch up. The last thing you want in a supercomputer is a component that has the word "delay" in it, and by using equal-length wires for every bit in a word between stages, you also reduce parts count. That means that you reduce parts and assembly labor costs, replacement parts costs, power and cooling costs (a very important function, back then), system volume and weight (and therefore, structural costs), and the costs of troubleshooting labor needed to identify which parts have failed that didn't need to be there in the first place (or additional circuitry to identify where faults occurred, adding yet-more of all of the above expenses). At the time, CDC had 39 employees, including Seymour and the janitor, while IBM's engineering and technician head-count alone was upwards of 20,000. The 6600s were the fastest computers in the world for over six years, and would have held the record longer, except that CDC's own 7600s eclipsed them. He hired local women with experience doing mind-numbing, repetitive, but precision tasks like knitting and needlepoint, to wire the interconnects between boards on the Cray 1s and 2s. However, they could gossip about who was seeing whom around town to while away the hours, for which they were paid less than technicians, but more than for any other work women could get back then. I'll bet they made fewer mistakes than alternative employees would have, too. Seymour told them how important their work was to the nation's defense, and they were proud of it (many Crays were used on DoD projects for advances in pure science, as well as engineering). "Things should be as simple as possible, but no simpler." -- Albert Einstein (talking about scientific education, but not a bad idea, in general) On Wed, Jun 6, 2018 at 3:26 PM, Paul Koning wrote: > > The crazy thing about the 6000 series display controller is that it > doesn't use tables at all. The selection of what stroke step to produce > for a given character and point in time is defined by a very large > collection of gates. The 170 controller does use table lookup (a ROM with > the equivalent information). I wonder why a ROM wasn't used in the 6000. > Perhaps they couldn't find a cost-effective technology that's fast enough? > Core rope would work just fine for this, but not at 100 ns cycle time. > > paul >
Re: CDC 6600 display character generation
> On Jun 6, 2018, at 5:17 PM, Jim Manley via cctalk > wrote: > > ... > I'm one of the early senior docents at the Computer History Museum in > SillyCon Valley and yammered on endlessly about the 6600 and its neighbor, > the 7600, but I never thought about character generation on the displays > beyond it being vector-based drawing. I'm pretty sure it was done via > look-up tables that directed the beams along vectors on the displays for > the operating PDP-1 we play Spacewar! The crazy thing about the 6000 series display controller is that it doesn't use tables at all. The selection of what stroke step to produce for a given character and point in time is defined by a very large collection of gates. The 170 controller does use table lookup (a ROM with the equivalent information). I wonder why a ROM wasn't used in the 6000. Perhaps they couldn't find a cost-effective technology that's fast enough? Core rope would work just fine for this, but not at 100 ns cycle time. paul
Re: CDC 6600 display character generation
When you have "Defense Products Division" in your organization's name, "high price" comes with the products, ala $10,000 hammers and toilet seats (and "Fairchild Camera and Instrument Corporation" doesn't exactly evoke thoughts of Walmart pricing, either). I grew up a few stones' throws from Clifton - if I'd known when I was a kid that you would need this info, I could have dumpster-dived a king's fortune's worth to give to you now, probably along with some samples. Unfortunately, I would have had to incur the cost of storage for nearly six decades for that and all of the other "must-have" artifacts that I would have also scarfed up along with them ... I'm one of the early senior docents at the Computer History Museum in SillyCon Valley and yammered on endlessly about the 6600 and its neighbor, the 7600, but I never thought about character generation on the displays beyond it being vector-based drawing. I'm pretty sure it was done via look-up tables that directed the beams along vectors on the displays for the operating PDP-1 we play Spacewar! on as often as we like ... usually against its principal creator, fellow Señor Docent, Steve Russell. All the Best, Jim On Wed, Jun 6, 2018 at 2:37 PM, Paul Koning via cctalk < cctalk@classiccmp.org> wrote: > > > > On Jun 6, 2018, at 3:40 PM, Chuck Guzis via cctalk < > cctalk@classiccmp.org> wrote: > > > > One of the more interesting things about the DD60 display was the use of > > 2C43 "Lighthouse" UHF triode tubes to drive the CRT electrostatic > > deflection. > > UHF, yes, but not those. The final state uses 3CX100A5 UHF transmitter > tubes. The 2C43 would not appreciate the 2000 volt plate voltage used in > that stage. The driver stages are fairly ordinary looking receiver style > dual-triode tubes. > > > Only being around briefly for the 170 system, I don't know how the > > magnetic deflection was driven there. > > > > I imagine that the cost of the DD60 was due in no small port by the use > > of the CRTs--I believe they were produced in Germany. > > Really? It is shown as a K2263-P31, manufacturer Fairchild Camera and > Instrument Corporation, Defense Products Div., Clifton NJ. I sure would > like to get my hands on specs for that tube. > > In any case, they were sometimes referred to as "radar tubes" which sounds > somewhat reasonable. Certainly very different from TV CRTs, and bigger > than what's used in oscilloscopes, so they were most likely low volume > which would explain a high price. > > paul > >
Re: CDC 6600 display character generation
> On Jun 6, 2018, at 3:40 PM, Chuck Guzis via cctalk > wrote: > > One of the more interesting things about the DD60 display was the use of > 2C43 "Lighthouse" UHF triode tubes to drive the CRT electrostatic > deflection. UHF, yes, but not those. The final state uses 3CX100A5 UHF transmitter tubes. The 2C43 would not appreciate the 2000 volt plate voltage used in that stage. The driver stages are fairly ordinary looking receiver style dual-triode tubes. > Only being around briefly for the 170 system, I don't know how the > magnetic deflection was driven there. > > I imagine that the cost of the DD60 was due in no small port by the use > of the CRTs--I believe they were produced in Germany. Really? It is shown as a K2263-P31, manufacturer Fairchild Camera and Instrument Corporation, Defense Products Div., Clifton NJ. I sure would like to get my hands on specs for that tube. In any case, they were sometimes referred to as "radar tubes" which sounds somewhat reasonable. Certainly very different from TV CRTs, and bigger than what's used in oscilloscopes, so they were most likely low volume which would explain a high price. paul
Re: CDC 6600 display character generation
One of the more interesting things about the DD60 display was the use of 2C43 "Lighthouse" UHF triode tubes to drive the CRT electrostatic deflection. Only being around briefly for the 170 system, I don't know how the magnetic deflection was driven there. I imagine that the cost of the DD60 was due in no small port by the use of the CRTs--I believe they were produced in Germany. As far as the keyboard, on more than one occasion, I discovered a CE using a Popsicle stick to probe around among the switches from the bottom. Another interesting aspect was the use of speaker to produce a keypress "chunk". The was a volume control accessible under the keyboard, so you could make the "chuck" to be quite loud. --Chuck
Re: CDC 6600 display character generation
> On Jun 6, 2018, at 3:19 PM, Toby Thain wrote: > > On 2018-06-06 2:08 PM, Paul Koning via cctalk wrote: >> >> ... >> The block diagram manual shows the waveforms generated by the controller. >> As you can see, they are pretty angular and straight lined. Each segment >> (between the small marks on the stroke) corresponds to a 100 ms clock cycle, >> with a one or two element step in X and/or Y. > > That must be closer to 100 ns? Typo? Oops, yes of course, 100 ns (the 6000 series "minor cycle time", the master clock period). >> ... >> I have converted the "chassis tabs 12" wire lists to a VHDL model, which you >> can find on my Subversion server. Run on GHDL, it demonstrates the behavior >> of the circuit and reproduces the documented waveforms. >> >> I have also attempted to create a SPICE model of the DD60 deflection signal >> path. So far that hasn't been all that successful. I probably have bad >> assumptions for the transistor models, and the CRT deflection plate >> capacitance figures are also a complete guess. My hope was to reproduce the >> actual screen patterns, but that hasn't worked yet. >> >> Finally, I did a much more primitive approximation of the DD60 signal path, >> with a couple of IIR filters that very roughly imitate the RC elements in >> that path. That was done as part of my console display emulator program for >> Tom Hunter's DtCyber program. It was somewhat successful in that the >> characters show some of the rounding and distortion that the real display >> has, but unfortunately I can't claim that this is because it's an accurate >> model. > > Nice work! Thanks. If anyone is interested, the bits are open for inspection at svn://akdesign.dyndns.org/dtcyber/trunk -- the VHDL is in the "vhdl" subdirectory and the attempt at a SPICE model in the "spice" subdirectory. The console emulation is dd60.cpp. paul
Re: CDC 6600 display character generation
On 2018-06-06 2:08 PM, Paul Koning via cctalk wrote:
>
>
>> On Jun 6, 2018, at 9:48 AM, Noel Chiappa via cctalk
>> wrote:
>>
>> Hi, I'm hoping someone here knows the low-level nitty-gritty on how the
>> characters on the CDC 6600 console CRTs were generated.
>>
>> Thornton, "Design of a Computer", says "Control of the beam .. is provided by
>> electrostatic deflection ... electronically converting from the symbol .. to
>> deflection voltages", but alas, doesn't say how that conversion is done. And
>> I
>> looked in some CDC 6600 documentation online, alas, even less detail.
>>
>> But looking at the characters (reproduced on the dust jacket), the curves
>> sure
>> make it look like it wasn't anything simple (e.g. using display vectors, as
>> one source indicated). Does anyone know?
>
> Yes.
>
> It is indeed a digital stroke generator, not a Fourier generator as someone
> suggested. The reason for the odd shapes on the Thornton book cover is the
> AC characteristics of the display electronics.
>
The tweet did, but I found the suggestion surprising.
> There are a couple of parts to the puzzle.
>
> One is the display controller ("synchronizer" in CDC terminology, the module
> that connects to the 6000 I/O channel). The 60125000 manual that was
> mentioned is the "block diagrams" manual for that (and several other)
> controllers. The block diagrams show the overall data flow and the general
> structure of the circuits, but they are not complete schematics.
>
> However, the full schematics also exist:
> http://www.bitsavers.org/pdf/cdc/cyber/cyber_70/fieldEngr/63016700A_6600_Chassis_Tabs_12_Apr65.pdf
>
> The block diagram manual shows the waveforms generated by the controller. As
> you can see, they are pretty angular and straight lined. Each segment
> (between the small marks on the stroke) corresponds to a 100 ms clock cycle,
> with a one or two element step in X and/or Y.
That must be closer to 100 ns? Typo?
>
> Incidentally, the 170 series display controller produces the same waveforms,
> though using a completely different (ROM based) design.
>
> The other part of the puzzle is the DD60 console display. That is fed from
> the 6602/6612 display controller by a bundle of coax cables. The waveforms
> are generated by A/D circuits (quite primitive ones) in the 6602, and travel
> in analog differential form to the DD60. There they go through a string of
> amplifiers and a scaling circuit, for the small/medium/large character size
> selection. Eventually they end up on the deflection plates of large
> electrostatic deflection CRTs. Much of the signal chain is early 1960s
> transistors; the final couple of stages are tubes. You can find the
> schematics at
> http://www.bitsavers.org/pdf/cdc/cyber/cyber_70/fieldEngr/82100010_dd60a_Mar65.pdf
>
> What appears to be going on is that the signal chain in the DD60 has enough
> bandwidth to draw the characters, but only barely. So there is distortion in
> the path, resulting in character shapes on the screen that are not the same
> as the nominal stroke patterns generated by the controller.
>
> I have converted the "chassis tabs 12" wire lists to a VHDL model, which you
> can find on my Subversion server. Run on GHDL, it demonstrates the behavior
> of the circuit and reproduces the documented waveforms.
>
> I have also attempted to create a SPICE model of the DD60 deflection signal
> path. So far that hasn't been all that successful. I probably have bad
> assumptions for the transistor models, and the CRT deflection plate
> capacitance figures are also a complete guess. My hope was to reproduce the
> actual screen patterns, but that hasn't worked yet.
>
> Finally, I did a much more primitive approximation of the DD60 signal path,
> with a couple of IIR filters that very roughly imitate the RC elements in
> that path. That was done as part of my console display emulator program for
> Tom Hunter's DtCyber program. It was somewhat successful in that the
> characters show some of the rounding and distortion that the real display
> has, but unfortunately I can't claim that this is because it's an accurate
> model.
Nice work!
--Toby
>
> By the way, the displays shown on the 170 series console (CDC 565) look
> somewhat different. ...
>
> paul
>
>
Re: CDC 6600 display character generation
> On Jun 6, 2018, at 12:31 PM, Noel Chiappa via cctalk > wrote: > >> From: Toby Thain > >> It's suggested there (without any proof though) that the CDC used a >> Fourier process >> ... >> I'd be very interested to know what you find out about the circuitry. > > Someone very kindly pointed me at: > > > http://www.bitsavers.org/pdf/cdc/cyber/cyber_70/fieldEngr/60125000C_6602_6603_6622_6681_6682_Data_Channel_Diagrams_Dec65.pdf > > (although why it's in the Cyber70 folder, I'm not quite sure :-). I don't > completely understand it (it's only drawings, no text, and the notation is > unfamiliar), but I think I get the general drift - and it's pretty baroque! The notation is explained at the start of http://www.bitsavers.org/pdf/cdc/cyber/cyber_70/fieldEngr/60119300BT_6600_Diagrams_and_Circuit_Description_Vol1_Jan68.pdf It's pretty straightforward: circles for AND, squares for OR. Arrowhead means inversion. They call the basic logic element "NAND" but it is NOR in the usual terminology (it's "invert then AND" while "NAND" as normally used means "AND then invert"). The logic diagrams show both AND and OR boxes because they are drawn to show the logic operations via De Morgan's law, not the actual circuits. The logic modules are drawn as larger rectangles with the circuit elements in them. A circle at the module outline is a twisted pair input or output (connection within the chassis). A double circle (figure 8 lying on its side) is a coax input or output, for between-chassis or external connections. Finally, circuit boxes with an X or dot in them are "special circuits", i.e., not plain logic. The AF module, which is the D/A converter for the display controller, has these, as do the core memory sense amplifier modules. paul
Re: CDC 6600 display character generation
> On Jun 6, 2018, at 9:48 AM, Noel Chiappa via cctalk
> wrote:
>
> Hi, I'm hoping someone here knows the low-level nitty-gritty on how the
> characters on the CDC 6600 console CRTs were generated.
>
> Thornton, "Design of a Computer", says "Control of the beam .. is provided by
> electrostatic deflection ... electronically converting from the symbol .. to
> deflection voltages", but alas, doesn't say how that conversion is done. And I
> looked in some CDC 6600 documentation online, alas, even less detail.
>
> But looking at the characters (reproduced on the dust jacket), the curves sure
> make it look like it wasn't anything simple (e.g. using display vectors, as
> one source indicated). Does anyone know?
Yes.
It is indeed a digital stroke generator, not a Fourier generator as someone
suggested. The reason for the odd shapes on the Thornton book cover is the AC
characteristics of the display electronics.
There are a couple of parts to the puzzle.
One is the display controller ("synchronizer" in CDC terminology, the module
that connects to the 6000 I/O channel). The 60125000 manual that was mentioned
is the "block diagrams" manual for that (and several other) controllers. The
block diagrams show the overall data flow and the general structure of the
circuits, but they are not complete schematics.
However, the full schematics also exist:
http://www.bitsavers.org/pdf/cdc/cyber/cyber_70/fieldEngr/63016700A_6600_Chassis_Tabs_12_Apr65.pdf
The block diagram manual shows the waveforms generated by the controller. As
you can see, they are pretty angular and straight lined. Each segment (between
the small marks on the stroke) corresponds to a 100 ms clock cycle, with a one
or two element step in X and/or Y.
Incidentally, the 170 series display controller produces the same waveforms,
though using a completely different (ROM based) design.
The other part of the puzzle is the DD60 console display. That is fed from the
6602/6612 display controller by a bundle of coax cables. The waveforms are
generated by A/D circuits (quite primitive ones) in the 6602, and travel in
analog differential form to the DD60. There they go through a string of
amplifiers and a scaling circuit, for the small/medium/large character size
selection. Eventually they end up on the deflection plates of large
electrostatic deflection CRTs. Much of the signal chain is early 1960s
transistors; the final couple of stages are tubes. You can find the schematics
at
http://www.bitsavers.org/pdf/cdc/cyber/cyber_70/fieldEngr/82100010_dd60a_Mar65.pdf
What appears to be going on is that the signal chain in the DD60 has enough
bandwidth to draw the characters, but only barely. So there is distortion in
the path, resulting in character shapes on the screen that are not the same as
the nominal stroke patterns generated by the controller.
I have converted the "chassis tabs 12" wire lists to a VHDL model, which you
can find on my Subversion server. Run on GHDL, it demonstrates the behavior of
the circuit and reproduces the documented waveforms.
I have also attempted to create a SPICE model of the DD60 deflection signal
path. So far that hasn't been all that successful. I probably have bad
assumptions for the transistor models, and the CRT deflection plate capacitance
figures are also a complete guess. My hope was to reproduce the actual screen
patterns, but that hasn't worked yet.
Finally, I did a much more primitive approximation of the DD60 signal path,
with a couple of IIR filters that very roughly imitate the RC elements in that
path. That was done as part of my console display emulator program for Tom
Hunter's DtCyber program. It was somewhat successful in that the characters
show some of the rounding and distortion that the real display has, but
unfortunately I can't claim that this is because it's an accurate model.
By the way, the displays shown on the 170 series console (CDC 565) look
somewhat different. That's because the display electronics are different, even
though the input waveforms are the same. The 170 display is a single large
tube, with electromagnetic deflection. That's a pretty amazing thing to do for
a random access stroke drawing display, but I guess the required bandwidth is
low enough that they pulled it off. The two key parameters are max character
stroke speed (8 display units per 100 ns, given the 2 unit max step and 4x
scaling for "large" characters) and full screen (512 units) max character base
position step in about 3 microseconds.
paul
Re: CDC 6600 display character generation
On Wed, Jun 6, 2018 at 9:20 AM, Toby Thain via cctalk wrote: > On 2018-06-06 9:48 AM, Noel Chiappa via cctalk wrote: > > (BTW, the VT11 in DEC's GT40 used bit maps for its built-in character > geneator, > > and the hardware did tiny raster zones to display them!) > > As does the PDP-1 (point plotting, 5x7 I think). > Some variants of the Type 30 display, used on the PDP-1 and other early DEC computers, included a Type 33 character generator option, which works as you describe. The computer sends two 18-bit words, which are interpreted as a 5x7 bitmap, with the leftover bit used to shift the character slightly for a subscript. The Type 30G display has the Type 33 character generator as a standard feature. The PDP-1 at the Computer History Museum has a 30G, but the character generator is not completely working. I suspect that most PDP-1 installations did not have the character generator. There is not known to be any surviving PDP-1 software that used the character generator; I wrote simple test programs we used to attempt to debug the hardware.
Re: CDC 6600 display character generation
On 06/06/2018 09:31 AM, Noel Chiappa via cctalk wrote: > The pronounced rounding which I noticed in the characters must be caused by > the limited bandpass of the A-D system, amplifiers, etc - it can't actually do > a sharp corner when going from e.g. a vertical stroke to a diagonal one. Or > something like that.. :-) Ah, Noel, you beat me to it--I wasn't even through my morning coffee before I read the query. Yes, a simple 5x7 scheme in an 8x8 "grid", which produced very readable output in small characters, but as you went to medium or large characters, the coarseness was immediately obvious. Still, pretty remarkable for 1964, a 64-character line with 64 lines of small characters possible. The 6602 programming reference is here: http://bitsavers.informatik.uni-stuttgart.de/pdf/cdc/cyber/peripheralCtlr/60333900B_6602_6612_Console_Display_Sep74.pdf The gotcha, of course, is that you were driving the display with a 12 bit PPU with 4K words and a 1 microsecond cycle time. No buffering--you looped in your display code to refresh the display. This was no storage device--if you didn't make the loop or your code hung, the display blanked completely at worst, or flickered severely at best. Although the "dot" resolution for graphics was 512x512, drawing of involved graphics took a long time, so, even on simple games, such as BAT (baseball), was a mixture of characters and pixel graphics. The display for CHESS 3.0 was mostly made up of characters-as-graphics. For example, to shade a square on the chessboard, the "/' character was used. This need for continual refresh made for complex displays having some degree of flicker. The same PPU that generated both screen displays (and there were quite a number of them for the operator--the default was the AB display setup, scrolling master dayfile on one side and control point status on the other) also had to handle operator commands entered from the keyboard--and there were no interrupts, so DSD (the usual name of the PPU program) had to poll the keyboard as well. As if that weren't enough, DSD also performed auto-completion of operator commands. Overlays were either loaded from disk (by calling another PPU to do the I/O) or directly from central memory. Space in the DSD driver was very tight, to the extent, I believe, that much of the memory taken by the PP resident was reclaimed by DSD. After all, DSD was loaded at deadstart and never unloaded. Like PP0, the system monitor MTR, it was there for the duration. There was also a user-callable PP program, called "DIS" that interpreted data from a user's CM area. DIS was granted access to the 6602 only with DSD temporarily giving it up. DIS was loaded only as needed. --Chuck P.S. Somewhere, I ran across a 1967 (granted) patent that describes the character generator scheme.
Re: CDC 6600 display character generation
On 2018-06-06 12:31 PM, Noel Chiappa via cctalk wrote: > > From: Toby Thain > > > It's suggested there (without any proof though) that the CDC used a > > Fourier process > > ... > > I'd be very interested to know what you find out about the circuitry. > > Someone very kindly pointed me at: > > > http://www.bitsavers.org/pdf/cdc/cyber/cyber_70/fieldEngr/60125000C_6602_6603_6622_6681_6682_Data_Channel_Diagrams_Dec65.pdf > > (although why it's in the Cyber70 folder, I'm not quite sure :-). I don't > completely understand it (it's only drawings, no text, and the notation is > unfamiliar), but I think I get the general drift - and it's pretty baroque! > > Very briefly, it appears to me that characters are generated from short > vector-type strokes placed in a 7x7 matrix, with each stroke being encoded as > motion of 0, 1 or 2 'boxes', both horizontally and vertically, from the 'box' > of the end of the previous stroke. A character can contain up to 22 strokes, > but most seem to average about dozen or so. OK, so that's definitely not a Fourier technique. I admit I was sceptical of the tweet. :) Thanks for the link. > > The pronounced rounding which I noticed in the characters must be caused by > the limited bandpass of the A-D system, amplifiers, etc - it can't actually do > a sharp corner when going from e.g. a vertical stroke to a diagonal one. Or > something like that.. :-) Makes sense. --Toby > > Noel >
Re: CDC 6600 display character generation
> From: Toby Thain > It's suggested there (without any proof though) that the CDC used a > Fourier process > ... > I'd be very interested to know what you find out about the circuitry. Someone very kindly pointed me at: http://www.bitsavers.org/pdf/cdc/cyber/cyber_70/fieldEngr/60125000C_6602_6603_6622_6681_6682_Data_Channel_Diagrams_Dec65.pdf (although why it's in the Cyber70 folder, I'm not quite sure :-). I don't completely understand it (it's only drawings, no text, and the notation is unfamiliar), but I think I get the general drift - and it's pretty baroque! Very briefly, it appears to me that characters are generated from short vector-type strokes placed in a 7x7 matrix, with each stroke being encoded as motion of 0, 1 or 2 'boxes', both horizontally and vertically, from the 'box' of the end of the previous stroke. A character can contain up to 22 strokes, but most seem to average about dozen or so. The pronounced rounding which I noticed in the characters must be caused by the limited bandpass of the A-D system, amplifiers, etc - it can't actually do a sharp corner when going from e.g. a vertical stroke to a diagonal one. Or something like that.. :-) Noel
Re: CDC 6600 display character generation
On 2018-06-06 9:48 AM, Noel Chiappa via cctalk wrote: > Hi, I'm hoping someone here knows the low-level nitty-gritty on how the > characters on the CDC 6600 console CRTs were generated. > > Thornton, "Design of a Computer", says "Control of the beam .. is provided by > electrostatic deflection ... electronically converting from the symbol .. to > deflection voltages", but alas, doesn't say how that conversion is done. And I > looked in some CDC 6600 documentation online, alas, even less detail. > > But looking at the characters (reproduced on the dust jacket), the curves sure > make it look like it wasn't anything simple (e.g. using display vectors, as > one source indicated). Does anyone know? Ah, this is a topic of great interest to me, and coincidentally it came up recently on Twitter. https://twitter.com/TubeTimeUS/status/1003752120867123200 It's suggested there (without any proof though) that the CDC used a Fourier process similar to the 1958 article by Kenneth E. Perry and Everett J. Aho (MIT Lincoln Labs). http://www.thecorememory.com/GenCharforCRR.pdf A more modern implementation is here: http://www.glensstuff.com/fouriersynthchargen/fouriersynthchargen.htm This is actually something I intend to build myself with a larger character set, and I've been specifically considering emulating the character set of the CDC console. I'd be very interested to know what you find out about the circuitry. Anyway the LCM seems to be the bunch who knows most about it, and they've seen this thread. I hope the discussion will continue in public. Related: I'd very much like to get good macrophotography of the console character set. > > (BTW, the VT11 in DEC's GT40 used bit maps for its built-in character > geneator, > and the hardware did tiny raster zones to display them!) As does the PDP-1 (point plotting, 5x7 I think). --Toby > > Noel >
CDC 6600 display character generation
Hi, I'm hoping someone here knows the low-level nitty-gritty on how the characters on the CDC 6600 console CRTs were generated. Thornton, "Design of a Computer", says "Control of the beam .. is provided by electrostatic deflection ... electronically converting from the symbol .. to deflection voltages", but alas, doesn't say how that conversion is done. And I looked in some CDC 6600 documentation online, alas, even less detail. But looking at the characters (reproduced on the dust jacket), the curves sure make it look like it wasn't anything simple (e.g. using display vectors, as one source indicated). Does anyone know? (BTW, the VT11 in DEC's GT40 used bit maps for its built-in character geneator, and the hardware did tiny raster zones to display them!) Noel
