Re: programmable logic

On Mon, 6 Oct 1997 17:00:10 -0800, you wrote:

>>Of course you can center a DVG anytime you like. But what you can't do
>>with an Atari AVG is jump around the screen like the Cinematronics and Sega
>>games do. If you want to write your own games you can control the order of
>>your list, but if you want to run emulated games (more my goal) you don't
>>have that kind of control.
>
>I agree. The only "gotcha" with the instantaneous re-positioning of the
>beam is that the color Amplifone and Wells Gardners can't keep up. As a
>result of testing with the Sega hardware on a WG I have a rule of thumb:
>Don't deflect farther than 1/2 the screen width in a single "jump". (Kinda
>makes sense the way the AVG works, eh?) Anything more than about 50% of
>the screen width as an instantaneous change results in the a distorted
>vector.

I agree with that, my point is that you can have a digital vector generator
emulate an AVG by simple going to the center of the screen when emulating
the AVG command to go to the center of the screen. You can also emulate
any delays that are needed to move to the new position before turning on
the trace. So if you're emulating a set of AVG commands you can easily act
like an AVG with a DVG, on the other hand if you try to run Asteroids or a
Sega game on a AVG, it's just not going to be able to do the direct
positioning these games may call for.
>
>>I just picked up a Asteroids Caberet this weekend, and this is the first
>>DVG game I own (well I have a non-working Omega Race) so I looked it over
>>pretty carefully. It looks like they never did get the draw speed quite
>>right since some angles are definitly brighter than others. But I really
>>like the way the lines connect *perfectly*. You just can't get the Tempest
>>AVG to do that -- I'm talking perfect!
>
>Yep, there's a lot to be said for directly driving deflection with the DAC.
>The smaller screen sizes (like 13") with vectors look really sharp too.
>
>>Of course if you're controlling the vector time in software (using the PIC)
>>you could probably add fudge factors based on the length of the lines and
>>get a better lineup than the AVG.
>
>I was basically going to put the burden of line brightness on the host CPU
>and have it loaded as a "line" parameter into the VRAM. The more I looked
>at Atari's way of controlling the brightness of all three guns with one DAC
>it really works well for fixing line length/brightness problems. Length of
>a line is a pretty calculation on a 486 or better, so I was going to use
>that for doing the correction.

Sounds like it would work to me.
>
>>Yeah, I doubt if you could even measure the error. The thing about the
>>Breseham algorithm is that it appears to be less complicated, and I believe
>>I can control the draw speed precisely so that the intensity for any angle
>>will remain the same. But the increment test registers must be
>>pre-calculated in software or the design would end up be much more
>>complicated than the simple *step rate* registers used by Atari.
>
>Wow. That would be really cool. I'd love to have a DVG card. ;-) I just
>didn't want to tackle all the issues with a stand-alone state machine. If
>you can pull it off that'd be tremendously cool...

Later on in the week I'll either whip up an ASCII block diagram, or a
simple graphic of some kind and post it with a block diagram of a bresenham
loop and you can tell me what you think.
>
>>Using PIC instructions I was able to write a Bresenham line draw loop in
>>about 12 instructions. So if I want to drive the WG monitor at it's rated
>>slew rate I figured I needed to upate a 10bit DAC at a 3.33mhz rate, so I
>>need a CPU with a 25ns instruction time. That would be a standard PIC
>>running a 160mhz. The new SX could do it with a 50mhz clock since it can
>>run an instruction on every clock (no internal divide by 4), giving it a
>>20ns instruction time.
>
>One thing to remember about the PIC is that you'll need to bit-bang stuff
>like writes to DAC registers and stuff. My actual control loop was really
>small for the AVG stuff, but then you start adding stuff like "set DAC1
>write low, set DAC1 write high, output data, set DAC2 write low, set DAC2
>write high..." etc. Added about 50% in my case 'cause I'm controlling some
>digital switches plus the DACs and memory counters...

I counted the bit banging, but I was just counting instructions for the
main 3.3mhz DAC increment loop, this is after all the registers and DAC
values have been preset. Time between vectors (loading the registers and
such) is a different matter and would be part of the 800k/sec rate I would
need to maintain.

All this speed is a reason the ISP parts look so appealing, albeit slightly
intimidating. The ideal ISP design would be the bresenham algorithm with
one level of vector buffering so an off board processor could preload all
the register while the current line was being drawn. The a PIC might be
fast enough to do the 800k transfers needed, and add an additional level of
buffering. I'm sure the SX-50 could pull this off beautifully.

I downloaded the freebie Synario and might give it a try (with or without
the added level off buffering) using the built in 7400 type macros.
>
>>It's very tempting to just wait for this processor...
>
>Yep. Particularly at <$5.

Really? That cheap? Any idea when?

With one SX-50 completely dedicated to the bresenham loop, and another
taking care of the VG to PC interface, this might be a slick solution --
though there would still be the problem of speed of comunications between
the processors... hmm...

>>I'm not sure what the speed is, or how ZIP calcuted their spec, but
>>currently this is the unknown part of the equations and I'm not going to go
>>ahead with any design until I figure out how I'm going to get the data to
>>it fast enough. My caclulation was on worst case data using a standard
>>DVG. 10 bit starting and ending X/Y data, and a 12bit color - 800k per
>>second (wince!). That assumes 500 vectors 40 times a second. On the
>>Cinematronics games most only generate around 200 vectors 38 times a
>>second, Sundance being the largest at 430+ vectors per frame.
>
>Hmmmm. 800K per second. I just don't think a parallel port can pull it
>off. That's more in SCSI 1 throughput range. (*Snicker*, you could make
>an IDE/ATA vector generator. ;-)

What I need to do is build a cable between to computers and see what kind
of speeds I can achieve.
>
>The Vectrex goes through about 230 vectors max before flicker (so assume
>about 33ms refresh, probably a little longer 'cause the monochrome
>phosphors have a pretty long persistance).
>
>Curiously enough, Asteroids seems to be tied to a 60Hz refresh rate.
>Vector drawing only takes up a fraction of that time though.
>
>I think I wanted about 750 vectors every 33ms, so that's probably pretty
>close to your 500 every 1/40th sec...

The 500 for 1/40 sec was used to hopefully take into account anything the
Sega system might be doing.

This is probably one of those dividing issues (athenticity and all), but I
think it would be really cool to come up with an emulated game that used
none of the original parts (except the monitor), but you would be hard
pressed to know whether you were playing the original or a copy.

And then if someone were ever to come up with a new version of an X/Y
monitor...

-Zonn
Received on Mon Oct 6 17:34:33 1997