discrete CRT character vector generator? Maybe Tek style?

[David Hess]

There were at least 3 later compatible versions of the Tektronix readout system after the analog ROMs were no longer available.  I think all of them were used at one time on their 7603 mainframe oscilloscope.

One of them used a standard digital ROM in place of the analog ROMs which encoded the strokes to make by a state machine.  The results of this design can be seen in the readouts for the 22xx series oscilloscopes which I think looked the best of all of them.  Details are available in one of the later service manuals.

[LaserSteve]

Barry Gilbert did many of the scope vector chips , with transconductance multipliers,  if you do some digging you'll find documentation and patents. 

-------------------------------------------------------

Hershey Fonts, one of many pages on the subject, whole list with vector data table is downloadable from a Government Documents Web Site in the USA:

http://paulbourke.net/dataformats/hershey/

https://en.wikipedia.org/wiki/Hershey_fonts

"Calligraphy for Computers" is the document.     NTIS AD662398
--------------------------------------------------------
All I want for Christmas is a type 340...

http://www.bitsavers.org/pdf/dec/graphics/H-340_Type_340_Precision_Incremental_CRT_System_Nov64.pdf

About as simple as it gets for the deflection part,  and uses Magnetic Deflection, which is not unusual for that period. The vector drawing logic, is well, unconventional and  unique.

If I only had room for it. 

---------------------------

Why be Nutz when you can be Voltz:

https://www.nutsvolts.com/magazine/article/the-arduino-graphics-interface-part-1

The above is popular.  A kit was available for it.

This is one of my favorite reads:

https://www.jmargolin.com/vgens/vgens.htm

Subset of Above for skipping to implementation:

https://www.jmargolin.com/vgens/aster.pdf

He has some other Gems in his main page:

https://www.jmargolin.com/uvmath/uvmath.htm

I still use vector graphics in one of my activities, in case you wondered how I knew where to find the links.

Peace,

Steve

[Berni]

For just generating characters you don't actually need any fancy vector math.

You can make your own "analog ROM" by sticking a R2R DAC on the data pins of a regular ROM chip. This lets you generate a analog X and Y signal that traces out the character by playing back the ROM sequentially. Run it trough a filter to clean up the jagged steps of the DAC into a smooth motion. One of the bits can also be a blanking signal to let the beam jump over. The lower part of the address is cycled by a binary counter, upper part of the address selects the character to draw.

Then to position your characters on the screen you can make another DAC that gets summed in to offset where the character is being drawn. So you then have a simple circuit (ROM, R2R DAC, and binary counter) that will continuously draw a chosen character at a chosen X and Y position.

The rest is then just digital circuitry to pump the contents of a text buffer RAM into it and step across the screen, this is again some more binary counters. All the computer has to do is place the text into the RAM buffer.

This is barely more complex than getting classical raster scan text, we just squiggle the beam around as we go rather than going in straight lines.

If you want to actually draw arbitrary lines and curves that follow a list of X Y points, then things are going to get a lot more complicated. You will need a way to interpolate smoothly along the line, this means a lot of computation before feeding into a DAC or it means a fair bit of analog circuitry being puppeteered around with digital logic.

[Martinn]

As I did a fair share of FPGA designs commercially, I am not too interested in a fully digital implementation (I would consider this rather straightforward, I implemented video interfaces way in the past).

