The Atari & the Tektronix 4014 Vector Graphics Terminal

[UNIXcoffee928]

I was wondering if anyone has ever heard of any Atari software specifically designed to display graphics on a Tektronix 4014 terminal.

 

For the uninitiated, this terminal was capable of 4096x4096 monochrome vector graphics displays. It had a 9600 bps serial connection, and displayed graphics & alphanumeric info via standard ASCII escape sequences.

 

Most of the functionality of the terminal's hardware is currently still available through standard xterm on UNIX/Linux,IXixish systems, when Tektronix mode is enabled.

 

Any modern xterm window on Linux can have Tektronix mode enabled. On a PC, the typical windowed size is 1024x768 for the Tektronix emulation, since few users can run above 1600x1200, on our /Modern/ systems...ha.

 

I recently thought, "Hey, wouldn't it be cool if you could output from your emulator to an xterm Tektronix graphics display window, to achieve a secondary, very high resolution display?". Of course you could just plug your hardware 850 into your Linux or UNIX box, too, with such a setup.

 

This makes a lot of sense, since it is just sending esc codes, so the Atari could handle it, with no problem... just like sending escape codes to a printer. The vector point info is just tons of XY co-ordinates in a *.tek file format. xterm interprets this ASCII data to generate raster-based images from the supplied datastream or textfile.

 

The closest Atari peripheral would probably be the Atari 1020 plotter, so I'm sure that a lot of the graphics algorithms for that device could be easily tweaked for graphics demos on the Tektronix.

 

I've found several manuals, & code samples in Pascal, Fortran, & *.tek format. I've been considering putting together a document that de-obfuscates the magic needed to interpret the XY tables in the Tektronix manuals. (They took every possible step to make the information as clear as mud. lol.).

 

The main mode-changing codes are easily available, but the actual co-ordinate plotting codes require some considerable thought, to translate from their stated table-form. Due to the vintage of the 4014, I would imagine that you need to be tripping to easily zen out their method. lol.

 

The downside to the Tektronix mode is that animation requires sending full screen-clears (causing a full-screen flash). It would be very good for static graphics displays, or for menu-based selection, though.

 

Animation without screen-clears is possible though, for things like this:

 

 

Anyone interested in this, or have any experience with Tektronix terminals?

[Rybags]

Some issues:

the line drawing seems somewhat slow, the 9600 bps no doubt would contribute to that.

If it's a vector monitor, then you have that absolute limit to how many lines can be present at once.

 

Of course in emulation those issues can be dismissed. It would be cool to have something like you propose. To be able to pass graphics commands through APE at ~ 57,000 bps or better would have some useful applications.

[UNIXcoffee928]

Some issues:

the line drawing seems somewhat slow, the 9600 bps no doubt would contribute to that.

If it's a vector monitor, then you have that absolute limit to how many lines can be present at once.

 

Of course in emulation those issues can be dismissed. It would be cool to have something like you propose. To be able to pass graphics commands through APE at ~ 57,000 bps or better would have some useful applications.

 

I'm unsure of the line speed via serial, since the above video was done on a Tektronix 4052 microcomputer (not the 4014 terminal, but close), using it's local BASIC interpreter... meaning the local interpreter could have been dog-slow... don't know. There is one other video, of a 4012, which shows fairly rapid line creation here:

 

 

 

Until a test is done, we won't know how fast it is, or if the flashing is even present when using xterm emulation. It seems like one one of those features that has always been present, but few people have actually used it. ...judging from the lack of much useful info about Tektronix mode, outside of the xterm man page, and a few obscure references. Apparently, there are a few plotting tools, such as gnuplot, which can output directly to a Tektronix xterm window. Haven't tried it yet, though.

 

It may be that the speed of transmission would just be limited to the max transmission speed of the Atari emulator, since xterm can handle such a wide variety of possible tty settings.

 

My guess is that for max speed, an Atari emulator window & an xterm Tektronix emulation window would probably be an ideal setup, but APE & real hardware should also do the trick.

 

Since the vector output is sent to a raster display via xterm, I don't know if the "Storage Tube" aspect of the Tektronix is emulated faithfully, with respect to how the actual terminal hardware leaves the lines on the display, once they have been rendered. I would guess that it is, though, because it seems like a fairly intrinsic aspect of the Tektronix display method. Should be... won't really know until it's tested, though.

 

