To Byuu, About BSNES (BankSwitching related)

This is an archive of a topic from NESdev BBS, taken in mid-October 2019 before a server upgrade.
View original topic
To Byuu, About BSNES (BankSwitching related)
by on (#97252)
I would like to see NES-Style BankSwitching for use (like 20-in-1 for SNES for example), Only in configurable sets of 32k, 16k, 8k, and 4k.

Also I want to map range set to $7E0000-$7FFFFF, where we must select between RAM and ROM, If you can Implent this in BSNES, This will make things easier.

Please, And Thank you for a good emulator!

by on (#97253)
> I would like to see NES-Style BankSwitching for use (like 20-in-1 for SNES for example), Only in configurable sets of 32k, 16k, 8k, and 4k.

Best you have now is S-DD1. You can map up to 256MB into 1MB blocks. Note that real hardware is almost certainly limited to 8MB, but I can't confirm from the software level like I can that SPC7110 can only support 8MB.

If you want more, you'll have to make it yourself. It's actually really easy, but I don't want to keep making fake chips without majorly compelling reasons.

> Also I want to map range set to $7E0000-$7FFFFF, where we must select between RAM and ROM

Impossible. Cartridges already respond in that range, but the SNES CPU ignores them and uses WRAM automatically. You cannot override it.

by on (#97254)
Is it true that the 65816's direct page only works for bank $00? Recently I tried to direct page from banks $7e and $7f, but it kept reading and writing the video registers from bank $00, instead.

by on (#97256)
True, at least based on what I remember from the Apple IIGS that used the 65816. TAD (or TCD) transfers a 16-bit value in A to the direct page base pointer D. The upper bits of D are always treated as $00. But that's still up to 32 direct pages minus what you're using for stack.

by on (#97257)
I guess SNES is not fit enough for me,

This is one reason to create my own system, The current choices are not sufficant enough for me.

by on (#97258)
There's already a system for you: PC.

by on (#97260)
Some standart on simple bankswitching on SNES could be useful to make multigame carts out of separate games of different sizes and LoROM/HiROM. Like, if there ever would be a SNES Coding Combo, such thing could be then used to make a multicart out of the compo entires.

by on (#97262)
I haven't traced official multicarts such as Super Mario All-Stars + Super Mario World, but can't each game just get its own set of program and data banks, with the NMI and IRQ vectors pointed somewhere in page $000100? Or is there something about Super NES programming that requires games to have code specifically in $008000-$00FFFF?

by on (#97263)
If you literally can't make something without 4K bank mapping, you might want to rethink what you're trying to do. 1MB bank mapping should work just fine for nearly all uses. I mean there were about 2,500 unique SNES games made with no mapping at all, after all :P

SNES gives you up to 12MB of ROM/RAM address space, not limited like NES to 32K.

by on (#97265)
tepples wrote:
True, at least based on what I remember from the Apple IIGS that used the 65816. TAD (or TCD) transfers a 16-bit value in A to the direct page base pointer D. The upper bits of D are always treated as $00. But that's still up to 32 direct pages minus what you're using for stack.

Just to confirm: this is correct. The upper 8 bits of the full 24-bit effective address when using DP is $00. In English: you can set D to $0000 to $FFFF, and thus the address will always be $00/0000 to $00/FFFF. See pages 46 and 94 onward for validation.

And if you say "well that sucks, what a crappy processor", I will repeatedly smash your balls with a hammer. :P Spoiled kids today...

by on (#97266)
I will admit that DP's DBR forced to $00 made full 16MB range open bus testing ... fun.

Code:
   //MDR: unmapped region
   //x = addr
   //y = addr + $0300
   lda $0300,x; cmp #$03; bne {+}
   lda $0000,y; cmp #$00; bne {+}
   lda #$01; jsl usart1_write; rts; +


Can't do < 512-byte granularity this way. (Yes, I know that code does it at 1024-byte granularity.)

by on (#97268)
I did not say that the processor is crap, but CA65 is not really great to set up for SNES, WLA is shit but everyone still uses it, and no offence, BASS is harder than XKAS as it is not in the original syntax.

I still can use CA65, just can be hard for SNES code!

About the Bank Problem: Some games tend to not work when converting source to NES to SNES.

Let's say I have disassembled Hebereke all the way (Not true for now) and I need to port it to use SNES code, Only One Problem, It depends on FME7 or MMC3 as the mapper, Otherwise it will not work!

by on (#97269)
Isn't that is the whole point of porting, to change the code to make it work on a different architecture? I mean, rather than changing the architecture to make that code work.

by on (#97308)
koitsu wrote:
And if you say "well that sucks, what a crappy processor", I will repeatedly smash your balls with a hammer. :P Spoiled kids today...


Today's kids are upset that the direct page is only 256 bytes.

"How the hell am I going to fit an entire game in only 256 bytes?"

by on (#97317)
If you are going to whine that SNES isn't good enough, do as tepples suggested and do whatever it is on PC. If not there are a ton of other platforms, PS1, PS2, DreamCast, Xbox, whatever.

Also, making a SNES multi-cart would probably be pretty easy. It's not like there is alot to it.

by on (#97319)
MottZilla wrote:
Also, making a SNES multi-cart would probably be pretty easy. It's not like there is alot to it.

Would be interesting to hear how exactly it could be done for stand alone games that weren't initially developed to be in a multicart, use Lo/Hi ROM, and potentially can't be modified by various reasons.

by on (#97321)
When porting, It's essential to use banks. But for some NES games, It is needed period.

Like I said, The reason Hebereke MMC5 is dropped is because of mapper specific stuff, leading into corruption. Things can't be done without lots of help. a bad mess is in the rom even if I do it from scratch, when I switch banks, It freezes!

by on (#97340)
If you mix LoROM and HiROM mapping games on the same cart that complicates the design since now you need to switch alot of signals I believe, or atleast some. It also gets more complex if you need SRAM. But for regular ROM only games, particularly if they are the same size, it's not really any different from say CNROM or AxROM NES mappers. You just make a mapper for the SNES cart. It can and has been done by pirates.

by on (#97342)
I know that it was done by pirates, that's the reason why I said that having a standart would be nice - what the pirates did is not really reusable or helpful, as it is not emulated, and not even completely reversed. Their solution, however, allowed to mix games of different size and Lo/Hi ROM mappings.

by on (#97364)
Quote:
When porting, It's essential to use banks. But for some NES games, It is needed period.


I don't see how this is the case.
Bankswitching is a means of addressing more data than you can fit in the CPU's address space at any given time, which on the NES is a fairly small amount. On the SNES you can address any byte in the game at any given time, and if you don't want to use absolute long addressing for performance/size concerns you can get away with using absolute addressing a lot of the time if you just organize your code and data properly.

The concept of porting (at least between systems from before the cross-platform API era) is that you should break dependencies to the original target system's hardware and find ways of implementing the same behavior using the new target system's hardware. If that means that you have to completely rewrite some parts of the code and/or reorganize the code and data, then that's what you need to do. Saying that you require NES-style bankswitching on the SNES to be able to port an NES game is a bit like saying that you also require an NES PPU because the attribute table data can't be used by the SNES PPUs.

by on (#97368)
mic_ wrote:
Bankswitching is a means of addressing more data than you can fit in the CPU's address space at any given time, which on the NES is a fairly small amount. On the SNES you can address any byte in the game at any given time

Most of the time this is true. Exceptions I can think of include the following:
  • Vector pulls (always from $00/FFE0 to $00/FFFF)
  • Direct page in ROM
  • PLA from stack in ROM
I don't know whether or not direct page in ROM or PLA from stack in ROM are used in actual games, but games certainly use vector pulls because they use interrupts. My NES multicart engine runs multiple NROM games by switching the entire $8000-$FFFF bank, which also switches the IRQ and NMI vectors. How should the vectors be switched on a Super NES if I don't know in advance what RAM the games aren't going to be using?

Quote:
If that means that you have to completely rewrite some parts of the code and/or reorganize the code and data, then that's what you need to do.

I have had someone recently ask me through private messages on this forum how to make a multicart of entries to a Super NES game competition. Reorganizing the code and data isn't possible if the entries aren't distributed as source code, or if the maintainer is too occupied with other projects to do such reorganization.

by on (#97370)
Sure, but I was referring to the process of porting an NES game to the SNES, which was mentioned in this thread. A multicart with SNES games is a different matter - if all else failed it could probably be done with some custom hardware (design your own mapper chip).

Quote:
or if the maintainer is too occupied with other projects to do such reorganization

Then the maintainer should focus on getting those other projects finished and come back to this one when he/she can dedicate the necessary time to it. :P