discrete CRT character vector generator? Maybe Tek style?

[Martinn]

Hi all,
for my discrete CPU idea which is simmering on low fire I still need a display and a CRT would fit perfectly (I even have an almost working scope clock design, so CRT control is done).
But how do you generate text on a CRT using discrete components only (not using VHDL/FPGA or a microcontroller, which would be the trivial option)?

Two designs from the relevant era (around 1965?) come to mind:
The CDC 6600 is a discrete supercomputer with vector CRT display. Schematic is in here http://www.bitsavers.org/pdf/cdc/cyber/cyber_70/fieldEngr/60125000C_6602_6603_6622_6681_6682_Data_Channel_Diagrams_Dec65.pdf starting from page 5.
Not sure about the IBM System/360, which was also fully discrete.

And (probably more known on this part of the forum) there is the Tektronix 7000 series readout. It is described here https://w140.com/tekwiki/wiki/7000_series_readout_system
with the key component being an analog ROM (designed by Barry Gilbert), schematic 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 find this quite elegant as it solves both the coordinate storage and the transition or vector generation - fully analog (the LeCroy orange CRT scopes used analog integrators for vector generation, but the rest was fully digital (68000 IIRC)).

Unfortunately I have neither a supercomputer design budget (or team) nor access to a foundry making full custom chip designs. What I do have (and Seymour Cray or Barry Gilbert didn't have) is the JLCPCB assembly service, which let's me order a PCBA with a few thousand SMT components without going bankrupt. Unfortunately chip design specials as for example Gilbert's multi emitter transistors (mask programmed) for the analog character ROMs are not easily replicated with discrete components (I'll give that a try though).

Any other idea how I could tackle character generation?

As a side note: Looking back, in these times (1960s) there seemed to be many "celebrity" designers - Shockley, Gilbert, Wilson, Cray, Widlar... If I would have to name a famous designer of the past few decades, I would not know a single one. Are there none or do I just not know them? Maybe today's technology has gotten that complex that no single genius could achieve something worth mentioning (thing of the monstrously complex EUV steppers)?

- Martin

[cantata.tech]

Any other idea how I could tackle character generation?

In software ?

Have a character output buffer, [w,h,c] (width * height * sizeof(colorinf)) and a font table.

Generate scan lines by reading the buffer and working out the bit pattern for each character then buffer line.

Send that to the next output stage.

I have the cutest Sony TV 501 from the 1970's that I bought in Japan that would love something like this so I'm keeping an eye on this thread.

[Martinn]

In software ?

Of course, this would be easy. But as I wrote the question was

But how do you generate text on a CRT using discrete components only (not using VHDL/FPGA or a microcontroller, which would be the trivial option)?

[cantata.tech]

In software ?

Of course, this would be easy. But as I wrote the question was

But how do you generate text on a CRT using discrete components only (not using VHDL/FPGA or a microcontroller, which would be the trivial option)?

Use 74* series discrete components https://en.wikipedia.org/wiki/7400-series_integrated_circuits , but the process that I described would most likely be the same.

If you have some plan to do something that isn't based on any digital components and uses analog only then of course that will be interesting to hear about.

[Martinn]

Use 74* series discrete components, but the process that I described would most likely be the same.

Discrete means transistors, resistors, capacitors, inductors. 74xx are integrated circuits - the opposite of "discrete"

If you have some plan to do something that isn't based on any digital components then I'm happy to listen to your plan.

This formulation is a little vague.
CDC 6600 or System/360 were supercomputers (=digital) built from individual transistors (or hybrids in the IBM case).

But have a look at the 7000 readout (linked above) - although it uses a lot of integrated circuits, core concepts like the analog ROM are fully analog.

The reason why I am looking at a discrete design ist just for the challenge - as I wrote it would be simple and straightforward to do this an a microcontroller (just go through a display list via IRQ) or FPGA (which would be more fun).

[ale500]

The HP9100 doesn't use integrated circuits and has a CRT for numeric display. More limited than an 80x25 text display but may give you some ideas. I have seen in hackaday.io a project with transistorized drive of a display,... but trying to remember ... I am not very sure anymore it really had a display I may be mixing two projects...

[mariush]

If you use 7-8 pixel wide characters, then maybe you could resort to EPROM memory chips, and counters and dual port sram for the character buffer ... kinda like Ben Eater did his vga controller.

[BrianHG]

Eproms are not discrete...  Might as well use a 8bit PIC if you are going to an eprom.

This is discrete (The score board is an character generated by transistors and diodes...):
https://www.eevblog.com/forum/projects/oscilloscope-pong-for-1-or-2-players/msg1406029/#msg1406029

[Tomorokoshi]

Here are a couple links that might be interesting:

https://www.eevblog.com/forum/projects/designed-a-cro-in-spice/

https://www.glensstuff.com/fouriersynthchargen/fouriersynthchargen.htm

[Alex Eisenhut]

Here are a couple links that might be interesting:

https://www.eevblog.com/forum/projects/designed-a-cro-in-spice/

https://www.glensstuff.com/fouriersynthchargen/fouriersynthchargen.htm

Oh man that's so cool. I was trying to remember that Fourier thing and that link you posted will be great to  read!

[wasedadoc]

Any other idea how I could tackle character generation?

In software ?

Have a character output buffer, [w,h,c] (width * height * sizeof(colorinf)) and a font table.

Generate scan lines by reading the buffer and working out the bit pattern for each character then buffer line.

Send that to the next output stage.

In my book that is raster graphics, not vector graphics.

[Martinn]

https://www.glensstuff.com/fouriersynthchargen/fouriersynthchargen.htm

Very nice!
In this context worth mentioning: http://www.sgitheach.org.uk/scope2.html

[cantata.tech]

In my book that is raster graphics, not vector graphics.

Yes or no. For it to be vector graphics the characters would need to be stored as vectors. Like on the early NEC 7220s (μPD7220) which stored characters as vectors which was neccessary for Kanji. In any case it was an IC and not discrete components.

Because of my lack of knowledge on analog components, there's not much further I can assist with this. Analog computers were well before my Career in computing started. Good luck.

[wasedadoc]

In my book that is raster graphics, not vector graphics.

Yes or no. For it to be vector graphics the characters would need to be stored as vectors. Like on the early NEC 7220s (μPD7220) which stored characters as vectors which was neccessary for Kanji. In any case it was an IC and not discrete components.

Because of my lack of knowledge on analog components, there's not much further I can assist with this. Analog computers were well before my Career in computing started. Good luck.

My opinion is that "vector" refers to the way things are drawn on the screen. Like a pen plotter draws on paper.  Compared to a dot matrix printer which is "raster".

[cantata.tech]

My opinion is that "vector" refers to the way things are drawn on the screen. Like a pen plotter draws on paper.  Compared to a dot matrix printer which is "raster".

Yes I understand that. But you may not be aware that characters can easily be stored as vectors.

In modern computing, one example would exist in SVG or 'Scaleable Vector Graphics'

You may wish to look at this longer description which includes the picture I've added to the post.

https://www.codeproject.com/Articles/5262594/Text-to-SVG-Path-Utility-in-Uplusplus

Maybe a set of resistors/diodes with a resistance for each vector position ?  or easier, a sequence of potentiometers for each character.

Now I don't know any easy way to store these vectors in an analog circuit except for having a resistor/diode pair for [x,y] of each point. And then cycling through that 'line' to get the vector drawn.

That would be one line for X, and one line for Y. So you need two lines of resistors/diodes for each point in the character vector map. If you can get your characters to have an average of 6 points that's a total of 12 wires with resistors or diodes per character in the map.

If you assume 26 characters with 4 punctuations then that's hypothetically 30x12 = 360 wires for something useable. You could start with just 5 characters of 12 wires which would only be 60 in total.

You could use the PCB making service to make a pcb for every character that you need in your sequence. That would surely save some time.

Let's wait and see what unfolds.

[Ian.M]

It rapidly gets *FUGLY* if you try to do it purely in the analog domain, as you'll also need to control the stroke speed, and probably also generate a Z blanking signal to distinguish between drawn strokes and hidden moves.  I reckon that's three resistors and four diodes per stroke,  with an extra diode per character to signal the end of the stroke sequence.   

Building a couple of discrete DACs and using Core rope ROM driven by one-hot ring counters seems like a much saner alternative.

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

[james_s]

Yes I understand that. But you may not be aware that characters can easily be stored as vectors.

In modern computing, one example would exist in SVG or 'Scaleable Vector Graphics'

How they're stored is irrelevant. "vector graphics" refers to the way they are drawn on the screen.

I've never seen it done without a microprocessor of some sort. The Atari vector arcade games used a vector generator which was a sort of bespoke CPU built out of discrete TTL logic. The objects on the screen and their location were selected by writing to a vector RAM and then the vector generator would read each object out of ROM and paint it on the CRT. The monitor was inherently vector based, the deflection circuitry being much like an audio amplifier.

[Berni]

There is also HP test equipment that uses fully digitally controlled vector displays with vector fonts.
I had to repair one of them in this thread:
https://www.eevblog.com/forum/testgear/hp-4145b-semiconductor-analyzer-repair-with-photos-(display-garbage-dead-rom)/

The CRT is actually part of a self contained module called the "HP 1345A Digital Display"


