# What is the real maximum Sega Genesis can address

## Recommended Posts

I was looking around internet and some sources claim that the maximum is 4 megabytes, the others 16 megabytes. Can somebody give me clear evidence what is the reallife maximum that you can use for a Sega Genesis game without special techniques like bankswitching = the same as 4k limit for the 2600? Thanks!

##### Share on other sites

According to the memory map here :-

http://en.wikibooks.org/wiki/Genesis_Programming

The cart's ROM/RAM maps from 0x000000 to 0x3FFFFF so it has a size of 0x400000 or 4MB. The 68000 has a 23 address lines and an upper/lower byte select so its entire memory map range is 16MB. It looks like the full number of 68000 address lines are available on the cart connector but you'd have to make sure that your cart design didn't conflict with existing peripherals in the memory map if you wanted to make use of any reserved space.

##### Share on other sites

So it's actually 16 MBs isn't it. Is that something similar to C-64 memory space where you could switch between ROM and RAM allowing you to use nearly all 64k for yourself?

##### Share on other sites

So it's actually 16 MBs isn't it.

Nope! There are peripherals and RAM inside the console mapped into that address space (all the time) that control things like video, sound etc. Plug in peripherals need some of that memory space too. You could probably use the reserved areas (I'm not a genesis expert) but you'd need more complex address decoding.

Is that something similar to C-64 memory space where you could switch between ROM and RAM allowing you to use nearly all 64k for yourself?

With bank switching such an arrangement is possible.

##### Share on other sites

The entire memory map for the 68000 is 16 MBytes. On the Genesis, that 16 MBytes is divided like this:

0x000000 - 0x3FFFFF = CART if a cart is inserted, if no cart, this is CD space

0x400000 - 0x7FFFFF = CD space is a cart is insert, otherwise it is cart space (a cart that doesn't assert the /CART line is considered a BRAM cart)

0x800000 - 0x9FFFFF = 32X space - if you have a 32X and it is enabled, this will have the cart rom, frame buffer, and frame overwrite regions

0xA00000 - 0xDFFFFF = IO space

0xE00000 - 0xFFFFFF = Work RAM space - only 64KB, but mirrored through whole 2MB

If you do not have a CD or 32X, you CAN use the space for those if the cart does its own decoding and asserts the /DTACK for areas outside the CART space. So you CAN have carts that go to 8 or even 10 MBytes, but only without the CD or 32X. With the CD and/or 32X, 4 MBytes is the max without bank selection.

SEGA did define one mapper for the Genesis (which is also supported by the 32X): A cart can have up to 32 MBytes of rom split into 512 KByte segments. There are eight 512 KByte pages in the cart space; page 0 will ALWAYS point to the first segment of the rom; pages 1 to 7 can be set to point to any of the 64 different segments of rom.

0xA130F1 controls the save ram

0xA130F3 sets the segment for page 1 (0 to 63)

0xA130F5 sets the segment for page 2 (0 to 63)

0xA130F7 sets the segment for page 3 (0 to 63)

0xA130F9 sets the segment for page 4 (0 to 63)

0xA130FB sets the segment for page 5 (0 to 63)

0xA130FD sets the segment for page 6 (0 to 63)

0xA130FF sets the segment for page 7 (0 to 63)

The only game to use the official SEGA mapper is Super Street Fighter 2, so most people call it the SSF2 mapper. SEGA had two different developer carts that implemented the SEGA mapper for developers wishing to make games larger than 4 MBytes. Note that the SH2 processors on the 32X cannot access the page registers on the cart; it must command the 68000 to do it for it. The 32X BIOS for the 68000 has two functions built into it besides the exception jump table - one functions sets one mapper register, and the other sets all the mapper registers. So it's clear SEGA meant to have 32X games that were larger than 4 MBytes, but it died before that happened.

##### Share on other sites

Thanks for detailed explanation!

##### Share on other sites

Thanks for detailed explanation!

No problem. Most of that is from SpritesMind. If you really want technical info on the Genesis/CD/32X, you probably want to check there. Especially low-level info on the YM2612.

##### Share on other sites

Yep. The full address space of the 68000 chip is 16 megabytes, but the cartridge slot only pre-decodes for 4 megabytes. There is also a certain amount of pre-decoded space for the Sega CD unit through the expansion connector.

The rest of the address space consists of roughly decoded stuff (like VDP and SRAM) mirrored many times in large blocks, and of completely undecoded space which doesn't provide bus acknowledgement (DTACK) for the 68000, so attempting to access those addresses will normally hang the CPU. I think the 32X has to provide its own bus acknowledgement signal.

DTACK is important because, unlike most 8-bit CPUs, the 68000 waits by default for the device (whether memory or I/O) to say it's ready with the DTACK signal. It is possible to bypass this by always asserting DTACK in "DTACK Grounded" mode (which was the name of a newsletter for 68000 programming). If neither DTACK nor BERR are asserted for a given memory address, the 68000 simply hangs waiting for either one. It is possible to add a circuit that generates a bus error signal if there is no response after a certain number of clock cycles, but the Sega does not have it.

##### Share on other sites

it would really be nice to see some new genny homebrew now that the everdrive is so ubiquitous...

##### Share on other sites

The EverDrive cannot handle the larger homebrew games coming out these days. From some of the posts Krizz has made on his forums it looks like this is intentional. Must be good to be that one homebrew developer who Krizz is protecting. Sucks to be the developer that, er, is everyone else I'd love to test my larger games on an EverDrive. Also, I've kind of gotten used to backing up my games and then safely storing them away. Not everyone has 2 Genesis systems: one for EverDrive and one for 64meg homebrew..

Edited by theloon

##### Share on other sites

The EverDrive cannot handle the larger homebrew games coming out these days. From some of the posts Krizz has made on his forums it looks like this is intentional. Must be good to be that one homebrew developer who Krizz is protecting. Sucks to be the developer that, er, is everyone else I'd love to test my larger games on an EverDrive. Also, I've kind of gotten used to backing up my games and then safely storing them away. Not everyone has 2 Genesis systems: one for EverDrive and one for 64meg homebrew..

Might not be a matter of "Krikzz" going out of his way to protect them (Pier Solar team), but more a matter of respect in not supporting the special hardware setup that the homebrew developers specifically setup as a security device (among other security steps, from what I've been told), so they can actually sell the game. That is, assuming Everdrive even supports the backend hardware needed to begin with. I'm sure if other developers went out of their way to implement security devices in their homebrew works to be sold, even if they don't extend anything special beyond the stock addressing limit, then he would show the same kind of respect. At least, I would assume.

##### Share on other sites

I guess what I meant was that the everdrive can help developers come up with homebrew games, not so that we can play them for free. I was reading up on Pier Solar but it's not my cup of tea in terms of gameplay so I am hoping someone comes up with a good platformer or shooter or something.

##### Share on other sites

Pier Solar sucks anyway. I wouldn't need that game in my Everdrive if I had one...

## Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

Only 75 emoji are allowed.

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.