Here is a page with many manuals of different types of Tektronix terminals.

 

Tektronix Manuals on vt100.net

 

 

It appears that many are compatible with the 4014, which is emulated in xterm. If anyone knows anything about the compatibility of the various Tektronix models, it would help reduce the amount of research time, to get something working.

 

I say this, because some of the models have "Programming" manuals, some have "Service" manuals, and most have "User" manuals. I haven't gotten to comparing the tables in each manual yet. There is no specific "Programming" manual for the 4014 available online... so I won't know until I start testing codes from the programming manuals from other models.

 

I'm really surprised that there is so little trace of the use of xterm's Tektronix mode available online. It seems like it would be quite handy, for a lot of stuff.

 

An interesting feature of the 4014 is that it can accept received XY mouse movement transmissions (it had XY dials, locally). I'm sure that a driver for any other input device (joystick, trackball, pad, etc.) would be very easily created.

 

All in all, it looks like a fascinating thing to mess around with. Hopefully SOMEONE who has actual experience with one of these hardware terminals will turn up... that would save a lot of guesswork.

 

Well, enjoy the computer archeology... lots of neat stuff in the manuals on the VT100 site.

[UNIXcoffee928]

OK, did some more searching, & turned up some more info. It seems that searching for Tektronix 4000 or 4010 series gives better results.

 

xterm specifically emulates the 4014. As it turns out, the following systems are directly compatible. There may be more, but these are definite:

 

Tektronix 4000 (4010, 4014, etc.), 4100 and 4200 series of graphics terminals.

 

 

Hopefully, now that I have this info, I'll be able to build a decent guide to the necessary escape sequences, then we'll all have a new toy to mess with on our Ataris!

[UNIXcoffee928]

OK, got enough to figure things out from this little tidbit, found here:

 

Tek 4014

 

"The command set was an extension of that of the 4010. The 4014 could be switched into Graph Mode after which subsequent output was interpreted as vector drawing commands until it was switched back into Alpha Mode when it reverted to being more like a VDU although it was possible to draw the characters at specified position on the screen and at different sizes.

 

Drawing a full sreen vector took about 3.25 millisecs. The command consisted of four bytes (5 low bits per byte define the coordinate, the high order bits determine the command). Thus the four bytes defined (HiY, LoY, HiX, LoX) and either the beam was moved to that position or a line was drawn from the current position to this position dependent on the state. The first three bytes were stored in registers in the terminal and did not need to be resent if they were the same as the previous command. This was the major method of optimizing the line usage and speed of the machine."

 

Check out the large pics on that page, the resolution is very impressive.

 

There is some more eyecandy here, including large pics & some low res videos:

 

Tek Thumbnails

 

 

Based on that above info, I should be able to work out the tables pretty quickly, this week. This is gonna be really cool when it is all set up!

[MEtalGuy66]

UnixCOffee, do you get your weed locally, or is it some exotic imported shit that has high enough potency to induce more psychadelic experiences?

[UNIXcoffee928]

lol, THC isn't in my instruction set.

 

You'll find a .pdf of the lookup tables with the correct codes for the Tektronix 4014 here:

 

Tektronix 4014 Control Codes

 

I cleaned up, straightened, & despeckled the document. I also added thumbnails & bookmarks for each page. I left it in it's original high resolution format, so that it will be very readable when printed on a laser printer.

 

These codes are verified to work with the 4014. No guesswork involved. 

 

If you follow the instructions at the bottom of the first coordinate table, (by testing their example values), you'll find that figuring it out is not as crazy as it first appears to be on first glance.

 

I'm going to be putting together a program to do the conversions automagically, but for now, this is enough to get started with, in xterm.

 

I'll post more about getting an xterm window operating in Tektronix mode next time. For now, just check the xterm man page, if you're feeling experimental.

 

Have fun!

[Laemeur]

That's funny, I was just talking with my dad about those old storage-tube terminals a few weeks ago (he worked at Tek back when they were still producing them). I had no idea the 4014 was emulated in xterm. I've been thinking on and off about ways of driving a vector (or emulated vector) display with an A8 for a while, and while 4014 emulation isn't exactly going to have us all playing Asteroids, it'll still be cool to see.

 

For the uninitiated, this terminal was capable of 4096x4096 monochrome vector graphics displays. It had a 9600 bps serial connection, and displayed graphics & alphanumeric info via standard ASCII escape sequences.

 

