Weird Science - Tales from the
Vectrex Academy Lab
Vectrex
Project Title
MC 6309 (or rather HITACHI 6309)
Synopsis
Processor upgrade for the Vectrex
Using a Hitachi 6309 instead of the Motorola 6809
Project
Status (for details see sections below)
2022/11/30: Scramble - comparison 6309 vs. 6809
2022/11/29: BIOS flash eeprom in place, first
versions of a custom 6309 / 6809 BIOS written
2022/09/22: some quick tests running Mine Storm,
Berzerk, and Spinball in 6309-native mode
2022/09/21: implemented a method to run arbitrary
vectrex binaries in 6309-native mode
2022/09/20: wrote and tested some utility
functions for setting the processor mode
2022/09/17: wrote a small processor checking
utility, see below
2022/09/16: console cleaned from dust and closed
again
2022/09/15: mc6309 inserted and tested, works fine
2022/09/09: socket soldered
2022/09/10: console opened and mc6809 unsoldered
2022/08/22: two 6309 processors and a socket
received from Richard
Scramble -
Comparison 6309 vs. 6809 (2022/11/30)
In the previous post I wrote that Scramble runs
fine in 6309 native mode. Well, as I noticed today,
not only fine, but also a lot faster! Here is a
video of the game running simultaneously on my 6309
console and my 6809 console:
I checked in Vide. Scramble, on a 6809,
averages around 44000 cycles per frame, so it is
clearly below 50Hz (but still looking great). It
is hard to estimate the exact cycle count and
framerate in 6309 native mode, but it is
definitely faster. Roughly, the speed-up seems
to be around 13%.
Also, it looks like the scrolling animation of
the "incoming" vectors on the right side of the
screen is much smoother with the 6309 (gliding
in) than with the 6809 (step-wise popping up).
Right now, I have no technical explanation why
this should be the case and how this could
relate to processor speed.
Work
on custom BIOS versions started (2022/11/29)
I have unsoldered the GCE BIOS Chip in my
6309 console, soldered a socket in its
place, and put in one of nes4life's Multi
BIOS PCBs, which came with a 64K eeprom. Now
I can flash my own BIOS binaries and cycle
between 8 images, which works absolutely
great.
As a first experiment, I have created a
custom 6809 BIOS which contains a patched
Draw_VLp() routine which does not suffer
from the infamous "mystery gaps" (see here if
you do not know what those are). Those gaps,
though small, can be seen in the mines and
the ship of Mine Storm, for example. With
the custom BIOS, the gaps are gone now, and
the vectors of the Mine Storm objects now
connect without interruptions. Below, there
are pictures of Mine Storm running with the
original BIOS (left) and with the patched
BIOS(right).
I then started working on a custom 6309
BIOS. When booted, it puts the CPU in 6309
native mode and from then on the processor
runs with reduced cycle counts and extended
instructions enabled. This also means that
any cycle based timing is off to some
degree. Most prominent, the Print_Str()
routine is affected and the text becomes
unreadable. I started with this routine and
wrote a patched version with adapted timing.
The text now looks as before and is readable
again. I also ported the patched Draw_VLp()
routine to 6309 timing.
The fun with patching BIOS routines is
that they have to fit in exactly the same
rom space as the original routines.
Basically this means that you have to
achieve the same functionality with
different cycle counts, but with (at most)
the same number of bytes. And you have to
take into account that most instructions
have reduced cycle counts in 6309 native
mode. Great for speed up, but hard if you
need enhanced delays to fix the timing.
Once I got this working (after several
days of trials and fixing stupid mistakes I
made) I ran some of the original GCE games
with the 6309 BIOS. Mine Storm runs fine,
also no gaps here anymore, and you can
actually see the speed up you get from the
6309. The wobbling of the vectors at the
beginning of a mine field is (almost)
completely gone. Meaning, here the game now
stays within the 50Hz frame barrier. The two
distortion test screens of the Test Rev.
cart now also stay within 50Hz and show no
flicker at all. Armor Attack, Scramble
and Berzerk run fine. Clean Sweep, as
expected, is completely off, as it uses its
own instruction cycle based timing for
drawing the walls. There is nothing a BIOS
patch can help here.
That's it for now. And yes, all this is
probably completely academic and of no
general relevance, but it is sure fun to
play around with, and already I learned a
lot about the hardware and the BIOS in the
process.
Running
arbitrary Vectrex binaries in 6309-native mode
(2022/09/22)
I have implemented a method which allows
to run arbitrary Vectrex 32k binaries in
6309-native mode.
It works by creating a 64k bank-switching
binary, with the original game kept in bank
0, and my own code in bank 1 (start-up
bank). My code sets the processor to
6309-native mode, does a bank-switch to bank
0, and then starts the residing binary.
This turned out to be slightly trickier
than I thought at first. For one thing, the
bank-switching-and-starting-the-original-binary
routine itself must be executed in RAM
(bank-switching safe zone), and to start the
game binary, I at first simply tried a cold
reset (Cold_Start(), jump to 0xf000). But
that also resets the VIA and causes a
switching back to bank 1. I then used a warm
reset (Warm_Start(), jump to 0xf06c), but
got crashes. The crashes disappeared when I
also reset the processor stack-pointer to
0xcbea, before doing the jump. I still have
to investigate this closer to understand the
reasons for the latter.
Once I got it working, I tried Mine Storm,
Berzerk, and Spinball (Flipper). Some quick
findings (for these games at least):
As expected, any text drawn by means of
the BIOS printing routines looks distorted.
Sound and controllers work fine.
Drawing vectors works fine, except for
that the infamous "mystery vector-gaps" (see
here)
now appear at different scale-factors (which
again is expected due to the differences in
cycle counts of the assembly instructions),
and are now pretty prominent and visible in
Mine Storm.
The game play itself worked fine in
Berzerk and Spinball, but I got a crash
while playing level 2 of Mine Storm.
I had the impression that there is some
sort of performance benefit in Mine Storm
(less wobbling of the stars at the beginning
of a level), but I could not notice any
performance improvements in Berzerk or
Spinball so far. But such things are hard to
tell, and I played way to few to be able to
say anything for certain in this regard.
Fun fact: Spinball obviously uses the BIOS
Print_Str() with the circle-character for
drawing the ball, apparently wasting lots of
cycles here. Drawing a small octagon for the
ball should be must quicker.
Due to lack of time I could not try more
games, but I hope to find the time soon to
continue these experiments.
First
experiments with 6309 native mode (2022/09/20)
I wrote some utility functions for setting
the processor to 6809-emulation or
6309-native mode which can also be used from
C level.
Did a first quick test in 6309-native
mode, printing two strings of digits on the
screen by means of the BIOS Print_Str_d()
function. The result is as expected. The
positioning on the screen works fine (the
timing is done by means of VIA), but the
characters get distorted (the timing for
"going back and one line down" is done by
instruction cycles, which are different in
6309-native mode). See pictures:
Processor
Checking Utility (2022/09/17)
I wrote a small utility that checks
whether a 6809 or a 6309 processor is
present in the console.
The check is a modified and simplified
version of the method proposed in "The 6309
Book" by Chris Burke. It relies on the
assumption that invalid opcodes are executed
as NOPs on the 6809. I could not find any
source that officially verifies this
assumption to be true, but the method works
fine on my real world consoles, see picture
below.
Fun fact: The program also works fine in
VIDE and in Dr. Snuggles web emulator,
detecting a virtual 6809, but it causes
ParaJVE and Vectrex Online Vs. 0.2.6.0 to
crash.
If you try it, please let me know if the
result is correct for your Vectrex (please also indicate the
BIOS version and the serial number of
your console). Contact:vectrex@pforzheim-university.de
Downloads are free and for non commercial
use only. Use
at your own risk.
Pictures
Background
Story and Project Summary
A discussion
on
the Vector Gaming Forum triggered my
interest in trying to use a Hitachi 6309
processor as a replacement for the Motorola
6809 in a real Vectrex console.
The Hitachi 6309 is an extended CMOS
version of the Motorola 6809. It can be run
in a (default) 6809 emulation-mode in which
it is 100% compatible with the Motorola
6809, and in a 6309 native-mode which
features an extended instruction set and
less cycles per instruction.
Among other things I would like to
investigate how the original GCE games
perform when run in 6309 native-mode. Also,
I am interested in possibly extending the
gcc6809 C compiler to using the extended
6309 instruction set.
Owing to favorable circumstances, I met
Richard Goedeken and learned that he already
has successfully integrated a 6309 in his
console an is using it smoothly in
emulation-mode as a 6809 replacement, but
has not yet done any native-mode experiments
on the Vectrex himself. With his kind advice
and help, I am now in possession of two 6309
processors and a 40 pin socket.
The MC 6809 has been unsoldered and
in its stead now the 40 pin socket is
soldered.
The MC 6309 has been inserted and works
fine (in default 6809 emulation mode).
Experiments with real 6309 native mode
have started.