WG Monitor experiments...

clay wrote:

>>The only "gotcha" as far as the slew rate is concerned when using it with a
>>Wells Gardner monitor is parallel loads on the counters to the DACs.
>>(Those can make a big deflection fast when the new position is latched in.)
>>Otherwise, the max vector slew rate looks to be something the WG monitors
>>can handle OK.
>

zonn wrote:
><more data clipping>
>
>So it sounds like the real problem is how fast they move to a new screen
>position to start a new vector. That explains the misplaced vectors.
>
>So you can live with misplaced vectors, or crank up the voltage on the WG,
>or (this might be the hardest, I guess) find yourself a GO-8 monitor (and
>uh, fix it since you know it's going to be broken).

Ok, I did some tinkering this weekend in between building a brick retaining
wall for the garden. ;-)

I made an adapter to hook up the G-80 cage to the Wells Gardner monitor and
experiment a bit. (I took the design from... was it Dave Shuman's?
description without modification. Just a non-inverting op-amp for each
channel. I powered the opamps from +-12Vdc off the G-80 main board.)

I tried both Space Fury and Star Trek on the WG Color monitor. They worked
fine, although there was the occasional "misplaced" vector. I'm 99% sure
that the vector "misplacements" are just due to the WG not being able to
keep up on a big deflection when the DAC counters get a parallel load. For
grins I tried a bunch of different op-amps and (of course) nothing changed.
(The "problem" isn't with the convertor.) TL082, TL072, LM353, a bunch of
weird TI stuff all work fine. (Deflection speeds are really quite slow by
op-amp standards-- I was just desoldering op-amps from an old Paradyne 1200
bps modem and sticking then in... All worked fine. ;-)

Anyway, I'm going to look into it some more, but like I said-- I think the
problem's just in the big loads to the counters. For example:

1) The "misplaced vector" always appears in the same objects. (The "C" in
CREDITS on Star Trek, the player score in Space Fury, etc.)

2) It's always on the first stroke of an object. (The Klingon battle
cruiser in the demo-mode on Star Trek and the "C" in Credits are the first
vectors in the vector list.)

The effect makes sense when you see it and think about it. If you're
drawing a "C" that should look like:

 +------
 |
 |
 |
 +------

But what you get is:

       /
     /
   /
  |
  |
  |
  +-----

I think we're just seeing the beam getting turned on and the first stroke
started before the deflection had a chance to reach the beginning of the
character and settle.

I'm going to "freeze" the display list and dump the contents tomorrow
night, and try another experiment too... In theory, (with the vector
generator running) if I just change the position of the object to be closer
to the last location of the beam, the problem should disappear. (Since the
deflection is less.)

I wonder if there isn't a way to force a couple of "wait" states in the
vector generator on every parallel load to the counters? What if we added
a little logic that would basically eat a few (N?) clock pulses after the
DAC counter latches tripped to give the WG a couple more uS to get the beam
there?

Something like:

 Vector Clock---------> Tristate buffer ----------> Vector generator
      | ^ |
      | | pullup
      v |
Count to N counter ------------+
      ^ (enable)
      |
      |
 Counter latch
    signal

As long as the vector generator can still complete a full pass through the
display list in 1/40th second the game will still "play" the same...

Any ideas?

Oh, one other thing. It looks like the effect is always the the "Y"
deflection isn't making it in time-- the x positioning looks ok... Hmmmm...

-Clay

Clayton N. Cowgill Engineering Manager
_______________________________________________________________________
/\ Diamond Multimedia Systems, Inc. clay@supra.com
\/ Communications Division http://www.supra.com/
Received on Mon May 5 11:01:45 1997