You can get full schematics of it in the service manual. Most of its digital brains contained on a board the size of a A5 sheet and consists mostly of a microprocessor that orchestrates the flow of data from lookup ROMs and RAM out into a ADC that drives the beam around.

[Martinn]

It rapidly gets *FUGLY* if you try to do it purely in the analog domain

No, that was not the idea. I wrote "discrete", not analog. Of course once you are on the discrete level, adding analog tricks (like the analog ROM for the 7000 readout) become possible, in contrast to microcontroller or FPGA programming.

I am looking for some out-of-the-box ideas for character generation - which probably is difficult because these techniques were necessary around 60 years ago and few designers from that era will hang out here. But still some interesting ideas are around:
- Tek 7000 readout
- Fourier synthesis
- CDC 6600 (although this is more conventional)
Unfortunately the HP9100 schematic is difficult to decipher and I also found nothing from IBM.

Discrete also does not mean "no logic": As example here is an 8 bit ALU (6502 style) synthesized from VHDL, around 1400 components (I showed this in the KiCad forum recently). It's just that you can't afford massive constructs.
I think I give Gilbert's analog ROMs a try - set up a simulation and see if it could be reproduced using discrete transistors. From the complexity it would easily be within limits.

[cantata.tech]

I am looking for some out-of-the-box ideas for character generation - which probably is difficult because these techniques were necessary around 60 years ago and few designers from that era will hang out here. But still some interesting ideas are around:

Actually, Computers didn't use Vector character generation around 60 years ago. They used punched cards.

You can see how they actually operated in a video such as this -



"Vectors" at that time were simply a location of a punch card hole.  You could research on your own time when the first CRT terminals became available but the first ones I knew to be available in Australia were the DEC PDP-11's and they had CRT terminals - not sure what character generation system they used - that was way later in the '70s.

Edit: I was close - "It seems the first device to use a CRT computer monitor was the U.S. military’s SAGE. Developed in the 1950s, the SAGE had more than 150 display consoles housing a 48-inch-long Vector CRT computer monitor. The first commercial device equipped with a CRT computer monitor was Digital Equipment’s PDP-1 in 1959."

Available on a US Military Base, does not typically mean "Generally available". They tended to keep their Technology quite secret as they do now.

[Martinn]

Actually, Computers didn't use Vector character generation around 60 years ago. They used punched cards.

I think punched cards were primarily input, not output. I would guess they used printers for human readable output.

Actually the CDC 6600 had a vector terminal https://en.wikipedia.org/wiki/CDC_6600
"The first CDC 6600s were delivered in 1965 to Livermore and Los Alamos"
OK you could argue that makes 58 not 60 years, but let's not be picky. See this video https://youtu.be/4Zt03YsMyW4?t=123

[cantata.tech]

Actually the CDC 6600 had a vector terminal https://en.wikipedia.org/wiki/CDC_6600
"The first CDC 6600s were delivered in 1965 to Livermore and Los Alamos"

Well there you go. They include a picture too.



Let's guess that what you are planning is going to potentially be that big and have that many wires if you build it with discretes.

[Martinn]

