• 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

• Download-Link, version 0.1: mc_6309_checker.bin
• 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.
  

Author

• Peer Johannsen

Latest modification on 10/31/2024, 14:05

• Work on complete on fully optimized 6309 BIOS version