Current info on Sega Genesis Progamming

[swlovinist]

I somewhat recently got to hear a speech at NWCGE 2K6 in which an Atari Homebrew programmer(I forget his name) said that the Sega Genesis was relatively easy to program for. What does it take for someone to write and program a game for this system?(Hardware and program knowledge). Any info or links to info would be great. Thanks, John

[CosmicMonkey]

I would suggest Devega (http://www.sega-devega.net/). The site has a full how-to tutorial guide plus loads of examples of code. Seems to be down atm, though.

Maybe try some other sites in the Genesis Dev Ring (http://www.genny4ever.net/index.php?page=sgdr)?

[idrougge]

I wouldn't trust a 2600 programmer when he said that a system was easy to program for. After all, the 2600 is a system that makes programmers for other systems shiver (with anticipation).

[LocalH]

Genesis programming is relatively easy in that the system has a flat address space of 4MB for cartridge ROM. The easy part is making a ROM that runs in an emulator - the hard part is making it run on hardware, as emulators tend to be much more forgiving than hardware (for example, emulators don't require that you initialize the joypads, but if you don't do it on hardware, then your button reads will be broken).

[blue lander]

If you don't initialize the joypads, I don't see how the emulator would know which set of buttons you're trying to read (at least on a 6 button pad). Since there's 11 buttons (not including mode) on a 6 button pad and the joystick port is only 8 bits wide, you've got to tell the controller which set of buttons you want to read.

As for Genesis programming, it is extremely simple compared to writing for the 2600. 68000 is easy to understand, the VDP is versatile and intuitive (except maybe the way that sprites are linked togeather). The only really difficult thing about Genesis programming is getting collision detection to work correctly. When two sprites hit eachother, a "collision" flag is set but it doesn't tell you which two sprites collided. You've got to figure that out by noting where the raster scanner is when the collision flag was set, and then figure out which two sprites happened to be there at that time.

Also, unless you're a sadist like myself, I'd suggest using one of the C compilers rather than writing the whole thing in assembly. Do the low level stuff in assembly, but the actual game logic in C.