A Sega 32x Programming Question

[Chaotix]

Lets say I was creating a Sega Genesis game, but I decided to add 32x features/effects later on. Could I just initialize the Sega 32x during boot when I start programming and forget about it until the future when I am ready to implement 32x features or would I be required add more code to monitor the 32x further in my code?

Also, is it possible to create a "hybrid" 32x game? Like could I design something that would boot in a plain old Genny, but then with a 32x, it would set off a flag so the 32x would turn on and "32x features" would be enabled in the game?

The reason I'm asking is because I know very little about programming the Genesis and even less about programming the 32x. A friend of mine and I are planning to teach ourselves 68k assembly programming heavily over the course of the next year. I have an ultimate goal I wish to achieve; a 2d platforming clone of a semi-popular modern game (of which I wish to remain anonymous as I'm not making promises that I will ever reach that point). I would eventually NEED to use the hardware sprite handling + scaling and rotation ability of the 32x as I know the Genesis will not be able to handle the amount of sprites the game will require and do not wish to design nor will I have the extra processing power for software sprite scaling and rotation. However, I'll need to learn the (so I've heard) more difficult SH2 assembly before then. I'm sure a lot of this is documented somewhere, but I wish to know from the "pros" before I start!

Thanks ahead of time!

[mrbigreddog]

That's your cue Chilly Willy!!! <--- He's a pro!
He made a Wolfenstein 32x port! And is currently working on a 32xCD version!

[Jorge Nuno]

Yes it is.

The 32x does have an "ID" register which can be read for presence detection: in case the 32x is present it reads "MARS". Otherwise it's just garbage (open-bus, IIRC) data.

[sheath]

Not a game programmer, but I would figure that a standard 24-32Mbit would answer the hybrid question quite handily. I can't imagine that Genesis DAC samples and 32X PCM samples would take up the same amount of ROM space. Also, assuming we're talking about 2D games only, I am reasonably certain that you could not have sprites and backgrounds in Genesis color and then higher color version without duplication on the ROM.

[Chaotix]

That's your cue Chilly Willy!!! <--- He's a pro!
He made a Wolfenstein 32x port! And is currently working on a 32xCD version!

Ah, I know! I've been watching that since the start! He is half my inspiration.

Yes it is.

The 32x does have an "ID" register which can be read for presence detection: in case the 32x is present it reads "MARS". Otherwise it's just garbage (open-bus, IIRC) data.

Thanks!
Does having 32x boot code cause any adverse effects in the case that it wasn't there (like the Genny halting)? (In the case that I plugged the cartridge into a Genny w/o a 32x attached)

Not a game programmer, but I would figure that a standard 24-32Mbit would answer the hybrid question quite handily. I can't imagine that Genesis DAC samples and 32X PCM samples would take up the same amount of ROM space. Also, assuming we're talking about 2D games only, I am reasonably certain that you could not have sprites and backgrounds in Genesis color and then higher color version without duplication on the ROM.

Yes I know. However instead of pure enhancement, I would use the 32x for effects or other things that would not be necessary to play the game. (AKA background effects)

[Jorge Nuno]

The 32x boot code only runs when you start the 32x. If it isn't there (by reading that IDreg) then jump over that code.

I think you also need to make all adresses relative, because code running on a MD is based at 0, while when you start the 32x it remaps the cartridge (the first 512kBytes of it) to 0x880000 and (a 1Mbyte bank you choose IIRC, to) 0x900000.

[Chilly Willy]

The 32x boot code only runs when you start the 32x. If it isn't there (by reading that IDreg) then jump over that code.

I think you also need to make all adresses relative, because code running on a MD is based at 0, while when you start the 32x it remaps the cartridge (the first 512kBytes of it) to 0x880000 and (a 1Mbyte bank you choose IIRC, to) 0x900000.

This - putting 32X code in the rom, even if it does nothing, makes the memory map change when the 32X is activated. The mapping is very dissimilar, and you have an extra jump table in the rom header to deal with. So making one rom for both MD-only and MD+32X means paying careful attention to code and data positioning.

However, once you've dealt with those initial issues, then it shouldn't be a problem to add 32X later. Space will probably be your biggest issue as 32X graphics won't be at all like MD graphics. Plain 8 bit PCM audio in DAC for the the MD can easily be converted on the fly to PWM samples for the 32X, if needed. You could also compress the audio, then have different decompressors for Md vs 32X.

[kool kitty89]

However, once you've dealt with those initial issues, then it shouldn't be a problem to add 32X later. Space will probably be your biggest issue as 32X graphics won't be at all like MD graphics. Plain 8 bit PCM audio in DAC for the the MD can easily be converted on the fly to PWM samples for the 32X, if needed. You could also compress the audio, then have different decompressors for Md vs 32X.