If I'm not mistaken, isn't the 4014 like Atari's vector display hardware in that its addressable resolution is only 1k x 1k, and 4k x 4k is the interpolated resolution of the yoke control circuitry? So calling it a 4096x4096 display is a bit misleading. Like saying an old TV has a resolution of ∞ x 525.

[UNIXcoffee928]

 

For the uninitiated, this terminal was capable of 4096x4096 monochrome vector graphics displays. It had a 9600 bps serial connection, and displayed graphics & alphanumeric info via standard ASCII escape sequences.

 

If I'm not mistaken, isn't the 4014 like Atari's vector display hardware in that its addressable resolution is only 1k x 1k, and 4k x 4k is the interpolated resolution of the yoke control circuitry? So calling it a 4096x4096 display is a bit misleading. Like saying an old TV has a resolution of ∞ x 525.

 

There was an Enhanced Graphics Module known as "Tektronix Option 34" which provided full 12 bit resolution, with 4096x4096 resolution. (page 30, in the 4014 Service Manual). It is also emulated in xterm.

 

Keep in mind that you may need to compile xterm to include Tektronix functionality, as some distros leave it out.

 

You can find the newest sources here:

 

xterm src

 

 

The man page for the current xterm can always be found here:

 

xterm man page

 

 

The current man page states that xterm can do the 12 bit Tektronix display... so, if you ACTUALLY HAD a PC graphics card that could give you a resolution like that (+ some space for a VT100 window...) you definitely would have the capability to display the 4096x4096 Tektronics resolution in xterm.

 

Instead of interpolating, xterm apparently gives you the highest res window that your display hardware can handle. Here's what the man page says:

 

"The VTxxx and Tektronix 4014 terminals each have their own window so that you can edit text in one and look at graphics in the other at the same time. To maintain the correct aspect ratio (height/width), Tektronix graphics will be restricted to the largest box with a 4014's aspect ratio that will fit in the window. This box is located in the upper left area of the window."

 

The standard mode was 1024x1024, the enhanced mode was 4096x4096. I have read some very old newsgroup postings that say that you will get unpredictable results, with lines jutting from the edges incorrectly if you run below 1024x768. I have not tested yet, so I can't verify this... but it does suggest that it is not interpolated.

 

 

I downloaded the sources to xterm today, and I've been going through them. I'm going to try to put together a document that specifies what the xterm emulation will & will not do, since all the man page says is: "The Tektronix 4014 emulation is also fairly good. It supports 12-bit graphics addressing, scaled to the window size. Four different font sizes and five different lines types are supported. There is no write-through or defocused mode support." 

 

 

"Scaled to the window size", in this other quote may imply interpolation, or may be implying that the rest is clipped or scrolled. Not sure, until I test. You may be right, in the case of actual contemporary PC hardware displaying it. It is cool that it has the actual 12 bit addressing available to use, once the hardware becomes available, years from now, though!

 

I've been looking around on the web for *.tek files, once I have a good amount, I'll post them for testing.

 

Right now, I'm just working from manuals, source code, faqs, & the like, so that I can get a better understanding of the way that it all works.

 

It is pretty fun actually, much more fun & interesting than say, installing a Micro$loth product... & all of it's patches, then rebooting several times, then defragmenting, then tweaking, then installing patches, etc. over & over. lol. 

 

The Tektronix stuff is so obscure, yet has so much neat potential. It requires a very long attention span, so, it's intriguing.

 

Once I get to the bottom of it's mysteries, it will be a very cool tool, not just for the Atari, but for everything that I own that has a serial port, and as cool "How the f*&K did you do that?!" stuff in shell scripts. Mu-haha.

 

= )

[Rybags]

IIRC, most of the Atari vector machines had a co-ordinate resolution of 1024x768.

[Mr.Amiga500]

This thread has reminded me how much I love vector graphics - those glowing, extremely crisp lines that could barely be reproduced by computers 25 years later. Effects in late 70's/early 80's movies using vector graphics totally blow away later effects using blocky raster graphics. I think vector graphics was abandoned too soon - before raster was at a high enough resolution.

 

(...but this is a bit off topic. Carry on.)

[UNIXcoffee928]

This thread has reminded me how much I love vector graphics - those glowing, extremely crisp lines that could barely be reproduced by computers 25 years later. Effects in late 70's/early 80's movies using vector graphics totally blow away later effects using blocky raster graphics. I think vector graphics was abandoned too soon - before raster was at a high enough resolution.

 