What I consider more fun would be what you can do on top of digital (there always has to be a digital part for reading out the characters somehow, but as I said that's not the interesting part).

There were at least 3 later compatible versions of the Tektronix readout system after the analog ROMs were no longer available.  I think all of them were used at one time on their 7603 mainframe oscilloscope.

I really like Barrie Gilbert's design. Here's much more detail on him: https://vintagetek.org/barrie-gilbert/
It seems that the reason why Gilbert designed the readout with lots of analog internals (like communication to the plugins via current levels) not only because evidently he was an analog guy (had Tek hired Seymour Cray, the 7000 readout certainly would have looked different), but because there were absolutely no commercial (more compex) chips available, Gilbert designed most parts of the readout (including the custom chips) himself. At one point he mentions that there simply was no other option; the readout consisted of around 8000 active components (in 14 Tek-made bipolar chips). The character ROMs contained 7200 emitters that could be mask programmed for current splitting.

Does anyone here understand how the analog ROMs worked in detail? https://w140.com/tekwiki/wiki/7000_series_readout_system
Looking at the datasheet of one character generator https://w140.com/tekwiki/images/d/d9/Tek_155-0023-00_155-0024-00_155-0025-00_155-0026-00_155-0027-00.pdf
I wonder how the character scanning works: It seems Q6/Q16 for a long tailed pair and the resistor string R6 to R18 divides the SCAN and /SCAN signal into 8 different steps, going into the bases of the ROM resistors, encoding 8 different coordinates. But I fail to see how the individual adressing works... it does not help that it is not evident how the inputs and outputs are connected, schematic is for example in the 7603 manual (p. 173), but the 11 other custom chips used there don't make it easy to get an overview.

[David Hess]

had Tek hired Seymour Cray, the 7000 readout certainly would have looked different

Tektronix already had the future readout planned and designed when Gilbert started working on his alternative.  The readout was originally going to be a fiber optic design similar to the Tektronix 576 curve tracer.  That is why the injection molded ends to the 7000 series plug-ins have those holes at the top; those were the interface for the fiber optic cables.

[cantata.tech]

had Tek hired Seymour Cray, the 7000 readout certainly would have looked different

Tektronix already had the future readout planned and designed when Gilbert started working on his alternative.  The readout was originally going to be a fiber optic design similar to the Tektronix 576 curve tracer.  That is why the injection molded ends to the 7000 series plug-ins have those holes at the top; those were the interface for the fiber optic cables.

Interesting.

That sounds like there was some sort of Reverse-Engineering from Space class Technology going on here. The only time that Fiber-Optics are really needed is when you have huge G-forces or Electromagnetic Interference where Electrical devices don't work well. (Apparently, from what I have read)

Does anyone here understand how the analog ROMs worked in detail? https://w140.com/tekwiki/wiki/7000_series_readout_system
Looking at the datasheet of one character generator https://w140.com/tekwiki/images/d/d9/Tek_155-0023-00_155-0024-00_155-0025-00_155-0026-00_155-0027-00.pdf
I wonder how the character scanning works:

You will need to get on top of understanding that to make your project work.

I suggest that you don't work from old datasheets and instead work back from things that are known today.

Build what you can in analog, build what you can't with "digital". Replace all the "digital" parts with analog as you can.

Obviously in these early designs, there's evidence of "Space Tech" such as Fiber-Optics which may or may not help but it makes all the datasheets that you are referencing more questionable as authentic construction documents.

[Martinn]

had Tek hired Seymour Cray, the 7000 readout certainly would have looked different

Tektronix already had the future readout planned and designed when Gilbert started working on his alternative.  The readout was originally going to be a fiber optic design similar to the Tektronix 576 curve tracer.  That is why the injection molded ends to the 7000 series plug-ins have those holes at the top; those were the interface for the fiber optic cables.

Interesting!
Some more info from https://w140.com/tekwiki/wiki/576

This display is a complex unit of fiber optic light-guides driven by incandescent lamps to provide alphabetic, numeric and Greek characters. The same readout modules were used in the short-lived 5030/5031 scope series.
...
The 576 was designed before the 7000-series scopes, and by a different engineering group. Surprisingly, this fiber-optic unit has not proved to be the least bit troublesome, considering all of the incandescent lamps required to implement the design. Wise operators will keep the display illumination at a lower level to prolong lamp life.

[David Hess]

That sounds like there was some sort of Reverse-Engineering from Space class Technology going on here. The only time that Fiber-Optics are really needed is when you have huge G-forces or Electromagnetic Interference where Electrical devices don't work well. (Apparently, from what I have read)

Tektronix had already used the fiber optic based readout successfully in their 576 curve tracer, so they were building off of what they were already familiar with.

Barry Gilbert was the right smart guy, at the right place, at the right time, to implement the fully electronic readout.  It was one of those long shot type projects where they were not sure that it would work, and they had a fallback position.

And Tektronix already did their own IC fabrication which made it possible.  I think a discrete implementation was feasible, but it would never have been suitable for mass production and the form factor would have been way too large.

[artag]

You could use a rope memory - magnetic cores threaded into a matrix. They're not core store as such (the cores do not contain remembered bits) but a map of couplings between rows and columns. See youtube videos by Curious Marc for the Apollo 11 navigation computer, and by Look Mum No Computer for a Soviet telephone number memory re-invented as a drum sequencer.

You can also make a capacitative PC memory where coupling between rows and columns defines memory contents. Many computer keyboards work this way.

Easiest of all, you can make a diode matrix.

Any of those would drive that amazing  Fourier character generator, or the scope clock scheme.

Another approach could use a rotating magnetic or optical memory holding the oscilloscope traces (see Oscilloscope music) and selected for display. This might have problems selecting in time for the character display, but you could use a long-persistence tube or a muilti-head drive.

[David Hess]

The analog transconductance approach controlled by emitter area had the advantage of producing a smooth curve for each stroke, but I still prefer the look of the straight strokes programmed by digital ROM that Tektronix later used.

[Martinn]

You could use a rope memory - magnetic cores threaded into a matrix. ...
Easiest of all, you can make a diode matrix....
Another approach could use a rotating magnetic or optical memory holding the oscilloscope traces (see Oscilloscope music) and selected for display. This might have problems selecting in time for the character display, but you could use a long-persistence tube or a muilti-head drive.

I think someone else mentioned the rope memory before. Interesting, never heard of before (core memory - sure, I see those daily lying around as souvenirs). But I thing I don't really like the hand-threading approach.
Diode matrix: If I need a (digital) ROM, this would be the way I'd do it. Even fully populate the diodes and do the programming via miniature soldering bridges.
Rotating memory: Fantastic idea! Probably too slow to be useful, but I'll give this a thought...
BTW I was also considering of how to boot a discrete CPU. ROM would be one possibility, the other would be to load the software into the RAM. Punched tape would be the obvious solution for a storage medium, but I am still considering how I could most efficiently make a storage medium (like a cam roll) using a 3D printer (which I have, in contrast to a tape punching machine). If I manage to build a 6 transistor/bit SRAM (which is more difficult than one might think using discrete transistors - correct sizing of the transistors is essential), I'd think a 1 kBit RAM - 6000 transistors + some more for decoding and control - would be the max I'd put on a PCB. at $0.01 per element that would be < $100, which I'd consider affordable.
So the challenge would be to get 1000 bits from a 3D printed drum, disc or whatever - preferably not using 1 kg of filament or requiring fiddly readout mechanics. But that's another story.

[Martinn]

The analog transconductance approach controlled by emitter area had the advantage of producing a smooth curve for each stroke, but I still prefer the look of the straight strokes programmed by digital ROM that Tektronix later used.

I can understand that - but don't you think that the analog readout somehow contributes to the iconic touch of the 7000 series? Particularly if you now how it was done?
I'd like to give the analog version a try because, as you write, it naturally (using correct drive waveforms) produces smooth vectors. While a vector interpolation would be easy to do in software or a FPGA, doing this in discrete logic would be extremely messy.
Do you have an idea how the coordinate "blending" worked? I posted a fragment of the ROM schematic above, but can't quite see how the sequential blending using the single scan input signal might work.

[David Hess]

The analog transconductance approach controlled by emitter area had the advantage of producing a smooth curve for each stroke, but I still prefer the look of the straight strokes programmed by digital ROM that Tektronix later used.

I can understand that - but don't you think that the analog readout somehow contributes to the iconic touch of the 7000 series? Particularly if you now how it was done?

It does have a very iconic look, but some of that was because of small shifts in the readout position influenced by the beam position because of imperfect thermal balance in the amplifier chains.

Do you have an idea how the coordinate "blending" worked? I posted a fragment of the ROM schematic above, but can't quite see how the sequential blending using the single scan input signal might work.

I never tracked the operation down to that detail, however I think something can be learned about it from the readout calibration procedures, which as I recall includes calibration of the overscan.

I think that means that each additional stroke was simply calibrated to start where the last stroke stopped.

[cantata.tech]

[ Specified attachment is not available ]

Interesting!
Some more info from https://w140.com/tekwiki/wiki/576

This display is a complex unit of fiber optic light-guides driven by incandescent lamps to provide alphabetic, numeric and Greek characters. The same readout modules were used in the short-lived 5030/5031 scope series.

Sounds like they "found an old module" somewhere.

Greek letters typically come from Phoenician characters and are mainly rotations, flips or inversions of those Phoenician characters in some way.

As are the modern ascii character set that we use.

Point is these are easier to do with vectors than pixels. I could do the straight lines in Analog Diodes.

Implementing the curves, I'm not sure. You'd need to know how to implement nice Bezier curves in Analog.

That I don't know. I'm waiting to be shown.

Edit: My first computer I ever owned had a Pen Plotter that drew with vectors - but that was digital.

https://youtu.be/CVkkii15TLo?t=14

[james_s]

Sounds like they "found an old module" somewhere.

Why do you think that? The Greek letter μ is very widely used in EE to denote Micro. β also comes up now and then in relation to semiconductor characteristics and there may be others I'm not thinking of, I've been sick all week so my brain is not running at full speed.

[wasedadoc]

 Not forgetting 

[wykasz]

>>So the challenge would be to get 1000 bits from a 3D printed drum

Maybe a row of 8 independent tacktile switches, and PLA cylinder rolling over it and pushing / releasing the switches? I guess 600bits is posible with 15cm wide drum, about 5cm tall
You could "program it" easly on PC.
I guess its scalabe to 16bit per row with some extra control bits and still being printable.


EDIT; I guess you could achieve greater density (aka faster print time and smaller filament usage) using optics to read data. I think cylinder would be easier to control - you just have to rotate it
 

[Martinn]

I never tracked the operation down to that detail, however I think something can be learned about it from the readout calibration procedures, which as I recall includes calibration of the overscan.

The calibration info (in the  7603 manual) is rather brief regarding readout. But there is a full chapter explaining how the system works in detail - just how the scan signal looks like was too much detail it seems...

As I find it a bit annoying I can't figure out how the seemingly simple ROM readout works, I'll set up a LTspice simulation. There are a number of zener diodes (without voltage spec) in the ROM schematic - would you know what typical zener voltages in this early bipolar process would be? Wild guess would be 6.5 V.

But for now I just got myself an AM502 differential amplifier (I am sure everyone remembers Jon mentions this frequently! So finally I got one). Ebay vendor said in working condition, but... - input works (1x-100000x gain, filters, offset, balance - everything), but the + input is dead. Let's hope it's just a blown fuse and not the input dual JFET. But that also is another story. EDIT: Already fixed, the /100 switch was corroded. Pushed it 50 times and now everything works! Phew.

[Martinn]

>>So the challenge would be to get 1000 bits from a 3D printed drum

Maybe a row of 8 independent tacktile switches, and PLA cylinder rolling over it and pushing / releasing the switches? I guess 600bits is posible with 15cm wide drum, about 5cm tall
...
EDIT; I guess you could achieve greater density (aka faster print time and smaller filament usage) using optics to read data. I think cylinder would be easier to control - you just have to rotate it

15 cm would be 471 mm circumference, 8 tracks 3770 mm, so 3.8 mm per bit for 1 kBit. Could work. I could even go to 20 cm (Prusa MK3). Stacked cam rolls would create overhangs though (no soluble support yet), so I'd have to create slopes for the upper bits. All automatically generated from a hex file of course...
Optics: Not sure. Maybe mechanical levers with slotted photointerrupters instead of cam switches.

[Martinn]

Not sure if anyone is interested in this...
So here is how the analog ROM works (schematic linked/shown above): For one symbol, all emitters are connected. So the transistor with the highest base voltage will turn on. The eight base lines (corresponding to the eight coordinate pairs) are blended over sequentially using the SCAN input. Here is the simulation (LTspice file attached)

By varying the input from -11.3 V to -8.7 V, one after another of the eight base lines (lines in simulation plot) is highest, causing the corresponding transistor triple to conduct.

As varying emitter size with discrete transistors will be difficult (one would have to select differently sized transistors), I wonder if this could be implemented with emitter resistors instead. Probably not, as the voltage differences are too small.

[David Hess]

The calibration info (in the  7603 manual) is rather brief regarding readout. But there is a full chapter explaining how the system works in detail - just how the scan signal looks like was too much detail it seems...

There were at least 3, and I think 4 total compatible readout boards which used different methods, with the last one being fully digital.  There are detailed descriptions of at least the first three.  I am traveling so do not have access to my workstation or I could find the service manual documentation for each one.

[wykasz]

15 cm would be 471 mm circumference, 8 tracks 3770 mm, so 3.8 mm per bit for 1 kBit. Could work. I could even go to 20 cm (Prusa MK3). Stacked cam rolls would create overhangs though (no soluble support yet), so I'd have to create slopes for the upper bits. All automatically generated from a hex file of course...
Optics: Not sure. Maybe mechanical levers with slotted photointerrupters instead of cam switches.

Since it's going to be quite a big cylinder, probably you want to print it in a vase mode, or at least without an infill and top layers, because it would be impossible to print top layer without an infill on cylinder of such a diameter.
If so, you will have an empty spece inside and access to it, so you can put an array of led inside and second array of photosensitive elements outside.
Then you need to use holes instead of indents/bulges for bit encoding.
I think that could allow greater density in comparison to switches and bulges, because you are not limited by the size of the switches nad geometry of cylinder.
My only concern is that SNR may be bad in vase mode even using black filament, due to possible print errors and small holes between the layers.
And holes probably makes printing in vase mode not as useful in this case
Maybe a bigger nozze (like 0.6 or 0.8mm) would help. Or just print in normal mode with relatively thin cylinder wall, but with at least 2 perimeters.

One more thing that came to my mind. It should be possible to add few control bits. Bare minimum would be to add two clock signals, a little out of phase, lets say 45* and 90* after the data.
Then you can use first clock signal to ensure that all switches / fotoelement are in a stable state at the time of reading. In this scenario you would need debouncing circuits only for clock signals.
Having second clock signal you can create an address register using binary counter and then you can effectively copy whole cylinder by just rotating it. Clock signals will do the rest, no need for any control circuit, maybe just a switch pushed by single bulge on the cylinder to stop it from repeating itself.
I guess you could cope with one clock signal bu its easier with two.

[Martinn]

Adding the "ROM cell" transistors shows that the current blending works rather perfectly! Symmetry is a bit off, but that hopefully can be fixed. Makes you wonder how Barrie Gilbert came up with the resistor values. Could the Teledeltos fixtures https://vintagetek.org/barrie-gilbert/ have been used for this?
Essentially the ROM transistors work like a long-tailed pair differential amplifier, just with more than two inputs. I wonder how well I can simulate the variable emitter sizes for ROM programming with emitter resistors.

[Martinn]

Since it's going to be quite a big cylinder, probably you want to print it in a vase mode, or at least without an infill and top layers, because it would be impossible to print top layer without an infill on cylinder of such a diameter.

Vase mode: I had discarded that idea as it lacks stability - just one perimeter would be pretty wobbly, like a cardboard tape. The drum idea was to have an axle in the center with the cams at the circumference - meaning the drum would have to be solid (e.g. 10% infill) or with spokes. Both does not work well with lighting form inside. Anyway I think holes are not a good idea, as start/stop extrusion is rather inaccurate, achieving a continuous flow would be much better.
Vase mode would of course be the ultimate continuous flow... so why not? For support one could fix it on a solid drum or feed it with rollers like one would do with punched tape. In addition to the data cams, having index or transport teeth would make sense and could double as clock signals. Also, vase mode would be the fastest printing mode with fewest filament usage.

[David Hess]

Makes you wonder how Barrie Gilbert came up with the resistor values. Could the Teledeltos fixtures https://vintagetek.org/barrie-gilbert/ have been used for this?

That is what I remember being told.

Essentially the ROM transistors work like a long-tailed pair differential amplifier, just with more than two inputs. I wonder how well I can simulate the variable emitter sizes for ROM programming with emitter resistors.

It works in an integrated process because the transistors are matched.  Emitter degeneration only produces the same result at one current because it changes the relationship between current and transconductance.