VecFever FAQ

VecFever FAQ (v1.14, 11th May 2019)

  • What is the VecFever ?
    1) the basics
    2) slightly more technical explanation
  • How do I start using it ?
  • Which cartridges are pre-installed ?
  • What are hybrid cartridges ?
  • Can I automatically run a cart. upon start ?
  • I’ve copied everything over but some files seem to be missing – is this normal ?
  • Can the firmware be updated ?
  • What’s the directory structure used ?
  • What are MAME ROMs ?
  • What’s the Volume Info. option for ?
  • How many menus are there ?!
  • How are high score tables for old games implemented ?
  • What is tournament mode ?
  • How do I reset hiscores for a game ?
  • What is the joystick option for ?
  • Isn’t there a VecFever with 3-color LED, too ?
  • A serial port for a Vectrex ?!
  • Any other versions of the VecFever around ?
  • Can I connect the VecFever to a computer via USB while it’s in a Vectrex ?
  • Why is the used space on the volume (so much) larger than the data put on it ?!
  • What is the V4E file format ?
  • What are .DS_Store and other .* files for ?
  • Are there standalone cart. of the games ?
  • Robot Arena/The Core: what are these joystick options ?
  • Rocks Deluxe: what is ‘Drift Improvement’ ?
  • Emulators: how do I improve the graphics output for a given Vectrex ?
  • Emulators: what does the ‘graphics boost’ option do ?
  • Red Baron: why is the joystick response wrong ?
  • Red Baron: why is the LED blue frequently ?
  • Tempest: what are the input options exactly ?
  • Bad Apple: is it stuttering ?
  • Developers: VecFever features
  • Developers: load/store feature
  • Developers: cartridge hw possibilities
  • Developers: other cartridge hw. available
  • Developers: faster text
  • Developers: what is the multibank option for ?
  • Developers: what is the VecMulti emulation option for ?
  • Developers: how does the ramdisk operation work ?

What is the VecFever ?

1) the basics
The VecFever is the culmination of several years of development to build a modern hardware base that is
flexible and allows the development and easy use of all Vectrex cartridges that are available in binary form.

To do this the basic operation revolves around these main features:

  • the VecFever has a USB connection and when plugged only into a computer it presents itself as a 16MB drive
  • the menu includes a file browser with which the user can find/select/start any cartridge copied onto the drive
  • at any time the user can press reset and get back into the menu

and specifically for developers:

  • immediate upload of new cartridges via a USB-ramdisk mode or a serial mode for larger binaries

2) slightly more technical explanation
At it’s core the VecFever uses a (small) operating system that always supports two cartridges at the same time:
a privileged one (‚the menu‘) and an application one – any cart. loaded and started by the menu.
When loading a cart. the OS determines the needs for a loaded cartridge and sets up the relevant
‚bus hardware‘ necessary before starting it. Additionally, there are several new modes
which allows accessing new features like loading/storing data if the cart. is VecFever-aware.

How do I start using it ?
The VecFever comes already fully set up. When starting the very first time in a Vectrex you
may or may not see a weird text output: this is due to the fact that it uses an extremely fast
text routine that needs to be calibrated for a given Vectrex. To do this you need to press 1:
to enter the options – you will see either a ‚Calibration‘ option (in the normal menu, enter with 4:)
or a ‚Font‘ option (expert menu, enter with 4: then enter ‚Timing’ with 4:) and then you can
switch between ‚heuristic/zero/one/two/three‘ by moving the joystick left/right. Press 4: again
to confirm. That’s also already the operation explained, it is always:

1: go back/cancel
3: show high score table(s), if possible
4: start/confirm

throughout, and in the options most of the time you switch options using the joystick left and right.
The only thing I’d like to note is that when entering a specific option entry the entered state is
stored and when you press ‚1:‘ to cancel any changes are reset to this previous state.
There’s no ’do you want to cancel’ reminder so initially you might be wondering what happens if option
changes don’t ‚stick‘ by pressing ‚1:‘ to exit. If this is too confusing for some people I might
add additional warnings throughout..

Which cartridges are pre-installed ?
The VecFever was specifically built for myself as a development system and all my finished games
are part of its firmware: 2048 Deluxe, Head On, Robot Arena, Rocks’n’Saucers, Rocks Deluxe and ‚The Core‘.
These games appear on the initial ‚ROM‘ page together with ‚Minestorm‘ which lets you play the Minestorm
in the ROM of your Vectrex. Since v1.14 I’ve also developed a dedicated Tailgunner emulator which
also resides in the ‘ROM’ page.
On the disk are also my test cartridges for the multibank extension: a music player (using plenty of
32k banks), the tiny 4096-byte version of 2048 and the ‚Bad Apple Video‘ – a video player using a
vectorized ‚Bad Apple‘ video stream.

My games are normal Vectrex games, btw, just using the VecFever extensions to load/store (and use
the LED). I’ve also made a few physical cartridges of each and every one using a 1-wire chip
to load/store.

What are hybrid cartridges ?
Since Firmware V1.15 the VecFever supports an entirely new cart. type called hybrid cartridges.
Here both the 6809 in the Vectrex and the CPU of the VecFever work together in a dual-cpu setup.
To maximize things I can do with this setup the VF-CPU-code is not held in RAM but is flashed into an
internal buffer, if necessary. This allows for much larger binaries and the maximum available RAM for
those binaries at the same time. I’ve also built a stripped-down version of the VF so that I can create
standalone hybrid cart.
The current max. is 512KB for the VF-CPU code, 64K for the 6809 and 32MB additional data
which can be loaded at runtime (all of this is stored compressed).
Overkill, of course, but plenty to play with in the future. Overkill is underrated, anyways.

Can I automatically run a cart. upon start ?
Yes, starting with v1.15 if a file named ‘autostart.bin’ is found in the root folder it is
loaded and started even before the menu. The ‘Reset’ option is also (temporarily) set so that a
reset stays in the cart. and doesn’t switch back to the menu.
So by using this feature the VF can present as a dedicated cart. for a given vectrex binary, e.g. useful
for public meetings where it can be left unattended to show a specific cartridge.

If the autostart.bin is not recognized as a valid cart. it is substituted with an ‘error’ cart which
displays a short error msg. and then switches to the menu.
It’s important to note that the menu/os system is setup but not used in front of the autostart.bin.
This means that a developer can test a binary w/o any 6809-interaction by the VF using this feature.
Functionally it is identical to burning it into an eprom.

However since the OS/menu is initialized v4e-aware cart. can also work – esp. load/store of options/scores
or the fast menu-switch still works which means that a v4e cart. which jumps back into the menu can exit this mode.
Multibank cart. are not supported (jukebox, bad apple video and firmware updates) and are ignored.

I’ve copied everything over but some files seem to be missing – is this normal ?
The menu entirely runs on the Vectrex and has serious memory constraints – due to this
I’ve limited the displayed entries in a given folder to 127. So yes, this is probably normal.
You can always just create one or more folders and organize them a bit..

Since I rewrote parts of the menu code for v1.09 I’ve doubled that limit in principle, if the memory
doesn’t run out. However, if every displayed filename is of max. length only around 210 can be displayed
in the dev. menu.

Can the firmware be updated ?
Starting with v1.05 a capability to update the entire firmware has been added – the update file
is a Vectrex cartridge with the firmware as a payload so it is started via the menu.
Once started it will load the entire firmware to both check it and compare it to the current
one installed. If indeed valid and different from the current one you can flash it:
it will first once again load the entire firmware, store it to a secondary place and check it one last time.
If this ‚pre-setup‘ still checks out it allows you to finally flash the VecFever firmware itself.

What’s the directory structure used ?
the file structure on the device is simply:

/MENU.DAT if present, the used menu (otherwise the default one in the firmware is used)
/BUFFER.DAT a 1 or 2MB buffer used as storage for all cartridges
/ROMS/ the vectrex roms folder, the top level on the Vectrex side
/MAME_ROMS/ the necessary ROM files folder for emulation cart.

with a few cartridges in the roms/ folder that use the v4e extensions initially.
The ‚BUFFER.DAT‘ is a rather special file: it’s actually not used as a simple file but as
a container from the Vectrex-side bypassing the filesystem so please don’t move it around (or remove it).
You can’t break the system but might loose the data in the BUFFER.DAT – when moved it might need
special treatments both for alignment reasons and not to trip the protection layer for the score data.
The VecFever might think you want to cheat.

What are MAME ROMs ?
The MAME ROM files are the same as the ones for MAME (I am using v0.194), the
‘M’ultiple ‘A’rcade ‘M’achine ‘Emulator’. These are zip files which include all necessary
dumps of the actual chips of the arcade games needed to emulate the game itself.
My own arcade emulators are – also for legal reasons – always split into an emulator binary
(.v4e) and the necessary data needed for those emulators (.zip). The emulator binary
is a VecFever binary and can be put anywhere in the ROMS folder. When started
this emulator searches for the necessary zip(s) in /MAME_ROMS/.
Since MAME evolved over the years there are frequently older versions of those ‘mame roms’
around, e.g. llander.zip has been updated ‘recently’ (I think some language data was faulty before).

