YouTube genius Arcade Jason, the guy who connected an arcade vector monitor to a Vectrex, has now come up with a hack for a color Vectrex. I'm not sure how it's done since the technical aspects are briefly discussed at the end of the video, but this looks like something that could be used for some cool color vector games if the colors could be controlled and programmed on purpose. I'd love to see a real Tempest conversion (wouldn't we all).
If you're thinking Full color control by software then Arcade Jason's solution is not what you are looking for.
Can you explain why not? The colors seem consistent (meaning they stay on certain sides of shapes instead of shifting every time they're drawn) so I could see a modified Vectrex with a daughter board that has an IC or 2 that something like a Vectrex32 could access. Assuming that the new chips are wired in that way and not simply wired in like a bunch of resistors. I guess the key would be making those extra ICs accessible. I can understand that what is being shown in that video isn't programmable but wiring a modified Vectrex to a color vector monitor is doable, yes? So long as whatever drives the colors is accessible?
Edit: I'm thinking in terms of like, for example, the extra graphics board that I've read about that can be added to an Atari 800 in order to give it more graphics modes, something that original programs have no awareness of but that new programs can take advantage of.
Last Edit: Dec 21, 2017 20:19:03 GMT -5 by ledzep: Forgot to add.
From first viewing, I understand he's using the intensity/gradient signal from inside the Vectrex to specify colour. So instead of different brightness of lines, they come out in different colours.
A game could be written with this in mind, so that everything is the same brightness but comes up in different colours, but it would be much better to use another output from the Vectrex logic to specify colour on it's own, so that brightness can still be controlled properly as well. One/some of the spare I/O lines connecting to the cartridge port or the controller port might be suitable for this, if the data is read in serially by the external circuitry.
The issue with this approach is that people have to make significant modifications to their Vectrex to make it work, and the exact procedure may vary between different models of colour CRT TVs/monitors (which would need to be converted for vector use). I looked at using LCD displays with the backlight removed, but the trouble there is finding ones that are the right fit for the vectrex's display (and how to mount them). They would also need much more custom control circuitry: computernerdkev.heliohost.org/eleoverl/eleoverl.htm
Too bad he didn't have a better camera for it, as several of the games look amazing. Others get somewhat monotonous with purples and reds or hardly any colors at all (like Bedlam). Still a very interesting project though.
In the past, and again just recently, Arcade Jason has discussed on Facebook his project to colourize vectrex programs, and has designed a board to do the colourization. He's tried various heuristics for selecting colours, and some perform better than others, but in essence they're all arbitrary and somewhat random.
When I saw his post the other day, an idea came to me for a solution that would allow true deliberate colouring of the vectors.
The basic idea is to monitor the address bus and keep track of the 6809 Program Counter. Then when the PC is equal to certain trigger points, the 'current colour' register is loaded with the predefined colour and any subsequent vectors drawn until the next trigger point will be that colour. That's the entire hardware side of the solution.
The most robust way to build the table would be completely manually, but with the help of an instrumented emulator, we can help this process along considerably. There is *always* a code address somewhere that is only executed before drawing specific objects. Even if most objects are pre-built lists, there will be a place where that list's address is loaded and the drawlist code invoked. So what we can do is let a frame execute, record the sequence of code addresses executed, and tag the items in that list with the vectors that are drawn and where they're produced.
The code would then scan down the vector list and set a colour at some point, then draw a few more vectors and reset the colour to default. With a slider each for the start and end vectors, a user would adjust the sliders until a specific object is colourised. (I.e. an object recognition routine which would be too difficult to program is replaced by a human) Then a code analysis routine would look at the code between what follows the previous vector before the object and the first vector of the object, and examine each code address that was executed. If there is an address that is not executed for anything else on the display, then tag that address as a trigger for colourizing that object (or group of objects - this would probably find all asteroids or all space ships, but not all asteroids and space ships for example)
Sorry if that sounds confusing but I have a clear picture in my head of how this would work and I can think of ways of coding it. If the hardware side is possible then the idea should work. (I'm very sure the display part could be done in a Vectrex emulator even if it turns out not to be possible in hardware, so this scheme should be possible in a true vector system using a PC and a ZVG, even if not in a modified Vectrex itself).
Also the table of code addresses where the colours would be selected is something that could be implemented in a database that is refined over time, in much the same way that disassemblies are improved over time and disassemblers are seeded with known code addresses identifying areas of a rom that are discovered to be code as opposed to data.
And clearly it would be trivial for code that has source available... (Also a non-hardware solution that uses patched roms would be pretty easy too)
It would be nice to see a software implementation proof of concept at some point - I'm fairly tied up working on the PiTrex project but I might come back to this next time I'm working on an emulator, if the hardware gurus here can say whether or not tracking the PC externally is feasible. Actually tracking the PC may be overkill, it may be sufficient to track fetches from the cartridge rom regardless of whether they're code or data - that might even work better because you could trap on accesses to vector lists in rom...
I've just finished a software proof of concept for this colourizing suggestion, and I have to say I'm quite pleased with the way it came out. I modified vecx-SDL to add colour attributes, and inserted triggers corresponding to the code locations in minestorm where it draws the player's ship, and immediately after where it is drawn, to switch the displayed colour to yellow and then back to white. And when you run vecx and play minestorm, you get a nicely colourized ship and nothing else.
I'll upload a file of diffs in case anyone else wants to play with this concept. Pretty sure a hardware implementation would not be too impractical (and the concept would work for any arcade system, not just the vectrex, as long as you could piggyback a rom of colour tags on top of the game rom and feed its output into a colour display with the logic on the right hand side of Jason's board diagram)
Damn - "This forum has exceeded its attachment limit" ... so I'll host the file on my web site and link to it:
With a colourizing vecx running on a PiTrex and drawing output to the Vectrex display, coupled with a 3d imager using a modified colour wheel (something I suggested on FB last year which Jim Watt actually built and confirmed that it works), we ought to be able to schedule the drawing of vectors from arbitrary existing games to match the wheel timings and get colour on a standard Vectrex display! Malban just now mentioned that he has an imager, so this experiment is likely to happen some time (though not in the near future as we have our hands full with more urgent critical path development tasks for the PiTrex). Since this is pretty cool we'll probably end up doing it sooner than we ought to ;-)
In the mean time as a background task on days when I need a change of scenery, I'll continue to examine the Minestorm rom and find more code locations corresponding to various objects so we can fully colourize the game...
(OK, I couldn't resist having a go at this... I have Minestorm 95% colourized now. I'll post some photos or a video as soon as it reaches 100%)