|
Post by thomas on Nov 26, 2015 10:19:51 GMT -5
I was wondering about the bank switching actually being used out there and also about the preference of anyone interested in really, .really., large Vectrex programs:
From what I found out so far there are only a very limited amounts of carts out there using the 'VIA method', and not all for bank switching. Thrust uses it for programming an eprom to save hiscores, for example. ParaJVE in the documentation i just googled clearly states the 2nd bank needs to have a valid Vectrex header. This puzzles me, after a reset the bank is always back to the normal one, so why does ParaJVE have this restriction ? Are there Vectrexes out there with different VIA reset behavior ?!
So, in a "let's say it's almost christmas" kind of world what type of bank switching would you like ? I personally prefer these two versions: obviously a legacy "use via pin for >32k but <=64k ones" and a functional one, where you can request any kind of page for the 'upper' one only. This is mildly limiting for code but the 'normal' page can be writable, too, so there are no severe limitations. This means you can store data or copyable code in the upper one for access and leave the normal one for normal operation but I would like to hear what someone else might think..
Thomas
|
|
|
Post by gliptitude on Nov 30, 2015 2:17:48 GMT -5
Well i am not remotely qualified to answer your question, but since no one else is responding i'll mention that in the past Fury has weighed in a little bit on the subject of bankswitching here.
If i understand correctly, bank switching does not really allow for "really, really large Vectrex programs". I think each bank is basically a separate independent program. So it is just a series of programs that each have the exact same size limitations of other non-bank-switched games.
I think of it as two separate ROMs, that are just organized (hardware) in such a way that you don't have to switch the cartiridge to switch between them.
|
|
|
Post by christophertumber on Nov 30, 2015 9:37:04 GMT -5
Thomas - I'm not really sure if your question is hardware based or software. If software, then software design is currently driven by the availability of PCBs. Currently available PCBs only support 64K (32x2) of ROM. I have no understanding of the hardware involved and can't comment on the possible design of new, larger bankswitching schemes.
Glip - I'm currently using the full 64K ROM in my WIPs. While the banks are independent, RAM is in common. And switching banks causes the processor to resume running code at the same ROM address. So you just need to carefully plan the structure of your code. It goes something like this:
Start of Bank 1: Code Subroutine Subroutine Code Subroutine Bankswitch to Bank 2 Continue after switching back from Bank 2: JMP to Start of Bank 1
Start of Bank 2: Code Code Code Subroutine Code Subroutine Bankswitch to Bank 1 Continue after switching back from Bank 1: JMP to Start of Bank 2
"Continue after switching back from Bank 1" and "Continue after switching back from Bank 2" must be the same ROM address in their respective banks.
Note: This is how the standard 32Kx2=64K PCBs work. IIRC some multicarts use completely different bankswitching schemes which may or may not support bankswitching after the initial boot. However, I believe that in a lot of cases these multi-carts simply behave this way because adding the ability to return to the main menu/game selection screen would require modifying all the games. Once you start playing a game of Minestorm there's nothing in the game to allow you to exit the game.
|
|
|
Post by thomas on Dec 2, 2015 8:37:29 GMT -5
Thanks Christopher, your usage is what i expected, and yes, it is obviously dependent on actual hardware used; My initial question was actually twofold and software based: I am wondering whether anyone ever had problems about the reset state with the via being in 2nd bank mode. But also a practical one: I am implementing my very own 'multi bank switching' as you read this in my own multicart, and I thought I'd ask whether anyone out there has some advice/preference. My cart uses a microprocessor to emulate the 6809 bus protocol in real time so I am not encumbered by static hw behavior. I can pretend to be rom/ram or ic logic on a per cart basis, if needed. And no cart data needs to be patched. I also passively track the hw reset behavior of the 6809 in the moment and switch the Vectrex back to the menu depending on this. Works flawlessly. Just push the reset button and you are back to the menu, otherwise it stays in the selected cart forever. I could make this a user variable so that a reset would not switch carts to menu back but fail to see the point in the moment, except for let's say perfect emulation purposes (after all, a Vectrex Berzerk manual states to push the reset button to switch between 1/2 player modes..). But I digress..
Anyways, I allow a cart to permanently save/load up to 4K of ram via an extension at the moment, enough to dump the exec rom and plenty for options and hiscores. I could also implement a loading function similar to this. Meaning you could simply load any <=64k data size from a >64k cartridge 'rom' to any place. But I think anyone actually using this feature initially would probably use it to develop their own hw pcb. And switching entire 32k banks would simplify the implementation.
|
|