Re: ZVG firmware / the future of ZVG

>> How about a hybrid approach to the hardware. Use an FPGA for
>> the time critical stuff, vector drawing and beam control, and
>> an ARM to do the rest ?
> You could, but that's basically why I abandoned my digital generator-- I
> decided that you could just do everything with the same cheap ARM. (So no
> need for the FPGA if it works.)
>
> The proof is in the pudding so to speak, so once we have game + VG running
> will be the point at which I'm comfortable saying "that worked" as opposed
> to "that *should* work", but until then I still don't see any problems.
> (Not like it's a new idea-- the Cinematronics stuff and Vectrex both use the
> CPU to draw vectors and managed it just fine.)
Point taken ;-) 32-bit ARM wins hands down and it's a lot easier to code.

>> BTW, tried a dual SPI DAC on my Cinematronics FPGA board and
>> in some games the vectors were noticeably out of position,
>> solved it by using a pair of parallel DACs.
>> Timing is critical when drawing
>> vectors and a 100ns makes a noticeabe difference.
> The DAC quality in the ARM is my main concern at this point-- some of those
> built-in "free" DACs are a bit of "wishful thinking" when it comes to specs,
> but again-- proof will be in performance. Worst case, add external DACs.
> ;-)
>
> If this ends up working as designed, the nice part will be that vector draws
> will be essentially zero CPU for all intents and purposes. We're using a
> Cortex family ARM (so you get very quick and more importantly--
> deterministic-- interrupt processing time) and with fast vector timer clock
> all but the very shortest vectors (like legth of one or two) are in the
> 100's of clock cycles. A draw will basically amount to a couple register
> loads and a timer value and go on about your business... The timer
> interrupt fires and shuts down the Z at the end of a line and loads up the
> next vector. Since most lines takes many useconds to draw, that leaves the
> vast majority of the CPU free to do other stuff still.
>
> The other upside to a really fast CPU is even if you're "on the edge" or
> something with an instruction that's executing before an interrupt and
> there's just a perfectly, inconveniently timed flash fetch that messes up
> the next execution timing... At 72 or 144MHz your instruction cycles are
> close (or in) single-digit nanoseconds, so a couple here and there of
> 'jitter' still isn't going to amount to much on screen. (...and worst case,
> move the VG interrupt code to zero wait state RAM and execute from there to
> avoid any flash accelerator behaviours...)
I think the shortest Cinematronics vector is 600ns, and to be honest some of my
timing problems were due to using a TEK scope to display the vectors and not a
magnetically deflected CRT, probably hadn't taken into account the short delay
in the coil drivers. Must get around to hooking it up to a Vectrex some time :-)

> If you assume a draw is 15us/inch, that's 0.0666" per us... So even 20ns of
> jitter is like 1/1000th of an inch on screen? Phosphor bloom should hide
> *that*. ;-)
>
> Coming from a raster video generation background I always work backwards
> towards the vector stuff to get some "sanity check" going on and relate it
> something I'm more comfortable with (raster resolutions like 320x240,
> 1024x768, etc.)
>
> If you say a 4:3 monitor is maybe 16"x12" (yielding a 20" diagonal) and SWAG
> that ~15" across is full deflection in the visible portion of the tube, we
> multiply by 15us/inch and get 225us for a straight line across the screen on
> something like a G05. That's probably not the upper limit of speed (the old
> G05-802 manual said it could do that in 150us), but we don't want to push
> the envelope or the 30 year old electronics *too* much. ;-)
>
> Just comparing that mentally to something common like NTSC (or QVGA), those
> are about 63.5us for full screen width sweep, but with only maybe ~53us of
> that in the 'visible' portion of the screen. Working backwards from there,
> a 320x240 raster would come out to be about 52us/320 = 163ns per pixel.
> About 6MHz (I think the 'official' QVGA pixelclock is like 6.36MHz, so we're
> close).
>
> So... 225us vs. 53us is about 4.25:1. A "QVGA" sized pixel (163ns on
> NTSC/QVGA) is about 700ns on the G05. 350ns would be about a 640x480 sized
> pixel. 175ns is about like a 1280x960 screen pixel, etc. As long as we're
> in the sub-100ns range of precision I'm pretty sure we're talking
> non-visible impact even on the nice high-res monochrome CRT...
>
> -Clay
Shame I don't have a nice high-res monochrome CRT, oh well the Vectrex will have to
do for now :-)

Who ever picks this up as a project, Zonn or Clay maybe, is it going to be open source ?
Would be nice to see more independant vector games.

Chris

---------------------------------------------------------------------------
** Unsubscribe, subscribe, or view the archives at http://www.vectorlist.org
** Please direct other questions, comments, or problems to chris@westnet.com
Received on Sat Apr 21 15:48:23 2012