Bringing vector graphics displays back to life

... snip about vector generators for xyz scope ...

You didn't like the cheap 7 segment stroke generator I described earlier? Seems that writing generatable chars all over the screen should be fairly impressive, especially since you don't have to change the hardware to go to 15 segments, or whatever.

--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
     USE worldnet address!

Hrmf... Actually, no, this doesn't change my statement any. I still think it's overkill. The horsepower required to transmute "64,64" to

0x00000040, 0x00000040 is negligible. The speed bottleneck in this system is likely to be the serial interface (if by "serial" you mean "RS232"). I'd say this is all well within the capabilities of a reasonably frisky 8-bit microcontroller.

BTW, why 68000? It's relatively complex to interface with, and (IMHO) a moribund architecture. Why not a cheap ARM like Philips LPC21xx? It has all the ROM and RAM you need on-chip, and it's in a handy QFP package that's easy to prototype.

snip

snip >

have a look at this:

it's for a DSP but it should give an idea on how it could be done...

-Lasse

[snip]

can

I

most

[snip]

How about taking the stereo outputs of a sound card and using the left channel for X and the right channel for Y? The left channel then becomes a list of X coordinates and the right channel a list of matching Y coordinates. Create a wav file, then use your PC to play it over and over. That should work for static images.

If you want to do something more complicated, you'll have to use a double buffering scheme -- while the sound card "plays" one image, build the next, then switch buffers. The nice thing about this is that you can let sound card display the image via DMA from memory while your CPU is generating the next image.

I'm not sure what you would do about intensity except to suggest maybe using a second sound card or one with more outputs. Good luck.

Scot Allen

We chose AVR's as the controllers since they were the only small 8 bit processor that had fast enough timers. Most micros *really* want to divide their CPU clock by 2 or 4 before feeding it to the internal timers. AVR can use the CPU clock directly for their timers.

We went with an analog vector generator that works like this:

Place an analog switch between the output of the DAC and a capacitor to GND, then place another analog switch between the output of the DAC and a resistor and then to the same capacitor:

|\ [DAC]-+-[START-SW]--------+-| >---> to X or Y channel of Vector display. | | |/ +-[END-SW]----/\/\/-+ | --- --- | --- - .

duplicate the circuit for the X and Y channels.

The start of the vector is selected by setting the DACs to the vector start positions, then turning on the START_SW's, the DACs charge quickly to the vector's starting position.

START_SW's are turned off, and the caps act like sample and hold circuits.

The DACs are then set to an ending voltage (that is way beyond the real ending voltage of the vector's endpoint), and then the END-SW's are turned on, the Z-axis is also turned on, the capacitors begin charging to their new values and the vector length is very precisely timed, and then both the END-SW's and the Z-axis are turn off -- before the caps actually reach the ending voltages of the DACs.

That's the block diagram overview, however the ZVG is much more complicated than that. In order to refresh a 1000 endpoints at 40 to 60 frames per second, we had to use an ECP parallel port interface (the serial port doesn't even come close), so also embedded in the ZVG is IEEE 1284 compliant firmware to communicate with the PC. We also had to write DOS IEEE 1284 routines for the PC. The 1284 protocol is used to send/receive the ZVG low level commands used to indicate the starting and ending points of the vectors being drawn. Since the ECP ports were still not fast enough, the command set compresses the vector information, removing redundancies between sequential vectors. This instruction set was carefully worked out between me and Neil (the guy that wrote the message I'm replying to.), his Arcade Emulator (Retrocade) was the first to support the ZVG.

Another thing is that we drive yoke based vector monitors, which add another level of complexity to the Vector Generator. The yokes create pincushioning effects that must be compensated for using analog multipliers, also the images bloom near the edges of the CRTs which is corrected for using variable gain amplifiers.

There's also a subtle, but pain in the ass problem with driving yokes, that does not exist with oscilloscopes. There is a delay between the time you start the vector moving and the yoke responds, (caused by the yoke's inductance), there is also a delay between the time you stop the vectors movement and the trace stops moving. These times are not symmetrical. So you must start the vector movement, wait for an amount of time that is based on the yokes specs, turn on the Z-axis, finish timing the vector length, turn off the vector generator, wait for the yoke spec's amount of time, and then turn off the Z-axis. (It actually gets worse, for small vectors: Start vector movement, time vector length, Stop vector movement, wait, start Z-axis, time vector length + yoke delay, turn off Z-axis, since the delay can be such that the vector is fully drawn before the yoke starts to respond.)

These timings need to happen with the resolution of an 8mhz clock to handle the various timings needed to emulate all the 80's vector arcade games, on the vector monitors used at the time. This means a *lot* of cycle counting in the firmware with IRQ's disabled. There was no way to do this and run a 1284 compliant interface, so we used two CPU's, one for the I/O code (and timing calculations) and another's whose only purpose is to precisely time the Vector length and Yoke delays.

The ZVG is probably a bit overkill for what you (you - as in the original poster) would want (actually you were looking for a project, not a solution ;-).

We don't make any money selling ZVGs (We support ourselves by manufacturing Audio/Video switching equipment), at $239 (similar to the price of a high end video card) it will never pay for it's development costs, but it will most likely (*hopefully* ;-) pay for the parts and labor involved in having them manufactured. (Of course if someone wants to buy a 1000 of these, we can talk about a $100 / board price! ;-)

We built the ZVG

simply because *I* wanted one! Running all the 80's Vector Arcade games on one vector monitor is just too cool! ;-)

