Re: vectorbeam hardware

Adam Wiggins wrote:

> > 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.
>
> In other words, draw a line the exact same way that you would on a raster
> monitor. :)
>
> Yes, that was the first thing I thought of, and I think I mentioned that
> in my first post (that Zonn replied to). My problem is that I get a series
> of very close together bright points, which of course is not what I want.
> Since I refuse to believe that a 450mHz processor is not able to compute
> a few thousand points per second, I determined that the slowdown is happening
> at the level of my analog output card. Checking the documentation, it lists
> 70 microseconds as the settling time of each DAC channel. Glancing at the
> specs for the AM6012 used in Atari vector games, it reports a latency of
> 250 *nano*seconds. Quite a difference. So I must assume that the board
> I'm using is too slow.

Nah, board will work, it's your computer that's too slow. If you're using
floating point math it's probably slowing you down too much. Do something like
use integer math and send the high bits to the DACs (in other words, make
yourself a fixed point math routine with the decimal point somewhere in the
middle of the number). The object is to get the speed up another order of
magnitude by making the math very fast without having to diddle with the result.
If the result is two bytes and the top byte gets sent to the DAC you have gotten
as efficient as you're going to get.
Received on Fri Nov 26 12:34:17 1999