As it turns out the CDC 6600 would not be easy to replicate even with today's discretes: https://cpldcpu.wordpress.com/2020/02/14/what-made-the-cdc6600-fast/
The console manual I linked above does contain the schematics (in CDC's own cryptic style) for the display, so one could probably build the display processor. Still a lot of work though.

[Benta]

Well, taking it from the top down, it amounts to counting and gating/encoding/decoding.
Horizontal scan/deflection (counters).
Vertical ditto (counters).
Generating of sync signals (gating/decoding).
Outputting of video bit stream (character ROM plus shift register).

You can draw this up using standard 74HC logic.
After that, you can break it down into gates and FFs plus an enormous diode array for the character ROM.
And after that, you can construct those using discrete parts.

Lot of work. Have fun

[james_s]

The Cathode Corner scope clock used a discrete design, albeit driven by a microcontroller but it probably wouldn't have to be. It has two sine wave oscillators that are used to draw circles and lines, IIRC there are analog switch ICs that are used to mix the signals as needed. It's been about 20 years since I built mine so I don't remember all the details of the circuit. Surprisingly the original CRT I used is still working though it's pretty dim now after running 24/7 most of the time since I built it.

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

[james_s]

Were these ROMs programmable in some fashion (mask?) or was the data baked into the layout of the IC? It's interesting that they went with this approach rather than a more conventional ROM feeding a resistor DAC.

[David Hess]

Were these ROMs programmable in some fashion (mask?) or was the data baked into the layout of the IC? It's interesting that they went with this approach rather than a more conventional ROM feeding a resistor DAC.

There is no DAC.  An earlier stage produces a sawtooth waveform which is fed into the analog ROMs, along with a digital address, and that produces a set of X and Y outputs which are functions of the sawtooth input.  Each character is then made with a series of curved strokes.

The analog ROMs are programmed using resistor values and emitter areas, so like a mask ROM.

[james_s]

Were these ROMs programmable in some fashion (mask?) or was the data baked into the layout of the IC? It's interesting that they went with this approach rather than a more conventional ROM feeding a resistor DAC.

There is no DAC.  An earlier stage produces a sawtooth waveform which is fed into the analog ROMs, along with a digital address, and that produces a set of X and Y outputs which are functions of the sawtooth input.  Each character is then made with a series of curved strokes.

The analog ROMs are programmed using resistor values and emitter areas, so like a mask ROM.

Yeah I get that there was no DAC, I meant I'm surprised they didn't just use a DAC, although maybe conventional ROMs were still too primitive.

[David Hess]

Yeah I get that there was no DAC, I meant I'm surprised they didn't just use a DAC, although maybe conventional ROMs were still too primitive.

They used their own ADCs which implemented 1-of-10 encoding, so like a flash converter but with only 10 levels or 3.3 bits.  One of the later compatible implementations uses 3-bit DACs to define the endpoint of strokes within the character cell.

[Martinn]

Update:
I found out that by far the best information on Gilbert's analog ROMs is the patent: https://w140.com/tekwiki/wiki/Patent_US_3651510A
It really is well written and entertaining to read! Unfortunately, duplicating the functionality with discrete components is pretty difficult, but I'll try anyway.
For experiment 1 I replaced the multi emitter triples with three transistors with adjustable degeneration. The remaining control like the vector blending is mostly identical to the ROM version.
On the scope XY plot you see it drawing a "M" character, which needs only five of the eight available points. In the signal plot to the right you can see that the blending does not give the nice linear shapes as Gilberts analog ROM, which IMO is caused by the degeneration resistors. Also there's some noise on the signal - I'll have to find out where this comes from. But overall this works.
Of course this is just one character! For multiple ones, one would have to use fixed resistors and a more compact layout. I wonder if the total capacity of such an array would be prohibitive.

Many of you have commented why I bother with this old stuff and not just solve it digitally. The reason is that I do that all day long and it would be straightforward for me. On the other hand, I know noone in my line of work who could still do analog BJT designs (not just switching on a LED). This kind of knowledge at least where I work got mostly extinct.

[David Hess]

That is great that you got usable results.

In the signal plot to the right you can see that the blending does not give the nice linear shapes as Gilberts analog ROM, which IMO is caused by the degeneration resistors.

Using emitter degeneration does not give quite the same effect, and Gilbert had the advantage of integrated transistors which have matched Vbe and hfe.  You should get significantly better results if the Vbe of each transistor in a set is matched, along with the use of a reference transistor for each set.

[Tomorokoshi]

Is the oscillation noise because there is no bypassing on the board? How long are the leads from the power supply?

[HarryDoPECC]

Late to the party (as usual!)

I work with vintage calculators, at the start of the 1960's Friden produced the EC-130 - in my opinion the most attractive machine of that era.  See it on my site:  https://dopecc.net/calculators/friden/ec130/  On the photos tab you will find a picture of its multi-line '7-segment' style display,  generated on a CRT.

The entire display circuit is analogue and discrete, just as the OP is seeking.  Elegant and subtle work.  Designed by Stanford Research Institute for Friden.  Can't find the patent just now.  I have a number of these machines and the displays still work well in machines with 50yo components. 

I have attached an original Friden's Service Note where the principles are described in a uniquely chatty way.

If OP wants a real challenge, consider if this could be extended to 12-segments, which would give a fair alphanumeric substrate.  Note that part of the extended scan is already present....
Otherwise, just enjoy the engineering of that era.

[Martinn]

Bypassing: Yes, I noticed that when I had ordered the boards. Just added two decoupling capacitors - much better!

Friden calculator: Nice idea. Beam deflection is fixed to the segment pattern, blanking is generated via a diode ROM. Interesting!

[Martinn]

And a letter "2". Quite a flowery script...

[Martinn]

And here's experiment 2.
You cannot replicate multi emitter resistors with discrete components, but you can connect them in parallel, which should linearly scale their transconductance.
The patent states that for all combinations, 8-10 emitters should be connected in total. So here I have eight transistors per point. The slide switches connect the collector to one of the X, Y and Z lines. If you want to have a square character matrix, this gives you a range of 0-4xIC for the X and Y lines, so a grid of 5x5 total. This is somewhat limited compared to the Gilbert ROM, but should be sufficient nonetheless.
And here is another "2" try:
Much better than the potentiometer version.

BTW now you really should see why I love PCBA services (JLCPCB)... no more hand soldering for me!