The first application using the Vector Terminal was an adapted MAME version – a regular MAME with some additional code added to mirror output via the Vector Terminal on the Vectrex plus to be able to use the Vectrex controller as an input device for those games. Still an excellent application to test the serial port connection of the vf. but also allows to play the arcade games with the original audio (emulated or using samples) albeit having to use a computer to do so.
As you may know even basic innards of MAME do still change and look nothing like regular code but are more of a macro-/declarations-fest and changing one of the basic ones necessitates to adapt a gazillion source code files. Which seems to happen not infrequently. For VecMAME this means that the vector screen duplication could quite likely stay portable/updateable for quite some time into newer MAME versions but the input adaptations are not. When I was working on it I also saw a few dispiriting bugs – both years old and documented ones, like Tempest vector problems or SEGA V80 cpu issues, or new ones popping up like Star Wars ESB not working – even though noone was working near these source codes, just adaptation side-effects. A bit sobering, that, or rather good to clarify expectations towards what to expect: I believe there was never an automated QA setup for MAME builds implemented early on and by now it is such a massive, all-encompassing emulation that implementing one now from scratch is just way too much hassle, really. Or rather, it is definitely so much of no fun whatsoever that noone is masochistic enough to tackle this.
At least that is what I got out of the experience, so settled on a build and fixed whatever needed fixing myself there. For once I also borrowed a Windows notebook back then and tested and compiled a Windows version (thanks, KiWi!). The zip includes the entire MAME setup for macOS minus the romsets as usual – the additional files are just the 32/64 bit binaries for Windows. Getting the VF part up and running – if you have a VF with serial port already setup – basically means specifying the serial port to use on your system via the MAME text files or command line parameters. Default setup in the zip file is for macOS and a Silabs uart-usb chip at 921kbaud, for Windows the actual ‘port’ used is shown in the Windows driver itself, if memory serves.
First: this text assumes that you are already familiar with MAME itself. The 'Vector' MAME can use a Vectrex as a terminal via a serial connection to a VecFever cart. with a secondary, dedicated serial port. Besides this it's just a normal MAME but for vector machines MAME tries to open a serial port and if successful tries a handshake via this serial port with the 'vector terminal' cartridge running on the VecFever. Again, if successful, all vector data is mirrored on the Vectrex side. To set this up several things need to be done initially: 1) A device driver needs to be installed for the serial chip, at the time of writing I've used a CP2102 and the SiLabs drivers can be downloaded directly from their website for a large variety of OSes https://www.silabs.com/products/development-tools/software/usb-to-uart-bridge-vcp-drivers 2) The port and baudrate to be used for MAME needs to be specified. MAME is compiled to use 921600 baud, 8N1, and searches by default for the correct serial port on OS X and tries to open COM4 first, then COM5 on Windows so if these are used under Windows nothing needs to be done. To set either port or baudrate manually two new options were added to MAME, either via commandline or mame.ini e.g. an entry for OS X in mame.ini could be: # # CORE VECTOR OPTIONS # vecterm_port /dev/tty.SLAB_USBtoUART vecterm_baudrate 921600 beam_width_min 1.0 beam_width_max 1.0 beam_intensity_weight 0 flicker 0 And for Windows e.g. a COM4 path would be: \\\\.\\COM4 3) The baudrate (and 8N1) needs to be set on the VecFever to the same value 4) Now MAME should be able to connect to the terminal, the next step is improving the visual output. The terminal's options page can be entered via button 2:/3:/4: when it is waiting for a connection. There you will find a 'calibration' option consisting of two pages: the first is to set a parameter to improve 'drift', the change of vector segments over time. The second for the width and height of the output and the offset for the center. The important thing here to know is that even when the calibration pages are displayed MAME can connect to the terminal. In that case one can still change the params while a game is displaying and immediately check the parameters. For 'drift' one place to check for example is the BattleZone score display. The first zero is drawn independently from the rest and usually there's a vertical offset. With the 'drift' calibration parameter this can be corrected. For size/offset Cosmic Chasm is a good test subject for a general setup. 5) The last step is optional: a lot of the games can be played using the Vectrex controller(s) but this has to be specifically enabled. This is mainly due to the analog joystick and spinner/paddle emulation using analog values: digital joysticks and buttons can be put 'in parallel' with the normal MAME input but for analog values one or the other needs to take over. Since for the Vectrex analog joysticks the zero position is hardly ever measured at zero (not even near for a lot of joysticks after decades of use) when on the input page the joysticks are measured and the zero values displayed. These are used to offset the measurements afterwards to improve the handling. This means that the joysticks need to be untouched when it is enabled by pressing 4: If you ever open up your controller to fix a button please do remember to also check the potentiometers - the 'joystick test' option in the vecfever menu can help with this since it displays the actually measured values all the time