Sega Genesis programming

[Bruce Tomlin]

Is anyone out there interested in Sega Genesis programming? I've been taking some time in the past few weeks getting a 68000 assembler working, then looking into stuff about the Genesis, and I even had a couple of circuit boards made. (I got it working yesterday, then spent the rest of the day redesigning it almost completely.) I also scraped together a Genesis system and got my Multi Game Hunter working on it, then quickly whipped up a "Hello World" program (cribbing signifcantly from the TMSS boot ROM to save time) and got that running on the MGH.

 

Basically, if you can handle the ColecoVision, and can figure out 68000 assembly language, this is probably one of the easiest to program systems out there. (Note that this does NOT apply to the Sega CD! The Sega CD is not only not easy, it's extremely under-documented, too!)

 

Since this is the first message in the topic, I'll try to keep a list of links here:

 

WikiBooks page, very little info: http://en.wikibooks.org/wiki/Genesis_Programming

Documents on Zophar's Domain: http://www.zophar.net/tech/genesis.html

Programming FAQ from 1995, kinda lame but some good info: http://home.hiwaay.net/~jfrohwei/sega/genesis.html

Some more random documents: http://www.classicgaming.com/epr/genesis.htm

sega2f, the "official" Sega documentation: http://mekanaizer.planetaclix.pt/sega2f.htm

This guy has some stuff, including a copy of sega2f: http://www.spritesmind.net/_GenDev/index.php?page=doc

This guy has some info about getting GCC set up: http://darkdust.net/marc/sega/index.php

Genny4ever with "Sega Genesis Dev Ring" links: http://www.genny4ever.net/index.php?page=sgdr

Devster's page, with some source code: http://devster.monkeeh.com/segapage.html

Eidolon's Inn, http://www.eidolons-inn.net/ and http://www.eidolons-inn.net/old/sega/gen_dev.html

 

And my own multi-CPU assembler with my new beta-version 68000 assembler (it works okay, but doesn't support larger than 64K code right now and probably has a few holes in error handling) is at http://xi6.com/hacks/

 

EDIT 2006-12-27:

 

some Sega CD info: http://www.retrodev.com/

Sega CD BIOS manual: http://stech68k.net/postline/cdisk.php?dnl...OFdPiQgTXpg.zip

Sega CD dev manuals: http://stech68k.net/postline/cdisk.php?dnl...ieN5evg6ef1.zip

Edited December 27, 2006 by Bruce Tomlin

[Bruce Tomlin]

Here's some sample code:

 

Hello World source code:

hello.asm.zip

 

Hello World binary:

hello.bin

 

Disassembly of TMSS boot ROM:

genboot.asm.zip

 

EDIT 2006-12-14: updated hello world source/binary with a few clean-ups

Edited December 14, 2006 by Bruce Tomlin

[Flojomojo]

Is it true that someone ported Mac System 7 to the Genesis?

 

The Amiga, Macintosh, Atari Jaguar, Atari ST, Neo Geo, and 3DO all used the Motorola 68000 processor, so this isn't so far-fecthed.

[djmips]

That is very cool. I have a full set of Genesis related docs (from back in the day) so if you need some info that you're missing, let me know. I haven't checked your links but I bet everything you need is all out on the 'net already.

[Bruce Tomlin]

Is it true that someone ported Mac System 7 to the Genesis?

 

The Amiga, Macintosh, Atari Jaguar, Atari ST, Neo Geo, and 3DO all used the Motorola 68000 processor, so this isn't so far-fecthed.

I think it's extremely unlikely. First of all, the basic console only has 64K of RAM, when the original Macintosh had 128K of RAM (minus 22K for the video), and System 7 surely required 512K because of it's always-on multitasking. System 6 might have squeezed in, but you might not have enough memory to run the Finder.

 

Then there's the matter of the video. The Genesis video wasn't memory-mapped, so getting Quickdraw to work would have been a big undertaking, even if the Genesis had a 1-bit video mode. You could rig it into a pseudo-bitmapped mode, but it only supported 4 bits per pixel, and had less pixels than the original 128K Mac.

 

And then where are you going to store all the files it needs to boot? You would have to build in a ROMdisk like the Mac Classic II had.

 

The Sega CD would have taken care of the files problem, more or less, and added sufficient RAM, but the video would still be completely wrong. The Genesis is tile-based, while the Mac is bitmap-based. I think video is the big killer here.

 

Even someone with no life would have had a lot of work trying to get any OS from the 68K-based computers (Mac, Lisa, Atari ST, Amiga) running. Well, maybe Tandy 6000 Xenix might have a chance... if it had any kind of MMU.

[djmips]

I remember when someone got the Mac OS running on the Atari ST with a cartridge containing original MAC ROMs. It was pretty cool. Yes, the ST had a B/W bitmapped display so that made it a lot easier.

 

Now the Genesis doesn't have a bitmapped display per se, but I've written a bitmapped graphics library for it nonetheless. It's similar in execution to other systems that have tile based bitmapped graphics like the C64 in some ways.

 

It's not out of the question to re-write the Quickdraw code to draw to the Genesis 'bitmap'.

 

I don't think it would be as hard as you might think.

[Bruce Tomlin]

It's not out of the question to re-write the Quickdraw code to draw to the Genesis 'bitmap'.

 

I don't think it would be as hard as you might think.

And I don't think it would be as easy as you think. I did a LOT of assembly language programming on the Mac back in the 68K days. Quickdraw is some highly hand-optimized code that makes one big assumption: that the video is a bitmap in main memory. Sure, you can put handler procedures to do things like record QD commands, like for printing to a Postscript printer, but then you pretty much have to rewrite most of the drawing code from scratch.

 

And even then, there are still big problems:

 

Genesis: only 64K of RAM

Sega CD: insufficient documentation for programming the damn thing, even now

 

Unless someone has some good evidence that it actually happened, it almost certainly didn't. It's got all the makings of an urban legend: almost possible (if it worked on the Amiga and Atari ST, it must work on anything else with a 68000!), and "I heard someone did this".

 

Yeah, there's no escaping topic drift.

[djmips]

> Yeah, there's no escaping topic drift.

 

 

Here's an approach that I've used successfully in the past. Create a buffer in memory that represents the 1bpp video buffer. Allow Quickdraw to draw to this buffer. On some schedule (20 Hz) , in a fast unrolled routine, copy/convert the bitmap memory to the bitmap set up in the tiled memory. Yes it's slower but it still allows for real time interaction, and a lot less work than re-writing Quickdraw (although that sounds fun somehow). If possible to intercept the mouse, draw these at 60Hz with sprite.

 

I think we agree that the memory is the biggest issue, and also I'd probably go with something of an earlier vintage (MAC OS wise). Memory expansion might be the first thing to tackle.

 

But as for more realistic matters, what exactly do you intend to program for the Genesis? A game or something else?

[Bruce Tomlin]

But as for more realistic matters, what exactly do you intend to program for the Genesis? A game or something else?

Uh, yeah, I thought I'd program a web browser for it. Of course I'm going to program a game for it, what else?

 

Right now I'm in the middle of converting graphics from my Colecovision RPG, then I need to convert the tiles from Tubes. Both of those should be a lot easier to finish when I'm not having to push square pegs into round holes to work around the limitations of the Coleco (32K code space and 1K RAM) and 7800 (despite its potential, the Maria mostly sucks). And last week I tried to get a Star Trek type game working on Coleco (having recently rescued a bunch of my 20+ year old TRS-80 code), but trying to store data in VRAM just bogged the thing down too much.

 

It'll be so nice to use real sprites for the RPG, but those are a lot of work to merge the tile and sprite data, then re-mask them to have a one-pixel border--four times per sprite! I'm working on the second of seven sprites right now. The font and tiles went a lot faster.

 

I basically just hacked at my Hello World demo to make it dump a bunch of tiles to the screen, and expanded the font table. Once I started working on the sprites I had to change the background color to dark gray to test the transparency. Those changes took almost no time at all.

Edited December 14, 2006 by Bruce Tomlin