Subject: X-Box and PS2 port candidacy
To: None <email@example.com, firstname.lastname@example.org>
From: Miles Nordin <carton@Ivy.NET>
Date: 03/14/2001 19:10:45
> c. If ports for other hardware consoles (PS2, XBox, etc.) are created,
I've been lurking here for a while, and can affirm that NetBSD ports to
new hardware seem to be considerably less difficult than one might
imagine, given how tightly most of us are bound to ``desktop'' computers,
or how many ``Internet Appliances'' are disguised PeeCee's, or the
colossal fanfare and pressrelease hornblowing surrounding a new port of
RedHat or Debian GNU/Linux. They usually only take a couple months to
become useful, _if_:
o The CPU has VM.
o More than one person is interested in the result. Three or four
people seem to be plenty to pull off a port all by themselves.
This is obviously not a problem for the PS2, but maybe for the XBox.
o The device itself is obtainable. This is difficult with PS2 if
you do not have Japanese citizenship, since Sony enjoys considerable
protection by the Nipponese government.
XBox does not exist and could be cancelled at any moment from some
business strategy market model redirection necktie-damage. This has
happened with one device to which NetBSD was ported already, and the
decision involved the same technically-suspect markedroid company.
o The device is documented.
The DC is unique in this respect, because I think maybe Sega does
not have the technical/legal power to mask their own CPU's, so the
SH4 chip has documentation from Hitachi. Also, Sega has elected
not to use serious cryptographic obfuscation techniques, expensive
legal threats, or government lobbying to turn their meatspace
devices into protected so-called ``intellectual property''---
consequently, some independent hardware docs for DC exist, and
will probably have the freedom to develop further.
While there is a fairly good chance that any sort of ``cryptographic
obfuscation'' on the XBox will be broken to the point of
meaninglessness just like ``domain authentication'' and ``PPTP,''
I think documentation will be harder to get for the PS2 and XBox
than for the DC. but that is just my opinion.
This is Critical. Ports seem to be made to documentation, not to
hardware. Ex., this is plausible:
``I got low-level documentaiton for Device X, want to do a port?''
``Sure! How hard is it to lay your hands on an X?''
while this succeeds far less often than one might think--amost not at all:
``I got 20 free Y's! want do do a port for me? I'll give you
half of them.''
``Sure! How hard is it to find correct documentation for a Y?''
> in theory, could this indie developers create NetBSD console games
> that run on any NetBSD supported system?
What a foolish idea. Why would anyone want to use working thread
libraries, Mesa GL, and first-rate compilers in a proven embedded
operating system that runs on all the major game consoles and all
the major ``desktop'' computers, when the person could simply write
their own version of these things, and write them repeadedly, once for
each proprietary console, and twice again for Mac and PeeCee?
seriously now, it seems there is a gigantic financial incentive for
console companies to prevent NetBSD from creating a port to their
hardware, and the price of their success is passed directly onto their
customers in the form of more expensive games that bear the ``Sony Tax.''
This is terrible for NetBSD in general, not just NetBSD on game consoles,
because so much bleeding edge technology goes into making games. Rather,
I think we would like this financial incentive to pay for free(ly
available) contributions to NetBSD for things like a fast, light, 3D GUI
layer; or our SMP/preemptibility work; or a good FLASH filesystem; or (my
favorite, a longshot) toolchain improvements on notIntel CPU's, like clisp
on netbsd--mipsel or proper C optimization on arm32 or some more assembley
primitives for libm.
These are all things that game companies will probably have the money,
expertise, and inclination to contribute to NetBSD. I can envision a
gaming company being more interested in getting free support for such
improvements than depriving their competitors of their work, because the
work is so tangential to their ``product''. These improvements are also
things that will be a godsend to other NetBSD users who are not game
companies. so, this scenario is an example of code-sharing that is
uniquely enabled by the sometimes-dubious BSD license.
However, NetBSD and the hardware manufacturers are fighting over the
same wad of cash, albeit indirectly. If the game companies have to
pay the Sony tax, they will use the Sony toolkit. If NetBSD is an
option for them, then they will have this additional budgeted tax
money freed up to improve the NetBSD toolkit to meet their needs.
My hopefully-mistaken gut impression is that the Sony Tax is basically
what Sony is depending upon to ensure their solvency over the next five
years, so I think ``why can't we all just `get along,' and both
Sony and NetBSD can win. no, really. The best way is to make
`relationships' with companies---it worked with Digital, so it'll work
with Sony.'' is going to be the Lemming Option for NetBSD. see, (1) It
didn't, exactly, ``work'' with Digital, remember? and (2) Sony is a very
different kind of company. I'm not even sure Sony _is_ a company any
so, it's war. Any ideas on how to insure that we win and they lose?