It it possible to have a game use the full 24-bit address bus on the snes. I haven't seen a game this large ever, except for the 96mbit version of Star Ocean. But it also seems to exceed the maximum 64mbit limit on LoRom and exploit the memory mapper in the GD7.

I've seen some conflicting information on romlab that pin 48 on a HiRom cart is either A22 or A23. Would special mapping be necessary to get a game this large?

I'm pretty sure Star Ocean is 48Mbit (6kbites), and you probably can't acess the full 128M adress range, because some adresses are used by the console (for RAM and registers) and you have to spare them.
The maximum size, without using an additional bankswitching hardware on the cartridge (which is possibly what Start Ocean does I don't know but it has special hard on the cart), would be 128MBit minus all adresses used by the SNES itself.

Just like it's not possible to have full 64kB of ROM on the NES without bankswitching, because RAM is used at $000-$1fff and registers at $2000-$4017. This leaves $4018-$ffff (slightly less than 48kB) for cartridge usage.

Also, games with special hardware like Star Ocean or Mega Man X2 aren't really LoROM nor HiRom if I'm not mistaken, they are just special. SNES9x notes them as LoRom but I doubt this is correct (again I'm no SNES expert yet)

_________________Life is complex: it has both real and imaginary components.

It it possible to have a game use the full 24-bit address bus on the snes. I haven't seen a game this large ever, except for the 96mbit version of Star Ocean. But it also seems to exceed the maximum 64mbit limit on LoRom and exploit the memory mapper in the GD7.

I've seen some conflicting information on romlab that pin 48 on a HiRom cart is either A22 or A23. Would special mapping be necessary to get a game this large?

The console decodes the ROMSEL signal on 95 megabits of the address space, but split up over 4 separate areas. Without a lot of logic you can efficiently decode this using one 64M ROM configured as HiROM and a 32M configured as LoROM, each enabled under a little more complicated address conditions than usual:

the 64M is additionally enabled with A22, and the 32M with !A22 and both ROM's significant address bit is now controlled by A23, that's it!

You could also I guess manually decode a few more megabits into into the save RAM area too (a lot more logic will be required), though I'd rather fill it with eastereggs. After that, you're absolutely out of space and you've gotta bankswitch.

I haven't seen a game this large ever, except for the 96mbit version of Star Ocean. But it also seems to exceed the maximum 64mbit limit on LoRom and exploit the memory mapper in the GD7.

Just to make it clear, since I see this popping up now and again, the Star Ocean hack only uses standard features of the GD7. It just so happens that only the GD7 supports such large roms.

ALL of the SDD1 capabilities where removed in that hack (including the bank switching). So if you make a cartridge like kyuusaku suggested, you could run StarOcean on it. It really is a 96Mbit static mapping of the ROM (and yes, technically only 95Mbits is accessible).

No. Tales also stores compressed graphics. The difference is that Tales decompresses them in software. neviksti's hack doesn't use any compression, because the original game used hardware decompression, and software decompression would slow the game down a lot.

Anyway, you can get up to ~95mbits, as neviksti said, with a dedicated mapper. But that's it. If you want more, use a programmable MMC. Such as in the S-DD1 or SPC7110. You write which megabyte of ROM you want to map to which range via registers. In theory, both of these chips could allow a 256 megabyte data ROM (bank selection is an 8-bit register). In reality, they're almost certainly both limited to 4 megabyte data ROMs (why have all the extra pins if no games use them?)

Short story: I successfully made a 96mbit cart using Neviksti's version of Star Ocean.

Back on track:
I tried out the circuit you drew up above and it gave me garbled graphics when loading up the game. I got as far as the title screen but that's it. Right now I'm using the onboard MAD-1 for SRAM decoding. There might have been a conflict since A21 assertion is used on most hirom carts I've seen.

I really don't think there's a problem with the circuit, I guess I didn't make this clear before but you have to rearrange any ROM data to match my decoding... By no means do you just put the first 64M on the 64M ROM and the last 32M on the 32M, how you do it for TOP depends on how Neviksti mapped the 4M chunks in the Game Doctor header (which is bankswitched into memory). Since 96M games can't exist with contiguous ROM, I figured this was a given.

Linearly the memory is laid out like so: first half 32M (LoROM), first half 64M (HiROM, last 1M not usable), second half 32M (LoROM), second half 64M (HiROM).

I didn't use Neviksti's rom straight up. I had to reconstruct a binary that fit the snes memory map from the interleaved file.

C0-FF:0000-FFFF
40-7D:0000-FFFF
00-3F/80-BF:8000-FFFF

I put the rom back together in that order similar to how TOP is laid out. The garbled graphics still puzzles me though. Not quite sure if it was how I decoded the 64m block into smaller chunks or if the SRAM was being addresed incorrectly.

When you say "garbled graphics" do you mean the game runs, but the graphics are just messed up? If so, that is a really interesting clue to what is going on.

Please also re-read the GD3 file format specification to verify that you put the ROMs together correctly. In particular note that the "hi-rom sections" are interleaved in the GD3 file format. I don't really remember how I laid out the ROM, so the only way to check now is reading the GD3 header.

Yes I did. I think the garbled graphics was due to improper sram addressing. At the time, I thought the sole purpose of sram was to save game data but then it hit me that it is also used as an extension of system ram. Once I got the sram part working correctly, the game worked perfectly, so to speak. I played through the entire game without too much trouble. The gd3 file format specification was key to reconstructing the rom since the normal deinterleaving tool i used (ucon64) only works up to 48mbit.

That's great to hear you got it working.
One other person emailed me about trying to make such a cartridge several years ago, but I never heard any from that again. So I think you are probably the first to pull this off! A cartridge of StarOcean without a SDD1 chip, congratulations!

If you can provide details on everything you did to get it working it would be greatly appreciated. For one it would cut down on SDD1 cartridges being used for that purpose. I'd certainly like to try it too, but I'd like to avoid any trial and error.

Who is online

Users browsing this forum: No registered users and 2 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum