Re: Cinematronics vector generator...

Clay wrote:
> I was playing with the Cinematronics vector generator last night in
> Electronics Workbench (a spice simulator).
>
> I have a couple questions that maybe someone knows the answers to.
> Otherwise I'm going to try to measure it with a DSO over the weekend...
> ;-)
>
> From playing with my (fairly) realistic model, it looks like the time
> for the output to react to a change in voltage at the DAC is about 1us.
> Does this sound realistic? Seemed kinda fast to me. (I think this is
> while in "DRAW" mode-- voltage going through the 10K+5Kpot series
> current limiter. Maybe I screwed up and had it in "INIT" mode... Hmmm.)

What do you mean by "react"? I would think the output starts changing almost
immediately - the DAC just feeds an RC circuit, so as soon as there is
a change at the DAC it should move. Read on.

> Do any of you know what the "clipping" (z blank) timing is? For
> example-- when watching the output on the "virtual scope" in Electronics
> Workbench it looks like the linear portion of each charging curve starts
> about 50ns after the new voltage is applied. From there it's pretty
> linear out to about 150ns or so. Is z-blanking software controlled?
> Seems like 50ns is pretty tight timing to keep, but since it's also the
> period of the 20MHz clock it seemed like a strange number to show up
> "accidentally". (I'm wondering if the clipping is done in hardware and
> starts automatically one clock tick after the DAC is loaded and lasts
> for two clock ticks after it.)

The Z blanking is controlled in hardware, however vectors may be drawn
over various amounts of the charging curve. Here's the deal:
The beam is moved "fast" to the start of a line. Then you load the deltaX,Y
into the accumulators and execute the Normalize instruction. This does a
couple things (Zonn's docs cover this a bit). The deltas are repeatedly
left shifted (doubling the line length) until bits 9 & 11 are different.
That means a line will always be lengthened until it is at least 512 units
long. With each doubling, the line-length counter is updated. The line
length counter is responsible for stopping the drawing at the "real" or
unmodified end of the line. Once the "modified" deltas are calculated the
software must add the starting coordinates to get the "modified end point"
(which is some distance beyond the real end point) then a DRAWTO is
executed which: 1) outputs the endpoint to the DACs 2) engages the 13331
switches which use the resistors (RC for slow mode) 3) enables the line
length counter and finally 4) when the line length overflows (I think it
counts UP) it Z-blanks and turns off the 13331 switches so the beam doesn't
keep going to the target point (which was set way beyond the real end pt).

Blah. Anyway, for a short line, the "targeted" end point may be say 32 times
farther away than the real end point. While a long line, the targeted point
may only be twice as far away. This means the percentage of the charging
curve used can vary quite a bit. Because of the left shifting, there are
only about 9 different amounts of time used for line drawing - depending
of how many shifts it takes to reach "really long".

> Anyway, it just seemed really fast, so I'm hoping for a reality check.
> (This might be explained if I had the thing running with the "INIT"
> switch closed instead of "DRAW"... Up too late-- don't remember.)

It should respond quite fast. It seems like there is something that keeps
the Z-blank blank for a brief instant while the beam is "stuck" - i.e.
before it gets going. So I guess movement isn't instantaneous.

> I also put in that weird-ass bridge rectifier-resistor *thing* in the
> feedback loop of the output Op-amp. It looks like it kinda flattens out
> the charge curve of the cap, but it also looked like it was screwing up
> the discharge curve shape. Maybe I had it wired wrong (or it confused
> SPICE, which really shouldn't happen)...

I thought that weird-ass thing was the cinematronics way to compensate
for nonlinearity in monitor deflection. Notice that X & Y are not coupled
like Atari did.

BTW, I was thinking of running the un-weird-assed CineSignals down to my
space duel board (via X-invert, Y-invert) so they'd go through the 1492s
for pincousioning. I could then use the "invert" signal to select Cine
or Atari output :-) Of course there isn't a good way to hook into the
Atari color outputs... Yep, when I have the CineMenu working I plan to
add Space Duel as an option and just install it in that cabinet! :-) Even
if I have to use relays. Too Bad Gravitar & Black Widow aren't able to
run on the Space Duel board or the other way round. Anyone looked into
this???

-- 
 ___   __   _   _  _
|   \ /  \ | | | || |       phkahler@oakland.edu     Engineer/Programmer
|  _/| || || |_| || |__     " What makes someone care so much?
|_|  |_||_| \___/ |____)      for things another man can just ignore. " -S.H.