The zip files used are checked for length and consistency first (mainly to greatly simplify
the loading procedure – I am under serious memory constraints) and the MD5 checksums and sizes are:

    ASTEROID.ZIP        16bdd4303cf3c49236766bc4d140720c    7264
    ASTEROID1.ZIP       0cb56332b97eaea721c2eb9def2194ca    7029
    ASTEROID2.ZIP       5b0be1994e788a1f99937054a9e5c9d6    3610
    ASTDELUX.ZIP        320ddf104d95325a9223a3127189e0e0    10848
    BZONE.ZIP           c7dbc59d239e1a35341d4646475c994d    14534
    LLANDER.ZIP         d1c008bc919e555fb3c7be79fd1d6eb0    11523
    REDBARON.ZIP        22c6a84764894d11ebeef630dc052796    17347
    SPACDUEL.ZIP        76e8b24bb776fb378c103f8288f7b0a1    20209
    TAILG.ZIP           7f52d5fba9c1ea468ac950be816e6682    7969
    TEMPEST.ZIP         04877aa818facef77e0fdc42eab61f6c    20581   (rev3, revised hw)

For Vortex – which is not emulated by MAME yet – I’ve used the zip file hosted on http://www.andysarcade.de/tempest.html :
VORTEX_ROM.ZIP bec2edcf1785fe03dbd41427a50286a6 23196

When you start an emulator you will get a ‘ROM xxx not found’ error message from the emulator init. if
the rom file itself is not found. If it is loaded but the checksum wrong it will display a
‘rom invalid’ message.

Please note that I do not supply the necessary ROM files myself for obvious reasons.
Also: MAME rom zips do change infrequently over the years, I probably have to update the emulators
to use the latest every once in a while once the used romsets are harder to find..

What’s the Volume Info. option for ?
Apart from identifying the flash ram used for the usb volume it displays the max. amount of contiguous blocks
in the BUFFER.DAT file – the part the OS can use in the buffer container. If a BUFFER.DAT file is added
at a later time when the volume is fragmented this size might fall under 1MB – the lowest size where
the buffer is used.

How many menus are there ?!
In the moment only two flavors – the simplified version that is installed initially and an expert version
that exposes a lot more options. The basic one currently has these options:
-Calibration
-High Scores (simplified version, just on/off)
-Menu Mode
-Minestorm
-Version
-Volume Info

whereas the full version has the full high score option plus:
-Development
-Font
-Joystick Test
-LED
-Multibank
-Password
-Reset
-Screensaver
-Serial Port (only if one of the very few with extra serial port)
-Switch Options
-VecMulti Emulation

An expert menu is the default menu of the firmware itself but if a valid ‚MENU.DAT‘ file is found on the drive then
this one is used instead – when initialized the simplified menu is copied here.
So if you want to see/use the expert version simply delete or better rename the MENU.DAT on the initial setup.

What’s the ‚Calibration‘ option, really ?
from a programming standpoint it is a specific delay in 1.5MHz-cycles for data to appear when ‚printing‘ text.
This is not dependent on the BIOS version, it depends on the motherboard and esp. the 6522-VIA
used. However I’ve seen some delays more often with certain BIOS versions so the ‚heuristic‘ option
uses these more (?) common values based on the BIOS version detected.

How are high score tables for old games implemented ?
For a list of games the OS includes the patches to convert them into versions that add a hiscore table
with 8 entries for each game mode: the changes for each and every old game were created in a way
that it is added seamlessly into the game, just as if it had been made back in the day.
Specifically, the changes are all outside of the actual gameplay but always in the ‚end‘ code so that
highscores are all identical to the non-patched games: it displays a ‚new high score‘ text and enters
a high score entry page, afterwards displaying the changed high score table.

This is relatively straightforward but at times a bit complicated: there have to be high score tables
for each game mode since a score for say, Scramble in normal mode, is not comparable to Scramble
at ‚hard‘. Equally some games may not use scores but times and two player games have to be handled,
too. In essence this means that some games (can) use a lot of high score tables, up to 16.
Only the ones actually changed are stored, though. The game will always show the hiscore table
of the current game mode, if it has an attract mode, but the menu will only display the actually stored
ones, with the latest updated one first.

The cartridges that are patched, if enabled, are:
Armor Attack, Berzerk, Berzerk debugged, Bedlam, Clean Sweep, Frogger, Gravitrex, HyperChase,
Moon Lander, MineStorm 2, Fortress of Narzod, Pole Position, Rockaroids Remix, Rip Off, Scramble,
Space Frenzy, Spike, Spinball, Star Castle, Solar Quest, Star Hawk, Star Ship, Star Trek, Verzerk,
Web Warp, Web Wars, Wormhole

Additionally, Thrust’s 1-wire load/store routine will be substituted with a VecFever version.
You need to use the exact, unchanged binary for the game in question, a changed one won’t work.
So no cheating by adding more lives.

How do I change the hiscore entry page ?
In the expert menu there is an ‚entry mechanism‘ option where you can select a few different
hiscore entry pages, cycling through them by using 2: (go back) and 3: (go forward).
You select them by entering an initial and confirm with button 4:

‚Classic‘ and ‚Amiga Years‘ uses only digital joystick measurements so are also suitable if you
use digital joysticks, the ‚box‘ and ‚ellipse/circle‘ versions however use the analog joystick
of the Vectrex.

