V4E File Structure

The VecFever supports a file structure geared towards a low memory footprint which at its most basic is a simple checksummed and compressed container structure. Plus it defines what is stored inside – sliced into data blocks of up to 32KB. The advantage from a Vectrex cart. hw point of view is that this defines the hardware which needs to be created/emulated – e.g. 8KB ROM with a bit of RAM inside of cart. space for Animaction w/o bank-switching, or 4x48KB for Vectorblade using both VIA6 and IRQ to switch four 48kb banks.

Additionally this allows to add any necessary data loaded by a cart. to be just included as additional blocks of data and loaded manually afterwards – the 6809 audio & video players or the apps can load any data included afterwards whenever needed this way. And additional features can be added inheriting compression, lower memory needs and at least basic robustness due to checksumming everything – e.g. for vym data, apps or firmware updates a native path is used to support these files.

The ‘serial’ development capability – to upload data to be tested instantly – accepts only this v4e file format. So the data sent over is verified using the checksum per block plus it allows almost any amount of data to be sent due to the convenient max. 32KB sync. points per block. Sending native apps is more intricate – these are additionally secured and need meta-data to link against the system – but 6809 code is straightforward: create a v4e file and use a tiny tool to handshake with the vf in serial dev.mode and hand over that v4e data.

I myself use macOS / Unix so as a starting point for others pasted together all the basic, necessary code into a small and self-contained source code file for a unix tool. This can create a valid v4e file for a given 6809 cart. as input and store it or send it via serial to the vf. Upload-wise this is more to document the handshake and upload mechanism and less a guaranteed tool to work: for other OSs like Windows you would obviously have to substitute the hw code but even depending on the Unix/macOS and serial hw used the delays might need to be slightly longer, depending on the latencies. If you have trouble getting it up on Windows let me know – the Vector Terminal serial handshake used is similar so that Windows code might be a good starting point but I have no way to test this here since I have no Windows system.