Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Oct 20, 2014 22:39:16 GMT -5
Looking here: sonicresearch.org/forums/index.php?showtopic=3843I see that a few people have figured out the SSFII mapper (or Sega Mapper, whatever ) Anyway, I have a few questions on this: First one is: Is this usable in BEX (at least the mapper, not so much the code?) Second is, assuming the link above is on the right path, the macro that's written appears that it should probably go somewhere in the header/basicasm.cni file (I think that's the one?), right? Third: How would you calculate the range? Maybe I state what I'm assuming first. From the looks of things, it appears that each range is a 512KB chunk of the rom. The bottom block of code in the link above says to set that up at a certain point in the rom hack - is this where you would put it right before your game loop? Once you reach the end of a bank (assuming we're using a 6 MB rom, for example), how would you determine which bank/page you're in? Is there a register that tells you where you're at in the rom? I'm assuming that through normal execution, the standard mapper just flows straight through? When you switch banks, how do you tell the SMD to jump to that code? I hope this wall of text is easy to follow It's a bit late here.
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Oct 21, 2014 5:13:44 GMT -5
Is this usable in BEX (at least the mapper, not so much the code?) Sure, why wouldn't it? Second is, assuming the link above is on the right path, the macro that's written appears that it should probably go somewhere in the header/basicasm.cni file (I think that's the one?), right? Don't use the macro. Simply write to &h$A130?? when you need to. How would you calculate the range? Well, &h80000 is equivalent to 512KB .. so ? x &h80000 does the trick The bottom block of code in the link above says to set that up at a certain point in the rom hack - is this where you would put it right before your game loop? That block simply sets the mapper so that it uses the first 4MB of the ROM ( just like when you wouldn't use a mapper ). Once you reach the end of a bank (assuming we're using a 6 MB rom, for example), how would you determine which bank/page you're in? You ( should ) know this as a programmer. You / your program is controlling that. When you switch banks, how do you tell the SMD to jump to that code? You're swapping out which part of the ROM is mapped to a certain part of the 68K address space. So, not sure what you mean with "jumping". Besides, the data you're switching between should be tiles or samples .. not code. If you can't fit your code in let's say 2MB of ROM, you're doing something wrong
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Oct 21, 2014 6:39:17 GMT -5
Oh moon I think I'm confusing myself with bank switching, though I think you cleared up most of my confusion. Please let me know if I'm understanding this correctly: Bank switching isn't about the code, but the assets. So if I wanted to use more tiles/audio, and it extended past 4MB, that's when I would write to &h$A130??, with the location in the rom the data is located at? I'm assuming the program code shouldn't be broken up at all, like subs and functions? Would accessing it still be the same? Suppose I move page 9 (using the links terminology, unsure if that's the proper term for it) using move.b #7,($A130FF).l, once I move that page to that location, would I just load everything in the same manner as if I didn't do any bank swapping? Could any program code be placed in there? And will bex compile over 4 mb roms? Sorry for all the questions! I do appreciate your patience with me
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Oct 21, 2014 8:20:58 GMT -5
Ehm, let me just try to explain the principle. The MegaDrive's has 4MB of the 68K's memory space reserved for ROM. This cannot be changed nor configured. So as long as your ROM is 4MB or smaller, it can simply be connected to that memory space directly. However, when your ROM is larger than 4MB there's a problem. There's only room to connect 4MB, which means that you won't be able to access any data that isn't connected. So, for ROMs bigger than 4MB they came up with a so-called "mapper chip". Instead of connecting the ROM to the memory space, the mapper is connected instead, and the mapper can be configured at run-time to connect / redirect to various parts of the actual ROM. So, in the code snippet on the page you linked to, the mapper is configured to access the first 4MB of the ROM. But each 512KB block of the mapper ( and thus 68K memory space ) can be redirected to whichever 512KB block of ROM. Hope this clears things up. And will bex compile over 4 mb roms? Yup
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Oct 21, 2014 9:00:51 GMT -5
Okay, that makes sense. I'll do some testing and if I have any more questions, I'll post them here
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Oct 21, 2014 10:17:10 GMT -5
I'll do some testing and if I have any more questions, I'll post them here This works just fine ( tested in Gens ) .. not sure why & where the 2 bytes of junk that BEX inserts before bar come from, so i've offset the label. asm move.b #2,($A130F3).l end asm dataptr& = &h80000 for i=0 to 7 read c locate 0,i print c next end asm "org $FFFFE" bar: data 1,2,3,4,5,6,7,8
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Oct 21, 2014 12:22:28 GMT -5
Thanks for the example still at work for another 3 hours or so, but I'll be testing this out later (I know you said it works, but some things I'm having a hard time understanding, but I think that may go away once I start seeing it in action)
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Oct 21, 2014 18:10:38 GMT -5
So after some testing, I finally understand how it all works Unfortunately, it seems in order to use this, you would need to sacrifice a SSFII cart to use the mapper. Is there a logic circuit or a clone of it available, or a similar IC that would work in its place?
|
|
|
Post by jlf65 on Oct 22, 2014 1:54:34 GMT -5
Most flash carts emulate the SSF2 mapper. In fact, the MegaEverdrive allows the SSF2 mode for the full size of the DRAM chip - 16 or 32MBytes, depending on the cart.
How it works is pretty simple: You have the 4MBytes of cart space (0x000000 to 0x3FFFFF) split into eight banks, each 512KBytes in size. The registers at 0xA130F3 to 0xA130FF control which bank of the rom appears at the corresponding bank in the cart space.
Bank 0: cart space 0x000000 to 0x07FFFF - fixed to the first bank of the rom. That way the rom header and int vectors and such all have a fixed place in the address space.
Bank 1: cart space 0x080000 to 0x0FFFFF - set to the bank # written to 0xA130F3.
Bank 2: cart space 0x100000 to 0x17FFFF - set to the bank # written to 0xA130F5.
Bank 3: cart space 0x180000 to 0x1FFFFF - set to the bank # written to 0xA130F7.
Bank 4: cart space 0x200000 to 0x27FFFF - set to the bank # written to 0xA130F9.
Bank 5: cart space 0x280000 to 0x2FFFFF - set to the bank # written to 0xA130FB.
Bank 6: cart space 0x300000 to 0x37FFFF - set to the bank # written to 0xA130FD.
Bank 7: cart space 0x380000 to 0x3FFFFF - set to the bank # written to 0xA130FF.
Bank #s in the rom can go from 0 to 63 (limit of the Sega Mapper). That allows up to 32 MBytes of rom for a game. SSF2 only used 6MBytes of that. You can see, Sega was thinking ahead to bigger games. You can put code in those banks, but it's harder to keep track of the entry points when you do so. Think back to the old SMS days with bank selected games...
Bank 0 is fixed and 512KBytes in size - you probably don't need more for game code than that. You use the other banks for accessing more game data... more tiles for the backgrounds and sprites; more data for music and sounds; more data for cut-scenes.
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Oct 22, 2014 7:02:28 GMT -5
Most flash carts emulate the SSF2 mapper. In fact, the MegaEverdrive allows the SSF2 mode for the full size of the DRAM chip - 16 or 32MBytes, depending on the cart. How it works is pretty simple: You have the 4MBytes of cart space (0x000000 to 0x3FFFFF) split into eight banks, each 512KBytes in size. The registers at 0xA130F3 to 0xA130FF control which bank of the rom appears at the corresponding bank in the cart space. Bank 0: cart space 0x000000 to 0x07FFFF - fixed to the first bank of the rom. That way the rom header and int vectors and such all have a fixed place in the address space. Bank 1: cart space 0x080000 to 0x0FFFFF - set to the bank # written to 0xA130F3. Bank 2: cart space 0x100000 to 0x17FFFF - set to the bank # written to 0xA130F5. Bank 3: cart space 0x180000 to 0x1FFFFF - set to the bank # written to 0xA130F7. Bank 4: cart space 0x200000 to 0x27FFFF - set to the bank # written to 0xA130F9. Bank 5: cart space 0x280000 to 0x2FFFFF - set to the bank # written to 0xA130FB. Bank 6: cart space 0x300000 to 0x37FFFF - set to the bank # written to 0xA130FD. Bank 7: cart space 0x380000 to 0x3FFFFF - set to the bank # written to 0xA130FF. Bank #s in the rom can go from 0 to 63 (limit of the Sega Mapper). That allows up to 32 MBytes of rom for a game. SSF2 only used 6MBytes of that. You can see, Sega was thinking ahead to bigger games. You can put code in those banks, but it's harder to keep track of the entry points when you do so. Think back to the old SMS days with bank selected games... Bank 0 is fixed and 512KBytes in size - you probably don't need more for game code than that. You use the other banks for accessing more game data... more tiles for the backgrounds and sprites; more data for music and sounds; more data for cut-scenes. Thanks for this! Lots of good information between both you and moon I know the flash carts support it, but I'm looking for a way to be able to put it on a physical cartridge. I have some new boards that support both 2 and 4mb EPROMs (solder a pad to determine which chip you're using), as well as 2mb flash boards with 128kb SRAM, so I was hoping to be able to make some bank switching boards as well. The reason for all of the above is to put games in cart format without having to sacrifice a commercial games pcb for parts, and SSFII isn't a cheap donor (not expensive either, but the overall cost is too much to use for a moderate size print run for the games).
|
|
|
Post by jlf65 on Oct 22, 2014 19:13:24 GMT -5
You'd probably be better off making your own mapper with a PLD and a new PCB to go with it than to sacrifice SSF2 carts. The main reason I pointed out that flash carts support the mode is that makes it easy to test code. A "real" cart is fine as a product, but shit for testing. Sega's dev cart uses the Sega Mapper along with ram. Technically speaking, b7 of each mapper register is a write enable bit to allow devs to write to the ram in that bank.
|
|
|
Post by arcadetv on Feb 5, 2016 9:14:26 GMT -5
I tried to create a muti-rom with krikzz' multirom-tool and put it on a 27C160 and mounted it on a SSF2 cart pcb after removing the SOP44 roms. The tool is supposed to split all input-files into 512k-pieces and I thought it was compatible with the mapper but infact it is not.. The Menu comes up but it just jumps back to game-selection so I believe it is not the same as SSF2 uses the mapper. Here's the tool: krikzz.com/pub/support/everdrive-md/v3/tools/I'm running out of ideas and you guys seem to have the right know-how... I would really appreciate if somebody could confirm that krikzz' menu is using the same registers for bankswitching like SSF2 and if not, maybe some kind of patch could be applied to make it work on the hardware. I even stripped both my SSF2 carts and added them to the stripClub, that's a project of mine where I provide hires scans of naked hardware: stripclub.arcade.tv.de/Also I made this pinout: Thanks guys!
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Feb 5, 2016 9:25:55 GMT -5
Are you removing the mapper chip or the mask rom off of the SSFII cart?
If you're removing the mapper chip, try removing the mask rom and using that PCB as a doner/test cart to see if it works. I don't have a SSFII cart handy to test it out.
|
|
|
Post by arcadetv on Feb 5, 2016 12:24:57 GMT -5
Of course I only removed the mask-roms and left the mapper in place ^^ I used the SEGA pcb, it has the 315-5709. On the Capcom-Board there's jumpers on pins 23 and 24 of the mapper. I know that some carts have only 2 roms and then pin 23 is grounded, also tried that I tried to get an answer in krikkz forum but no luck yet: krikzz.com/forum/index.php?topic=1732.0I'm totally willing to buy a SSF2 on eBay and have it send to you (or just give you the money to buy one) because I really would love to get this to work. Thanks!
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Feb 5, 2016 14:07:38 GMT -5
No need, I just remembered about a box of games I had in the closet. I may have one in there And just making sure Some people get things mixed up when first starting off, so I wasn't sure about your experience level (probably more than mine, tbh ) I'll see if I can get any extra info from some tests.
|
|