Re: vectorbeam hardware

The Vectorbeam/Cinimatronics used the DACs to charge a capacitor to the starting
point and then had the DACs charge the capacitor to a finishing point that (through
a resistor) that was WAY past where they wanted to go. Then they only used a small
part of the charging of the capacitor as their line. This gave them a relatively
linear line out of an exponential charging curve. A timer determined how long to
generate the line.

I believe others used a similar approach using integrators.

Doing it your way you'll need a software version of a rate multiplier. Initialize
the DACs to the starting point. For example, let's say you then want to draw a line
that's moving to a finishing point 50 steps in the X direction and 30 steps in the Y
direction, take the larger number (50) and make a for-next loop that changes X from
the starting to the ending value. Inside that loop you will change X by 1 for each
iteration and Y by 30/50 (.6). This will create your smooth line. Just don't go
faster than the monitor can move and you'll be OK. NONE of this needs to be
floating point math.

Adam Wiggins wrote:

> 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.)
>
> 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.
>
> Hopefully this makes things clearer, and thanks for helping out a vector
> newbie.
>
> Adam
Received on Thu Nov 25 18:07:13 1999