Yeah, but as mentioned th elast time this came up, you could have games with the primary difference being extra code for the 32x (very small amount of added cart space) and have the 32x just used for rendering onto the geneiss layer, scaling/rotating graphics data also used for the plain genesis version, or having added audio effects with the same samples. (pitch and volume control, full stereo, possibly better quality playback, etc)

Or possibly have minimal additions for 32x graphics and possibly use more advanced compression schemes for those too. (in a game like Chaotix, only the "sprite" layer is 32x rendered, for example)
That, and stuff like added untextured polygonal graphics (or re-using other graphics data as textures) would be mainly code as well (and data for the 3D model vertices).
Common graphical data could be useful for applying to other texture effects too, like a "mode 7" type backgound. (and if using 4-bit MD indexed tiles, you'd have to convert that to 8-bit bitmaps)

[Chaotix]

Yeah, but as mentioned th elast time this came up, you could have games with the primary difference being extra code for the 32x (very small amount of added cart space) and have the 32x just used for rendering onto the geneiss layer, scaling/rotating graphics data also used for the plain genesis version, or having added audio effects with the same samples. (pitch and volume control, full stereo, possibly better quality playback, etc)

This is exactly what I want to do.

The 32x boot code only runs when you start the 32x. If it isn't there (by reading that IDreg) then jump over that code.

I think you also need to make all adresses relative, because code running on a MD is based at 0, while when you start the 32x it remaps the cartridge (the first 512kBytes of it) to 0x880000 and (a 1Mbyte bank you choose IIRC, to) 0x900000.

This - putting 32X code in the rom, even if it does nothing, makes the memory map change when the 32X is activated. The mapping is very dissimilar, and you have an extra jump table in the rom header to deal with. So making one rom for both MD-only and MD+32X means paying careful attention to code and data positioning.

However, once you've dealt with those initial issues, then it shouldn't be a problem to add 32X later. Space will probably be your biggest issue as 32X graphics won't be at all like MD graphics. Plain 8 bit PCM audio in DAC for the the MD can easily be converted on the fly to PWM samples for the 32X, if needed. You could also compress the audio, then have different decompressors for Md vs 32X.

Just making sure I get this...so what you're saying that when the "MARS" flag is thrown, I will have to remap in the first 512kB to 0x880000 and the next 1MB to 0x900000? Everything after that is where its supposed to be? How can I remap this without wasting precious cycles? Should I just place the data after the first 1.5MB and just waste the rest (which sounds like a poor idea) or is there a way to intercept the MD addresses and convert them to the 32x ones without constantly checking for the "MARS" flag (which I imagine would slow the game down heavily if I had to do it often...)? Remember...I'm new to this so I don't know if there is an easy way or not.

[Jorge Nuno]

The "MARS" ID register has nothing to do the remap.

The remap is only done when you set the ADEN bit to 1 (the «mars initialisation program» does this automatically when you call it). Of course if the IDreg isn't "MARS" then you won't run the 32x startup code at all and your code/data will be in the expected location.

Also forget about wasting cycles, only run this once at the beginning before even showing anything on the screen. Its not people are taking the 32x out and putting it back during the game .

[Chaotix]

Okay, I think I'm sort of getting this now...but how am I able to run shared code when the cartridge is in 32x mode when my shared code is designed around plain old MD mode? Will I need to duplicate all of it? (Ex. A menu screen that displays and acts the same in MD and MD+32x mode...) In other words, how can I make things designed to check, lets say, 0x000000 check 0x880000 instead without duplicating or checking the flag? Does the 32x redirect the calls automatically?


Does this make sense at all? I am quite used to Java and not the wonderful world of assembly...haha...

EDIT: After reading http://devster.monkeeh.com/sega/32xguide1.txt It says 0x880000 - 0x8FFFFF Cartridge (Appears as 0x000000 - 0x07FFFF)

...does the 68k still see the cartridge as 0x000000 - 0x07FFFF afterwords? What sees the cartridge as 0x880000 - 0x8FFFFF? I'm a bit confused now...

[Chilly Willy]

Let's try to clear it up a little... it you want a cart that boots on both the MD and the 32X WITH THE SAME IMAGE, then you will have the 32X header and at least some code that does nothing but make the SH2s sit in a loop, and the 32X WILL be active. There's no ability to switch on the 32X later and have it work from the cart... only the CD can do that.

So when you run the image on a MD, it will be mapped to 0 like a normal cart and all the 32X stuff is ignored. When you run the image on a 32X, the 32X is active and the MD side runs at 0x880000, not at 0. There's no getting around that for a dual-boot cart.

[Chaotix]

Okay. I believe I understand now.
Thank you very much.