Development

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 is 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. Depending on the hardware present in a vf there are two different routes for a fast. dev. cycle:

Using a usb connection the vf 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. Using a serial connection a small tool on the computer sends over a ‘v4e’ file and when the file is received it is automatically started. 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.

This fast upload specifically includes apps using the runtime library/environment for native and hybrid applications so these types of ‘cartridges’ can be uploaded for immediate testing, 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 VF with USB can export the entire volume 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).

Please Note: for the gamer pcb only the serial dev. mode is -optionally via expert option- accessible.