What is tournament mode ?
On top of ‚normal‘ hiscore tables, which are permanent, the VecFever allows the use of a temporary second
set called ‚tournament mode‘ – enabled by entering a 6-character tournament code that will be displayed in
these tables. The tournament tables are still stored on the VecFever but upon disabling tournament mode
all these stored tournament tables are deleted, reverting back to the non-tournament tables, which cannot
be deleted globally.

How do I immediately see the current hiscores for a game ?
By pressing 3: in the menu the hiscore page will be displayed, if it’s either one of the games
that can be converted or if it’s a VecFever-aware game that supports direct hiscore entry.
The convention is to show the hiscore table that has last been changed first and to switch
between tables, if there are more than one, with joystick left/right.

How do I reset hiscores for a game ?
When displaying the hiscores via the menu for a specific, patched game (via button 3:)
you can press 4: to reset all Highscore tables for this game, if not in tournament mode.
In tournament mode the normal tables are protected from reset.

What is the joystick test option for ?
This option is useful if you happen to have the joystick open and want to calibrate it (and can read hex).
It can also be used to check positions for a ‚7F‘ scale move to a certain point after a zeroref.

Isn’t there a VecFever with 3-color LED, too ?
Well, this changed over time – originally I really didn’t want to build them with LEDs and this
was added literally a few hours before ordering pcbs at one time as an afterthought. The very
first prototypes don’t have this. However, even though it’s more work for me since I have
to adapt all shells and put in those LEDs at one point I’ve decided to always add them now.

—original text below—
The first VecFevers professionally built had a LED placed on them almost as an afterthought to be able to
easily see what’s going on in USB disk mode and for general bringup debugging – the connections used for
the LED were really meant for tinkering with other hardware. However, I toyed with them from the Vectrex-side, too,
to see whether they could be used for anything – I was specifically curious how fast I could switch them on/off
to try to get a wider color range to use in the Jukebox. Even though the time-slicing in Jukebox works quite well
I kept thinking that it’s just a gimmick and not worth the effort (and still do). However some people seem
to like this and I grudgingly agree that in certain environments, for me esp. in a transparent case on
retro meetings, it does look nice so I’ve kept the support in the firmware and all VecFevers so far were
built with the SMD-resistors for the LEDs already in place.
One useful thing the LEDs do show is the state in USB disk mode: green when idle, blue when ejected,
cyan when reading, red when writing and magenta when reading+writing.

A serial port for a Vectrex ?!
My debug setup uses an additional serial port so at one point I thought it might be a neat idea to
make this port available to the Vectrex, too. This is done by a dma-like mechanism
for receiving and simple, immediate transmitting (the uProc status/transmit registers are directly mapped
into the Vectrex space for this) since that’s all that was needed for all the cases I’ve tried so far.
This was implemented as a feature for Vectrex cart. to communicate with the outside
world e.g. using a keyboard this way or input/output via serial for say a 6809 Basic or Forth or
simply for debug output.

After a while (over a year, actually) I thought it would be a nice project to see what kind of performance I could
get using this serial for a terminal setup – receiving all gfx data via serial and only displaying things and
sending back measurements so that the entire app/game/demo can run on something else.
This turned out better than expected so I’ve spend quite a bit of time testing/tinkering/improving this ‘vector terminal’.

Any other versions of the VecFever around ?
Besides specific variants of the release VecFever – like the one with serial port or ones
that drive LEDs in marquees I built for my games – the current release version
is the fourth incarnation of the VecFever pcb so far. The 3rd version differs mainly in the location of the
holes (slightly off) and has no serial port but uses the same firmware – and a few made it to friends/developers.
The 2nd version is markedly different, smaller and hand-built and uses a ‚PROTO’type id, also needed a slightly
different firmware. Three were built start of 2016 and used for quite a while.
(Starting with v1.09 I’ve also added all necessary code to the current firmware to support these boards and
updated one of them to test this.)

The very first version which I’ve used to develop the initial firmware and most parts of Robot Arena
is not a pcb but a bunch of stuff hooked up together by many wires (carefully..).
I’ve built two setups – one specifically only to develop 1-wire code back then – and both still work and are in
occasional use.

Lately I also tried out a modification for the release VecFever since VectrexMad! nudged me to do
this several times – hooking up a real time clock with battery. As of bios v1.09 this is implemented but
only enabled for a few specific ones for testing – on those the menu has an additional clock menu mode
and takes over the vecfever startup screen displaying a date page if the ds3231-rtc is detected.

Can I connect the VecFever to a computer via USB while it’s in a Vectrex ?
Yes, when the VecFever starts it detects where it’s powered from and starts accordingly.
It can also be powered at the same time via USB and via the Vectrex. In fact, you have to hook it up
to a computer when it’s alive in a Vectrex to enable the development mode Ramdisk…

