nesdev.com

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.

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:



"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.

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:



...because I think they should be like this:



... 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?

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....