(...but this is a bit off topic. Carry on.)

 

I wholeheartedly agree with you.

 

Here's a very nice vector ttf font, that's based on the Atari 1020 plotter font. It will give you the perfect Wargames look. I've also attached a DEC VT220 font that is very accurate to the original.

 

The combo of these two fonts will give you a very authentic look & feel, for all of your retro type needs. They are both quite nice to use in your favorite text editor, as well, since they are monospaced, and everything will line up properly in your code. For a real treat, look at 6502 assembly code with the 1020 font!

 

Enjoy!

Glass_TTY_VT220.zip

ATARI-1020_EMU.zip

[Laemeur]

There was an Enhanced Graphics Module known as "Tektronix Option 34" which provided full 12 bit resolution, with 4096x4096 resolution. (page 30, in the 4014 Service Manual). It is also emulated in xterm.

 

Well that's pretty cool. Although, I'll bet if you had an actual Tek terminal and told it to draw two parallel lines separated by one "pixel" of space (1/4096th of the screen) you wouldn't actually be able to discern the two lines anyway on account of beam diffusion. I could very well be wrong, though.

 

Anybody out there with a Tek terminal who wants to take a macro photo of that for us?

[Laemeur]

IIRC, most of the Atari vector machines had a co-ordinate resolution of 1024x768.

I've seen that figure a lot, too, but I think it's been spread by the emulation community. Jed Margolin's info on the Atari DVG (http://www.jmargolin.com/Vgens/vgens.htm) indicates that it took the full range of 10-bit coordinates for X and Y, but the deflection circuitry timed X and Y deflection differently to squash-to-fit the vectors to a 4:3 picture tube.

 

Although I don't remember noticing any squashed effect (which would be immediately noticeable when rotating the ship) when playing Asteroids. This might require a walk down to the arcade to ogle the real thing.

[UNIXcoffee928]

IIRC, most of the Atari vector machines had a co-ordinate resolution of 1024x768.

I've seen that figure a lot, too, but I think it's been spread by the emulation community. Jed Margolin's info on the Atari DVG (http://www.jmargolin...Vgens/vgens.htm) indicates that it took the full range of 10-bit coordinates for X and Y, but the deflection circuitry timed X and Y deflection differently to squash-to-fit the vectors to a 4:3 picture tube.

 

Although I don't remember noticing any squashed effect (which would be immediately noticeable when rotating the ship) when playing Asteroids. This might require a walk down to the arcade to ogle the real thing.

 

Jed is one dude that knows his sh1t from his Shineola. His papers are great, all of the Atari emails are hugely enlightening, and to top it off, he's a very nice guy. He should be getting a percentage of royalties from "

" for the iphone... blatant ripoff, with not even a thank you to Jed or mention of Atari. Not too cool, particularly because he's been sick, and could use the cash to pay the bastards at the hospitals & insurance companies. Somebody should just write an iphone app & donate all of the proceeds to him, considering all of the good work that he did, and cool times that we had playing the games that he helped to develop. Just my 2 bits.

 

 

As for the 4014's resolution:

 

The Service manual states that the "Display Resolution" is 4096x3120 & that the addressable resolution is 4096x4096. Same goes for 1024x1024 mode, making the display resolution 1024x780. I presume that this means that the Display resolution is equivalent to the more modern concept of a "Viewport".

 

Interestingly, the coordinate system is as follows:

 

0,0 is at the bottom left

 

4095X is at the top right, as is 3119Y

 

...so, this implies that the non-viewport area is ABOVE the top of the visible display. 

 

The manual (page 63) also states that the monitor displays approximately 280 points per inch, with approximately .045 inches, point-center to point-center.

 

Also, it states that what we know in Rasterland as "Pixels" is refered to in Vectorland as "Minipoints", as the basic unit of measurement. Ha, learn something new everyday, huh? So, today's word of the day is "Minipoint"... lol.

 

 

 

 

 

[Laemeur]

Since the vector output is sent to a raster display via xterm, I don't know if the "Storage Tube" aspect of the Tektronix is emulated faithfully, with respect to how the actual terminal hardware leaves the lines on the display, once they have been rendered. I would guess that it is, though, because it seems like a fairly intrinsic aspect of the Tektronix display method. Should be... won't really know until it's tested, though.

