A Vectrex project I wish I could do

[godslabrat]

I've been tossing an idea around for a while, but since I don't really have the hardware knowledge to get it off the ground, I thought I'd let you guys play with it. You'll probably all tell me my idea is impractical or ungodly expensive, and that's okay.

 

With the advances in technology over the last few years, I've thought about what it would be like to have a reproduction Vectrex, sans monitor. Yes, you heard me, a newly-constructed Vectrex, but with a/v output, not a dedicated montior or speakers. Okay, I can already hear the vector monitor purists gnashing their teeth, but hear me out. We have some caveats:

 

1) The machine IS NOT AN EMULATOR. It has an actual cartridge slot, and takes actual Vectrex games.

 

2) Instead of the vector monitor, the hardware has effects built in to scale the vector images to any HD resolution.

 

3) The only video port is DVI. Maybe Component. While we can't give this thing a vector monitor, we CAN insist that it have an HD display.

 

4) Overlays could be loaded by bitmap images on a USB flash drive.

 

I've actually thought of starting from a dedicated emulation PC, installing a cart port, and slowly reverse engineering the whole works until I had everything in its most set-top-box-like form. Unfortunately, I just don't have that level of know-how. So, I'm putting the idea here, to see what we all come up with.

 

So... any input, aside from the obvious "It's heresy to play Vectrex games on a non-vector monitor"?

[BigO]

This is similar to thoughts I've had about LCD displays for classic light gun games:

 

At some level, a single pixel on a display is addressable. If there existed fast enough A/D converters, analog voltages could be converted to X and Y addresses. It might also require direct access to the addressing circuitry as opposed to loading portions of the address into buffers and shifting or doing some serial to parallel magic in the LCD controller circuitry. (I just don't have a sense of the speed required for all of this.)

 

This is almost pure conjecture as I know almost nothing about the particulars of state-of-the-art LCDs. I also don't know if A/D conversion to a large enough number of bits (address) is feasible. If all of the parts fell into place, I could conceive of an LCD drop-in replacement for a CRT. The theory, weak though it might be, could apply to raster scanning or vector CRTs.

 

As for the proposal at hand, I wonder if it can be done without ungainly amounts of delay. I think you'd have to sample the output from the Vectrex circuitry over a period of time and store it in a frame buffer.

 

Another challenge that comes to mind: as I understand the workings of the Vectrex, the brightness of a given vector relative to other displayed vectors is controlled by drawing the brighter vector more times than the dimmer buffer. A digital display emulation of a vector display would have to somehow keep track of this repetition to produce the brightness effect. Along that same line, the scheme might also need to keep track of what was previously drawn at a given location and when it was drawn in order to simulate the persistence effect of phosphor.

 

(Note: I'm not in any way qualified to give input of any genuine value on this subject)

[godslabrat]

If there existed fast enough A/D converters, analog voltages could be converted to X and Y addresses. It might also require direct access to the addressing circuitry as opposed to loading portions of the address into buffers and shifting or doing some serial to parallel magic in the LCD controller circuitry.

 

...

 

I also don't know if A/D conversion to a large enough number of bits (address) is feasible.

 

...

 

As for the proposal at hand, I wonder if it can be done without ungainly amounts of delay. I think you'd have to sample the output from the Vectrex circuitry over a period of time and store it in a frame buffer.

 

Very good points, and all are in a deeper level of detail than I was working with. Thank you. My response to the above would be that since the Vectrex HAS been successfully emulated on the PC, then it is at least possible to do tackle these challenges. The idea here would be to adopt the emulator functions into hardware and remove the need for an underlying operating system.

 

Perhaps I need to be more generous with my "not an emulator box" requirement. That's fair.

 

Okay, so let's say we designed the output of the unit to only allow two resolutions: 1280×720 or 1920×1080. You wouldn't even need a configuration screen, just toggle between the two of them with a switch. We'd need to have it generate monochrome frames at 30fps. If we're not dealing with complex images, having a buffer would be fairly reasonable.

[BigO]

If there existed fast enough A/D converters, analog voltages could be converted to X and Y addresses. It might also require direct access to the addressing circuitry as opposed to loading portions of the address into buffers and shifting or doing some serial to parallel magic in the LCD controller circuitry.

 

...

 

I also don't know if A/D conversion to a large enough number of bits (address) is feasible.

 

...

 

As for the proposal at hand, I wonder if it can be done without ungainly amounts of delay. I think you'd have to sample the output from the Vectrex circuitry over a period of time and store it in a frame buffer.

 

Very good points, and all are in a deeper level of detail than I was working with. Thank you. My response to the above would be that since the Vectrex HAS been successfully emulated on the PC, then it is at least possible to do tackle these challenges. The idea here would be to adopt the emulator functions into hardware and remove the need for an underlying operating system.

 

Perhaps I need to be more generous with my "not an emulator box" requirement. That's fair.

 

Okay, so let's say we designed the output of the unit to only allow two resolutions: 1280×720 or 1920×1080. You wouldn't even need a configuration screen, just toggle between the two of them with a switch. We'd need to have it generate monochrome frames at 30fps. If we're not dealing with complex images, having a buffer would be fairly reasonable.

 

 

If emulation of the hardware is acceptable then the problem changes somewhat, to the easier side in a way. Are we talking dedicated hardware? If so, then it's a different ballgame. Clearly, a fast enough processor with code written for that hardware should be able to do the job. Even if it has to be a fullblown PC motherboard, some talented programmer should be able to write software to execute from ROM (or disk drive as BIOS on a PC would support without an OS). I would expect someone could come up with a custom Linux kernel to take maximum advantage of the specified hardware platform and make it look like there was no operating system.

 

It's way too ambitious for me, but all of the needed software could be written (possibly in C, definitely in assembler, maybe in something else) to run on PC hardware without an OS. Back in the olden days, I wrote stuff for 8088/8086 that didn't need DOS or any other OS. I believe Borland gives away a version of Turbo C, free for download. There are libraries in there that one can use to make calls specific to DOS or calls that are native to standard PC hardware. Have fun.