I have just finished a slightly different VecFever hardware project and since I already got quite a few ‘but is it better ?!’ questions I realized I have to explain the motivation behind it a bit further. Short answer: it is different, neither better nor worse, and runs the exact same firmware, 6809 code and apps on a Vectrex.
The design decisions behind it are simply different and the first influence comes from:
Atari Asteroids cabinets
I have become ever more interested in owning original Atari Asteroids vector cabinets both to play Asteroids but also as a ‘bigger Vectrex’, just would be nice to see & run some of my things on it. By now I own a working specimen of each cabinet-type Atari produced (cocktail table, cabaret and upright) and have a few more Asteroids parts so I am starting to become more confident that I can test more broadly eventually. Interestingly every single of my original Atari Asteroids pcbs is different from the others which is.. weird..
At the moment I actually do not want to put in an adapted Vectrex cpu board but would prefer to run code on the Atari Asteroids pcb. Which is why the v2 menu/vf lib. was developed in a way that it internally generates DVG code (if wanted) and uses an Asteroids emulation layer to produce output for the Vectrex. The ‘vector text’ menu output for example is pure DVG code (== Atari Asteroids pcb code) piped through a DVG emulation layer for the Vectrex.
So initial middle and upper level software parts are already in place – but a 6502 low level hw is needed plus some code to keep it all happy.
Inside an arcade cabinet I for once would prefer a hot-pluggable memory card, though, since updating it via usb or another cable is just bothersome inside huge cabinets. Bluetooth or WLAN might work but are not my first choice: I do not use either here, I have seen that kind of hardware produce weird side-effects in retro hw so would have to be powered up if and only if ever used and the hw code for it is not public – and from what I’ve seen a while back these black boxes are just buggy, too. Getting to the 6502 – and hence any pcb needing to access the bus – is easy via the coin door on the upright/cabaret and no problem whatsoever on the cocktail, anyways – and just popping out a memory card and updating data on it or swapping with another card is quite easy to do. It really comes down to: how often would you update really, if you are not developing .right this second. some new code for it ?! And for rapid development tests I could still use a very long usb cable and a uart-usb pcb to use the serial dev.mode.
Building the current ‘developer’ VecFever
I do enjoy developing stuff but building more than a few of any of my projects is not fun. The developer VF due to a few reasons and very early design decisions, e.g. the adapted shell, manually cutting the label, extending the legs of and placing the LED into the shell, the customized initialization procedures for the flash chips and uproc per pcb etc., just oversteps the kind of time I am willing to put in for non-developers which is why I stopped building them for a few years for others and after the current batch of Mark 2 vf would preferably not want to offer them anymore. But to be able to let people play these games ideally a different version should exist: changing as much as possible to come up with the least time-consuming version to build for me while still supporting every game/app running on the original VecFevers.
And there is also another thought nagging at me for quite a while: it would be nice to have a ‘dedicated game’ vf pcb version which runs everything running on the vf, just put it in an unmodified shell and it’ll come up as whatever game possible. And bonus points awarded if it could also support additional hardware – esp. more buttons or controllers.
The result: a ‘gamer/tinkerer’ VecFever pcb
By placing the 3-color LED differently, removing the USB port plus supporting infrastructure and swapping out the flash chips for a micro sd socket in-line with the Asteroids cabinet project’s setup enough GPIOs were freed and the geometry of all parts changed sufficiently (by completely routing the pcb anew) that:
- a serial port, an i2c port and up to 10 additional buttons (depending upon whether i2c/serial GPIOs are used) are supported by the pcb – hooking up a uart-usb pcb and enabling the serial port for example enables the ‘serial’ features like the serial dev.mode, the vector terminal and the 6809 serial extension
- the pcb can be put into an unmodified shell – meaning the micro sd socket is placed so that it barely fits in a shell. And thereby if a large enough hole is cut into a shell the micro sd card can be accessed from the outside – but not easily with a small opening since this would need a different placement of the socket which would break the ‘unmodified shell’ feature. Plus the LED placed directly on the pcb can be bent inwards so that it works with a clear shell (or just not be visible in others) or bent outwards for a simple 5mm hole. Or you have to lengthen the legs again to place it in a place of your choosing…
- the firmware was changed recently so that the autostart feature can support all vf apps, covering the ‘dedicated game pcb’ feature – plus hot-plugging of a micro sd card with an autostart binary immediately enters this standalone mode
In my mind this ‘gamer/tinkerer’ version complements the dev. version, which I intend to support and improve upon for the foreseeable future, too. ‘Gamer’ obviously since it lacks the usb dev.-mode and will be mostly used to just pop it into a vectrex and play games. Plus it doubles as the ‘dedicated’ game pcb I wanted. But it specifically can be tinkered with and hw features added – the LED, more buttons, a serial port, a real time clock or a combination of it all are optional, not necessary here as at least the LED is for the dev. version (showing the USB state when active). But how you put it into a shell and make it all as nice as possible takes time and depending what you want also some skill – others’ time and skill specifically and not mine – since I intend to only offer the parts to play with at the moment.
One other hope was that this version would be substantially cheaper to manufacture. It would be in normal times which sadly we are not in: the chip and production situation became very different from last year to now and the vf parts, esp. the microprocessor and the flash chips for the dev. version, are extremely hard hit price-wise and for the first time ever not even readily available at all. For the last pcb test batch costs suddenly jumped ridiculously up and I had to wait w/o knowing when they’d ship, ‘whenever we can get them’. And it did take (months) longer than ever before. That definitely is a new experience and checking today the major suppliers are out of stock with stated supply times of at least a year (!) and accordingly prices just going up further. That microprocessor is still guaranteed to be built and supported for at least a decade by the manufacturer so this is not an obsolete chip by any stretch – the covid fog of war on the manufacturing side led to this.
Which leaves me wondering as to what to do, honestly: just pay those punishing prices to build a few more for others in the hope they will arrive some day as I just did with the few for verification ? Or wait a year or three for better times ?
to quote the late Sir Terry Pratchett: ‘May you live in interesting times’,
Thomas
P.S.
not necessary to update if using v2.32 already but since the gamer pcbs were init. with a new firmware here it is:
v2.34
- removed 2nd controller button reporting to eliminate spinner/atari drv. controller interaction when plugged in for
berzerk, fortress of narzod, scramble, spike, vectrexagon, webwarp and webwars
- initial i2c driver abstraction for native apps added
- added options to invert joystick y-direction for flight sticks for Star Wars & Empire Strikes Back
- added warning to firmware downgrade, if buffer type not supported by older fw
v2.33
- fixed 'Vortex tubes' levelset option
- more robust buffer behavior to be able to recover most data if the buffer ever gets corrupted somehow