I volunteered to update the FAQ, but have not gotten past the
preliminary message I posted a while ago:

 http://mail-index.netbsd.org/port-dreamcast/2002/01/28/0000.html

Yeah, I've been feeling bad about it.  Above post will tell you how to
netboot a DC, but

 (1) The compiler might not work.  I wasn't able to test it.  Even if
     it does, I guess -current isn't buildable yet, so the
     instructions are more of a head-start on the development cycle
     than a working system.

 (2) I haven't booted root-filesystem-on-CD yet, only NFS.  I'm
     supposed to build and use objcopy to make the CD, but it's hard
     for me to get anything done (dialup/40MHz sun4c/disk space
     problems).

Making pre-packaged ISOs is misleadingly appealing because dreamcasts
do not have hard disks.  Look, if the dreamcast is self-hosting, it
must have Ethernet and an NFS root, so an ISO is useless.  OTOH, if
you use a host-target build environment instead you can still use
Ethernet/NFS, or you can use a CD as the root filesystem but then
pre-built ISOs are still useless because building the ISO becomes part
of the development cycle.  

And it is a multi-session CD, so an ISO underdetermines what the CD
should look like, rather than excusing you from the need to understand
weird boot-up styles like ISOs do on other architectures.  What we
need are instructions for making ISOs and CDs, not the ISOs
themselves.  Unless someday the ISOs are of ready-to-run Quake under
NetBSD or something.

I guess right now we are waiting for gcc 3.x to get merged into NetBSD
so that the SuperH ports work again.

w.r.t. a sound driver, I noticed that KallistiOS requires an arm??
compiler to support the SPU.  I'm using the ``DC Tonic'' CD to play
MP3s.  The arm source is in

 On the DC Tonic CD
  /source/packages/kallistios-1.0.0.tar.gz
   kallistios-1.0.0/userland/streamtest/arm/

which calls 'arm-elf-gcc -mcpu=arm7' to build the so-called
``firmware'' for the sound chip.  The KallistiOS ``firmware'' doesn't
do any respectable computation---it just frobs registers and toggles
between two shared memory buffers.

This could be an interesting project for someone who knows more than I
do---at least you could finally do DMA the way you think it ought to
be done.  Depending on the chip's capabilities, it might decode Vorbis
streams, scale arbitrary sample rates, mix multiple audio streams.

Or you could try to do something really weird, like a device driver
that uses language features more like IPC than DMA.  There seems to be
a real poverty in current OS design (language tools, debuggers, ...)
for properly dealing with modern computers that contain multiple CPUs
of different architectures---instead, all CPUs except the fastest are
oppressed into the status of mere ``devices'' and forced to run
interpreters for sickening punchcard languages that one writes only in
hex.  _I_ say, this is not gospel, but rather an unholy alliance
between inherently evil proprietary software and intimidated
electrical engineers who prefer FORTRAN.

At least the two-architectures-in-one-target deal means you could make
my NetBSD builds take one day longer.  fun!

-- 
``[The capitalist] intends only his own gain, [but he is] led by an
invisible hand to promote an end which was no part of his intention.''
		-- Adam Smith