Why is the used space on the volume (so much) larger than the data put on it ?!
Very likely due to the OS creating plenty of invisible files; macOS for example will try to put a 4K invisible
file for each and every binary you put on it. You can use ‚dot_clean‘ from a terminal to scrub
all those files to free space once it gets full (type ‚man dot_clean‘ in the terminal if you need more info.
on how to use it).

What is the V4E file format ?
Cartridges do not need to be in the V4E format to use the VecFever features in general, except if they
use more than 2 banks: the v4e container format holds data for any no. of banks of a Vectrex
cartridge. All banks are stored compressed and checksummed.
However in contrast to normal dumped binaries the format also specifies the underlying hardware
for the bank data and can be used for just one or two banks, too, to either specify the properties
(e.g. ROM-only or with RAM) or decrease the filesize a bit for larger cartridges.

What are .DS_Store and other .* files for ?
The VecFever was installed using a Mac running macOS and any .* file you see on there are hidden macOS
files. Some were added/created deliberately to prevent macOS from indexing (.metadata_never_index) or
managing a trash (empty .Trash file present) or logging .fseventsd/no_log

Are there standalone cartridges of the games ?
My games are normal Vectrex games so yes, I always build a few standalone cart. as a ‘the game is finished’
kind of milestone. These use a dedicated (‘1-wire’) extra chip to store scores and options.
Frequently as it turns out I still tinker with the code afterwards if I come up with an optimization or someone
reports a bug so the game in the firmware is not always identical to the ones built but a newer version. However
I do not add new levels or enemies – I just try to fix/improve the existing game with small changes.
And I can still build cart. of any game using the newest source code of course.

I’ve also developed a dedicated hw for hybrid cartridges like Tailgunner and plan on having parts
around to build (a few) if someone is interested in one of those.
After all: if I’d own a Tailgunner cabinet myself I’d want a dedicated Tailgunner Vectrex cartridge..

Robot Arena/The Core: what are these joystick options, exactly ?
First: Robot Arena was developed specifically to be played with 2 controllers, it’s a very fast 2-stick shooter.
However you can play it with one joystick, the game mechanics adjust somewhat for this setup;
this being said the options in the games are:

ONE – one controller, 4: for shooting and 3: to hold your position (R. Arena) or stop additional impulse (Core)
TWO – two analog controllers, e.g. two original Vectrex controllers
TWO, INACCURATE – two analog controllers but with a significantly larger ‚zero‘ area, useful if one or both
controllers aren’t calibrated well enough and/or the measurements interact too much
TWO, DIGITAL – this setup uses joystick 1 measured ‚digitally‘ and all four buttons of that joystick as
the digital direction input for the ‚fire‘ joystick. This setup makes it easy to add a 2nd joystick in parallel
to the four buttons when building your own Vectrex joystick – almost all of which use digital (arcade)
joysticks.
and in Core:
PS2 – this setting uses two analog controllers and sends setup commands to a PS2<->Vectrex converter
PS2, reversed – same as above with joysticks swapped

Red Baron: why is the joystick response wrong ?
It’s actually already improved a lot compared to a real cabinet but still: a Red Baron cabinet after power-up
wants the owner to calibrate the analog joystick by moving the joystick all the way up/down/right/left
during a game. I am grabbing those calibration parameters afterwards and store them, too, but it
has to be done at least once.

Red Baron: why is the LED blue frequently ?
For the arcade game ‘Red Baron’ Atari added a new feature which was supposed to maximize
earnings, an adaptive ‘auto-skill’ feature. Red Baron keeps track of the last games played
and changes parameters to try to guarantee an average time played. To do this permanently it is also
storing data in its EAROM frequently and not just when a new hiscore has been achieved. To visually
flag this, also because during an on-going store one cannot enter the options nor go back to the menu,
the LED is turned blue.

Rocks Deluxe: what is ‘Drift Improvement’ ?
Since I had to use rotating datasets here a typical Vectrex problem, ‘drift’, came more into play: the more
lines you draw the more they can deviate from the actual thing you expect. With the slowly rotating
rocks you can also see on quite a few Vectrex that this problem isn’t the same for all shapes:
depending on angle they open up and close again which shows that the drift result is also different
for x and y axis. Since I’ve seen the calibration of Tuts in Vector Patrol and Malban mentioned it to me
again when he investigated this I decided to try this out here, too: the idea according to Tuts is to at least be
able to nudge the zero value for both axis into a better spot. Not independently, though, so you’ve got to hide
the problems in the other axis by using shapes that hide this, if necessary.
The result for rotating shapes where I can’t hide anything depends a lot on your Vectrex – it seems to help (a bit)
with all of mine so I left it in, esp. since it doesn’t need many cycles.

So this technique does not guarantee to be able to draw perfectly closed rocks on all Vectrex which I wanted
to stress by giving a slightly technical explanation first and both calling it ‘improvement’ only, too.

