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)
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 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.
At some point, I wonder whether it'd just be easier to have a LoROM decoded into banks $00-$3F, plus some sort of block-addressed ROM (like the DS uses) in bank $40.
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.
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).
So the ROM size of Star Ocean would DOUBLE without the SD1 ?
Does that means the game is twice as large than
Tales of Phantasia ?
Quote:
Does that means the game is twice as large than Tales of Phantasia ?
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?)
I've come up with a REALLY easy 96M ROM + SRAM decoder using the 139 already in many SNES carts:
Clever huh? It doesn't look like SRAM will conflict with anything but I'm going by internet memory maps.
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.
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.
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!
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.
If you use a hi-rom board with a mad-1 decoder as a donor, all you need is a 74xx139 to access the entire rom memory space.
1. MAD-1 #4
2. MAD-1 #12
3. GND
4. ROM 3(00-3F/80-BF:8000-FFFF)
5. Connected to Pin 15
6. NC
7. NC
8. GND
9. NC
10. NC
11. ROM 1(C0-FF:0000-FFFF)
12. ROM 2(40-7D:0000-FFFF)
13. GND
14. A23
15. Connected to Pin 5
16. VCC
The rest is basically what kind of memory you decide to use for the rom. ROM 1 and 2 are hooked up like hi-rom games (use A15) and ROM 3 would be hooked up like lo-rom (ignore A15).
What about converting the 96mbit Star Ocean GD3 format ROM into the order for burning your EPROMs? You did that manually and if so how? If you made a program to do the conversion that would be appreciated too.
I wrote a program that deinterleaves it and puts it in the order I mentioned earlier. I'll have to dig it up since I haven't used it in a while.
kyuusaku wrote:
I've come up with a REALLY easy 96M ROM + SRAM decoder using the 139 already in many SNES carts:
Clever huh? It doesn't look like SRAM will conflict with anything but I'm going by internet memory maps.
Hello kyuusaku,
sorry for replying to such an old post of you, but I'm not quite sure if there's an error in your schematic.
I tried to check the truth tables for it and came up with the following problem.
EDIT: I found an error in my verification after I posted, so I deleted my findings from this post! Going to recheck it, please ignore my comment for now
So far thank you for your great circuit
If I really find an error, I'll let you know.
Thanks!
JohnDie
Hey guys, first time poster on here but long time reader.
I hate to bring up such an old post, but I was wondering if anyone on here has had any luck with this 96mbit on a standard cart idea? This idea is really interesting, as I'd love to be able to make a Star Ocean repro without using a SO donor. I pm'd shadowkn55, but its been so long he doesnt have the documentation anymore (although he did send me the GD3 header info, thanks!). I was just wondering if anyone on here had tinkered with this any more and got it working properly? Or better yet does anyone have the already re-arranged Star Ocean file anymore?
Hey Guys
Anyone here got a re-arranged rom or more detailed instructions on how to do so?
A full schematic wouldn't hurt either.
Thanks
Here is a map that can run Star Ocean 96mbit:
Code:
<?xml version="1.0" encoding="UTF-8"?>
<cartridge region="NTSC">
<rom name="program.rom" size="0xc00000"/>
<map id="rom" mode="linear" address="00-3f:8000-ffff" offset="0x000000"/>
<map id="rom" mode="linear" address="40-6f:0000-7fff" offset="0x800000"/>
<map id="rom" mode="linear" address="40-7f:8000-ffff" offset="0x200000"/>
<map id="rom" mode="linear" address="80-bf:8000-ffff" offset="0x400000"/>
<map id="rom" mode="linear" address="c0-ff:0000-7fff" offset="0xa00000"/>
<map id="rom" mode="linear" address="c0-ff:8000-ffff" offset="0x600000"/>
<map id="rom" mode="linear" address="c0:0000-7fff" offset="0x000000"/>
<ram name="save.ram" size="0x2000"/>
<map id="ram" mode="linear" address="20-3f:6000-7fff"/>
<map id="ram" mode="linear" address="a0-bf:6000-7fff"/>
</cartridge>
"linear" in this case just means that A15 is not connected as one of the address pins to the ROM chip, it's ignored.
The weirdest part is is the last ROM map line. It's required for the game to play, but it doesn't make a lot of sense to me to design a cart like that. Perhaps it's a GD3 quirk.
As for the original topic, the max sensible ROM size is 95mbit:
00-3f:8000-bfff
40-7d:0000-ffff
80-bf:8000-ffff
c0-ff:0000-ffff
With weirder granularity, you could push it to 110.125mbit:
00-3f:4380-ffff (0xbc80 bytes granularity)
40-7d:0000-ffff
80-bf:4380-4fff
c0-ff:0000-ffff
0x5e4000 + 0x400000 + 0x3e0000 = 0xdc4000
With absolutely psychotic granularity, you could grab a few more unused areas:
2000-20ff
2184-21ff (would even be fetched from a different bus)
2200-3fff
4000-4015 (slowest speed)
4018-41ff (slowest speed)
420e-42ff
4380-ffff
= 0xdeec bytes/block.
0x6f7600 + 0x400000 + 0x3e0000 = 0xed7600 = 118.73mbit
Anything further will require a memory map controller. Which is really the sensible option after 95mbit. I'd even do it after 64mbit.
I find it wasteful and stupid that the S-DD1 and SPC7110 had MMCs for 48mbit and 40mbit games.
NROM-368 uses a comparator IC to approximate "weirder granularity" on the NES: $4800-$FFFF is decoded as ROM.
But beyond 95 Mbit, you'd probably want to consider using a small boot ROM for the game engine and have the cart copy things from a surface-mounted microSD card into RAM. That'd give 16 Gbit for a couple bucks.
WRAM is too small to do anything useful, except play Space Invaders I guess :P
If you put 4MB of SRAM on there (doesn't need the battery, just has to avoid DRAM refresh), and had an IC to upload blocks from a serial NAND chip to the SRAM banks quickly, that'd work well enough.
byuu wrote:
Here is a map that can run Star Ocean 96mbit:
Code:
<?xml version="1.0" encoding="UTF-8"?>
<cartridge region="NTSC">
<rom name="program.rom" size="0xc00000"/>
<map id="rom" mode="linear" address="00-3f:8000-ffff" offset="0x000000"/>
<map id="rom" mode="linear" address="40-6f:0000-7fff" offset="0x800000"/>
<map id="rom" mode="linear" address="40-7f:8000-ffff" offset="0x200000"/>
<map id="rom" mode="linear" address="80-bf:8000-ffff" offset="0x400000"/>
<map id="rom" mode="linear" address="c0-ff:0000-7fff" offset="0xa00000"/>
<map id="rom" mode="linear" address="c0-ff:8000-ffff" offset="0x600000"/>
<map id="rom" mode="linear" address="c0:0000-7fff" offset="0x000000"/>
<ram name="save.ram" size="0x2000"/>
<map id="ram" mode="linear" address="20-3f:6000-7fff"/>
<map id="ram" mode="linear" address="a0-bf:6000-7fff"/>
</cartridge>
"linear" in this case just means that A15 is not connected as one of the address pins to the ROM chip, it's ignored.
The weirdest part is is the last ROM map line. It's required for the game to play, but it doesn't make a lot of sense to me to design a cart like that. Perhaps it's a GD3 quirk.
As for the original topic, the max sensible ROM size is 95mbit:
00-3f:8000-bfff
40-7d:0000-ffff
80-bf:8000-ffff
c0-ff:0000-ffff
With weirder granularity, you could push it to 110.125mbit:
00-3f:4380-ffff (0xbc80 bytes granularity)
40-7d:0000-ffff
80-bf:4380-4fff
c0-ff:0000-ffff
0x5e4000 + 0x400000 + 0x3e0000 = 0xdc4000
With absolutely psychotic granularity, you could grab a few more unused areas:
2000-20ff
2184-21ff (would even be fetched from a different bus)
2200-3fff
4000-4015 (slowest speed)
4018-41ff (slowest speed)
420e-42ff
4380-ffff
= 0xdeec bytes/block.
0x6f7600 + 0x400000 + 0x3e0000 = 0xed7600 = 118.73mbit
Anything further will require a memory map controller. Which is really the sensible option after 95mbit. I'd even do it after 64mbit.
I find it wasteful and stupid that the S-DD1 and SPC7110 had MMCs for 48mbit and 40mbit games.
Can't say i quite got it yet.
I open the star ocean 96 mbit rom (without header) in my hex editor.
and open a new file to copy all the parts of the SO rom in the correct order.
then i look at the first line: address="00-3f:8000-ffff" offset="0x000000"
does that mean i need to copy 0x008000 - 0x3fffff?
sorry if i'm acting a bit noob
I think I can understand byuu's GD7 memory map explanation, altough I wonder how he checked it is right, since I couldn't find any information on internet about ExtROM mapping in GD7. In fact, I tried to compare those two lines:
Code:
<map id="rom" mode="linear" address="40-6f:0000-7fff" offset="0x800000"/>
<map id="rom" mode="linear" address="40-7f:8000-ffff" offset="0x200000"/>
...because I think they should be like this:
Code:
<map id="rom" mode="linear" address="40-7f:0000-7fff" offset="0x800000"/>
<map id="rom" mode="linear" address="40-7f:8000-ffff" offset="0x200000"/>
... considering that $7E-7F:$0000-FFFF is the WRAM and it must be blank.
Anyway, just in case I could undo the mapping to build a working SMC file, which emulator would be able to run such a big SMC file?
Fusoya released a fixed SNES9x 1.53 version recently which allowed up to 64Mb in ExtLoROM mode, but I don't know any emulator which can reach 96Mbit. I guess the only way to test this SMC file should be making a customized cartridge which supports 95Mbits, right?
I used the Super Sleuth debugger to look at every memory address.
I never would have figured out "<map id="rom" mode="linear" address="c0:0000-7fff" offset="0x000000"/>" by guessing. That one is weird as hell.
> ... considering that $7E-7F:$0000-FFFF is the WRAM and it must be blank.
This confuses everyone.
Real carts are comprised of logic chips to test and select lines, and they utilize the /CART line which is low for 00-3f,80-bf:8000-ffff, 40-7d,c0-ff:0000-ffff.
My maps describe layouts, and try and do so with simple maskable conditions. Eg $00-7f:8000-ffff's range can be tested via: if((addr & 0x808000) == 0x008000) ...;
My maps are designed for emulation usage, as simulating the logic chips would be too slow, and describing them would be ridiculously hard, let alone others understanding them.
So the idea with my maps are that conflict regions aren't going to occur on real carts, so don't support allowing them. If you are iterating through my list, then you decode WRAM first. If you are building a table of mapped ranges, then you map WRAM last. Either way, banks $7e-7f are always WRAM, regardless of what the map says. The map only looks that way so that the address masks are simpler.
Is star ocean so popular and valuable, would it justify making a cartridge (custom) that had provisions for 96 Meg's (3 x 32 tsop to 36mask) so long as no custom chips are used? Am I understanding this right? I forget who, someone wants to make a SO using a standard cartridge format without special chips?
I am in the process of designing my own cartridge so it wouldn't be too crazy to look into this..... If enough people were interested.
Or have I completely missed the point?
Markfrizb wrote:
Is star ocean so popular and valuable, would it justify making a cartridge (custom) that had provisions for 96 Meg's (3 x 32 tsop to 36mask) so long as no custom chips are used? Am I understanding this right? I forget who, someone wants to make a SO using a standard cartridge format without special chips?
I am in the process of designing my own cartridge so it wouldn't be too crazy to look into this..... If enough people were interested.
Or have I completely missed the point?
Yes, you got the point. Besides, it's the kind of technical challenge that I like to face.
I'm already designing a board with 3 flash memories, but there are some room limitations that I will have to overcome.
Before a cart is made, wouldn't it be prudent to get a working code first ? Or is that not an issue if the cart is made correctly, would the code run as-is?
I would think you could get 3 tsop adapters inside it. I've seen pic's of your board ( I think ) , you use a 16 bit 32m EPROM, right?
Or maybe easier is to mount 2 tsop on 1 adapter board..... Or for that matter, have all 3 on an adapter board (no longer compliant with the 36 pin mask) with decoder also on the adapter....
Just thinking out loud....
When you make your own board, you don't need any "adapter", since you make all "adaptions" in the board itself.
And yes, I use 27C322, but I'm thinking of 29LV3211, which are smaller, 8 bits bus width, and less power consumption. It's the best way to overcome those space limitations on the board, since 27C322 are too big. The problem with 29LV3211 is that it's powered with 3.3V, so the logic levels are not compatible.
Yep, it would be pretty hard to get 3 of those 42 pin monsters on a cart, you are right. I was referring to the tsop adapters. There is a discussion on here about the low voltage flash roms and level translators to use the LV roms.
In my design, i would still use the tsop adapter as I, like many, am not very good at soldering those tiny legs on a pcb. So I prefer to use the adapters. Even so, getting 3 of the tsop adapters would still pose a challenge. But making a 64m adapter would get rid of one of them. Too bad the 64m 5v flash roms are really hard to find.
I'm still learning.
magno wrote:
When you make your own board, you don't need any "adapter", since you make all "adaptions" in the board itself.
And yes, I use 27C322, but I'm thinking of 29LV3211, which are smaller, 8 bits bus width, and less power consumption. It's the best way to overcome those space limitations on the board, since 27C322 are too big. The problem with 29LV3211 is that it's powered with 3.3V, so the logic levels are not compatible.
Aren't the 29L3211 chips 16-bit? How do would you wire it to run in 8-bit mode?
I know they can be used in the actual Star Ocean cart (SDD-1) as a drop in replacement, using a voltage regulator to step down to 3.3V. But there are also the 26L6420 chip which is 64Mbit, or alternatively the 26L12811 which is 128Mbit (that would be ideal, as it would require only 1 chip). All of those are in the same 3.3V SOP44 package.
getafixx wrote:
the 26L12811 which is 128Mbit (that would be ideal, as it would require only 1 chip)
The datasheet I found (for the MX26L12811MC) says it can only be used in word mode...
Also, I'm not altogether convinced you could have safely used it in a 5V system without level shifters or creative interpretation of the datasheet (by e.g. running it at 4V and relying on the 1V official overvoltage allowance)
lidnariq wrote:
Also, I'm not altogether convinced you could have safely used it in a 5V system without level shifters or creative interpretation of the datasheet (by e.g. running it at 4V and relying on the 1V official overvoltage allowance)
Over at racketboy forums: The 29L3211 in a Star ocean cart using an AMS1117 3.3V voltage regulator.
http://www.racketboy.com/forum/viewtopi ... &start=520
Sorry, I didn't mean that as "it won't work". I meant "I fear that slightly exceeding the rated capabilities of the IC will cause premature failure"
That said, his solder jobs are beautiful.
getafixx wrote:
Aren't the 29L3211 chips 16-bit? How do would you wire it to run in 8-bit mode
No, they aren't. You can set them in word or byte mode by tying pin 33 to GND or Vcc. Anyway, if they were 16 bit only, you could multiplex their output.
lidnariq wrote:
Also, I'm not altogether convinced you could have safely used it in a 5V system without level shifters or creative interpretation of the datasheet (by e.g. running it at 4V and relying on the 1V official overvoltage allowance)
No, you SHOULDN'T do that. The datasheet is crystal clear about that: absolute maximum 4V supply, typical 3.3V+10%. I don't know where you read that "
1V official overvoltage allowance", but the "[b]Absolute Maximum Ratings" can't be never exceeded. Anyway, the problem in using 29LV3211 is not the power supply (linear regulators are cheap as hell) but the Vih: the HIGH output level is, at least, 2.4V and at most, 3.3V and the TTL HIGH input level is, at least 2V. At first glance, you may ask where the problem is, because 2.4V is higher than 2V so the TTL logic after the 29LV3211 flash should sample the proper logic value, but this becomes fussy when there are long traces between flash and CPU, an edge connector and supply noise in each digital chip (specially, those synchronous to the MCLK). It's confirmed that 29LV3211 flash memories cause problems when used directly as a mask ROM replacement. They MIGHT work when used connected to some special chip like SA-1 or Super-FX, but not 100% reliable either.
Interesting. From the way they were talking on racketboy I figured they had been working great... Maybe its just in conjunction with the SDD-1 chip that they seem to work good?
magno wrote:
No, you SHOULDN'T do that. The datasheet is crystal clear about that: absolute maximum 4V supply, typical 3.3V+10%. I don't know where you read that "1V official overvoltage allowance", but the "[b]Absolute Maximum Ratings" can't be never exceeded.
The datasheet I saw (MX26L12811MC, P/N PM0990, REV 1.0 OCT 29 2003) said:
page 1:
Latch-up protection is proved for stresses up to 100 milliamps on address and data pin from -1V to VCC + 1V ← here
page 21:
Code:
ABSOLUTE MAXIMUM RATINGS
[…]
Voltage with Respect to Ground Voltage on any signal ……… -2.0 V to 5.0 V
[…]
Notes: 1. […]Maximum DC voltage on input or I/O pins is Vcc + 0.5V. During voltage transitions, input or I/O pins may overshoot to VCC + 2.0V for periods < 20 ns.
[…]
OPERATING RATINGS
Vcc Supply Voltages
Vcc for full voltage range……… +3.0 V to 3.6 V
Operating ranges define those limits between which the functionality of the device is guaranteed.
You'll note, that the OR is not an AMR. But yes, it's still a terrible plan.
You are talking about MX26L12811MC and I'm talking about MX29LV3211, nothing to do one with the other. The 29V3211 is pretty clear about all what I said before.
Anyway, connecting this flash memory to S-DD1 doesn't guarantee it will work. S-DD1 reads from the flash to decode data or to pass-through data to the SNES, so stressing the S-DD1 could corrupt some of the bits because of the 2.0V high level detection.
Well, i've been tinkering with this 96mbit Star Ocean project for a couple months, and have made no headway at all. I got a linear rom from Mottzilla (thanks again!) that I hoped was the answer, but when i broke it down into three 32mbit parts and soldered it all to a cart, it still didnt work. I then doubled back to this thread and checked again what was posted earlier, about the different rom sections (C0-FF:0000-FFFF, 40-7D:0000-FFFF, 00-3F/80-BF:8000-FFFF) and it still makes no sense to me. Maybe that makes me daft, but I'm still new to all this.
Can anyone break this down a little for me? I just can't seem to understand how I need to order the rom file, and split it... and seeing as RetroUSB no longer sells Star Ocean, I really want to be able to make this work without gutting a donor. Whatever I have tried thus far has clearly been incorrect, and it looks like the only thing I'm missing is the rom ordering. I have followed the '139 pinout to work according to shadowkn55, but to no avail.
Can anyone help me out?
I got this from somewhere, does that help?
If you use a hi-rom board with a mad-1 decoder as a donor, all you need is a 74xx139 to access the entire rom memory space.
1. MAD-1 #4
2. MAD-1 #12
3. GND
4. ROM 3(00-3F/80-BF:8000-FFFF)
5. Connected to Pin 15
6. NC
7. NC
8. GND
9. NC
10. NC
11. ROM 1(C0-FF:0000-FFFF)
12. ROM 2(40-7D:0000-FFFF)
13. GND
14. A23
15. Connected to Pin 5
16. VCC
The rest is basically what kind of memory you decide to use for the rom. ROM 1 and 2 are hooked up like hi-rom games (use A15) and ROM 3 would be hooked up like lo-rom (ignore A15).
Yeah that was mentioned previously in this post, as well in that file you sent me. however, it doesnt explain which parts of the rom get moved around before the files are split.
I would guess that you should be able to split it into three even 32mb pieces.
Given the names ROM 1, 2, and 3 I would suspect that those refer to the 1st, second, and last 32 megabit pieces of the 96 megabit ROM. That means on ROM 3, you need to skip A15 when wiring that ROM to the board. For HiROM the signals on the Maskrom connect as you suspect, A15 to A15, A16 to A16. But on LoROM, which this 3rd ROM is, you skip A15 on the ROM socket, and instead connect the ROM 3 EPROM's A15 to A16 on the Board Socket. A16 goes to A17 on the board socket. And so on.
That's my understanding, but I may be incorrect. I have never made a Star Ocean 96 meg cartridge before.
I might have to give that a try... I figured he was talking about how the '139 was wired to the MAD-1 it would register the first 2 roms as Hirom, and the last as lorom. Maybe its as you say?
MAD-1 doesn't control HiROM/LoROM connection of the actual eproms. You need to connect two of them as I said, in HiROM fashion and the final one in LoROM fashion (skipping A15 on the socket). If you wired all 3 roms address lines exactly the same/all together then it won't work properly. Perhaps all that was wrong was you connected the upper address lines on ROM 3 incorrectly (non LoROM fashion).
Alright, I will give that a try and report back.
Well...i feel sheepish. That's all it was, just the 3rd rom was wired as Hirom instead of Lorom.
Thanks for pointing out that obvious step to me Mott!
Just one last question about this, and this is probably aimed more at shadowkn55. It's been mentioned on here a few times that the SNES can only access about ~95Mbit of data, so being that this game is 96Mbit, will there be issues with it crashing or glitching later on? Has anyone played it on an actual cart long enough to see?
EDIT: I just re-read a pm I got from Shadowkn55 a few months ago, and he stated that he did indeed play the game through to the end, and it worked. He did mention a couple times where the cart crashed, but he figured it was due to power consumption issues, as he said the cart never crashed twice in the same place. To avoid this, I'm going to run thicker VCC and GND wires to my roms and see if that takes care of it. The other thing might be adding some caps to take care of potential noise.
A well-formed patch will just have no data in the 1 Mbit hole where the internal RAM is ($7E0000-$7FFFFF).
That last bit of ROM is never accessed. The 96Meg hack as far as I've heard is fully playable.
kyuusaku wrote:
I've come up with a REALLY easy 96M ROM + SRAM decoder using the 139 already in many SNES carts:
Clever huh? It doesn't look like SRAM will conflict with anything but I'm going by internet memory maps.
while visiting this topic (again), I was drawing up a schematic for the star ocean cart and I noticed 2 different approaches to using the 139. The above pic and below post........
1. MAD-1 #4
2. MAD-1 #12
3. GND
4. ROM 3(00-3F/80-BF:8000-FFFF)
5. Connected to Pin 15
6. NC
7. NC
8. GND
9. NC
10. NC
11. ROM 1(C0-FF:0000-FFFF)
12. ROM 2(40-7D:0000-FFFF)
13. GND
14. A23
15. Connected to Pin 5
16. VCC so my question is.......do both methods work? Getafixx tried the method illustrated in the pic and said it worked. I believe it uses the mad1 although it's not referenced. obviously, the other method (in green) uses the mad1.
thanks!
Markfrizb wrote:
kyuusaku wrote:
I've come up with a REALLY easy 96M ROM + SRAM decoder using the 139 already in many SNES carts:
Clever huh? It doesn't look like SRAM will conflict with anything but I'm going by internet memory maps.
while visiting this topic (again), I was drawing up a schematic for the star ocean cart and I noticed 2 different approaches to using the 139. The above pic and below post........
1. MAD-1 #4
2. MAD-1 #12
3. GND
4. ROM 3(00-3F/80-BF:8000-FFFF)
5. Connected to Pin 15
6. NC
7. NC
8. GND
9. NC
10. NC
11. ROM 1(C0-FF:0000-FFFF)
12. ROM 2(40-7D:0000-FFFF)
13. GND
14. A23
15. Connected to Pin 5
16. VCC so my question is.......do both methods work? Getafixx tried the method illustrated in the pic and said it worked. I believe it uses the mad1 although it's not referenced. obviously, the other method (in green) uses the mad1.
thanks!
Hey Mark I have begun reviewing such a 96Mb cartridge, and the first mapper without the MAD-1. It doesn't use a MAD-1 at all. I detailed the ROM pinouts here:
http://www.cs.umb.edu/~bazz/snes/96MbCart/see derp.html
hi,
sorry that i pick up this old thread, but i read all pages and have a last question.
The max ist 64MB(Eprom) + 32MB(Eprom) + 8MB SRAM
Would that mean have to use 1x 8MB Eprom + 1 x 4MB Eprom (i.e.27c322?)
Or could you use 2x27C322 + 1x 27C322 eproms?!
Has anyone built a 96 Star Ocean Cart with this solultion?!
Thanks
red
Anything totaling to atleast 128Mbit that places the rom image in all the right spots should be capable of working. 3x32Mb, 1x64Mb + 1x32Mb, 6x16Mb, 1x128Mb with wasted space, it's all the same in the eyes of the SNES if its all decoded properly with the expected data.
infiniteneslives wrote:
Anything totaling to atleast 128Mbit that places the rom image in all the right spots should be capable of working. 3x32Mb, 1x64Mb + 1x32Mb, 6x16Mb, 1x128Mb with wasted space, it's all the same in the eyes of the SNES if its all decoded properly with the expected data.
So, there isn't a billion "mappers" like NES? It's just the speed of the ROM?
For games with 32 Mbit or smaller ROM and no coprocessor that aren't weird multicarts, the two "mappers" you really have to deal with are LoROM (skip A15) and HiROM (skip A22).
The total 65816 address space is 128 Mbit. Subtracting areas reserved for the console (banks $7E and $7F and the first half of $00-$3F and $80-$BF) leaves 95 Mbit. For anything bigger than that, you'll need a Real Mapper of some sort.
My post was in reference to a 128Mbit game that didn't have any co-processors as Tepples brought up. Exotic SNES carts (non Hi/Lo ROM) often have co-processors in comparison to the NES's 'memory mappers'. See
wiki if you've got one of those my statement is null and void. I'm not certain, but I'd guess that over 95% of SNES games don't have any special chip/co-processor and are just plain rom uniquely mapped to the SNES memory space (don't forget all important mirroring though) via an address decoder such as the MAD.
Sorry for being a little off topic. Actually, the SNES Hi/Lo-ROM reproduction flash boards from infinitelives can go up to 128mbit so it's nearly there
Is there a way to see at runtime if a genuine infinitelives repro board is in use?
slobu wrote:
Sorry for being a little off topic. Actually, the SNES Hi/Lo-ROM reproduction flash boards from infinitelives can go up to 128mbit so it's nearly there
Well they've got support for up to 128Mbit of flash memory, they could be configured to fill as much of the unused system space as possible though. But as Tepples pointed out you'll never be able to see all that 128Mbit worth at one time. By banking it's possible to use it all though. My main motive was for stuffing a bunch of games on there for a multicart via reset toggling, but a select register could be implemented as well similar to NES memory mappers. That and it didn't cost anything in regards to the design once two flash chips were draw out aside from a CPLD pin which was already available.
Quote:
Is there a way to see at runtime if a genuine infinitelives repro board is in use?
It depends on how I configured it I suppose. With some games you actually need to be undetectable to run (SRAM size and mirroring mostly). I'm about to publish exactly how things are configured on all the different 'standard' size choices. So verifing that config would be possible. Probably closer to you goal though would be to read the device ID off of the flash chips. Granted using the same flash chips would get around that, but the memories I use are not compatible with typical TSOP to DIP adapters because they're 48 pin TSOP's. But that doesn't stop one from making one that would work. There is other trickery that could be inserted into the CPLD as well I suppose, but not likely to be done on my production boards.
Hey there people, I've read the entire topic but I still have not found the exact plain solution how to make Star Ocean cart. Well maybe there were some theories and debates but nothing 100% confirmed to be working on real hardware so.... has anyone figured out which portions of the code goes where?? How EXACTLY roms should be connected on the cart and which part of the code goes where?? Which part should be connected like normal and which part should be interleaved or connected different?? How about if I want to use combination of 8MB+4MB memories or even one 16MB memory?? I got kind of lost and now I have no idea what I'm supposed to do after reading all of this. I'd be so grateful if anyone made it very clear how to do the cart and provided me with confirmed & verified information. That would be so much appreciated!! Many thanks in advance!!
MaarioS wrote:
Hey there people, I've read the entire topic but I still have not found the exact plain solution how to make Star Ocean cart. Well maybe there were some theories and debates but nothing 100% confirmed to be working on real hardware so.... has anyone figured out which portions of the code goes where?? How EXACTLY roms should be connected on the cart and which part of the code goes where?? Which part should be connected like normal and which part should be interleaved or connected different?? How about if I want to use combination of 8MB+4MB memories or even one 16MB memory?? I got kind of lost and now I have no idea what I'm supposed to do after reading all of this. I'd be so grateful if anyone made it very clear how to do the cart and provided me with confirmed & verified information. That would be so much appreciated!! Many thanks in advance!!
The decompressed star ocean is a combination of lo rom and extended Hi rom mappers. Roms 1&2 are extended hi rom mapped just like Crimson echos and tales of phantasia. Rom 3 is mapped as lo rom where A15 is skipped. A22 determines when the decoder is active for the ex hi rom and lo rom mappings. When A22 is low, it activates the decoder (139) to enable rom 3 and when it's high, it deactivates rom 3 and enables the decoder to run as extended hi rom where A23 determines which rom is selected between Rom1 and Rom2.
Here are some examples:
Star ocean using the "cart creation" pcb.
http://youtu.be/vMVl1shH_50Star ocean using donor snes cart
http://youtu.be/_gnYuvCplE4You could have star ocean in 1 big rom but you'd need to do some address shifting (because of A15). It it could fit in a single rom, but without additional circuitry, it wouldn't work.
That really helped me a lot and now it is much easier to do. Many thanks!!
So as I can see this configuration is still correct where 64Mb is the first 8MB of code (as ExHIROM) and 32Mb is the last 4MB of code connected different??
http://www.cs.umb.edu/~bazz/snes/96MbCart/derp.htmlBut what really makes me wonder- how did you manage to make Star Ocean to work with only MAD-1 and without using any decoder (at least I didn't see anything)??
MaarioS wrote:
That really helped me a lot and now it is much easier to do. Many thanks!!
So as I can see this configuration is still correct where 64Mb is the first 8MB of code (as ExHIROM) and 32Mb is the last 4MB of code connected different??
http://www.cs.umb.edu/~bazz/snes/96MbCart/derp.htmlBut what really makes me wonder- how did you manage to make Star Ocean to work with only MAD-1 and without using any decoder (at least I didn't see anything)??
If you are referring to the donor star ocean build, I have very tiny decoders built on the TSOP boards. So they are there, you just can't see them.
Yes, the last 4mb (3rd rom) is wired just as if it was a lo rom mapper. I reorganized my star ocean rom data in rom3 to reduce my wiring which is why you
don't see a bunch of wires running around....
Referring to the link you posted, that's not how my decoder is connected but if you had 2 flash roms (1 64mbit and 1 32mbit) then that decoder configuration woukd work. That decoder diagram doesn't show how A23 is used in a exhirom decoding. If you are using a donor, then I wouldn't use that diagram becuse the sram enabling is already handled by the mad1. All you need to be concerned about is how to handle all 3 roms' OE lines and wiring rom3 as if it was a lo rom (skip A15).
Good luck! I'm sure you'll get there.
I did some work on the 96 Mbit cart in
another topic. I discovered that the 96 Mbit cart from infiniteneslives.com takes a ROM image in the order $400000-$7DFFFF, 128 KiB of padding, $C00000-$FFFFFF, top halves of banks $00-$3F, and top halves of banks $80-$BF. Is this true of your cart as well?
tepples wrote:
I did some work on the 96 Mbit cart in
another topic. I discovered that the 96 Mbit cart from infiniteneslives.com takes a ROM image in the order $400000-$7DFFFF, 128 KiB of padding, $C00000-$FFFFFF, top halves of banks $00-$3F, and top halves of banks $80-$BF. Is this true of your cart as well?
I'm not sure if I understand that completely at all. Either way I made my cart this way: 8MB memory is configured as ExHIROM and as far as I'm concerned ExHIROM games have to be kind of swapped: SECOND 4MB of code goes to the FIRST half of the memory and FIRST 4MB of code goes to the SECOND part of the memory. After that I interleaved data of ROM3 (last 4MB of code) and connected it to my board. After all that I connected my memories to PCB and added a 74LS139 decoder and connected everything this way:
16-5V
15-MAD-1 pin #04
14-MAD-1 pin #12 (SNES con. pin#47-A22)
13-GND
12-/OE of 4MB memory (ROM3)
11-/OE of 8MB memory (ROM2+ROM1)
10-
09-
(and pin#08 is of course GND)
Either way it is not working
.....
Load the test ROM
Holy Striker Batman (12 MiB) onto your card, run it on your Super NES, and tell me what numbers you get.
MaarioS wrote:
tepples wrote:
I did some work on the 96 Mbit cart in
another topic. I discovered that the 96 Mbit cart from infiniteneslives.com takes a ROM image in the order $400000-$7DFFFF, 128 KiB of padding, $C00000-$FFFFFF, top halves of banks $00-$3F, and top halves of banks $80-$BF. Is this true of your cart as well?
I'm not sure if I understand that completely at all. Either way I made my cart this way: 8MB memory is configured as ExHIROM and as far as I'm concerned ExHIROM games have to be kind of swapped: SECOND 4MB of code goes to the FIRST half of the memory and FIRST 4MB of code goes to the SECOND part of the memory. After that I interleaved data of ROM3 (last 4MB of code) and connected it to my board. After all that I connected my memories to PCB and added a 74LS139 decoder and connected everything this way:
16-5V
15-MAD-1 pin #04
14-MAD-1 pin #12 (SNES con. pin#47-A22)
13-GND
12-/OE of 4MB memory (ROM3)
11-/OE of 8MB memory (ROM2+ROM1)
10-
09-
(and pin#08 is of course GND)
Either way it is not working
.....
Your decoder is wrong....
139 pinout should be as follows:
1 mad1 pin 4 or you can take the OE signal from PIN 33 of the mask rom.
2 A22
3 gnd
4 ROM3 OE
5 pin 15 of 139 (this is where A22 controls WHICH decoder is active - the 139 is 2 decoder in 1 package)
6 n/c
7 n/c
8 gnd
9 n/c
10 n/c
11 exhirom ROM1 OE
12 exhirom ROM2 OE
13 gnd
14 A23 (this is what controls which rom is used WITHIN the exhirom mapping - Rom1 or Rom2)
15 from pin 5 of 139
16 VCC
SO when A22 is low, it outputs a OE on output1 and output2 is high (which deactivates the second decoder side)
when A22 is high, it outputs OE on output2 and output1 is high. So Rom3 is deactivated and 2nd decoder of the 139 is now enabled wherein A23 decides which of the 2 roms will be activated in the EXhiRom configuration.
Remember, ONLY 1 rom can ever be active at any one time.
have fun!
This is actually the same thing as I did. I put ROM2+ROM1 (in this order) into 8MB memory and connected it as I described below. Still it doesn't work...
But perhaps I should program my 8MB as tepples suggests: ROM1+ROM2??
MaarioS wrote:
This is actually the same thing as I did. I put ROM2+ROM1 (in this order) into 8MB memory and connected it as I described below. Still it doesn't work...
But perhaps I should program my 8MB as tepples suggests: ROM1+ROM2??
Ok, since you are using 1 8mbyte rom, then A23 would connect to the highest address line and the OE would connect to 2nd decoder output1 and then you would ground the decoder pin 14.
This is of the cuf, though.... you might not need to use both sides of the decoder....
edit: yeah, I went back and re-read your decoder connections - you need A23 on your high address line.
Are you sure settings you provided are 100% correct and confirmed?? This would mean either something must be wrong on my board (some trace is broken??) or the ROM I'm using is bad. Here are checksums of the 12MB decompressed deinterleaved ROM I'm using (with removed header):
CRC32: B1D82240
MD5: 8AC766702BE51975FAAB7A431C89D9B2
SHA-1: 7DBAA0265BB5D33422808BAD1041CDC8F9585EB4
Is this correct??
MaarioS wrote:
Are you sure settings you provided are 100% correct and confirmed?? This would mean either something must be wrong on my board (some trace is broken??) or the ROM I'm using is bad. Here are checksums of the 12MB decompressed deinterleaved ROM I'm using (with removed header):
CRC32: B1D82240
MD5: 8AC766702BE51975FAAB7A431C89D9B2
SHA-1: 7DBAA0265BB5D33422808BAD1041CDC8F9585EB4
Is this correct??
My settings are correct as they are in use in my pcb's shown in the youtube links.
My check sums would be different since I reorganized my rom data.
Alright I tried this test: I wrote an ExHIROM game on my 8MB memory (Crimson Echoes) and launched it using 2 configurations:
1st:
/OE of ROM goes directly to MAD-1 pin #04
74LS139 connected like this:
16-5V
15-MAD-1 pin #04
14-MAD-1 pin #12
13-GND
12-NC
11-NC
10-NC
09-NC
(pin#08 to GND)
So in this configuration LS139 is not involved at all but I thought it was worth a try anyway. Either way this configuration
works perfectly fine2nd:
/OE of ROM goes ONLY to LS139 pin#11
74LS139 connected like this:
16-5V
15-MAD-1 pin #04
14-MAD-1 pin #12
13-GND
12-NC
11-/OE of ROM
10-NC
09-NC
(pin#08 to GND)
This configuration
does NOT work. I think I know now where the problem is located. Do you think this configuration should work with regular ExHIROM game?? If it should then I have no idea why this one doesn't work
Oh and by the way if this is important: I'm using S29GL064N90TFI04 memory (I switch 8bit mode for SNES) which is 8MB and I use stepdown converter 5V->3,6V by using 2x 1N4148 diodes
MaarioS wrote:
Alright I tried this test: I wrote an ExHIROM game on my 8MB memory (Crimson Echoes) and launched it using 2 configurations:
1st:
/OE of ROM goes directly to MAD-1 pin #04
74LS139 connected like this:
16-5V
15-MAD-1 pin #04
14-MAD-1 pin #12
13-GND
12-NC
11-NC
10-NC
09-NC
(pin#08 to GND)
So in this configuration LS139 is not involved at all but I thought it was worth a try anyway. Either way this configuration
works perfectly fine2nd:
/OE of ROM goes ONLY to LS139 pin#11
74LS139 connected like this:
16-5V
15-MAD-1 pin #04
14-MAD-1 pin #12
13-GND
12-NC
11-/OE of ROM
10-NC
09-NC
(pin#08 to GND)
This configuration
does NOT work. I think I know now where the problem is located. Do you think this configuration should work with regular ExHIROM game?? If it should then I have no idea why this one doesn't work
Oh and by the way if this is important: I'm using S29GL064N90TFI04 memory (I switch 8bit mode for SNES) which is 8MB and I use stepdown converter 5V->3,6V by using 2x 1N4148 diodes
The first decoder example is completely pointless. It does nothing. The outputs aren't even connected.
I don't know what's going on in the second one. Using the ExHiRom game as an example, and using a 64mbit flash rom (the 3volt aspect is a WHOLE other topic) you shouldn't need any decoders at all. It should be how your rom is programmed and using A23 (mask rom pin 35, cart edge 48) as the highest address connection. It's because of the different mapping between the ExHirom and lo rom is why you have a need for a decoder because you most likely will use 2 separate roms and thus, the need for a decoder to control the 2 devices. How your rom works with Crimson Echos as exhiRom is a mystery to me. You haven't mentioned how you've connect A23 or how you built your rom with the data. Your second decoder example as an ExHiRom -- a22 isn't used to decode a ExHiRom and because you are using a 8m flash rom, deciding isn't needed. That make sense?
A22 of ROM goes directly to SNES A23, nothing was changed. By doing the 2nd configuration I wanted to confirm that ExHIROM game is read ONLY when SNES A22 is high. So if this doesn't work, this means this is NOT true. This means SNES must read ExHIROM game when SNES A22 is also low...
MaarioS wrote:
A22 of ROM goes directly to SNES A23, nothing was changed. By doing the 2nd configuration I wanted to confirm that ExHIROM game is read ONLY when SNES A22 is high. So if this doesn't work, this means this is NOT true. This means SNES must read ExHIROM game when SNES A22 is also low...
A22 isn't actively driven in ExHiRom games except for sram conditions. The converted star ocean drives that line for reading the additional eprom. Generally speaking, lines that aren't being driven are held low. This why most games (lots of exceptions) can run without mirroring. Example. You can put mario in a much bigger rom without mirroring. Mario is a small game that a high address line of A18. so what happens if A21 (and A20 or A19) is driven high? All the mario game data will vanish because it would be banked-out. For the snes to even see the Mario game in a big rom, it has to hold the higher address lines low. If you mirrored the mario data then it would still be seen even if A21 was driven high. My point, unused lines are
generally held low. Games like Megaman X, even though it's a small game, has to be mirrored if you put it in a big rom -- cause every now and then, it drives the A21 line high for whatever reason... Super Bonk is the same way too.
These are my observations anyway..... I have zero electronics training so I may have butchard the terminology.
In the decompressed star ocean, if A22 goes high, it's looking for data from Rom3, when it's low, it's looking for the ExHiRom data. This is how my decoder works.
Edit-- shouldn't your pin 13 be connected to something on your 2nd example decoder?
Edit 2: well, I shouldn't post from memory -- got the A22 high/low backwards after looking at my documentation. Sorry. When A22 is
LOW, it's looking for Rom3, when A22 is
HIGH, it's looking for the ExHiRom data.
I barely understand what you said about mirroring but thanks for your interested in my tpoic anyway heheh
Basically I'm so desperate to do this that I even built 12MB dev-cart today. Basically it is designed for 8MB memory (exHIROM) + 4MB memory configured as LOROM. All memories have been connected exactly this way:
http://www.cs.umb.edu/~bazz/snes/96MbCart/derp.htmlPCB:
74LS139 is connected like this:
01-MAD-1 pin#04
02-MAD-1 pin#12 (shared with PCB)
03-GND
04-/OE ROM 4MB (LOROM)
05-/OE ROM 8MB (EXHIROM)
06-NC
07-NC
08-GND
(and pin#16 is +5V)
I can confirm once again that Star Ocean configured this way does NOT work on this board: 8MB ROM consists of ROM2+ROM1 (written in this order) and 4MB ROM is ROM3.
Anyway I also programmed Holy Striker Batman 12MB ROM (provided by tepples) the same way as Star Ocean above. Here's what I got:
Is this correct??