|
|
Post by Peer on Jun 13, 2024 11:38:56 GMT -5
Greetings everyone!
Some time ago I started experimenting with using a Hitachi 6309 CPU in the Vectrex and with programming custom BIOS versions (see here). I used nes4life's Multi BIOS PCB, which worked great, but removing the PCB from the inside of the Vectrex console and plugging it in again each time I needed to flash a new version, turned out to be very cumbersome for BIOS development. At some point in 2023, I talked about this to Andreas Reber, who is a colleague of mine and an expert for embedded systems and hardware design, with a long experience in that field, reaching back to the days of the ATARI ST, for which he built several hardware extensions. Together we came up with ideas and a concept for an extension cartridge for the Vectrex which allows for a smooth and easy development of Vectrex system-software and applications. This translates to that I told him a long list of wishes, and he designed and built a great and powerful toy for me to play around with: the
This is still work in progress. A fully functional beta version PCB is now assembled and currently being tested.
Many Cheers, Peer
|
|
|
|
Post by VECTREXER on Jun 13, 2024 11:58:36 GMT -5
Peer Might also be nice to have simple location pictorials in the "Technical Requirements" section for the Vectrex logic board modifications. Showing removal of the the BIOS ROM chip package from the Vectrex logic board. Showing addition of the integrated circuit package socket onto the Vectrex logic board for later BIOS ROM chip insertion.
|
|
|
|
Post by kokovec on Jun 13, 2024 12:25:23 GMT -5
Great idea for a developer board.
Using FRAM for the full memory range was a good choice.
I built an FRAM cart a while back and use it quite often.
The read/write capabilities allowed me to run Coco Basic with 17K of RAM.
I never thought of removing the BIOS chip.
Brilliant!
|
|
|
|
Post by Peer on Jun 13, 2024 12:31:11 GMT -5
Peer Might also be nice to have simple location pictorials in the "Technical Requirements" section for the Vectrex logic board modifications. Showing removal of the the BIOS ROM chip package from the Vectrex logic board. Showing addition of the integrated circuit package socket onto the Vectrex logic board for later BIOS ROM chip insertion. I have now added pictures that show the location of the BIOS ROM chip on the digital board, and also the removed chip and the socket I placed in. |
|
|
|
Post by D-Type on Jun 13, 2024 15:29:11 GMT -5
Nice add-on!
Similar'ish in concept to my vapourware VecForth development cart. Well, not full vapourware, mine also exists, but using a VecFever or VecMulti to provide the bottom 32k of RAM only (no BIOS replacement etc.), so it's basically a serial port card at the moment.
I also use an FT245RL (actually a UM245R) with the Data Available (RXF) line hooked to the VIA PB6 line for polling by the Forth command line interpreter, as there is no spare interrupts to use. Mine works fine at 921,600 Baud, you can probably crank up yours from 115,200. (BTW, did you know the FT245R went manufacturer-EOL this month?)
What address space do you use for the FT245RL? I use minimal decoding $8000-$BFFF because I didn't have any decoder chips in the box, only some random TTL.
My idea eventually is to have the ability to download code to RAM via serial port and burn it to a standard FlashROM, such as the one used by Malban for Vectorblade. However, with only 1KiB RAM available as standard, it'll need to be automated or have extra RAM added, which was the idea for a Forth dev cart anyway.
I look forward to seeing what you do with it!
|
|
|
|
Post by Peer on Jun 14, 2024 1:28:51 GMT -5
Great idea for a developer board. Using FRAM for the full memory range was a good choice. I built an FRAM cart a while back and use it quite often. The read/write capabilities allowed me to run Coco Basic with 17K of RAM. I never thought of removing the BIOS chip. Brilliant!
great to hear that you have worked on similar things! Am I correct in remembering that you are also running a 6309 in your Vectrex? If you ever want to try my 6309 BIOS (work in progress) or one of my patched BIOS versions, please let me know.
Many Cheers, Peer
|
|
|
|
Post by Peer on Jun 14, 2024 1:53:16 GMT -5
Nice add-on! Similar'ish in concept to my vapourware VecForth development cart. Well, not full vapourware, mine also exists, but using a VecFever or VecMulti to provide the bottom 32k of RAM only (no BIOS replacement etc.), so it's basically a serial port card at the moment. I also use an FT245RL (actually a UM245R) with the Data Available (RXF) line hooked to the VIA PB6 line for polling by the Forth command line interpreter, as there is no spare interrupts to use. Mine works fine at 921,600 Baud, you can probably crank up yours from 115,200. (BTW, did you know the FT245R went manufacturer-EOL this month?) What address space do you use for the FT245RL? I use minimal decoding $8000-$BFFF because I didn't have any decoder chips in the box, only some random TTL. My idea eventually is to have the ability to download code to RAM via serial port and burn it to a standard FlashROM, such as the one used by Malban for Vectorblade. However, with only 1KiB RAM available as standard, it'll need to be automated or have extra RAM added, which was the idea for a Forth dev cart anyway. I look forward to seeing what you do with it!
also cool to read you have done similar experiments!
My focus is currently not on the USB communication itself, but on developing a 6309 BIOS. The USB comes in very handy for quickly sending new BIOS versions to the cartridge. The turnaround times are very fast. Write some new code, switch on the Vectrex, send the code, test it, write some more code, send the new code... All that without having to remove the cartridge or any chip.
On the laptop side, the baud rate of HTERM at the moment is preset to 115200, and that works fine. My Vectrex boot loader could still be tuned to reading the data even faster. I have not yet fully experimented what maximum speed I could get. Currently, writing a new BIOS version (8K) takes less than a second.
The FTDI data is mapped to address 0xc7ff, and the RFX and TFE bits are mapped to bits 7 and 6 of address 0xc7fe. But the complete 0xc700 page is reserved for the FTDI, which makes the address decoder a lot simpler.
The interrupt bits are (currently) not connected. When communicating, my boot loader is simply polling the bits. In an earlier version of the board, we had the interrupt bits connected, but that caused trouble and conflicts when using certain third-party games, or when using some cartridges on the external cartridge port. Polling is completely sufficient for my current activities, but we might change that in a future version of the board.
Many Cheers, Peer
|
|
|
|
Post by VectorX on Jun 14, 2024 13:44:30 GMT -5
Nice to see our residential mad scientist is doing more stuff with the Vectrex again  |
|
|
|
Post by Peer on Jun 14, 2024 15:15:20 GMT -5
Nice to see our residential mad scientist is doing more stuff with the Vectrex again Yes, the creature (i.e. me) is alive! I am currently pondering how to generate the 1.21 gigawatts of electricity I need to keep this board running…  |
|
|
|
Post by Peer on Jun 15, 2024 10:19:07 GMT -5
... (BTW, did you know the FT245R went manufacturer-EOL this month?) Andreas has just informed me and pointed out that our board is already using the new FT245RNL. So the EOL of the FT245R is not posing any problems here. I have now also added this FTDI type information to the project webpage. |
|
|
|
Post by D-Type on Jun 15, 2024 13:24:45 GMT -5
... (BTW, did you know the FT245R went manufacturer-EOL this month?) Andreas has just informed me and pointed out that our board is already using the new FT245RNL. So the EOL of the FT245R is not posing any problems here. I have now also added this FTDI type information to the project webpage. That's good to know. I couldn't see any difference between the specs on the manufacturers website, but ChatGPT found a discussion on the Digikey forums stating that the manufacturer confirmed that the only difference between the variants was the manufacturing location. |
|
|
|
Post by kokovec on Jun 16, 2024 16:48:01 GMT -5
great to hear that you have worked on similar things! Am I correct in remembering that you are also running a 6309 in your Vectrex? If you ever want to try my 6309 BIOS (work in progress) or one of my patched BIOS versions, please let me know. Many Cheers, Peer
Not yet, but it's on my short list of things to try. |
|
|
|
Post by D-Type on Jul 16, 2024 8:09:28 GMT -5
Peer , do you have an emulation setup for your 6309 system?
I'm currently debugging some Forth/assembly code that needs single stepping, which is tricky on real hardware and awkward with emulation because I need a Forth terminal.
It dawned on me that I could probably hack together a custom version of MAME dedicated to Vectrex and cut 'n' paste in a serial port UART driver/terminal from one of the other emulator targets. It's not done yet, but it looks doable.
Whilst I know VIDE is your goto emulator/debugger, you could probably swap the MAME Vectrex 6809 for a 6309 by changing a couple of numbers in the source code and then others could try out your 6309 BIOS without any hardware hacking.
Or maybe Malban has added 6309 to VIDE already?
|
|
|
|
Post by Peer on Jul 16, 2024 9:03:52 GMT -5
Peer , do you have an emulation setup for your 6309 system? Right now, unfortunately not  All my experiements (and debugging) are always on a life console. That would be cool. If anyone is willing to hack MAME this way, I am all ears. Currently, I do not have the time (and will) to do this myself. But I wonder if all the internal timing stuff of the Vectrex (VIA, DAC, integrators, comparators, ...) would be faithfully emulated? Hehe, I once suggested it to him in a subtle way, as "magnum opus" 
And I think that is indeed what such an extension would be. A major endeavor. And I can very well understand that there are better ways to spend one's time than attempting to do this.
Playing around (or rather programming around) with the 6309 on the Vectrex is a lot of fun, but certrainly there is no "mass-market" for it. I am still exploring the 6309 universe. Quite a number of the original games now work with my current 6309 BIOS version, but the speed-up is very moderate. Any game that uses its own 6809-based timing does not fully work. The extensions of the 6309 are nice, but a lot of them are of rather limited value, see the various articles which can be found on this on the web. But I am still learning here.
As a side-effect, I have found several optimizations of the original 6809 BIOS. No game-changers, but each cycle won is a cycle won. I do have a nicely improved BIOS random number generator, and a nicely improved BIOS collision detection, and some other stuff, e.g. no "mystery gaps" anymore. For some games, all this leads to increased performance and less vector wobble.
Still, a 6309 Vide extension would be cool 
|
|
All my experiements (and debugging) are always on a life console.
