Vectrex Vector Lists: Diffy, Duffy, Packets, and MAME's Rendering Model

The Vectrex is best understood through several layers that are easy to collapse into one vague idea of “vector graphics.” A program can provide relative-coordinate data to routines in the console’s resident software; the console’s display circuitry turns that activity into electrical control signals; an emulator models the machine and then renders a list of vector points into a modern display. A file-format description, a hardware manual, and an emulator’s drawing code answer different questions.

The original Vectrex Programmer’s Manual (Volume I, printed p. 16) documents three useful vector-list conventions: Diffy, Duffy, and Packet. MAME’s current driver source shows how one emulator schedules and renders vector activity, including a timer-2 policy described by its own source comments. The former is a software-facing manual contract; the latter is an implementation model, not a measurement of every original monitor’s analog behavior.

The manual’s relative-vector vocabulary

The Programmer’s Manual describes Diffy and Duffy as counted lists of relative (Y:X) coordinate pairs. The list’s count and optional scale details depend on which routine is called; do not assume every entry point consumes an identical header. In the documented Diffy form, drawing begins at the current pen position and proceeds to the first point, then through the following points. Duffy changes the start behavior: it first moves to the first point and draws from there to subsequent points. That difference is important when reading a path that would otherwise gain an unexpected line from the prior pen position.

Packet lists instead carry a sequence of three-byte entries in (mode:Y:X) order and end with the documented $01 terminator. The manual defines $00 as move-to-point and $FF as draw-to-point. A packet therefore makes the blanked move versus visible line choice explicit in each item; it is not just a list of endpoints with an assumed pen state.

The following is a schematic fragment, not a complete call frame for every resident routine:

00  yy  xx   ; mode 00: move to the relative Y:X point
FF  yy  xx   ; mode FF: draw to the relative Y:X point
01           ; packet terminator

Here yy and xx stand for the coordinate bytes consumed by the routine, not screen pixels or portable signed integers. The routine’s expected count, scale, coordinate interpretation, and calling convention still have to be established from the exact entry point and program context. A parser that identifies 00 and FF but ignores the terminator or starts at the wrong pen position can produce plausible-looking but incorrect paths.

The manual’s printed pp. 6–7 also describe the system at a component level, including the 6809 processor, 6522 interface adapter, DAC, and sample-and-hold circuitry. Those pages help explain why software feeds motion and intensity-related control into a display subsystem. They do not turn the three-byte packet into a calibrated measurement of beam position, brightness, or analog slew. Do not infer a modern pixel grid from the format alone.

How MAME’s driver turns activity into vectors

MAME has its own Vectrex machine driver and vector-rendering implementation. The driver source maps the emulated machine’s memory and devices; the Vectrex video source tracks display state and submits a point list to MAME’s vector device. The video file includes analog-oriented state in its model, such as blanking, ramp, and stored values used while updating points. Those names describe MAME’s implementation variables; they are not a direct trace from an original console.

One unusually useful comment in vectrex_v.cpp explains the driver’s refresh policy. MAME snoops VIA timer 2 because most Vectrex games use it for steady screen refresh. If a game stops timer 2, the driver continues refreshing at the last known frequency; its comment warns that the emulated refresh can drift out of sync and flicker. The source describes two restart policies: reset the period on every timer restart, which avoids flicker in most games but produces severe jerking in Mine 3D, or retain the current period under a stated comparison condition and change the next full period. This is explicit evidence of an emulator trade-off, not evidence that every original unit exhibits the same visual artifact.

The code’s refresh callback marks which range of the driver’s accumulated points will be used by the next vector_update(). The point list then goes through MAME’s vector device and screen configuration. That sequence is an implementation boundary: a defect can be in game data, the driver model, the generic vector device, or the presentation settings. A screenshot alone cannot tell which layer produced the effect.

A disciplined debugging workflow

When a line is missing or an unexpected segment appears, capture a repeatable game state before changing code. Identify the exact routine or packet sequence, determine its list convention and scale/count rules from the Programmer’s Manual, and write down the pen position before the first entry. Then compare the intended move/draw sequence with the points that the emulated driver submits. Keep a frame number, MAME version and source revision, game software revision, and the rendering configuration with the capture.

For a list decoder or test fixture, keep cases small and explicit:

1. A Duffy path whose first point must be reached without drawing.
2. A Diffy path that begins from a known current pen position.
3. A packet with one move, one draw, and its terminator.
4. A truncated packet and a missing terminator, which should be rejected by a defensive parser rather than read past its input.
5. A routine whose count or scale header differs from the fixture’s assumed convention.

These are parser and interpretation tests. They do not validate the timing or electrical response of a physical console. For MAME comparisons, change one variable at a time: preserve the game state and machine configuration, compare normal vector output before optional display effects, and inspect whether the driver emitted the expected point sequence before attributing a visual difference to the renderer. MAME’s source can explain its current behavior; a different release may change its model, so pin the version for reproducible bug reports.

Avoid unbounded per-point logging in a fast emulation loop. Aggregate counts or sample selected coordinates, and record enough context to repeat the same frame. A difference in point count alone is not proof of a bug: drivers can subdivide or represent equivalent paths differently, and the scene itself may have changed. Compare path order, endpoints, move/draw modes, and relevant timing assumptions before concluding that the display is wrong.

What this evidence cannot establish

The Programmer’s Manual is a primary technical document, but the linked copy is hosted by an archival Vectrex resource rather than the original manufacturer. Its documented routines describe software conventions; they are not a complete electrical specification for every console revision. The source comments and code in MAME establish what that revision of MAME attempts to emulate, not which analog waveform a physical Vectrex generated under every load, calibration, or display condition.

Likewise, MAME’s vector point list is not an oscilloscope. It cannot by itself establish actual beam dwell, phosphor persistence, spot size, power-supply condition, component aging, or an original unit’s deflection response. Do not label the resident software “a PC-style BIOS,” treat a packet as a bitmap, or describe MAME’s timer workaround as original hardware behavior. If an article, test, or preservation report makes claims about measured hardware, it needs independent hardware documentation or an actual instrumented test.

The useful engineering split is narrower and more reproducible: use the manual to decode what software asked the Vectrex routines to do, and use pinned MAME source to explain how that emulator transformed modeled activity into vector output. Keep the two records separate, and a visual discrepancy becomes a tractable question instead of a guess about “the analog part.”

Related:

• MAME Timers and Scanlines: Synchronizing Arcade Events in Emulated Time
• Inspecting MAME Vector Displays with Lua Device Notifiers

Sources:

• Vectrex Programmer’s Manual, Volume I (archival scan)
• MAME source at the inspected commit: vectrex.cpp
• MAME source at the inspected commit: vectrex_v.cpp
• MAME source at the inspected commit: vectrex.h