Hardware Description

The Vectrex consisted of:

the 8-bit 68A09 microprocessor (at 1.5Mhz)
1k x 8 bytes of RAM (consisting of two 2114 RAM chips)
8k x 8 bytes of resident ROM (a 2363 ROM chip)
a programmable interface adapter (PIA)
a digital-to-analog converter (DAC ‑ +2.5 to -2.5 volts)
three sample-and-holds (3 S/H ‑ active ground, 'Z' and 'Y' axises)
a programmable sound generator (PSG) (a General Instrument AY38912)
2 player controllers (each with one proportional joystick and 4 buttons).
a 9 x 11-inch monochrome cathode ray tube
an audio amplifier and speaker
both low and high voltage power supplies

The digital-to-analog converter (DAC) is an 8-bit multiplying MC1408 chip. Also included in the analog circuitry are operational amplifiers (LF353 & LF347 chips) and a 4-channel multiplexer (a CD4052 chip).

The 6522 programmable interface adapter (PIA) provides all the interface necessary between the microprocessor and the analog electronics (joysticks, D/A converter and the sample/holds). The PIA provides the interface to the programmable sound generator (PSG). It also contains two 16-bit counters (used as timers) and an 8-bit shift register. The shift register is used by the dashing and raster drawing routines.

The ROM contains the resident game 'Mine Storm' and the RUM. The RUM handles the initial set-up of the Vectrex hardware and gives a large selection of subroutines for drawing, calculation and game logic ‑ see the list of RUM subroutines organized by function.

Drawing a Vector

To draw a line, you would set values for the X and Y components of the vector. This gives a direction (or angle) for the vector (for example, setting X and Y to the same value would result in a 45 degree vector). As the CRT beam moved along this angle (or the vector), you can modulate the intensity of the beam. The length of the vector would be determined by the drawing speed (or the slew rate) of the vector and how long you allow the beam to move.

There's another control that affects the length of a vector. That control adjusts that integration time of the operational amplifier (ie- 'op amp'), which in turn affects the rate at which the vector is drawn.

Let's say I have a screen object that I'm drawing with a series of vectors at a fixed integration time (or slew rate), such as a fireball in Fortress of Narzod. If I set the slew rate to draw the vectors faster, this results in the screen object becoming larger. A slower slew rate results in a smaller object. Effectively a zoom control.

At the same time, the brightness of the beam is affected by the speed of the beam. Setting the same intensity for each object, a slow moving beam would appear brighter than a fast moving beam. So in the above example and keeping the same intensity level, the two objects would grow dimmer as they zoomed larger. The smaller object, since it was drawn slower, would retain more of its brightness than the faster drawn large object. The bottom line is that depending on what was being drawn, it might be necessary to constantly make adjustments to the intensity to have a consistent appearance on the screen.

When you got to the end of the vector, you would define a new angle and send the beam off for the next vector. Everything you see on the screen was drawn as a continuous line, with the intensity of the beam being set as necessary.

This drawing of vector after vector had to be done for each refresh cycle (it was around 60 times a second). During the current drawing cycle and the start of the next refresh, you had to do your game logic, any related calculations and then set-up for the next drawing cycle.

Another consideration about vector drawing: Because of the need to refresh, you had a limited amount of time to draw before the next refresh. You had to be careful to draw as efficiently as possible. If you spent too much time positioning around the screen (or using too much detail), then there were fewer objects that you could draw. The more careful you were about positioning, the more objects that could be drawn. Now consider that the game objects are moving on the screen and those changes could impact the order in which things had to be drawn.

During the initial coding of a game, I would generally force the beam to be on all the time. This way, I could see how I was placing objects on the screen. Once I was sure of my drawing, I would remove the code that forced the beam on and see how the game would look to the player.

If you didn't keep to the refresh cycle (ie- you took too long to draw the screen), you would start to see flicker.

Remember we only had 1 kb of RAM to keep track of everything (drawing, game logic and sound generation).

The Game Controller

The Vectrex came with a game controller (where the controller had a proportional joystick and 4 buttons). There was a connection available for a second game controller.

Most (if not all) joysticks of the time were simple switches with the center being 'off'. The joystick would indicate RIGHT/LEFT or UP/DOWN. I remember calling that type of controller a 'Bang-Bang' controller.

The Vectrex controller would give a voltage that was related to the position of the joystick. Center would give 0 volts. Halfway between center and full 'UP' would give about 1.25 volts, with all the way 'UP' giving about 2.5 volts. Halfway between center and 'DOWN' would give about -1.25 volts and all the way 'DOWN' would give about -2.5 volts. The same was true for 'LEFT' and 'RIGHT'. The joystick was implemented with a pair of potentiometers.

Conversion of the two analog values (UP/DOWN, LEFT/RIGHT) to a binary value was done programmatically by successive approximation.