VecFever documentation
Arcade Romsets
The VecFever runs versions of all the 8-bit arcade vector games natively meaning both on the cart. itself and also with managed input and output to convert them into or rather pretend them to be Vectrex games and hide some of the arcade heritage like coining up. To be able to do so for each and every arcade game the software for these games, the ‘romset’, was translated into a functional equivalent natively running on modern hardware which also straightforwardly allows adding options or game-state dependent handling, e.g. to map a multitude of cabinet inputs onto the few of the Vectrex controller depending on game state.
However, these translations do not include the necessary data for the arcade games for a simple reason: the copyright of a lot of these games even after all those decades is at best unknown. But in some cases they are definitely still marketed in some newer insubstantiation, esp. by the current Atari copyright owners. And it is my understanding that legally in a few places, e.g. in the United States, companies not enforcing their copyright can forfeit it which means that companies like Nintendo (esp. Donkey Kong when it comes to golden age games) or the Atari copyright holders have a strong incentive to go after anyone trying to keep their original games alive.
So the VecFever when trying to start an arcade game binary needs to load the software data from the original game pcbs to generate the playable game. These arcade game pcbs – you can think of them as custom computers build for a specific game – hold that data in EPROMs or masked ROMs of the time. For example for Asteroids there are three ROM chips for the 6502 CPU code and another one for the DVG vector generator:
The multiple arcade machine emulator – better known simply as ‘MAME’ – always had the same problem to deal with and so never included game data. It was initially created both for emulation but also archival purposes for data of arcade pcbs for emulators and also repairers of original hardware. The distinction archival/repairer <-> emulation may not be as strict as one might think, e.g. initially for quite some time the Asteroids digital vector processor – which conceptually is a discretely build cpu running a microcode defined by programmable logic – was emulated functionally and not the microcode itself. But eventually MAME improved this to a deeper, clock cycle accurate emulation nearer to the discrete logic, using the data of the programmable logic chips.
So ‘MAME’ romsets – the de-facto standard – are usually sets of compressed files of everything on the pcb, including unused (by emulators) pcb chip data and sometimes also texts or other unnecessary files. To make matters more interesting MAME has been developed for many decades by now and in that time the file naming convention and necessary files did change. In some cases the chip ‘dumps’ used were incorrect and it took a while for a valid copy to become commonplace (e.g. Lunar Lander). In a lot of cases simply the filenames changed from an 8.3 characters DOS-style naming to longer filenames which could include additional info., like the location of the dumped contents on the pcb.
All of the above is to explain the underlying process to better understand what is going on: the games need data to start, the contents of specific chips on the arcade games, and that data is usually very easy to find but needs to be available in a certain way.
So how does the VecFever load these romsets ? At first it tries to load a specific romset zip (identified by a specific filename, checksum and size) from the /System/Data/ folder. If this fails it tries to load the necessary contents uncompressed from the /System/Data/xyz subfolder for the game, using the current MAME filename definitions. If unsuccessful it will show a complete list of what it could load successfully and what is missing or corrupt/incorrect.
So let me explain this using Atari’s ‘Star Wars’ as an example: at first the system tries to load the file /System/Data/STARWARS.ZIP (documented as: md5 checksum / filename / file size):
71B35081E4E37F98250FD8AA4588914C STARWARS.ZIP 46602
and if not found the necessary contents in the /System/Data/STARWARS/ subfolder:
6237089E81A9702CA86A948C61EC68B7 STARWARS/136021.105 4096
A21B39AF0D62E7FDA61FD8AFB18CC976 STARWARS/136021.214.1F 16384
2CE8FE455ADFE2F3AA00F2E9A49C278C STARWARS/136021.102.1HJ 8192
8BE5173EBD3BEC79426D0645202A5BB9 STARWARS/136021.203.1JK 8192
CF561A852CA54BAFBB3C3D519826E804 STARWARS/136021.104.1KL 8192
363BF1440ACEC80F1C013B770C0A032E STARWARS/136021.206.1M 8192
547A09CD77A30CA361658ADE1245FEFB STARWARS/136021.110 1024
9C1E2A5AC007D840012FD847ED4F6EB3 STARWARS/136021.111 1024
35DB9517074B7BA2621F3FA4D15298AB STARWARS/136021.112 1024
61A1CC6A7081C5BA2266B8EC38536FA7 STARWARS/136021.113 1024
these filenames are defined by/grabbed from the latest MAME source code. However, filenames in a given MAME ‘STARWARS.ZIP’ downloaded from wherever frequently are for an older MAME version – e.g. like this:
$ ll /Users/thomson/Downloads/starwars
-rwxr-xr-x@ 1 thomson staff 256 24 Dez 1996 136021-105.1l
-rwxr-xr-x@ 1 thomson staff 8192 24 Dez 1996 136021.102
-rwxr-xr-x@ 1 thomson staff 8192 24 Dez 1996 136021.104
-rwxr-xr-x@ 1 thomson staff 4096 24 Dez 1996 136021.105
-rwxr-xr-x@ 1 thomson staff 8192 24 Dez 1996 136021.107
-rwxr-xr-x@ 1 thomson staff 1024 24 Dez 1996 136021.110
-rwxr-xr-x@ 1 thomson staff 1024 24 Dez 1996 136021.111
-rwxr-xr-x@ 1 thomson staff 1024 24 Dez 1996 136021.112
-rwxr-xr-x@ 1 thomson staff 1024 24 Dez 1996 136021.113
-rwxr-xr-x@ 1 thomson staff 8192 24 Dez 1996 136021.203
-rwxr-xr-x@ 1 thomson staff 8192 24 Dez 1996 136021.206
-rwxr-xr-x@ 1 thomson staff 8192 24 Dez 1996 136021.208
-rwxr-xr-x@ 1 thomson staff 16384 24 Dez 1996 136021.214
-rw-r--r--@ 1 thomson staff 730 19 Mai 2014 readme.html
and trying to start the game loading these files is not going to work – the romset contents are actually all there but the filenames do not match correctly. But it is easy to see what matches what just by the filenames – and it usually is that simple just by filenames and filesize. And when in doubt the necessary checksums, filenames, and filesizes needed are documented automatically for each and every game when building a firmware and are part of a firmware update – in an ‘md5_info.txt’ file.