Re: ZVG firmware / the future of ZVG

From: Zonn <mlists_at_zonn.com>
Date: Fri Apr 20 2012 - 03:30:32 EDT

On 4/19/2012 8:52 PM, Clay Cowgill wrote:
>> Clay, Sounds like you have put some thought into this..
>>
>> Have you actually been working on a stand alone multi vector
>> or a ZVG type vector interface?
> Yeah, as Zonn alluded to, this has been on the "approaching two decades now"
> to-do list. ;-) I've actually lost count how many different designs I've
> "decided" on and then changed. ;-) While I had a couple of (I thought)
> clever digital vector generators, I ultimately wound up with something quite
> close to Zonn's Cinematronics-like setup. (From a game emulation
> standpoint, the Cinematronics style VG is easier to deal with, IMHO. If I
> was making something that was vector, but no need to run old code I'd
> probably go digital.)
>
> When Zonn said the ZVG run was done, I decided to blow the dust off my
> hardware (and refresh it for "current technology") and talked Neil into
> doing the software side. It's a stand alone multi-vector emulator platform.
> Plugs directly into an existing cabinet. We're doing hardware validation
> and firmware development at the moment. Neil already has the vast majority
> of the software written though, so once I get caught up on the HW stuff it
> might actually come to life pretty quick...
>
> -Clay

Cool!

When (and if) I have the time, I've also given a lot of thought to a 2nd
gen ZVG.

My version would use an ARM processor with built in 12 bit DACs, 2 to 4
16 bit timers (based on the programability of the start and stop times
of the timers). And probably 6 outboard DACs. This would allow driving
vector monitors as well as laser projectors. The current ZVG uses timers
accurate to a single 8MHz cycle, it should really be a 16MHz cycle (2
times oversampling) to remove all rounding errors -- not that you'd see
the difference, the rounding errors are smaller than the size of the trace.

You should be able to get all the power you need from the USB interface,
you'd need a 5V to +/- 15V switcher, but not a lot of current. And, what
the hell, throw in a TCP/IP port to allow the generator to be run
remotely from any computer on the net.

With a 100MHz to 300MHz clock, you could easily add an emulator to the
ARM. You could have a full Cinematronics PCB replacement board the size
of the ZVG, with all the games built in.

The nice thing is the Cinematronics patent expired in 1998, and it is
easily the most versatile of the vector generators. It's analog so it
displays very smooth vectors, and it can be started and stopped anywhere
on the screen, so it's as easy to use as a digital generator, and it
never needs to be zeroed, like the Atari AVG's did.

The key issues with any generator is dealing with the yoke delays. The
X/Y (yoke) axises must be started before the Z-axis is turned on, and
they must be stopped before the Z-axis is turned off (you'll see what I
mean). This must also be done with very accurate (8MHz to 16MHz) clocks.

The Cinematronics vector design, specifically, needs very accurate
timing of the vector length if you want to run all vectors at maximum
speed. This allows emulation of faster games on slower monitors -- since
none of the original vector generators could run all their vectors at
full speed, it is possible to run faster games on slower monitors
without frame skipping. For instance all the Sega games run fine on a
WG6100 monitor. Theoretically you end up with a 50%, on average,
improvement in speed over the old 80's style vector generators. Which
means you can refresh 50% faster, or run 50% more vectors at the same
framerate, on the same speed monitor.

In reality, because of the starry backgrounds of most games, which are
not affected by the speed up, it's more like 20% to 25% faster. If this
was still the 80's I'd patent the improvements and make a killing on all
the license fees that would surely come pouring in from Atari. ;-) Ok,
Atari probably already knew about these improvements but didn't have the
memory for a 16K lookup table, or the processing power to implement it.

I'm going to publish the math used to generate these timing tables, and
the proper ending DAC values, along with the code. It's the most
important part of the generator. Publishing the code without it wouldn't
be that much more helpful than a binary image.

Let me know if you or Neil, would like to look at it before I get the
licensing worked out, and I'll send you the info.

I look forward to a modern Vector Generator! I'm glad the ZVG won't be
the last one!

-Zonn
---------------------------------------------------------------------------
** Unsubscribe, subscribe, or view the archives at http://www.vectorlist.org
** Please direct other questions, comments, or problems to chris@westnet.com
Received on Fri Apr 20 03:30:48 2012

This archive was generated by hypermail 2.1.8 : Fri Apr 20 2012 - 05:50:01 EDT