The VecFever was specifically created as a flexible base for development of vector games and applications. The underlying setup at least from a hardware perspective not fixed but adaptable and can and has changed or added to or improved upon over time for specific environments.
So, what does this flexibility mean, really ? Initially it meant that the vf can present as any kind of ROM, or a ROM with RAM in some parts, or entirely as RAM preloaded with data. To be able to communicate with the menu and (tinier back then) vf operating system there was also an extension added (e.g. to load/store data or set the LEDs) for 6809 cart.
Over the years several ideas were tried out for additional capabilities and/or specific features. For example optional 6809 registers and a ring buffer for fast serial communication were implemented (still used for e.g. a 6809 MS basic cartridge or a vector terminal cart.). So besides handling the rom/ram necessary in the cartridge address space it additionally pretends to be a serial communications dma chip here for the 6809. Different cart. adr. spaces have been added. Loading of ‘massive’ amounts of data (audio/video player) implemented. Lately ‘hybrid’ features have been added: here the VF cpu runs in tandem with the 6809 to maximize the performance in a dual-cpu setup, both only in-sync when necessary.
For rapid testing on real hardware the vf can be hooked up to a computer while running in a Vectrex and put into a ‘development’ cycle. In that mode it at first exports a small ramdisk, always initially empty when exported, so that a ‘CART.BIN’ can be transferred by just copying it on the ramdisk. When the volume is ejected (or button 4: pressed) this cart.bin is executed. The Vectrex start page can be skipped optionally, too, so testing can be immediate after compile/assembly. Pressing the reset button or using an optional exit function in sw exits the cart. and gets back to the Ramdisk stage for the next test. So testing can be very rapid – esp. useful when testing or fine-tuning cycle dependencies in custom graphics functions.
All of the above were already in the first firmware but as of firmware v2 the focus changed and the dev. setup expanded quite a bit, even though hidden below the surface. The reason for this is simple: the v2 firmware includes a new runtime library/environment for native and hybrid applications and these types of ‘cartridges’ can be uploaded for immediate testing now, too. The setup allows everything from custom helper code for normal 6809 cart. up to completely vector hw independent applications where the vf library takes care of the entire hardware input/output handling. I myself do not think of these as cartridges anymore – they are applications running on the VF, most just loaded into RAM and executed there, interacting with the OS via an abstraction layer.
Besides the RAM disk mode all VF also can export the entire disk temporarily to upload data – the RAM disk has a size restriction of 64KB (can be a compressed v4e but still only 96kb uncompressed) – so this way one can upload and test larger files and/or necessary data (localization text files for example). The few VF with additional, dedicated 2nd ‘serial’ usb port support a ‘serial mode’ which also supports upload of larger binaries immediately via the serial connection.