Re: Cinematronics > Atari Adapter???

On Wed, 16 Oct 2002 01:10:04 -0500, Rodger Boots <rlboots@cedar-rapids.net>
wrote:

>Zonn wrote:
>
>For what it's worth, I am well aware of how Cinematronics draws vectors
>(it's Atari I've never studied). The original question was how to
>reduce the costs of the circuit because someone thought $11 was too much
>to pay for a DAC and that's when I said to get rid of the DAC and build
>what is in essence a home made DAC. The tradeoff was accuracy for cost.
> And if there is any system out there that would work with inaccurate
>DACs, it's Cinematronics.

Yeah, I have to agree with that. The timing used to control the trace length on
a Cinematronics monitor is already a compromise, they don't use a fully
logarithmic table to adjust the timing against DAC voltage. They use a PROM
that has nine logarithmic timer values for 1023 vector lengths, and then adjust
the DAC voltage linearly to control the vector draw speed, so the end points are
a compromise at best. I had always wondered why I could never adjust the end
points to line up exactly, on all the vectors, all the time, on the
Cinematronics monitors, until I *really* reversed engineered the vector
generator that is.

>Yup, I screwed up calling it an integrator. It isn't. It relies on the
>concept that the first fifth of a time constant, or so, of an RC
>EXPONENTIAL (NOT logarithmic) response is close enough to being linear
>to be useful for drawing a line on a screen.

Of course your right, the RC charges exponentially, the calculations needed to
time the vector lengths use the log() function, which is where my confusion came
from. (Note to self: Never argue analog electronics with Rodger Boots! You
will always lose! ;-)

>It really doesn't matter to me, I'm not going to bother to build it
>anyway. Any time I've ever come up with an idea of designing something
>useful to the vector folks half a dozen other people chime in that
>they're doing the same thing. (Remember the replacement for the
>Amplifone HV supply? Seemed like everyone had a version of it.)
> Nothing ever comes of any of the projects that way. So screw it all, I
>don't operate or collect games any more so why should I care, right?

Well, I'd say wrong. I have a good number of your posts saved for future
references. I think the most recent being your discussion of the SOA of a
transistor when looking for an X/Y yoke driver replacement.

The problem is you listened to them. ;-) People have been claiming to be
working on a PC vector generator for five years. (Search Google and you will
find old hits on the old Vectorlist archive.) There was also a lot of opinions
on how to do it. I just took an approach I was comfortable with and went with
it. But only after looking at every vector generator I could find, and even
coming up with one of my own which consisted of driving an R/C circuit setup
like Cinematronics with a constant current source, for a constant speed vector,
but setting it's initial position with a voltage DAC. It would give you the
best of both Atari and Cinematronics VGs, and would make the timing much easier.
However it made the hardware more complicated (and I never tried it), so I bit
the bullet I wrote more complicated software for the simpler Cinematronics
hardware.

We looked at the Amplifone HV also, the problem we saw was that any solution we
could come up with, was that at such low qtys, it would have to be sold at a
price higher than the $190 Wintron replacement xfrmer that fixes 99.9% of the
Amplifone HV problems. I think this is why so many of those proposals went by
the wayside.

>The only exception was the PC vector card project. Good going, guys, on
>that one.

Yeah if I can only finish up the Parallel port I/O side of things! After all
the work needed to get vectors running properly, I figured throwing in some IEEE
1284 parallel port compliant code would be a breeze! I can do it in a week I
said! After all these years of doing software engineering you'd think I'd know
better! It's not the code itself that's a pain (though it was) it was that the
1284 code must be interleaved with the vector generator code (all written in
Atmel assembly language) where over 50% of the instructions must have their
cycles counted for everything to work properly! Whew! I really want to finish
this and move onto the ZVGIO and ZVT!

-Zonn

---------------------------------------------------------------------------
** To UNSUBSCRIBE from vectorlist, send a message with "UNSUBSCRIBE" in the
** message body to vectorlist-request@synthcom.com. Please direct other
** questions, comments, or problems to vectorlist-owner@synthcom.com.
Received on Wed Oct 16 00:01:41 2002