Subject: Re: Accomplishments to shoot for.
To: None <port-dreamcast@netbsd.org>
From: Rob Healey <rhealey@norstar.com>
List: port-dreamcast
Date: 01/11/2002 12:26:44
> On Thu, Jan 10, 2002 at 01:03:32PM -0500, Drew P. Vogel wrote:
> Executive summary: XFree86 uses a lot of address space to access card
> registers and framebuffer space. This shows up in "ps" listings, but
> is not actually taking any physical memory.
>
> It is entirely possible to run an X server that takes less than 1MB of
> memory (using Keith Packard's Kdrive setup). It is even possible to
> have a full XFree86 server using about 2-4 MB.
>
I originally stated the X was too big, notice I refered to the entire
system, not just the server. Once you load in the fonts and misc into
the server and the apps, and worse the LIBRARYS, into memory then your
physmem goes WAY down and thrashing starts. I spent enough years on
NetBSD/Amiga and NetBSD/x86 with 16M machines to know what is real
and what is imagined/sparse address space!
The server size can be minimized but 16M of physical RAM + the X
system as a whole just doesn't work. In the old days the required libs
didn't consume the address space like they do now. Modern apps, fonts
and modules now make 16M unrealistic for practical use.
Looks like the KOS code will allow some chance to code audio and
graphics in NetBSD if the ^%$^%$^% compiler will eventually cooperate...
For those that wish to tinker I would suggest the KOS code gives the best
details on the hardware from which to base NetBSD drivers and user mode
code.
While the LinuxDC port code is more UNIX(tm)y in nature, the license
on the code usually prevents the NetBSD core from accepting derived works.
KOS appears to have a BSDish license that would be more acceptable to the
NetBSD core team for derived works.
Best way to attack it would be to
copy down the hardware specs from KOS headers and start whacking on a
similar driver type from somewhere else in the NetBSD tree; don't know off
hand if any of the PCI sound cards use an ARM7 like the Dreamcast does and
the gcc compiler is squirrly enough with SH code, let alone ARM7...
My $0.02 till I can get #$%#%$ gcc to cross compile correctly for at least
SH code.
-Rob