Linux on a Sega Dreamcast

The Sega Dreamcast is a pretty kick-ass little piece of hardware, despite its untimely demise. With the recent price cut and the release of the BroadBand Adaptor (a fast ethernet interface), many of us geeks are liking the prospect of a sub-$200 set-top *nix box with OpenGL, programmable sound engine, and lots of other niceties.

The NetBSD people had a head start (they're really into this cross-platform thing), but the Linux Camp gained ground fast, thanks in no small part to the efforts of the SH Linux project.


Lacking time to hack this puppy anymore, I sold the whole kit'n'kaboodle (or however that's supposed to be spelled).

Work Log

A proper OS logo on the DC chasis
Adam's DC running Linux
I've started researching XFree86's DRI architecture, with the intent of using it as the framework for PowerVR2 acceleration support. Put myself on some mailing lists, pulled soem source and some documentation... lots of reading to do before I get my hands too dirty :-(
My "linux inside" badges just arrived from ScotGold via air mail, now I'll be able to cover that ghastly "Windows CE" logo on the front of the Dreamcast chasis...
Ok, created /tftpboot/ on my bootp/nfs server and populated it with the latest base-sh3-datecode.tgz tarball from this directory, customized a few files (/etc/hostname, /etc/fstab, /etc/network/interfaces, /etc/hosts, /etc/resolv.conf, /etc/localtime), and we were pretty much ready to boot.
Here (and to the right) is a picture taken just last night (4/11/2001) of my Dreamcast successfully booting up, talking with my BOOTP server/router (an old IBM PS/1), and trying to mount an NFS root (which I haven't yet set up). The tell-tale orange light is visible toward the lower-left corner of the image; tux sits atop both the TV screen image and the TV itself. The laptop beside my lovely plush tux doll is my Inspiron 3500, used (among other things) to burn the boot CD and to telnet to all the other machines in my network to set things up; also visible at right is the Ricoh G-1200s, which is in-shot for no particular reason.


Now that my HP CD-RW drive is working under Linux, it's time to get to work. I've got my BBA and a big ol' pack of pristine CD-Rs, just waiting to be put to maximum use.

Distro bootstrap
A proper technique for bootstrapping a Debian distribution (like the one being worked on over at onto a dreamcast is needed. Since the dreamcast is pretty much a static piece of hardware, what's really needed is a "baseline" distro CD that includes most of the packages unpacked and configured, and a fairly simple way to have must-be-configured state reside in either a memory device or a local NFS server.

A few options:

  • NFS Server install: all Debianisms are actually handled on a bootp/nfs server with an exported root for the DC to use. Simple, flexible, quick upgrade, but performance may be less than ideal since the DC needs to get everything except the kernel (or boot loader) over the network.
  • Burn-yer-own-CD: A CD-R capable host builds the filesystem, including all /etc configuration and all that junk, then burns a filesystem which includes the kernel and / on an ISO9660 fs. /usr/local and /home and /var would need to be either remote mounted (nfs/samba/coda/etc) or reside in a VMU (very limited capacity), and the locations are hard-burned into the /etc structure. It's a shame Linux doesn't yet have an overlay filesystem - it would make updating so much easier (mount an NFS overlay on top of the read-only ISO9660 tree).
The DC has a pretty nifty sound architecture, including its own dedicated ARM7 processor and a wavetable synthesizer. I see at least two projects here...
  1. Write a shim engine for the ARM and a basic "bounce" driver so the traditional sound architecture and/or ALSA can offer the "traditional" OSS interface. This will certainly include /dev/dsp output, a basic mixer, and should probably include using the Yamaha wavetable as a synth/midi target and supporting pumping CD audio straight out as well (perhaps a parallel issue with the CD/GD-ROM driver developers - I don't know if there's a hard path or if we'll have to pump everything through in software).
  2. Expose the sound architecture directly (think of DRI) via a well-designed kernel driver. This is actually the easier of the two because essentially all you have to do is allow two memory regions to be mapped or read from/written to, plus a few ioctl()s to start and stop the processor. While simpler, I'm thinking of this as a longer-term project simply because the first will have a more immediately gratifying payoff!
This will require ports of:

Some Linkage: