For debugging purposes I sometimes use serial output so the vf has an accessible uart and I’ve build a few cart. which include a uart-usb pcb. At one point since the hw already existed I was wondering how to use this serial port also by the 6809. This 6809 serial implementation went through a few iterations and ended up being very simple on the 6809 side: a status, rx and tx register. The VF hides a massive, receiving ring buffer behind these 6809 registers so a lot of data can be sent to the 6809 and it pulls the data whenever it feels like it.
Nice in a ‘had not been done before’ kind of way but not really useful as such. Interestingly someone had built a minimal 6809 computer without video or keyboard, only using a uart for I/O, and used a modified Basic version for this setup. Which made it very easy to create an ‘extended basic’ cartridge using the serial port. So no input or output on the Vectrex, it is just running Basic using the serial port. With this cart. I can even claim that I can do floating point on the Vectrex natively whenever I want to. On a Microsoft ‘operating system’, no less, or what passed for an OS back in 1982..
Not that this is really useful, either, but was a nice proof of concept. If memory serves a Swiss enthusiast contacted me at the time since he wanted to implement a Forth variant for the Vectrex and he did end up tinkering with this setup, still at it from his last communicaton.
After quite some time later I became interested in the serial port again as a means to implement a vector terminal: in the 1970s there existed (astonishingly expensive and powerful for the time) vector terminals for supercomputers of the day. The Star Wars Death Star attack sequence in the 1977 movie for example was created using a vector terminal hooked up to a PDP-11/45 (recently restored, very heartwarming story; more info e.g. via youtube: ‘Restoring the Machine that Destroyed the Death Star | VCFMW 2019’).
Right away it became evident that for the receiving end to be as performant as possible the receiving cart. should not store and redraw vector data but would act as a display processor with its own opcodes and the computer side needs to redraw the frames, if necessary. The ‘vector terminal’ implementation therefore is conceptually split in four parts running on three processors: an application generates vector data in normalized float format for a generation layer which then creates vectrex stream data for a frame. A separate display thread constantly sends over the current frame data and receives synchronization and measurement info. from the Vectrex. And on the Vectrex the ‘vector terminal cart.’ pretends to be a display processor.
This conceptual split between application and display thread is quite useful: the application does not need to consider itself with any side-effects or intrinsic minutiae of the display; it just creates frame data at its leisure and hands it over to the display thread. The display thread does all the heavy lifting. So a useful and somewhat easy to use setup for vector-based applications to hook up to the Vectrex.
Audio data and LED values are also sent to the Vectrex, buttons and specific measurements (digital or analog joystick axis data) can be asked for per frame and are sent back. This approach turned out to be excellent – it not only was fast and stable: it comes quite near to the maximum amount of vectors the Vectrex is able to display at all anyways. And the maximum is approached when using around 1 megabaud of communication via serial. Perfectly matched to the uart, too, since current uart-usb pcbs support 921kbaud reliably on several OSes. The abstraction layer between the application and the actual vector output also meant that there were several useful things that could be handled quite easily. Esp. calibration of the x/y axis zero values and (part of) the nonlinearity of the DACs.
The very first application that had to be adapted of course just had to be MAME: this ‘VecMAME’ can mirror the output for vector arcade games on the Vectrex. Optionally these games can also be played using the Vectrex controller.
The intriguing and already pretty great output via VecMAME on the Vectrex turned out to be a blessing and a curse: it showed me what was possible with the Vectrex – and how to perfect it. Perfection necessitated to create unique emulations for absolutely every single arcade romset since VecMAME showed the way: create a streamlined display processor backend for each game. With hand-coded vectrex graphics code, the fastest possible emulation possible and optional changes to the games drawing pipeline to stabilize the output and/or increase the refresh rate this could be run perfectly even in the ‘spare time’ of the VF. Sounds insane, I know. Yet that was the path I chose and 40+ arcade romsets later the results are in each case definitely superior to any generalized emulator. In most cases by quite a margin and now almost all can be run in Vectrex-native, portrait mode, too: separating overlay, texts and game parts allows the reshuffling of the gfx to any aspect ratio and mode now. Digging into the innards allowed more vectors to be teased out of the code, if necessary and wanted at all, to display in the otherwise upper/lower parts of the Vectrex display.
In fact I like this what I call ‘hybrid’ Vectrex cartridge setup so much both for flexibility, performance and ease of use that I decided to write an entirely new firmware -version 2- from scratch based on the same design. So here again both the Vectrex CPU and the VF ARM CPU also work in a dual-cpu setup to get the absolute maximum out of the Vectrex, just like all the emulators. But now at the very top of the food chain – as the OS supporting everything. And it may be interesting to note that internally the setup of the vector terminal is still present both as the backbone of the v2 firmware and of all hybrid applications – only now everything is running directly on the VF.
I was quite ecstatic when I first saw the output of the VecMAME vector terminal output – an unprecedented glut of nice vector visuals on the Vectrex after all – that I for once did build a few cart. and handed them out to friends to try out. Reception was as usual -with two exceptions- not even lukewarm, I usually never hear back from anyone. Still, I liked this capability so much that I even decided to bite the bullet and manually build a handful of ‘ultimate editions’ with the additional uart pcb. This turned out to be majorly depressing – most I’ve given away or traded for arcade things which when I received them were either broken or way below description.
Which is why the second incarnation – a VF ‘Mark II’ 128MB cart. with a RAID flash setup – is not out there, I think I only offered one to a stranger, a Californian in the Bay Area at the tail end of me really coming to terms with all this nonsense. And a few friends got one which is why most of the very best VF built so far are still in my backups pile here (and I only made 10 anyways and dismantled one for some testing), just looked around and found most: the lowest right is the original version, the serial moved to the side for the vectrex stand on the ‘ultimate’: the last, best version of the initial version made.
