Historical high resolution graphics on the Raspberry Pi

[rricharz]

For those of you interested in the history of computer graphics, I have written a Tektronix 4010, 4013, 4014, 4015 and ARDS terminal emulator for the Raspberry Pi. It comes together with interesting historical graphics data.

Youtube videos:
https://youtu.be/4jZzypvxoHU
https://youtu.be/7FMewaoEOmk

Github repo with program, source and historical data:
https://github.com/rricharz/Tek4010

While working on this project I was very impressed with what was possible more than 40 years ago using up to 4K resolution!

[jamesh]

Cool! Very cool!

[RPi_Mike]

For those of you interested in the history of computer graphics, I have written a Tektronix 4010, 4013, 4014, 4015 and ARDS terminal emulator for the Raspberry Pi. It comes together with interesting historical graphics data.

Youtube videos:
https://youtu.be/4jZzypvxoHU

Your historical recreation is amazing!

One thing that grabbed my attention is the way you simulated a bright white phosphor glow at the leading edge of the green line as it rapidly "paints" a shape across the screen.

This phenomenon was recently captured at an astonishing 380,000 frames per second when a $100,000 Phantom v2512 high-speed camera was pointed at an old-fashioned CRT television.

In the following YouTube video, you can actually "see" the electron beam sweeping across the phosphors and exciting them to release a sudden burst of photons. For about 10 microseconds, it "over-saturates" and creates that white glow effect — even though the line being painted might be green, for example.

This link will automatically start the video at the moment I'm referencing:

https://youtu.be/rjDX5ItsOnQ?t=6m26s

[jamesh]

IRC, the bright stuff is also emulated/simulated in MAME on the vector games (e.g. Star Wars), but that might just be when the beam changes direction, where it lingers slightly.

[rricharz]

On the Tektronix terminal the bright drawing spot was very well visible. For a detailed explanation of the technology see
https://en.wikipedia.org/wiki/Direct-vi ... orage_tube

[LTolledo]

Got me to watch it..... somehow the video seemed "short".... (means I enjoyed watching it )
the thing that struck me was the leading "phosphor" beam.....

can this be done in ordinary RPi (3B, 3B+) without the P1DP-11 setup?

[rricharz]

Yes, you can display all the historic data just using a Raspberry Pi. They are all in the repo. Just downloading and installing tek4010 is sufficient.Then use the "cat" option to display the historical files.

Of course it's nice to combine tek4010 with the PiDP-11 (also Raspberry Pi based) because of the blinkenlights, and because you really end up with a simulated historical setup. There are a few graphics display programs which I have written in C for 2.11 BSD Unix on the PiDP-11. If you want those too, you would have to install the PiDP-11 software too (on the same Raspberry Pi). It works without the PiDP-11 hardware, but of course without the blinkenlights. One could also compile these C programs on the Raspberry Pi with a few syntax changes, as modern C is a bit different as compared to the historical BSD C.

[Paul Webster]

Very nice.
I think we had a Tektronics graphics display something like that at university ... we played Asteroids on it.
Also reminds me that I used sysgen to disable the PDP-11/70 Idle Lights display because customers had the impression that the machine wasn't doing much and they could have done the work with a cheaper 11/44.

[dancytron]

The PDP 11/70 was the first computer that I ever used other than a TRS-80 sitting on the shelf at Radio Shack.

It is what they had at college until they got a VAX something or other my Junior year. I remember they had one of the graphics terminals in the computer center that we got to see graph a surface from a formula.

Nice trip down memory lane.

[scruss]

Nice! Saw this on the blog this morning. It's way prettier than the Tek emulation built into xterm.

[rricharz]

I have tested the tek4010 emulator with the laters 4 GByte RPi4 (corrected), and it works very nicely with the additional memory, processing power and graphics speed. My terminal has a resolution of 1920 x 1080. Using a 4K terminal will be even better to emulate the original Tektronix 4014 with the enhanced graphics module, which had a resolution of 4096 x 3072. Because the original was a vector display, this is the resolution of the graphics address space, and X/Y deflection circuits, and not a pixel size.

If somebody has a 4K display hooked up to a RPi4, I would be interested to get some feedback on how well tek4010 performs at almost the original resolution.

[rpdom]

I have tested the tek4010 emulator with the laters 4 MByte RPi4

4MB? The first ARM system I used had 4MB back in the 1980s. I think the new Pi has a little more than that

[rricharz]

4 GByte of course, sorry. I'm blaming it to the hot weather today in Europe (already 30 deg C in my office at 9 AM).

[RaTTuS]

I though the vector graphic systems where about 1024x1024 sized not infinite because of the size of the scan or I may be confused

[rricharz]

One has to differentiate between vector displays using bistable storage such as the Tektronix 4014 and other types of vector displays. On a bistable storage tube, you could draw using a very focussed beam and high resolution deflection circuits, but drawing had to be rather slow. Because the image was stored on the screen, speed of drawing was less of an issue. The price to pay was that one could only erase the whole screen.

On other vector displays, which did not store the image, one had to redraw all vectors often enough so that no flickering was visible. The price to pay with those was the limited number of vectors, the lower resolution possible and the stronger, less focussed beam.