Tempest: what are the input options exactly ?
Besides using an analog joystick I have added two specific measurement modes for the three digital
spinners I had here: an Atari driving controller, a MiniVex with spinner and Binarystar’s 2-button spinner.
All these spinners encode the movement changes as button (1:/2:) changes and have the same amount
of transitions per revolution so are programmatically the same and have to be hooked up to port 2.

Since the button measurement is very different between the Atari driving spinner and the others I had to generate
a specific setup for this one (it is hooked up to an analog joystick y direction):
the measurement is very different from Vectrex to Vectrex and even depends on the analog joystick of the controller
in port 1 so there needs to be another calibration specifically for this button: when the ‘drvr cntrl’ input mode is selected
the fire button of the Atari driving controller is measured and the min/max values stored. Afterwards
the measurements are compared to these values and the nearest one is chosen.
If this ever fails -and it just might on setups I have not seen yet- a very simple dongle should help, pushing up
the ‘high’ level.

In all modes the 1: button of controller 1 is mapped onto ‘P1’ in the demo mode which allows to advance a level
immediately there.

Emulators: how do I improve the graphics output for a given Vectrex ?
All my emulators are using a common structure: the emulation side is taking care of generating
vector data for an interim, high-precision coord. system which then is mapped onto the Vectrex hardware.
This abstraction allows total control of the coord. system, esp. defining the center and the size
of the screen, which are different on every Vectrex after decades of use.
Additionally the ‘Drift Improvement’ technique has been added to the emulation core allowing
fine-tuning of one zero value (so one axis) capacitor-wise.

So:
3: during attract enters the options page
where in each emulator a ‘calibrate’ option allows first to fiddle with the ‘Drift Improvement’ parameter
and afterwards to set the center and size in x and y. To set the center you move the joystick while
pressing 3:, without pressing 3: the x or y size is changed. Since the game is displayed while doing so
you can immediately see how well this works.

Emulators: what does the ‘graphics boost’ option do ?
Some Vectrex -a lot less than one in ten based on all the ones I’ve seen- need a very specific and slower
setup of their capacitors or certain vectors are displayed incorrectly. In the past I have written graphics
code that works on those Vectrex (I own one, luckily) but since switching to a faster version both improves
performance and also stabilizes the output a bit further the emulation core recently was changed to allow
to switch the graphics code from the safer variant to a faster one.

It is most times not immediately obvious if the ‘boost’ option fails on a given Vectrex – the vectors that fail
are the ones with large, negative y values so vectors with vertical problems or rare positional problems in y
are the failure case.

for programmers: there are actually two different problems but they both seem to happen with the same
‘problematic’ Vectrex: one is the sampling of a value where the sample is different for one single cycle so a
std VIA_port_b
will fail sometimes because VIA_port_a is programmed a cycle after _b and the previous value is sampled that cycle.
Only for Y, only for large values, and a long sampling delay afterwards doesn’t help – the initial, lone cycle is killing
these Vectrex setups. Similarly, a fast Y-coord. and then X-coord. capacitor programming like:
stb VIA_port_a
sta VIA_port_b
nop
stx VIA_port_b
will fail on those because the 2-cycle nop is not enough sample delay for large y values. Needs to be 4 cycles at least.

Bad Apple: is it stuttering ?
Esp. if run on a no-buzz where the sound is hardly present you might think the video player is stuttering.
Actually, it isn’t – the video source already weirdly does this – the same as Malban’s VIDE uses.
I was thinking of converting another video – the bad apple demo uses a somewhat versatile video player
and could play anything – but actually converting a video takes a .long. time fiddling with parameters.
And you need good source material for a mostly automatic conversion, too, so this never happened (yet ?).
It is a nice demo, though, and was an excellent test case for optimizations built into the multibank extension.

Developers: VecFever features
Cartridges can be developed that are ‚VecFever‘-aware and flag and use additional features: this is
done by a small structure starting at a specific address, $30. With this structure the cart. can also
tell the menu whether it should jump right into it bypassing reset or whether the cart should be mapped-in
read-only (useful for legacy tests) or writeable, which is needed for most extensions.
The source code for a small example cartridge is on the VecFever (testcart.tgz).

Developers: load/store feature
The VecFever allows the storage of up to 4K of data using a constant 4-byte number supplied by the
cartridge as a ‚filename‘. The way it is implemented is that there is no ‚load‘ command – the data is loaded
automatically upon start – but only ‚store‘ commands to save the data when changed. So this is geared towards
creating permanent memory for high scores or options, not extending memory.

Developers: cartridge hw. possibilities
In a way the VecFever works like an EPROM chip simulator or RAM simulator. The default state is actually
not ROM but to load a cart. and map it in writeable, too. However, within limits there can be specific
things added in software – I’ve added a register for the LED for example or a dma-like setup
for the serial port myself. Recently I’ve added two more modes (in v1.09) for a max. 50K ROM binary
(not-banked ) that’ll appear at 0x0000-C7FF if someone wants to ever build a, say, 48K non-banked
cartridge which would be straightforward to do. And a similar setup for a 32K+n*16k banked version,
with banks at 0x8000-0xBFFF, static ROM at 0 and bank select via adr. lines at c0xy.
This gives you an idea of what can be added by a firmware change if you are wondering whether I could
add something specific for an idea of yours.

