# Which is the "equivalent bit-map resolution" of a Vectrex display?

I'm trying to replicate the Vectrex, but I don't want to deal with bare CRTs, death-level voltages and the like. So I need my Vectrex implementation to be able to be hooked to a regular CRT/LCD screen.

I am well aware of the vector nature of the Vectrex hardware, but due to the Vectrex manipulates the beam deflection using discrete values stored in a register, then converted to an analog voltage using a D/A converter, I suspect that not every position in the CRT can be reached by the beam, but only discrete positions, as well as not every bright level is available, but only (64?) levels.

So, is this true? Can we place the beam only in certain positions? If so, which ones? If not, how can we place the beam wherever we like using discrete values for X and Y?

On the other way, the beam may not be placed in any position, but if we change from a position to another position and then to the previous one in a loop, does the beam traces a straight line from one point to the other one? Or will we see two points, each of them at each starting and ending positions?

So at the end, my questions can be summarized as: which is the minimum resolution I would have to adopt in order to emulate the vector screen of a Vectrex?

• I had similar questions about Atari arcade systems, and always ran into "it doesn't have pixels" sorts of answers, which didn't tell me what I wanted to know. What finally helped was finding the Atari DVG programming stuff, which shows how coordinates are encoded. That system allowed absolute addressing at 1024x1024. That doesn't define how many pixels there are, but it does define how you can specify endpoints, which (combined with monitor phosphor characteristics) gives you a vague idea about how complex graphics will tend to be. philpem.me.uk/blogfiles/vecgen.pdf Jul 27 '18 at 17:36

The Vectrex' beam control is an odd beast.

## It's all Relative

A vector to be processed is defined by four values, each of them 8 bit wide:

