> 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.)
> 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...)
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
---------------------------------------------------------------------------
** 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 14:29:52 2012
This archive was generated by hypermail 2.1.8 : Sat Apr 21 2012 - 15:50:01 EDT