-Zonn

--------------------------------------------------------------- Zonn Moore Zektor, LLC

Remove the ".AOL" from the "From:" email address to reply.

You're right, that should be impressive. I certainly like the idea, and I will take it into consideration. The thing is that I was still trying to understand the basic operation scheme you proposed. Maybe you can elaborate?

"Lewin A.R.W. Edwards" schreef in bericht news: snipped-for-privacy@posting.google.com...

list

next

It is a simple matter of availability and of knowledge. My school has an army of 68k SBC's ready to go and complete with digital I/O ports and a sub-board for inserting external IC's. Contrary to zero LPC's. Besides I learned to program assembly and C on these machines. But if some architecture is *far* more suitable for the task I originally posted, I am willing to adopt it.

schreef in bericht news: snipped-for-privacy@4ax.com...

,

able

solution

Right. But still you provided useful design information and an interesting story.

I am not very good at ascii art. I assume you know what an analog integrater looks like. You have an X and a Y register, together with D/A converters, outputing the basic XY scope position through a mixer. The mixers are just resistors meeting at a virtual ground (the - input of an op amp). The mixers give you the opportunity to inject a perturbation to the basic X or Y position, which comes from 2 the integrators (a deltaX and a deltaY for each of the fundamental X and Y values). Don't forget you have a Z input to enable or disable the dot at any time.

You feed inputs of +1, 0, or -1 to the integrators. The quiescent state is with 0 input. You make sure that the net input over a drawing cycle is zero, which means the trace returns to the starting point. How to ensure this over many cycles is a problem, which might be handled by a long time constant from the output to the input to stabilize the DC base value.

Your controls are the integrator inputs, the X Y base values, and the Z axis modulation. To display a point you move there, blip the beam on, making a dot, then either move on to the next or energize the multi-segment sequence, and then move on. This is all software.

I could sketch the circuit in 5 minutes.

--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
     USE worldnet address!

can

That can be done, but I suspect that it won't be simple (at least for me

-- I'm not an analog guru). I think that the slewing rate should be fairly uniform, regardless of distance. On one such system I used, the Z drive had to be delayed slightly for the ramp to take effect. If you use an analog circuit for slewing, you will need to be fairly accurate in terminating the ramp and Z drive.

Thad

This is the approach Atari took on its later X/Y generators, for games like Tempest, Space Duel, etc (I'm not sure how many Arcade collector read this group, the list goes on, but if you weren't there in the '80s you won't recognize the titles. ;-)

One thing you have to worry about using this approach is drift. The integrator will drift and since your only frame of reference is your current position, the errors will accumulate. Atari solved this problem by placing an analog switch across the integrator's capacitor, and periodically (usually a few times per screen refresh) discharging the capacitor, allowing the moves to start from a known position (the center of the screen). Small offset voltages in the +1 0 -1 feeds (which come from bipolar DACs unless you only want to draw 0 45 90 and 180 degree angled vectors), also caused them to place an analog switch at the inputs of the integrators.

You also cannot "jump" quickly to the start of a new vector, but must turn off the Z-axis and move there. This and the drift problem were what kept us from using this approach. We needed to be able to emulate Vector Generators that could jump quickly to new positions in order for us to keep up with the game code.

However this approach is probably the easiest from a software point of view, the vector length time is linear (this is not true for the RC approach we used), which makes the timing routines much easier to calculate and the firmware much easier to write.

-Zonn

--------------------------------------------------------------- Zonn Moore Zektor, LLC

Remove the ".AOL" from the "From:" email address to reply.

... snip ...

I used it in the early '70s for annotation of screen displays. I never got into video games. These were PHAs (Pulse Height Analyzers) for nuclear physics radiation analysis and some other instruments for medical work.

Our systems always used z blanking. We were basically plotting counts vs a position, or sometimes a 3 dimensional version by mixing x & y values to form hor/ver base positions and using the counts to add to the ver value. We could afford slight drifts from the annotation integrators, as long as it did not accumulate.

The idea is to make the net position change zero, and also to zero the net dc effect of the integrator inputs. That means starting the trace from the middle and returning there. This also means some 1/2 segment moves, which is trivially done by adding those moves to the start and end of the segment path.

Having done that you add a long rc time constant, relative to the segment trace interval, from the integrator output to its input. This does not include the basic XY position. Now long term drift goes away, and the picture no longer walks slowly off the screen.

The pattern traced looks roughly like:

____ /_ _/ ____one of these two horizontal half segments /___/ is traced twice forward and back (while blanked at trace start/end) and takes 1/2 the time

The integrator looks like:

/| Voltage / | follower +---O |----------o---BIG C---gnd | \ | | | \| | R3 R2 | | o--- C int -------o | | | |\ | | | \ | in ---R----o-----|- \ | | \ | | 0------o------To mixer | / +----|+ / | | / gnd |/

You might want to complicate the DC feedback by using another opamp as a voltage follower in the path to R3, which greatly eases the selection of R2 R3 and BIG C. Now R2*BIGC controls the timeconstant, and R3 controls the gain, independantly. R*Cint independantly controls the actual integrator.

To do this you have to design out the DC components of both the output and the input of the integrator. If the input is a switching level (Vsat from gnd) you can supply the integrator + reference from a similar Vsat. This will temperature compensate drift.

This transfer function could probably all be simulated perfectly well with a fairly complex numerical chip, just as filters have gone that way. But op-amps are still cheap, as are R's and C's. The cost is board space and assembly time.

--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
     USE worldnet address!