The Tektronix 4014 used a bistable tube, but had also a mode in which a few vectors (maybe 20) could be drawn without storing. Those had to be updated constantly by the host to draw moving objects.

[ProDigit]

It's a nice start.
But I'm sure that the vectors can be accelerated using hardware video acceleration, and multiple can be ran at a time.
The pi is not only ~1000x faster, in terms of CPU and GPU speed, it is also multi core, which allows for multiple vectors to be drawn at a time, even if stored.

My interest is more in the non stored versions, allowing for moving vectors on the screen.

It should be able to draw entire screens for games and demos, in real time, at a 1080p to 4k resolutions, using 6 vectors or more.
Not sure how the translation from crt to lcd would work out, to keep those moving vectors visible.

More than likely, building the program from C, C++, or something closer to low level programming (down to machine code), will greatly accelerate the drawing of the vectors, over when the program was written in Java, j++, Python, basic, or other higher programming languages, that are easier to program, but slower to emulate.

[rricharz]

It's a nice start.
But I'm sure that the vectors can be accelerated using hardware video acceleration, and multiple can be ran at a time.

Yes, indeed, but the purpose of the project was to recreate the original as nearly as possible.

The Raspberry Pi is more than fast enough for what you are talking about.

[jamesh]

It's a nice start.
But I'm sure that the vectors can be accelerated using hardware video acceleration, and multiple can be ran at a time.
The pi is not only ~1000x faster, in terms of CPU and GPU speed, it is also multi core, which allows for multiple vectors to be drawn at a time, even if stored.

My interest is more in the non stored versions, allowing for moving vectors on the screen.

It should be able to draw entire screens for games and demos, in real time, at a 1080p to 4k resolutions, using 6 vectors or more.
Not sure how the translation from crt to lcd would work out, to keep those moving vectors visible.

More than likely, building the program from C, C++, or something closer to low level programming (down to machine code), will greatly accelerate the drawing of the vectors, over when the program was written in Java, j++, Python, basic, or other higher programming languages, that are easier to program, but slower to emulate.

I think you misunderstand the point of the project!

[ProDigit]

I did.
However, it would be cool if more advanced vector games could be created again, instead of raster graphics.

[scruss]

However, it would be cool if more advanced vector games could be created again, instead of raster graphics.

You can! Adapters like v.st allow you to drive vector CRTs

[jamesh]

I did.
However, it would be cool if more advanced vector games could be created again, instead of raster graphics.

Try playing some of the vector arcade games from Atari in a MAME emulator in the Pi. They are pretty good. Star Wars, Tempest etc.

[ProDigit]

The vector emulations are first of all just that.... 'emulations', running at a slower speed than the hardware can support (as all emulations do).

Second, they're made for Ataris (or old IBM/PC hardware), which ran in the sub 10Mhz region.

What I'm talking about, is a 3D game, consisting of vectors only. Thousands of them, in colors and 3D formation.

Like a vector demo of a 3D world, that would bring out the Pi's limits.

[scruss]

The difficulty would be the display for those thousands of vectors: nobody makes vector displays any more. Colour vectors are especially hard, what with beam alignment and timing. Deflection coils are big inductors, so they can only be pushed so fast. Long-persistance colour CRTs were amazingly rare even when CRTs were a thing, and you'd need one to keep images on the screen for long enough for POV to cut in. You have to send analogue vector controls for every item in the display list, too. DACs have a finite conversion time, plus they drift and have noise …

Tempest is the best vector game, anyway. How they did that with is 6502 amazes me.

[jamesh]

The vector emulations are first of all just that.... 'emulations', running at a slower speed than the hardware can support (as all emulations do).

Second, they're made for Ataris (or old IBM/PC hardware), which ran in the sub 10Mhz region.

What I'm talking about, is a 3D game, consisting of vectors only. Thousands of them, in colors and 3D formation.

Like a vector demo of a 3D world, that would bring out the Pi's limits.

As above, to have actual vectors, you need a vector display. They are no longer made, so emulation is the only option. Even hacking a normal display would require a CRT, and they are getting very thin on the ground indeed since LCD's took over.

And StarWars* was the best vector game....but don't forget Asteroids and Battlezone!


* With high vector counts the display actually slowed down, which was quite noticeable on Star Wars.

[scruss]

And StarWars* was the best vector game....

You step outside and say that again! 3D Starstrike and Dark Star, both clones of Star Wars, were better than Star Wars …

The Atari machines did get slow with more vectors, even with their "state of the art" AMD2901 bit slice coprocessors tacked onto the 6502. Seems a whole lot of time was spent making sure that the calculations didn't deflect the beam too far, or the whole console would need recalibrated.

Ahem … back to regular scheduled programming.

If you want to try programming your own demos to run in this, Matrix Brandy BASIC - a rather nice BBC BASIC interpreter - contains a Tek library. There are a couple of examples that should get you started.

I've just found the Fortran graphics library I used - Mongo - in my first job in sunny Hemel Hempstead. We had some kind of graphics terminal, but it wasn't a cool Tek one. Mongo does have Tek support, though, and may still build under Linux. We were running it on VAXes, then on Alpha.