In case you haven't played with it already, I fired-up xterm in Tek mode (the off-the-shelf Cygwin build does have Tek support compiled-in), and it does indeed behave just like a storage-tube terminal. If you mis-type a shell command and backspace over it, the cursor moves but the characters are not erased, so when you type over them, it draws each glyph right on top of the old one. You have to send a PAGE command to clear the screen. And when shell output reaches the bottom of the display window, it starts again from the top, just drawing right over what's already there.

 

I haven't dug into it enough to get any graphics drawn, but if you resize the Tek display window, it DOES do a bit of dynamic resizing, at least with text. It's a little strange, the glyphs don't change size, but they do change location. It'll be interesting to see how graphics are treated.

[UNIXcoffee928]

You'll find some *.tek graphics files, that you can test with, in the attachment.

 

Here's a list of the supported keyboard commands in xterm Tektronix mode (as found in the current xterm source ctlseqs.txt file):

 

Tektronix 4014 Mode

Most of these sequences are standard Tektronix 4014 control sequences.

Graph mode supports the 12-bit addressing of the Tektronix 4014.  The

major features missing are the write-through and defocused modes.  This

document does not describe the commands used in the various Tektronix

plotting modes but does describe the commands to switch modes.

 

BEL       Bell (Ctrl-G)

BS        Backspace (Ctrl-H)

TAB       Horizontal Tab (Ctrl-I)

LF        Line Feed or New Line (Ctrl-J)

VT        Cursor up (Ctrl-K)

FF        Form Feed or New Page (Ctrl-L)

CR        Carriage Return (Ctrl-M)

ESC ETX   Switch to VT100 Mode (ESC Ctrl-C)

ESC ENQ   Return Terminal Status (ESC Ctrl-E)

ESC FF    PAGE (Clear Screen) (ESC Ctrl-L)

ESC SO    Begin 4015 APL mode (ignored by xterm) (ESC Ctrl-N)

ESC SI    End 4015 APL mode (ignored by xterm) (ESC Ctrl-O)

ESC ETB   COPY (Save Tektronix Codes to file COPYyyyy-mm-dd.hh:mm:ss)

          (ESC Ctrl-W)

ESC CAN   Bypass Condition (ESC Ctrl-X)

ESC SUB   GIN mode (ESC Ctrl-Z)

ESC FS    Special Point Plot Mode (ESC Ctrl-\)

ESC 8     Select Large Character Set

ESC 9     Select #2 Character Set

ESC :     Select #3 Character Set

ESC ;     Select Small Character Set

OSC Ps ; Pt BEL

          Set Text Parameters of VT window

            Ps = 0  -> Change Icon Name and Window Title to Pt

            Ps = 1  -> Change Icon Name to Pt

            Ps = 2  -> Change Window Title to Pt

            Ps = 4 6  -> Change Log File to Pt (normally disabled by a

          compile-time option)

