Expansion port boot

[patroclus02]

Hello,

If a SegaCd is conected, and a cartridge is in, which one boots?? As far as I'm concerned, cartridge will, as it grounds /CART signal and disables expansion port??

I wonder how Sega CD Transfer Suite is used to dump a cartridge.

As I just read, you have to tap the /CART pin in cartridge.

So, how can both SegaCD access all ROM memory area if SegaCD BIOS is loaded over it?

thank you

 

[crazygoat]

i dont know much about this stuff but maybe it works like the sega cd ram cart thats in the genesis yet the sega cd boots and it can run it dunno probley sounds dumb but just an idea

 

[patroclus02]

But if you disable cartridge by tapping /CARt connector, so it does not load from it, and instead it loads from SegaCD expansion port... as SegaCD ROM is mapped over cart ROM area at $000000, I suppose you cannot acces cart. That would cause conflits. how can you then acces cart then?? anyone knows?

 

[lordofduct]

why don't you ummm... google the freaking tutorials for the transfer suite and maybe read em' first?

Yeah... I sound like dick, but it was the first link after typing in "Sega CD transfer Suite how to"

Originally posted by "tutorial"

dump.exe/dumpb.bin:This is used to dump cartridges. Before you can use this you need to put a piece of tape on the cartridge you want to dump. Put it on pin B32 (the pin furthest to the right on the front of the cartridge). This will keep the game from booting up and will instead cause the Sega CD to boot. Once this is done, start up dumpb.bin on the Genesis/Sega CD first and then dump.exe on your PC. You will then be presented with a few options on your Genesis as to the size of the cartridge. 'Auto' will use the size in the header of the cart, but since it's possible not all games will have a proper header you are also given choices as to the size of the cart in megabits. Choose one and press start. The transfer will begin and you'll get a progress indicator on your PC. The percentage is updated every 64KB (which takes about 5-6 seconds on my computer), so don't worry if it doesn't change immediately. Once the dump is complete you'll have a file called output.bin in the same folder as dump.exe

You have to cover the ground pin so the genny doesn't realize there is a cart... but when you tell the program there is one it pulls from all the other pins because you told it there is a cart.

 

[ExCyber]

Genesis has two spaces for ROM mapping: 000000-3FFFFF and 400000-7FFFFF. If /CART is grounded, the first decodes to the cart and the second decodes to the expansion port. If /CART is not grounded it's reversed. Thus the expansion port is not disabled; the CPU just grabs its reset vector from the usual address, which happens to be the cart if /CART is grounded.

 

[cgfm2]

Originally posted by ExCyber@Sun, 2006-02-12 @ 12:21 PM

Genesis has two spaces for ROM mapping: 000000-3FFFFF and 400000-7FFFFF. If /CART is grounded, the first decodes to the cart and the second decodes to the expansion port. If /CART is not grounded it's reversed. Thus the expansion port is not disabled; the CPU just grabs its reset vector from the usual address, which happens to be the cart if /CART is grounded.

[post=144324]Quoted post[/post]​

Interesting, does this mean 32X-enhanced Sega CD games bootstrap the 32X themself instead of relying on the 32X BIOS to start it up?

Otherwise it would get messy with the 32X pulling /CART low until the BIOS runs, then releasing it so the Sega CD BIOS could show up at the right area.

Purely out of curosity who figured this out and how? My hunch was that /ROM on the expansion port was the same as the cartridge port ROM /CE, and /CART disabled it when low.

 

[patroclus02]

lordofduct thanks, but I already googled, and I already read that web. Read my last post. I already knew about tapping /CART pin. My question was HOW could you access both ROMs.

ExCyber that was exactly what I was looking for. So, when booting from expansion port you can read whole ROM and SRAM in cart at 400000-7FFFFF...

cgfm2 that's good question...

Purely out of curosity who figured this out and how? smile.gif My hunch was that /ROM on the expansion port was the same as the cartridge port ROM /CE, and /CART disabled it when low.

Yes, that's what I thought. And that's why I could understand how to read a cart when booting from port

 

[ExCyber]

Originally posted by cgfm2

Purely out of curosity who figured this out and how?

I don't know who originally figured it out. I think it was sparked by some discussion at the old Eidolon's Tavern about an unlicensed cart that somehow accessed the SCD. It was already known that the cartridge slot was somehow mapped when booting from the expansion port because there are backup RAM expansion cartridges, and MoD's transfer suite proves that it's not just some hocus-pocus with the cart doing its own address decoding (although that much was known to at least a few people). The source for the dumping routines is on the ISO that MoD provides if you want to take a peek, but there's mot much magic in it aside from detecting the cart size and supporting the SSF2 mapper. The part where the expansion port is mapped with /CART asserted is something of a conjecture on my part (in the sense that I can't point to any particular code that successfully prods it), but that would be the "natural" way to go, considering that the logic would be no more complex (compared to what would be needed to conditionally move only the cartridge address space up) and that this mapping would make the expansion port potentially more useful than just disabling it. In other words, they'd be stupid not to do it.

edit: As for 32X, I just close my eyes, cover my ears, and pretend it doesn't exist. I have no idea how it could sanely implement the sorts of things that it does. <_<

 

[cgfm2]

was sparked by some discussion at the old Eidolon's Tavern about an unlicensed cart that somehow accessed the SCD. It was already known that the cartridge slot was somehow mapped when booting from the expansion port because there are backup RAM expansion cartridges

Good point. Maybe it was that Visual Light Show thing, and I know Datel made a region-busting cartridge that I think showed a splash screen before the Sega CD booted.

So I guess you could make a SRAM cartridge for loading games off the Sega CD into. Something like:

- On power-up reset /CART is held high by a memory mapped flip-flop in the SRAM cart

- Game selecting program booted off Sega CD, user picks a game to be copied to cart SRAM at $400000 onwards.

- Program makes main 68K jump to work RAM, toggles the flip-flop so the BIOS is gone and the cartridge SRAM is relocated to $000000 onwards, then loads the initial PC/SP and starts execution.

This would work even better using the /TIME strobe so you wouldn't have to worry about the relocated address of the flip-flop's address in memory, just the SRAM would change. Then you'd need minimal address decoding logic in the cart, just to split up the SRAM accordingly. Going by the DRAM post earlier, you could just slap 4MB of DRAM on a cartridge and keep things simple.

 

[Kaneda]

the best cart to test is Flux

I know it tests if 'floppy is present' then do some stuff

it seems you can choose which one boot (CD or cart)

at least the CD allows that (called boot mode 1 or mode 2 if i remember...i'm not a MCD pro)

I don't know more, I stopped my test on that (mode x and 'floppy is present')

Fonzie successfully tested it some months ago

 

[patroclus02]

- Game selecting program booted off Sega CD, user picks a game to be copied to cart SRAM at $400000 onwards.

When SegaCD boots, cartridge is supposed to be mapped at $400000. If you insert a RAM cartridge, you can copy a game to it. Then you assert /CART, and RAM cartridge goes to $000000 so you just do a jump to it. And game running.

Is that what you say? Did I get you?

This would work even better using the /TIME strobe so you wouldn't have to worry about the relocated address of the flip-flop's address in memory, just the SRAM would change.

I didn't understand that. What is /TIME used for??

Going by the DRAM post earlier, you could just slap 4MB of DRAM on a cartridge and keep things simple.

As far as I know, (and I read the post sometime ago), it is not known weather DRAM can be used and how (without a dedicated DRAM controller of course). Did that change?

 

[ExCyber]

'/TIME' is the schematic label given to pin B31 on the cartridge slot. It is essentially a chip enable for the I/O port range $A130Fx, and is used for programming on-cart memory mappers. The only games I know of that use it are Beyond Oasis, Phantasy Star 4 (both for switching between ROM and SRAM at $200000-3FFFFF) and Super Street Fighter 2 (for a full-blown ROM banking chip). I don't know why it's called '/TIME'; perhaps they expected to connect an RTC chip to it.

 

[patroclus02]

I see.. so, how can that be used to "worry about the relocated address of the flip-flop's address in memory" as cgfm2 said?

 

[cgfm2]

Originally posted by patroclus02@Tue, 2006-02-14 @ 12:07 PM

I see.. so, how can that be used to "worry about the relocated address of the flip-flop's address in memory" as cgfm2 said?

[post=144395]Quoted post[/post]​

Assuming you had 4MB of SRAM, the flip-flop to control the /CART pin would have to be memory mapped outside of the 8MB range (first 4MB for the Sega CD, latter 4MB for the SRAM), such as $800000-$9FFFFF. Apart from conflicting with the 32X, you'd need some hardware on the cartridge to decode that address as there is no dedicated strobe for it.

On the other hand, if /TIME was used you could write to $A130xx regardless of the /CART pin state and control it.

I'm not saying this is the best way, just trying to think of a simple way to play ROMs loaded of the Sega CD. I'm sure there are better solutions depending on the application.

 

[Mask of Destiny]

Originally posted by cgfm2@Sun, 2006-02-12 @ 05:30 PM

Interesting, does this mean 32X-enhanced Sega CD games bootstrap the 32X themself instead of relying on the 32X BIOS to start it up?

The 32X doesn't startup by itself regardless of whether a cart is inserted or not. It waits until a 32X game pokes at it and then the SH-2s start running their respective BIOSes (well I suppose the SH-2s could start right away, it would be difficult to confirm either way). If it's a cart-based game there is a 68K "BIOS" that get's swapped in to address 0 when the cart gets relocated (and control given over it to the 32X), but it's nothing more than a vector table. The SH-2s use the same BIOSes regardless.

The biggest difference between the two game types boot-wise is that in a cart situation, the 32X reads the initial SH-2 programs directly from the cart whereas in a CD situation the 68K has to copy the code to the 32X framebuffer.

Purely out of curosity who figured this out and how? My hunch was that /ROM on the expansion port was the same as the cartridge port ROM /CE, and /CART disabled it when low.

Earliest reference I could find to it on the old Tavern is here: http://web.archive.org/web/20021218182532/...ages/15867.html

It's possible others had figured it out independently.

Using /TIME for the flip-flop seems as good a solution as you're going to get. The only other practical alternative I can think of is to stick a switch on it and make the user handle it manually. A 4MB RAM cart would be nice for 32X/CD development. The lack of RAM in the 32X really criples the 32X/CD combo, especially since you have to shovel all the date through the framebuffer (or the com regs). Too bad no one makes 5V DRAM anymore (and SRAM is kind of pricey for those capacities).

 

[ExCyber]

ISSI still makes 5V DRAM in 4Mbit and 16MBit densities (Nu Horizons stocks them), but I don't see why a 72-pin module wouldn't work, aside from being a bit bulky and requiring slightly more complex decoding.

edit:

Wow, I was really a dick in that Tavern thread. :/

Anyway I think when I wrote that post I had already seen the discussion I mentioned earlier (which is almost certainly the "other evidence" I was referring to). The whole "expansion port mapped with /CART asserted" thing was at least as much speculation then as it is now. Anyway if anyone deserves credit for figuring this out it's probably Vic_Viper...