32X development docs

Hi,

I know this is a Saturn dev forum so this post is a little bit off topic, but I just don't know any other place where I can ask for this.

For a personnal project, I would need 32X development docs containing info about the VDP, registers and memory map. Where can I get such info? (I did a search at Eidolon's Inn before asking here)

Thanks!

PM
 
There is no useful documentation on the 32X on the internet at this time. Eidolon has a whole CD full of dev stuff, but he never got around to hosting it. He's been rather busy as of late, but you can try emailing him.

I have a little bit of documentation on the 32X but it's out of date with what I know and some of it is pure speculation. I could post it if you want.
 
Thanks for the fast reply Mask of Destiny,

At the point where I am, any tidbit of info could be useful, even if it's wrong :)

I would be grateful if you could post them. Or, if the files aren't big (<500Kb) you can send them to pyromeistar(A)thevortex.com .

Thanks again!
 
32X Hardware Notes:

32X Memory Map

00000000 - 000001FF: BIOS (different for Slave and Master)

06000000 - 06040000: Work RAM

20004000 - ? : 32X Regs

22000000 - ? : Cartridge

24000000 - 24040000: Frame Buffer

68K Memory Map:

000000 - 3FFFFF: Cartridge before Initialization

000000 - 000100: 32X 68K BIOS after 32X init

800000 - 83FFFF: Unkown

840000 - 87FFFF: 32X Framebuffer

880000 - 9FFFFF: Cartridge after initialization (bankswitched)

Regs:

A130EC: used to check for presence of 32X. A longword read should return "MARS"

All other Regs start at A15100 from the Genesis side so I will only list offsets from now on.

Offset Size Probable Use

0x0 Byte Bus Arbiter. Clearing bit 7 of this reg Bus requests the SH2's allowing access to the framebuffer and hardware registers.

Reading bit 7 indicates the status of SH2 BusReq.

0x1 Byte Unkown, gets set to different values during initialization and bit 7 is tested immediately following the "MARS" test

It seems to control the 32X operating state in some way as this reg is written to to give the 32X control of the cartridge

0x2 Word

0x4 Word

0x6 Word

0x8 LongWord

0xC LongWord

0x10 Word

These next few registers are initialized by the main SH2, perhaps they aren't accessible by the 68k? It should also be noted that the init routine writes to

all four of these registers twice.

0x14 Word

0x16 Word

0x18 Word

0x1A Word

0x1C Word

0x20 LongWord Inter-processor communication. All 3 processors can read and write to this register.

0x24 LongWord Same as above.

0x28 Longword Same as above.

0x2C LongWord Same as above.

0x30 Word

0x32 Word

0x38 Word

0x80 Word Appears to be a version/region register of some sort. If bit 7 is set, the 32X is an NTSC unit, otherwise it's PAL. This

register is also written to during initialization, but I don't have any data for what function writes might have.

0x82 Word

I suspect the following registers provide access to either the VDP or PWM sound generator because of the sheer number of zeros written to them at init.

0x84 Word Init routine writes 0xFFFF to this reg before writing a bunch of zeros to 0x88 and sequential numbers to 0x86

0x86 Word numbers from 0x0 to 0xFF00 written to this reg, numbers increase by 0x100

0x88 Word

0x8B Byte Appears to be a banking or bus control register. Bit 0 is cleared, 0xFFFF is written to 0x84, and then a bunch of zeros are written to 0x86 and 0x88. Bit 1 is then set, and the process is repeated.

It's possible 0x86 provides access to some kind of pallete RAM that is used in the VDP's 8-bit mode. Perhaps 0x88 provides access to some kind of RAM that controls the transparency of a color, or if it is displayed under or over Genesis graphics? Too early to say.

Upon further reflection, I believe these may be the registers that control the bankswitching mechanism.

Corpse Killer does the following at boot:

Check for 'MARS' at A130EC

Wait for bit 7 of 32X Reg 0x1 to be set.

Test bit 0 of Reg 0x1, fail if set

Write 1 to Reg 0x1

Waits in a processor loop

Clear out first 2 longs of 32X Com RAM

Bus Request SH-2s (At least I'm pretty sure that's what this is)

Write 0's to a bunch of registers

Do some funky stuff with Regs 0x84, 0x86, 0x88, and 0x8B

Write 512 bytes of zeros to 0xA15200+

Compares 32X region with Genesis region

Tests for 'SDER' from SH-2s, fails if present

Clear last two longs of 32X Com RAM

Copy initial program to framebuffer

Release SH-2 Bus Request

Write '_CD_' to Com RAM

Wait for 'M_OK'

Wait for '_CD_'


That's all I've written down so far. I figured out a little about the VDP by doing some RE on one of the little demos that came with the SDK (Quinntesson released binaries of them a while back). In the 8bpp mode there is a table that contains the starting address of each line of the display. This makes it easy to do horizontal line-scrolling.

So far I haven't been able to get code running on the SH-2s, so I haven't really messed with it further.

Two notes: The memory map listed contains the commonly used addresses for those things. Because of the way the SH-2 works you can access them at multiple addresses (some addresses disable the cache). Also note that the boot description I have there is only for 32X CD games. Cartridge games have a different boot process.
 
antime said:
You can download scans of the Megadrive, MegaCD and 32X manuals from here.


Dear Ant', I've already told you : your site is my start page. So, for sure, I've been there, of course I've downloaded it (search your log to find a Mac client), and I've even tried to OCR it !!!

Unfortunately, I didn't find anything relative to this "MARS" thing.

Anyway, let me tell you once more, that your docs are really, really welcome indeed. Gret place, man !


TascoDLX said:
The 32X is hardwired to return that word. If it doesn't say "MARS", it's not a 32X.


Oh, that would explain a lot of things. And so, emulators have this behaviour also ?


Thank you for your answers you guys.


By the way, I'm asking myself a question. By setting the ADEN bit (reg. 0xA15100), the 68k memory map changes. How is it possible ? I mean, while developping Genesis, did SEGA already think about 32x ? If I make a Genesis-only ROM with

Code:
bset #1,$A15100

inside, will the 68000 memory map changes all of sudden ?
 
By the way, I'm asking myself a question. By setting the ADEN bit (reg. 0xA15100), the 68k memory map changes. How is it possible ? I mean, while developping Genesis, did SEGA already think about 32x ?
They thought about expansion in general. For example the ranges of $400000-7FFFFF and $800000-9FFFFF aren't used on a stock Genesis and are treated differently by the bus logic to allow an external device to control them to various degrees.
 
ob1 said:
Unfortunately, I didn't find anything relative to this "MARS" thing.

It's mentioned at least in the 68000 memory map, but nothing beyond stating that it's there.
 
Stéphane, the author of Gens, confirms that the string "MARS" must be present. It is emulated as is.
 
I've found out that the genesis initial program is in the Master SH2 bios !!! In fact, the boot rom checks that the initial program is present. So, the initial program can be find in the bios from $36C to $76C !!!
 
ob1 said:
I've found out that the genesis initial program is in the Master SH2 bios !!! In fact, the boot rom checks that the initial program is present. So, the initial program can be find in the bios from $36C to $76C !!!


FYI, the Sega CD/Mega-CD works in the same manner. except that:


1 - Each region (USA, EUROPE, JAPAN) has a different security block.

2 - The security block can be found in the SUB CPU BIOS, which is compressed inside the MAIN CPU BIOS.


For the Sega CD, this method ensures that when the IP is executed, the Sega animated logo is displayed. For the 32X, it ensures that the 32X is properly set up and tested.
 
Back
Top