128mbit game possible?
Moderator: Moderators
Forum rules
- For making cartridges of your Super NES games, see Reproduction.
-
- Posts: 31
- Joined: Tue Aug 14, 2007 7:02 am
128mbit game possible?
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'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)
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)
Useless, lumbering half-wits don't scare us.
Re: 128mbit game possible?
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:shadowkn55 wrote: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 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.
Re: 128mbit game possible?
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.shadowkn55 wrote: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.
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.Does that means the game is twice as large than Tales of Phantasia ?
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?)
-
- Posts: 31
- Joined: Tue Aug 14, 2007 7:02 am
Continuing from http://nesdev.com/bbs/viewtopic.php?t=4877 before it veers off topic.
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.
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).
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).
-
- Posts: 31
- Joined: Tue Aug 14, 2007 7:02 am
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.
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.
I'm curious how this is going. Did you get it to work yet?
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.
I hope you get it to work. It sounds like a neat project!
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.
I hope you get it to work. It sounds like a neat project!
-
- Posts: 31
- Joined: Tue Aug 14, 2007 7:02 am
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.