Home Page Forums MAME MAME How does the hardware of vector-games work?

VectorMAME only worked on MS-DOS PCs with legacy parallel ports and only with the Vectrex as a practical matter, because who'd want to deprive an otherwise working vector cab of its monitor.

Someone's recently come up with a similar USB solution that works on modern PCs and operating systems, but it *only* works with the Vectrex and there aren't that many of those out there in good condition. (I have one, but I don't really want to screw with it if I don't have to).

Also the ZVG cards are not produced any more.

I kept your link R. Belmont, with the USB-solution: https://trmm.net/Vectrex

I actually have two working Vectrexes, but I wouldn't scrap one either to interface to MAME over ZVG & co, I rather make a custom cartridge that is connected to my PC which turns the whole Vectrex into a vector engine.

A ZVG like device could be used in one of these laser projects coming back too:
http://hackaday.com/2014/09/20/vector-laser-projector-is-a-lesson-in-design-processes/
http://hackaday.com/2013/03/12/playing-mame-games-on-a-rgb-laser-projector/
http://hackaday.com/2011/11/10/rgb-laser-projector-is-a-jaw-dropping-build/

Once I get a better hang of the full MAME code base I might contribute something in this area but it is rather far down my todo list and right now I hate C++ (again) and device clocks that doesn't start and stop as expected so we might talk about in a few years from now. ;-)

This sounds like a very interesting project. I would be one of the first customers willing to buy such a cartridge .

I am not intending to manufacture anything but maybe I post my findings for others to make their owns if found usable.

Its still a fantastic idea and hopefully do-able for you. I wish you all the best, regarding this .

So I got drunk and scrawled out a description of one part of the core overhaul necessary to properly support perceptually accurate vectors in MAME. Have a look, tell me what you think: https://github.com/mamedev/mame/issues/399

The description sounds very pragmatic and seems to make it easier/possible to render vectors with different brightness and also possible to render adjacent pixel glow?!
Thats a great improvement and will give vector games a more vivid appearance.

Without any deeper knowledge of the MAME sources I probably fail to see the full effect of the proposal, however if I just go to the Vectrex hardware which I know fairly well
I believe it will be difficult to render the ghost vectors of the beam zeroing as mentioned previously, these are sometimes non-linear and I would guess that is caused by the vectrex decharging some capaci/induc-tance in the deflectors.

There are also some home brews that took the Vectrex hardware, no modifications except for the cartdridge, to the extreme:
- http://hackaday.com/2015/04/24/extreme-vectrex-multicart-plays-bad-apple/
- https://www.youtube.com/watch?v=_aFXvoTnsBU

Vectrex actually has a preferred fps of 30 refresh cycles per second and the BIOS has a function to zero the beam and wait for the next cycle. The reason is that the beam only lives for so long and lower fps will make the screen flicker. The demo above uses the blank interval to play music on the deflector circuitry with the beam off.

Chew on that for a while, maybe it is too much to expect of an emulator.

Hmm. Good point on the vector beam having behavior that isn't directly controlled by the software. I'd imagine other vector monitors have other, similar things going on?

I wonder if another layer of abstraction, like a vector monitor device (C++) that could be inherited from for different vector monitor types would be able to handle this. Every time the beam turns off, the device would track its motion and create a series of short vectors whose intensity would decay at the necessary rate. This would mean the driver wouldn't have to take care of things that are a property of the monitor - it would come "for free" from the monitor device.

Maybe
/Andrew

PS. No level of accuracy is too much to expect of an emulator!

I like that, if we had an "analog" monitor device with some properties that could be driven by applying voltages to the deflectors and the beam it would be easy to map that to the actual D/A:s of the Vectrex for instance.

It would also be easy to multiply that to get an colour vector monitor.

I am not sure of the feasibility of emulating an analogue beam however but I suspect we talk about relative slow/few movements compared to a normal sweep based CRT.