Developers: faster text
The VecFever uses a self-modifying text routine that’s the fastest I could come up with:
it’s drawing twice as fast as the bios version (but only on average 1.6x or so due to the necessary setup overhead
pre-drawing).
I’ve added the text routine and the initial setup call also to the testcart source on the VecFever, in the moment
it is using the included font. If you enable the ‚supply font by system‘ it’ll be overwritten with the font
selected for the menu. When using it there is just one new consideration: a string starts and ends with
$8x and the lower bits flag whether the last font data line is all zeros and whether the end bits of a
string data line is ‚1‘ anywhere, in that case needing an additional 18-cycle clear each scanline.
For static text strings the VecFever determines this automatically, if there’s a string list present in the
structure upon start.

Developers: what is the multibank option for ?
The VecFever has an extension that allows loading more ‚banks‘ at runtime from disk, the current
implementation allows up to (4096-2) 32k banks. This has been implemented in a way that one can
develop and test both cartridges that will use more than 2 banks but also applications which stream in
smaller and variable packets of data.To do this there’s a new VecFever file-format that consists
of the needed metadata for loading (no. of banks, size and crc values for each one).
All banks are always stored compressed. To make sure that a loaded bank isn’t corrupt – because in principle
corrupt source data decompressed could wipe out more than the allotted memory for it and crash the
VecFever – there are ‚slightly‘ time-consuming sanity checks performed that can be disabled for testing
purposes, if you are investigating timing changes when developing/fine-tuning e.g. a video player.
Plus disabling these tests doubles the bank table to (8192-2) banks.
Anyways, explaining more about the multi-bank extension exceeds the scope of this FAQ by far, contact
me directly if you want to tinker with this.

Developers: what is the VecMulti emulation option for ?
Not all cartridges developed for the Vectrex are ROM-only, some have RAM, some have additional chips
for storage. For the VecFever I have made the choice early on to both allow writing to cart.space for
Vectrex roms as a default and to make them ‚bank-switching safe‘ by copying carts. <= 32k into the
‚other’ bank, too. This allows these non-ROM cartridges to work w/o changes.

However, if there is a bug in a cartridge and it tries to write to itself (I know of exactly one so far and that one
doesn’t exist as a binary) this will lead to erroneous behavior.

The VecMulti however doesn’t allow cartridges to write to the cartridge space by default but only
if the ‚GCE year‘ text is changed to ‚GCE SRAM‘. Enabling the ‚VecMulti‘ emulation switches the VecFever
into exactly this mode, useful for a quick check if a new cartridge might be behaving badly due to this.

Even if enabled the VecMulti still differs in two more ways: it does not copy <= 32k carts. into the other bank
and has a bug – it starts 64k cartridges in the wrong bank.

Developers: how does the ramdisk operation work ?
When the Ramdisk is activated the VecFever always generates the same new, empty volume whenever waiting
for data. The data (‚cart.bin‘) uploaded is extracted, the disk discarded and the cart.bin immediately run – no flashing
is involved. If you upload a VecFever aware binary with fast entry/exit the turnaround time is very fast – ideal e.g.
for developing your own graphics routines because you can tweak cycles and watch what happens immediately.

There are two considerations when using this mode: via the ramdisk only uncompressed 64k binaries can be
uploaded – so multibank cartridges need to be split up to be tested.
More crucially: in the dev. ramdisk mode you really shouldn’t press the reset button while the usb is still active:
It’ll wipe out the binary (the VecFever one displaying the text) in the Vectrex and the VecFever won’t notice this
so it’ll look like as if it disappeared since it keeps waiting for something. I may or may not fix this
eventually – it never bothered me so far – but it’s the only place in the entire firmware where it could
get into a bad state so I might develop a fix because of this after all.

version histories:

###### RED BARON SBT

V1.1

  • gfx code inherited fix for the tiny graphical glitch for rare, medium-sized vectors
###### LUNAR LANDER SBT

V1.2

  • gfx code inherited fix for the tiny graphical glitch for rare, medium-sized vectors

V1.1

  • added fuel option
  • tried to improve the thrust offset problem (in certain angles, thrust triangle needs to be large, too)

V1.0

  • initial release
###### BATTLE ZONE SBT

V1.1

  • gfx code inherited fix for the tiny graphical glitch for rare, medium-sized vectors
###### ASTEROIDS DELUXE

V1.1

  • gfx code inherited fix for the tiny graphical glitch for rare, medium-sized vectors
###### ASTEROIDS SBT

V1.3

  • gfx code inherited fix for the tiny graphical glitch for rare, medium-sized vectors

V1.2

  • fixed ‘E’ char offset (German/French ‘Push Start’ variants)
    added faster ‘E’ geometry also for Rev1 (only Rev2 & 4 previously)

V1.1

  • fixed orientation for ‘joy, analog’ input
  • tiny precision improvement for precalculated, static gfx data
  • updated rom/cpu translation core (faster and more versatile)
  • updated drawing pipeline to latest version
  • shot brightness range half of v1.0 now (as in Ast. Deluxe)
  • asteroids in portrait mode increased by 30% (there’s no ‘correct’ ratio here, previously
    it was defined by the boundary detection and now by visual aesthetics)
  • translation process improved to be able to generate rev1/rev2/rev4 versions;
    esp. rev.1 needed a lot of changes..

V1.0

  • initial release
###### VECFEVER

V1.17

  • new abstraction layer for flash access
  • more elaborate power consumption and cache/prefetch handling depending on usage
  • fixed hybrid. cart. loading of >(128+32)K (released v1.16 to days too early..)
  • Malban’s VRelease updated to incorporate the ‘rare Vectrex’ drawing code

V1.16

  • read cache for usb disk mode
  • led access changed
  • emulation roms folder changed from top level to /MAME_ROMS/
  • initial arm rom zipload area increased to improve startup time
  • loaded arm codesize max. increased from 128k to 256k (since I now tested it..)
  • additional romset load capability added (e.g. Asteroids rev.2 needs two romsets)
  • vecterm 1.2: slightly faster points drawing, one cycle delay in corner case added
    marginally faster setup in specific corner cases

V1.15

  • new ability: loading and executing hybrid cartridges 🙂
  • new feature: autostart
  • Vector Terminal v1.0: calibration rewritten to use the better ‘Tailgunner’ version
    v1.1: drawing routines and environment adapted/rewritten to use the new optimization
    technique developed for the new emulator – increase perf. across the board
  • Tailgunner v1.0: – improved minor and rare problem with aim/crosshair
    – fixed bus instability issue
    v1.1 – internal rearrangements to decrease code size
  • menu v1.14: sound reg. init upon (re)entry changed to always clear volume registers

V1.14

  • large-scale internal changes to rearrange the code, esp. to now support ‘hybrid’ cartridges
  • removed 50K and (32k+4x16k) cart. emulation since it wasn’t used and 2x48K is more useful anyways
  • Tailgunner emulator v0.9 added to firmware as test case for a hybrid cart.

V1.13

  • fixed hiscore display bug via menu for non-v4e enabled games that crept in while rearranging
    code for new capabilities

V1.12

  • 2x48K ROM support for Malban
  • new ‘serial’ dev. upload capability to support even larger binaries for rapid testing (2x48k..)
    on VF with additional serial port
  • new menu version starting with v1.12 – older menus/stored options aren’t loaded anymore
  • updated RnS to v1.05 and RnS Deluxe to v1.01 (brighter explosions)

V1.11

  • fix for ROM-MineStorm and non-hiscore MineStorm 2 behavior (and changed name to ‘MineStorm’)
  • fixed dev.mode reset behavior for serial cart. (two resets were previously necessary for vf-enhanced binaries)
  • added ‘Vector Terminal’ to firmware (only exposed for serial cart.)
  • added capability to reload data at any time for Malban
  • menu v1.11 (updated serial code, ram. init of cart., 64k dev.mode binary start improved)

V1.10
just a tiny update that fixes two bugs in the dev.menu, can also be fixed/updated by copying a fixed dev. MENU.DAT
onto the drive so if you do not encounter these you don’t need to update

  • dev.menu: fix for analog joy. input (when analog hiscore entry selected)
  • dev.menu: improved autostart for non-VecMulti 64k binaries in dev.mode

V1.09
this update is not typical since I had to change the menu-bios communication for the first time – so an
older menu.dat will not be executed by this firmware anymore. Also the former preferences aren’t used
since I enlarged the storage structure and changed it a bit to bring together a few other changes.

changes in no particular order:

  • max. files in folders displayed increased from 127 to 255
  • menu uses joystick repeat so that you can scroll through those hundreds of files more easily
  • fixed a bug when trying to reset high scores via the menu
  • the codebase for the VecFevers with additional serial port is now part of the normal release
  • the prototype codebase for the proto pcbs is now part of the normal release
  • added real time clock support to the firmware/menu (not enabled everywhere – for testing on certain cart. in the moment)
  • added i2c communication capability to VecFever cartridges for dev. purposes
  • added ‘Rocks Deluxe’ v1.0
  • updated ‘Rocks ‘N’ Saucers’ to v1.3
  • added a slightly changed ‘Release’ game by Malban; it uses the same buttons setup as my games and has a menu hiscore display
  • added ’50k’ flat rom capability (0-c7ff)
  • added 32k+4*16k bank switched capability for dev. purposes