Re: vectorbeam hardware

On Thu, 25 Nov 1999 16:04:08 -0800 (PST), Adam Wiggins <adam@angel.com> wrote:

>
>Hi Zonn, thanks for your reply.
>
>On Thu, 25 Nov 1999, Zonn wrote:
>> On Thu, 25 Nov 1999 01:28:21 -0800 (PST), Adam Wiggins <adam@angel.com> wrote:
>> >The question is: when drawing a line segment, how does one achieve a
>> >smooth, perfectly straight, unbroken line between points? I can do it on
>> >the vertical and horizontal axis, but when I want to draw a diagonal I
>> >have to regulate the velocity of the beam myself. I do this by breaking
>> >the line up into an arbitrary number of segments and plotting each point
>> >incrementally according to y = mx + b.
>>
>> You need to give us a little more description on what hardware you are
>> programming. The title says "vectorbeam hardware". Does this mean you're
>> programming a full Vectorbeam system (Star Castle, etc.)? Or have you
>> connected some other CPU to a Vectorbeam monitor? Or are you using
>> "vectorbeam" as a generic term for vector programming?
>
>Specifically, I have connected my a couple of DACs to my PC, which are
>directly outputting +-5V to the X and Y axis voltage lines of a Vectrex
>monitor, and 0-5V to the Z axis. Since I'm bypassing all the hardware in
>the Vectrex, I assume that this would work more or less the same way for
>any normal vector monitor, except that I think some take different voltage
>ranges.
>
>I've been looking more at the schematics for some vector games (Major Havoc
>and Gravitar, to be exact) as well as some of the programming info for
>the Vectrex itself. My limited knowledge of electronics and the terminology
>they use (like RAMP, X and Y integrator, etc) means that I haven't gotten
>much out of it.
>
>The thing that still puzzles me is that I have trouble believing that these
>old games really had the processing power to actual step the beam along in
>a straight line themselves. That is, I'm doing it without my trouble on
>my PC, but every iteration (of which there are several hundred for each
>line segment) uses about twelve floating point multiplies, four floating
>point adds, and a floating point square root. (I could certainly optimize
>it, but I don't need to, given the relative speed of my processor.)

The original games did NOT have the CPU power to draw these vectors, so in all
cases the line drawing was handed off to vector hardware.

What you're attempting is a technique similar to Atari's early B&W vector games
(Asteroids).

They used a couple of 10 bit DACs which directly drove (through some OP-amp
buffers) the X/Y axis of the monitor.

This has the advantage of knowing exactly where the beam is at any given time.
There is never a problem with end points lining up.

The disadvantages are the very fast sample rate needed to run these DACs. I
believe I calculated this out to be a 3mhz sample rate. (maybe it was 1.5mhz).

They achieved this by running counters off a fast clock. The CPU sets up the
counters, with different increments for each axis, depending upon slope, then
starts the timers counting. So it was these timers, and associated hardware,
that did the "babysitting" of the trace for each "little" step needed to make
the trace appear to be a solid beam, and not a bunch of bright dots.

Another problem is with the apparent intensities of the beam. Since a digital
step on a diagonal, takes longer than a vertical/horizontal step, the apparent
brightness of a diagonal line will be dimmer (since it stays on one spot for
less amount of time). Additional hardware had to be added to attempt to correct
for this. If you look at the edges of an Asteroids, you'll see that it wasn't
100% effective.

I once calculated that if you used external, settable, counters connected to a
couple of parallel DACs, and allowed a CPU to control the clocks of the
counters, you could use a Scenix 50mhz CPU and achieved the sample rate needed,
if you can keep the main line drawing loop within 12-14 instructions. I also
came up with a line drawing algorithm that properly corrected for display
intensities for any angle, and I believe the main loop could be done in the
12-14 PIC instructions allowed in the Scenix. The only problem would be getting
data from a PC to the Scenix fast enough to keep the line generator happy --
since the 12-14 instructions did not included a "look for data from the PC
poll", I assumed two processors would be needed for this digital vector
solution. One to communicate with the PC and one (the Scenix) to draw the
lines.

>So it makes more sense to me that the original vector hardware would have some
>sort of analog method for controling the slope of the beam, which would
>be smoother and (maybe?) simpler than doing it digitally.
>
>The specific situation is this: when drawing a diagonal line that has a
>slope other than lying on a principal axis or on a perfect diagonal, the
>drawing speed of the shorter axis needs to be slowed down so that it doesn't
>traverse the distance before the other beam is finished.
>
>For example, consider the line with a slope of 1/3. It *should* look like
>this:
>
> ___
> __.--'
> --'
>
>Because the for every 3 "units" that the x axis traverses, the y should only
>traverse one. In other words, it's moving at 1/3rd the speed of the x axis.
>
>However, my x and y axis DACs are totally independant of one another. The
>beam moves at maximum speed, so when I tell it to draw a segment from
>(0,0) to (12, 4) (having a slope of 1/3, as above), it looks like this:
> _______
> /
> /
> __/
>
>Because the y-axis moves at maximum speed, but it doesn't have as far to
>go, so it completes long before the x-axis has finished.
>
>So what I'm boggling over is: do vector games have hardware (perhaps in
>the post DAC stage, but possibly prior) that regulate this so that the game
>software itself doesn't need to worry about it? (Baby-sitting the monitor
>seems like a pretty big waste of time that the game could be using to do
>other calculations.) Or do they actually do exactly what I'm doing, which
>is manually stepping the beam along? In order for the prior to be true,
>at some point the inputs for the two axes would need to "know" about each
>other, which I haven't seen any particular evidence for in the schematics.

In a digital vector drawing system (like the one you're attempting) the X and Y
axis cannot be independent of each other. If the X axis is longer than the Y,
you will have to space the Y steps so that they are in sync with the X.

Rodger's response explained the other two (currently used) ways of generating a
vector, both involve charging a resistor/capacitor and using the voltage across
the capacitor to draw the line.

The hardware for doing this is much simpler than the digital solution. And
since the line moves at the same speed regardless of direction, there is no
intensity problems.

But since they are both open loop analog solutions, the CPU is never quite sure
where the beam is, and programming is all done on faith -- depending upon a
hardware tech (in our case the owners) to adjust the analog sections so they
work properly with the CPU. In practice it works pretty well, but even on the
best aligned systems it is impossible to get all the test patterns on a Tempest
or Star Castle to line up EXACTLY right.

-Zonn
Received on Fri Nov 26 15:04:39 1999