ESC `     Normal Z Axis and Normal (solid) Vectors

ESC a     Normal Z Axis and Dotted Line Vectors

ESC b     Normal Z Axis and Dot-Dashed Vectors

ESC c     Normal Z Axis and Short-Dashed Vectors

ESC d     Normal Z Axis and Long-Dashed Vectors

ESC h     Defocused Z Axis and Normal (solid) Vectors

ESC i     Defocused Z Axis and Dotted Line Vectors

ESC j     Defocused Z Axis and Dot-Dashed Vectors

ESC k     Defocused Z Axis and Short-Dashed Vectors

ESC l     Defocused Z Axis and Long-Dashed Vectors

ESC p     Write-Thru Mode and Normal (solid) Vectors

ESC q     Write-Thru Mode and Dotted Line Vectors

ESC r     Write-Thru Mode and Dot-Dashed Vectors

ESC s     Write-Thru Mode and Short-Dashed Vectors

ESC t     Write-Thru Mode and Long-Dashed Vectors

FS        Point Plot Mode (Ctrl-\)

GS        Graph Mode (Ctrl-])

RS        Incremental Plot Mode (Ctrl-^)

US        Alpha Mode (Ctrl-_)

tek-files.zip

[Laemeur]

I think maybe this .tek file is more suitable for our testing purposes.

zing.zip

[UNIXcoffee928]

Got a hold of some useful Tektronix code from an AI professor, still going through it. Tested under IRIX... keyboard combinations that don't include the ESC key work correctly. Going to have to tweak my tty settings, apparently. I've had my whole network & hardware setup apart this month, so I'm slowly getting all of the systems back online.

 

Some time ago, I had Cygwin running... I attempted four installs over the past few days, and they all failed in different ways... very annoying, considering the setup program could be A LOT better, and all of the time needed in the setup & download process. It is a useful tool, but it seems real "roll the dice" to get it installed properly. Eventually, I'll get the freakin thing to work.

 

There is a good historical resource for the Tektronix terminals here.

 

I cleaned up the image (from that page) of the 4010 Series Keyboard, as a hardware reference photo. You'll find it in the attachment.

[UNIXcoffee928]

OK, I spent some time with the Pascal code from the AI prof. I reformatted it into a more instructional style, and globally renamed variables from "*L1" to "*Tek", to make it a bit more readable. I standardized case, and otherwise made it a bit more suitable for an educational program. All procedures & body elements have been delineated via comment blocks, to make it easy to read for anyone, regardless of language background.

 

It's been a good 20 years since I did any Pascal coding, hopefully no errors crept in, but I think it's ok. The only thing I was a little fuzzy on was whitespace rules, but as far as I know, there aren't any. If you actually try to compile it, and it doesn't work, remove any artistic whitespace, and try again.

 

Here ya go, it's a good start to a drawing program:

GraphicsTek-jpl1.zip

[potatohead]

Re: Two parallel lines right next to each other, with one coordinate gap.

 

Yeah, they blend together somewhat, but not much, and when the display is run at lower brightness, it's actually damn sharp. It has been a very long time, but I used to do some CNC programming on these things.

 

There was a Zoom function that made use of the 4096x4096 coordinate space. I believe the terminal would perform the clipping operation to draw a window inside that range, making better use of the display capability.

 

On the system I used, we had a program written that read from tape, presented the user with a menu, and a rudimentary text editor for entering the CNC G-Codes in, along with tools and such.

 

Once the program was loaded, the display was cleared, and the program was drawn to the screen, one punch hit at a time. (turret punches have shapes that are loaded into tool holders, and the machine moves a sheet around, punching out the shapes to form parts.)

 

It actually worked very well, and the vector display was damn nice to see things with. The funny thing about bleed over was changes in brightness and or line thickness were something easily seen, giving good use of the display capability.

 

That program, once vetted, would be written to paper tape in 7 bit ASCII, for use out on the machines.

 

I loved paper tape actually. It was kind of cool because it had a "bit bucket" where literally "bits" were punched out to fall in the bucket, leaving holes in the tape for the machine to read. It was possible to just read the tape too, if you could recognize the binary.

 

On the early machines, they had only enough memory to hold one operation. So, the tape would get loaded, forwarded through, then taped together, to form a loop. Each part = one execution of the "program loop", which literally was a damn loop!

 

It was amazing to watch those tape readers run day in and out, with remarkably few errors.

 

When a tape got torn or mangled, repairs could be done on the shop floor by punching out the binary sequences missing, or by just taping the torn tape together with a splice sticker, which had all the hole positions punched out.

 

Later, when using PC machines, I used the tape puncher to store a copy of invaders. The thing was about 8K, and could be loaded directly from the tape, to the PC, then executed. Cool beans.

 

The Tek Terminals type machines also featured a very nice programming language, which was what the programming CAM software was written in.

 

I always thought it would be interesting these days to combine both a raster and vector display somehow. Maybe a fast refresh, or something. Wonder if a multi-channel scope wouldn't be capable of this task?

 

It's cool to think of an Atari machine doing images on these devices, and back in the day I always wanted to try it... that machine saw heavy use, so I never did. Once, a year or so, after it was sold off, I saw one at a garage sale, and missed out. Regret that, as those terminals were very cool and interesting pieces of technology.

[kohmah]

There was an Enhanced Graphics Module known as "Tektronix Option 34" which provided full 12 bit resolution, with 4096x4096 resolution. (page 30, in the 4014 Service Manual). It is also emulated in xterm.

 

Well that's pretty cool. Although, I'll bet if you had an actual Tek terminal and told it to draw two parallel lines separated by one "pixel" of space (1/4096th of the screen) you wouldn't actually be able to discern the two lines anyway on account of beam diffusion. I could very well be wrong, though.

 

Anybody out there with a Tek terminal who wants to take a macro photo of that for us?

The photos show a vintage tektronix CX4111 with keyboard, phaser printer and documentation.

It isn't broke, power on, and draw image. So i will fix it, need bisync protocol card, xterm. There is other atari 1024 somewhere, i will look if it have a vector graphic screen.

I meet this forum looking on NASA web server about MARSS software and graphics made by tektronix terminals.

I'm not sure that current graphics cards obsolete this technology.

Thank to this forum to provide all these infos.

Edited November 8, 2009 by kohmah

[UNIXcoffee928]

Yes, from the looks of it, NASA was one of the biggest buyers of these devices. It seems entirely realistic to presume that most of the CAD work that was done for NASA's Apollo-era spacecraft was done on Tektronix display terminals.

 

When the development of the Space Shuttle began, much of the design-phase shifted to DEC 11/73 & 11/83 systems with Genigraphics graphics subsystems. I used to work on these systems (not at NASA, unfortunately), and they were BADASSED for the time, despite having to use a DECwriter as a console.

 

They could do film resolution images in color, on a raster-based display, using a "puck" for input. A puck was kind of a hybrid of a mouse with a large 2.5 foot graphics tablet. I would imagine that they are still very useful, for creative Tron-like imagery. The output on these systems was very similar in shading quality to the famous Lightcycle scenes in Tron. Very cool system, wish I had one, nowadays, it had a very well-thought-out software suite, that enabled the user to be very productive.

 

It wasn't until years later, when I was taking an MIT telecourse on aerospace development, that I found out that the systems that I had used had been used in the initial design of the Space Shuttle... well, that & they still used French Curves, Slide Rules, & T-Squares...lol... same goes for the SR-71, amazingly enough (considering that it's one of the coolest planes ever developed), those Skunk Works guys knew what the hell they were doing!

 

 

Anyway, back to the Tektronix 4014... I spent the evening making "The Mother of All Translation Tables"... a document that allows easy translation of MANY escape formats, including ALL Tektronix & Atari... I'll keep you in suspense on ALL of the other escape formats, until it's done.

 

It allows very easy human-based table look-ups, and will be the basis for developing a computer-based lookup-table, and corresponding escape-code translation application software. All codes are displayed in DEC, HEX, BIN, ASCII, ATASCII, have separate platform-based descriptions, and keypress combinations. All, in all, it is one very nice document.

 

All of this research is leading to the development of drivers & apps that can be used with any modern OR retro system. When it is done, we will immediately have a lot of new graphics functionality, that can be accessed by any retro system (via RS-232) or retro-emulation package (Automagically).

 

...Additionally, the Long-Forgotten xterm Tektronix Mode will finally be useful via UNIX/Linux/Cygwin!

 

Since UNIX apps already exist to convert from Tektronix data to Postscript, a simple pipeline script will then allow for really cool results... like full Postscript & .pdf output from an Atari word processor, and secondary high resolution displays available to the emulator window, allowing for true 80 column (or greater) terminal windows, graphics plotting, and menu systems. Fast display (faster than hardware) XEP-80 & 1020 plotter (to screen) emulations can easily be based off of the groundwork here. Should be lots of fun.

 

Thanks for sharing your memories of the Tektronix hardware! Feel free to stroll down Memory-Lane as much as is possible, since it gives a lot of hints to the original operating environment.

 

ZERO downloads on my pretty-printed Pascal source! Tisk-Tisk, you don't know what you're missing. lol.

 

 

Pretty soon we are going to have a very neat tool to use in our emulators!

[ThomSW]

Instead of telling how to connect ataris to another refrigerator, please tell us what's up with YOUR version (or rather recompilation) of Atari 800 WinPlus. Jaskier provided the sources (as ya asked for), and nothing happenned till now. I'm even not able to find this thread here on A-age, so maybe it got removed.

 

(or do ya wanna remain weedsmoker?)

 

Thanks!

[UNIXcoffee928]

Instead of telling how to connect ataris to another refrigerator, please tell us what's up with YOUR version (or rather recompilation) of Atari 800 WinPlus. Jaskier provided the sources (as ya asked for), and nothing happenned till now. I'm even not able to find this thread here on A-age, so maybe it got removed.

 

(or do ya wanna remain weedsmoker?)

 

Thanks!

Refer to RFC 2324. Or would you rather remain a dicksmoker?