Reading current SGDK features, it reads that bank switching is already supported.
I am thinking on it, as you can have 2x 4 MB ROMs in a cartridge, and switch to the second one, when your game reaches a level, stage or map
In order to avoid continuosly switching, you can have a duplication of your spritesheets at each ROM, and a duplication of your SFX effects; as two indepedent cartridges in a single case
Are there examples about how to deal with a scenario such the one I described, using SGDK?
Is there a most basic needed electronics circuitry scheme for this?
Thanks in avance,
Edites: For this relatively easy to deal scenario, you will need to duplicate 68k code as well, at the same ROM addresses
Bank switching with SGDK
Moderator: Stef
-
- Very interested
- Posts: 3131
- Joined: Thu Nov 30, 2006 9:46 pm
- Location: France - Sevres
- Contact:
Re: Bank switching with SGDK
SGDK does support bank switching but using the official sega mapper (also called SSF2 mapper).
So it switches 512 KB banks and bank 0 is fixed.
SGDK can handle that almost all automatically for you in which case it access banks above 4 MB through the 3MB-4MB region.
If you want to use your own bank switching mechanism then you need to implement it on your own.
So it switches 512 KB banks and bank 0 is fixed.
SGDK can handle that almost all automatically for you in which case it access banks above 4 MB through the 3MB-4MB region.
If you want to use your own bank switching mechanism then you need to implement it on your own.
Re: Bank switching with SGDK
Usually when there is bank switching, there is a part of the mapped rom that never switches to avoid the problems you described.
The trick is to create sections within gcc, check documentation.
The trick is to create sections within gcc, check documentation.
HELP. Spanish TVs are brain washing people to be hostile to me.
-
- Interested
- Posts: 13
- Joined: Thu Jul 04, 2019 4:25 am
- Location: Juiz de Fora/MG, Brasil
- Contact:
Re: Bank switching with SGDK
I want to make my ROM with more than 4Mb work (at the moment I have a crash with an illegal function).
I opened the config.h file and changed ENABLE_BANK_SWITCH to 1, adding support for switching banks.
Then I ran the build_lib.bat file from the root of my SGDK by double clicking on the file. It looks like it worked, now I'm going to recompile my project (I deleted the out folder and the .h files from the res folder). Everything went well and the ROM has 4,224Kb. It doesn't run on Fusion, I got it on Gens Kmod. HOWEVER, when I access the graphics that were supposed to be at the end of the ROM (it's at the end of sprites.res) this graphic appears corrupted. Tiles appear to be correct, but everything is scrambled on the screen. Does anyone know what it could be or how to fix it?
I opened the config.h file and changed ENABLE_BANK_SWITCH to 1, adding support for switching banks.
Then I ran the build_lib.bat file from the root of my SGDK by double clicking on the file. It looks like it worked, now I'm going to recompile my project (I deleted the out folder and the .h files from the res folder). Everything went well and the ROM has 4,224Kb. It doesn't run on Fusion, I got it on Gens Kmod. HOWEVER, when I access the graphics that were supposed to be at the end of the ROM (it's at the end of sprites.res) this graphic appears corrupted. Tiles appear to be correct, but everything is scrambled on the screen. Does anyone know what it could be or how to fix it?
-
- Very interested
- Posts: 3131
- Joined: Thu Nov 30, 2006 9:46 pm
- Location: France - Sevres
- Contact:
Re: Bank switching with SGDK
Fusion has hardwired bank switch support, mean it will work only for SSF2 game. Gens KMod support it a bit better, but still the bank switch mechanism is a bit buggy and you may experience GFX bugs with it. The only reliable emulator to support SSF2 mapper fully and for custom ROM is BlastEm.DavilaGames wrote: ↑Thu Mar 10, 2022 6:54 pmI want to make my ROM with more than 4Mb work (at the moment I have a crash with an illegal function).
I opened the config.h file and changed ENABLE_BANK_SWITCH to 1, adding support for switching banks.
Then I ran the build_lib.bat file from the root of my SGDK by double clicking on the file. It looks like it worked, now I'm going to recompile my project (I deleted the out folder and the .h files from the res folder). Everything went well and the ROM has 4,224Kb. It doesn't run on Fusion, I got it on Gens Kmod. HOWEVER, when I access the graphics that were supposed to be at the end of the ROM (it's at the end of sprites.res) this graphic appears corrupted. Tiles appear to be correct, but everything is scrambled on the screen. Does anyone know what it could be or how to fix it?
I really recommend you to use it for development.
-
- Very interested
- Posts: 2984
- Joined: Fri Aug 17, 2007 9:33 pm
Re: Bank switching with SGDK
Picodrive has good banked rom support. I use it for testing 32X bank selected bins (big 32X video player roms in this case). Fusion works fine, but only up to 6MB. They apparently didn't support bigger since there was no rom bigger at the time. The NeoMyth MD cart works up to 8MB since that's all the PRAM it has for loaded games. The MED works up to 14, 15, or 15.5 MB depending on the model you have. There's a flash cart that was made for the Titan 2 demo that supports up to 128MB, which is as big as you can go with the standard SEGA mapper.
-
- Very interested
- Posts: 624
- Joined: Thu Nov 30, 2006 6:30 am
Re: Bank switching with SGDK
One little caveat here is that the way the Mega Everdrive handles SRAM with its extended "SSF2" mapper is not the same as the way the standard Sega mapper does. On the MED, one of the banks you can select is mapped to SRAM (except on the v1 which has no dedicated SRAM, though one of the banks is saved to SD on reset) whereas on the real Sega mapper there's a bit in $A130F1 that maps SRAM in the whole upper 2MB. In the current stable version of BlastEm you need to specify 'SEGA SSF' in the header (which is what enables the extended mapper on the MED), but you get the standard Sega mapper behavior. I have since changed BlastEm's behavior to better match what Genesis Plus GX does so in the nightlies you get standard Sega mapper behavior if your ROM > 4MB and the ROM end field in the header has $3FFFFF or less, if you specify 'SEGA SSF' you instead get the MED v2 behavior (which is generally compatible with the slightly different MED Pro behavior).
None of that matters if you don't need SRAM though
None of that matters if you don't need SRAM though