19th of October – “official” VecFever FAQ

Thomas is about to get a new firmware to his customers. Following is the official FAQ included.

VecFever FAQ (v1.5, 18. Oct. 2018)

– What is the VecFever ?
1) the basics
2) slightly more technical explanation
– How do I start using it ?
– Which cartridges are pre-installed ?
– 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’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’ ?
– 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 ?
– Developers: how does the serial port 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 it’s 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.
On the disk are also my test cartridges for the multibank extension: a music player (using plenty of
32k banks) 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.

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 a 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 one in the firmware is used)
/BUFFER.DAT a 1 or 2MB buffer used as storage for all cartridges
/ROMS/ the roms folder, the top level on the Vectrex side

and the ROM files for emulation cart. reside topmost, too, e.g.
/TAILG.ZIP the ROM file for the tailgunner emulator

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.

the ROM files for emulators are the same as the ones for the current MAME, they are checked for
consistency first and MD5s are:

TAILG.ZIP 7f52d5fba9c1ea468ac950be816e6682

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 ‘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. OS X 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 an iMac running OS X and any .* file you see on there are hidden OS X
files. Some were added/created deliberately to prevent OS X 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

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.

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 history:
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 v.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