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.
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 :))