• Brightness (0..+127) (*1)
• X direction (twos' complement -128..+127)
• Y direction (twos' complement -128..+127)
• Scaling (0..255)

In first aproximation this looks like a resolution of 256 by 256 with a brightness of 128 levels. Right? Wrong! Sure, the brightness works that way, but everything else are not coordinates, but rather the directions and length or better 'speed' of a two dimensional vector (*2). The beam will travel for a certain time at the given 'speed'. The time (*3) is defined by the scaling factor. The traveled distance - and thus the reached location on the screen - is defined by the product of the vector components and the scaling.

A vector of 5,10 with scaling 10 will have the same length and orientation as a vector of 50,100 with scaling 1. And three vectors of -127,-127 with the same scaling will end 381 'resolution units' toward the top and left of its origin.

Thus the values of -128/+127 for X or Y are not the edges of the screen. And there is also no direct relation between these numbers and how wide the screen is.

## The Root of All Evil?

If everything is relative, then we need some root coordinate to start out. In case of the Vectrex this is defined as the center of the screen and can be reached by calling an EXEC (*4) function called ResetRef(erence). Having this, we could give this the absolute value of 0,0 and calculate from there. Right? Well, mostly, but only for a short time.

All moves of the beam are 'added up' (integrated) into an analogue voltage, which acts as 'absolute' screen position/register. Except, it's not stable. The circuitry holding the added up value (basicly a capacitor) leaks and moves over time toward 0,0 again. And we're not talking long durations, it's already noticeable after a few miliseconds (*5). So no real absolute coordinates here.

So if we stack two oposing vectors, like -50,-75 and 50,75, we will not end up where we started, but a little bit moved toward the screen center (*6,7).

## An Endless Universe?

This all means there is no 'hard' resolution. Leaving this aside, a maximum archiveable positioning resolution is defined due the hardware and playing with some test programs will reveal that it can be said to be roughly 20,000 possible 'positions' with 'minimum' granuality (scaling 1).

## Resolution != Resolution

Awesome, that's way beyond any modern super high dev screen, isn't it? Yes, it is. but at the same time it is only the resolution the beam can be positioned. The beam itself isn't a bodyless ghost - or at least infinit small, but has a considerable size. As the CRT is a regular TV one, it's safe to assume it's size at around 1/300th of the screen height (in case of the Vextrec the width) when at full brightness. A simple conclusion without any need to know the electronics.

So the lower limit for resolution in non analogue terms would be at or above 300 by 400 (*8). Since the screen will not work at maximum brightness, a sensible minimum resolution for program design might be around 480 by 640 (*9).

I'd suggest that (or above) as guideline for your project.

## More Fun

Looking at these mechanics also tells us many details about Vextrex programing.

• Most important, draw vectors always as fast as possible (lower scaling).

• But faster drawing also means a weaker image, so either we need to draw (visible) vectors multiple times (might look odd at least), or crank up brightness in relation.

• Since brightness is also created via a the same DAC as position and stored in a similar capacitor circuit, it will also move toward zero (dark) over time. To get an equaly bright picture, brightness needs to be reloaded after a few vectors, even if it doesn't need to change - it already has!

*1 - Technical it's also -128..+127, but negative values will not result in anything darker than off :))

*2 - Make that 3D by adding brightness :)

*3 - It's literally time, as the scaling value will be put into teh VIA's timer and counted down during drawing.

*4 - EXEC is the what could be called the Vextrex' OS - or BIOS, whatever your taste is.

*5 - Thus the beam should be recalibrated more often - which in turn is not alway possible, as it again takes quite some time. If we want to maintain something like 50-60 Hz screen redraw (which is neccessary to maintain a picture, as the CRT is a standard TV one with a luminous layer designed for a similar timing) we only got about 30,000 CPU cycles per frame - ~30 or so clocks for recalibration (IIRC) is quite a lot. So graphics design on the Vextrex does also need to find a middle ground between exact drawing and timely display.

*6 - The first lesson here is that closed shapes should be drawn with as lleast as possible strokes and as fast as possible.

*7 - Second lesson is that the build in Asteroids clone is a great tool to forsee the future of the machine. Just look at a large asteroid drawn near the screen border - if its shape is not perfectly closed, heating up the soldering iron is in your future. Simply because the integrating capacitors are slowly going bad - and if these do, others might have aged as well.

*8 - In TV terms that's 200 lines.

*9 - Yes, we're always come down to the capabilities of TV :))

• Great answer. For reproducing drawings and texts, 640x480 or a bit less is plenty enough. For making an image that looks like a bit like a real Vectrex, you will need antialiasing and simulate that the spot appears a bit larger and brighter when its stops moving, such as ends of lines when the spot is still on and the CPU is busy until it updates vector draw registers. Brightness depends also on the slew rate, how fast lines are drawn. And then there are the temporal effects of phosphor decay on each pixel... Jul 27 '18 at 2:20
• @TEMLIB As I understand the question it's about what resolution must be used at least for all screen content calculations. Ofc, having a higher resolution display allows a better emulation image - but thats more dependant on the device a user hase than how a emulator needs to be structured. Isn't it? Jul 27 '18 at 2:26

The limitations in the registers do not make a Vectrex display equivalent to any particular resolution of bitmap.

The registers place limits on the resolution at which you can specify positions to move the beam to--that much is absolutely correct. For example, if you decided to draw a dot at each possible position on the screen, you would indeed be limited to specific, discrete positions.

That's not the whole story though. Much of the reason for high resolution on a raster display is to keep lines from looking "jaggy":

With a raster display, the slanted line is made up of discrete pixels at specific positions. Especially with a line like this that's nearly horizontal (or nearly vertical) those discrete steps are quite visible (even on a display with fairly high resolution).

With a vector display, you don't get that though. What happens is that you move the beam to a position, turn on the beam, then move it to some other position. The line that's drawn is essentially perfectly straight from the start point to the end point. You don't get a stair-step effect from one to the other at all.

Modern graphics hardware has a number of tricks (mostly anti-aliasing of various sorts) to minimize the visibility of these jagged artifacts--but they never really eliminate them like a vector display does.

Bottom line: from one perspective, the Vectrex display has quite low resolution--but from another perspective, its resolution is essentially infinite. It's different enough that there's no resolution of raster display that's really equivalent.

• I am willing to challenge your "essentially infinite" - Theoretically, you are right, the screen is perfectly able to push the beam basically everywhere in non-discrete positions. The D/A converters that control the beam, however, do have a resolution and will only be able to move the beam step-wise. So the question should be answered with the resolution of those D/A converters. Jun 8 '16 at 6:26
• But, and correct me if I'm wrong, while you can only place the beam in discrete locations (limited by the resolution of the X/Y registers), if you have turned the beam on and it is at its highest level (63 I recall) and move from one position to another one, it will draw a straight line joining both locations, and that line will cross locations that the X/Y registers couldn't go to. Jun 8 '16 at 6:47
• @mcleod_ideafix The question is: How is the beam made to "move"? This can only be done by modifying the deflection magnet's current, which (I guess) is controlled by the CPU through some D/A converter, which in turn has some discrete resolution. While there would be ways to electronically "straighten" the jaggy movement (e.g. by a filter capacitance, and I guess the inertia of the magnets helps as well here in roughing out the edges), the D/A resolution is still the limiting factor. Jun 8 '16 at 7:07
• How? By changing its position while it is on. By moving the beam between two discrete points very quickly, a line is showed, and that line turns on phosphorus dots in the CRT between both. Dots that wouldn't normally be turned on if you would try to locate the beam directly to any of them (because of said limitations on X/Y registers) Jun 8 '16 at 7:19
• Had a look at some online resources for the Vectrex - Seems I need to correct myself - I was under the impression the beam deflection current would be directly controlled by the DAC - Apparently it isn't, but from a cleverly built analogous circuit that can generate a ramp from the current deflection value to the one set by the DAC. DAC resolution applies only to the end-points of a vector. So you guys are right, I was wrong and have learned something ;) Jun 8 '16 at 8:30

A seldom-appreciated difficulty in emulating vector displays is that they don't necessarily have a well-defined frame rate, and time resolution can be just as important an issue as spacial resolution. Consider, for example, the effect of drawing two 128-pointed stars--one with lines connecting every 17th point, and one with lines connecting every 15th point, drawing one line on each star millisecond. Drawing each whole star would take 128ms, but the first star will look like a 15-pointed star redrawn once every 15ms, turning 1/128 rotation each time, while the second will appear as a 17-pointed star redrawn once every 17ms, likewise rotating 1/128 second each time. On a vector display, both stars can appear to rotate smoothly, but a 60Hz raster display will have trouble capturing the motion nicely.

It's a complex problem: the DACs are one aspect of it, but the CPU speed is another. If you pull the beam to a specific place but turn it off before the arrival, your endpoint position can be more precise than what the DACs offer you. I have no idea how Gamasutra reached that 330x410 number.

The way vector systems generally work is that the program positions the beam by loading the x and y locations and luminance into a quad 10 - 12 bit DAC. A sample and hold circuit locks onto these and drives the beam via deflection amplifiers. The line is then swept out using an analog integrator, which is essentially a type of operational amplifier which generates a linear voltage ramp until it reaches the stop point.

For more information on these techniques read Jed Margolin's "The Secret Life of Vector Generators" here: http://www.jmargolin.com/vgens/vgens.htm (Jed was one of Atari's main engineers during the golden age of vector games (Asteroids, Tempest, Star Wars etc))