Very Computer

Porting Linux to the Nintendo 64 has been the subject of April Fool's
jokes, semi-serious discussion, and "wouldn't be cool if..." remarks.

However, no one has really discussed the technical issues behind doing
this, and not many people have considered it seriously.

Well, porting Linux to N64 is not very feasible, but turning the
Nintendo 64 into a X-terminal IS possible.

Just for the hell of it, I looked up the specs for the N64, as well as
visited various N64 hack sites, to see if anything like this would be
possible at all.  These are the specs I came up with.

36Mb Rambus DRAM  (almost 5MB); Unified Memory Architecture, graphics
and ROM executables share this memory.

MIPS 4300i processor, instruction set is fully 4000-family compatible.

There are hacking tools that cover the creation of entire ROMs, as well
as pieced-together documentation of the N64 sound and graphics
processors

SOFTWARE:

Linux has been ported to the MIPS, including the 4000 family.  The
kernel can fit in less than 2MB of RAM, and with lots of tweaking and
paring down the kernel, probably less.

A very small x-host.  TinyX could serve as a base model.

Need to write drivers for graphics and sound DSPs, as well as keyboard
and mouse drivers, so that keyboard and mouse can be hooked up through
controller ports.

HARDWARE:

Cartridge to store kernel and X-host  (2MB should do it, compressed; 4MB
would allow you flash the ROM with larger ROM images in the future to
"upgrade")

8MB or 16MB of flash memory to serve as cache and virtual memory.  The
kernel could page to the flash memory, giving the illusion of much more
memory (flash memory is fast, so it shouldn't affect the performance too
badly)  Kernel could also use as small cache for network operations.

10BaseT on cartridge.  Switch available to set to hub or direct (direct
connects directly to another Ethernet card, hub connects to standard
network)

Keyboard/mouse adapters for controller ports.  Plug keyb in port1, mouse
in port2, then attach standard PS/2 mice and keyboards.

Nice to add cartridge interface on Xterminal cartridge, so that N64 can
be use as console and Xterm by just plugging in game cartridge, and
swapping controllers and keyb/mouse.

BOOT SEQUENCE: (POSSIBLE)

1.  Plug cartridge in.
2.  kernel boots, loads drivers for keyb/mouse adapter, sound and
graphics
3.  load TCP/IP support
4.  find server to connect to (XDM, etc.)
5.  load Xhost
6.  load WM, programs from server
7.  click shutdown
8.  turn off power and remove cartridge

OTHER POSSIBILITIES:

You could also use bootp and tftp to load the kernel and Xhost, cutting
down on ROM needed.

NOTES:

tools provided in ROM should include a utility to write new ROM image to
ROM.

single-user only, users would log in using XDM (standard Xterm
procedure)

Basically, it would work like a standard Xterminal.  Less expensive (the
cartridge with ROM, flash RAM, Ethernet chip) shouldn't cost too much
more than a new game.

Allows dual-use of home-computer.  For example, I can be writing a
thesis paper on the main machine, while my brother plays a Linux games
on the N64.  He can also use it to do graphics editing, writing short
papers, etc.

The TV text quality would suck of course, but in general, quality need
not be too bad.  640x480 at 16bpp (RGBA) with a virtual screen of
800x600 wouldn't be too shabby.  The Xhost would need some good
text-quality algorithms, though, but if these are implemented well, text
should be 'readable'.

the N64 terminal would probably not be used as often as a real Xterm,
but still, it would give a lot of flexibility to a current 1 homePC w/
N64 setup.  It would also be handy for any home network, and offer many
possibilities.

And anyways, it would ROCK if we could point to a N64 and say, "Right
now, I'm recompiling my kernel on that N64."

As far as porting and creating drivers and such, there are currently
hacking tools that allow N64 hackers to create their own games.
Therefore, basic graphics and sound information is available, making it
possible to write the needed drivers.

Any comments?  Anything that would really make this impossible?

David Freeman

.sig == wasted bandwidth
        hmm, just like this
        post, right?

A much more interesting concept would be an "Xterminal on a card".  I
thought of the idea a few years ago- a high speed graphics card, a
network adapter, and a large (perhaps 4MB) EEEPROM to store the Xserver
and/or bootup instructions, all on a single PCI card.  Pop it into any
obsolete X86 machine and you have an instant Xterminal.  Base the
Xserver and kernel on Xfree & Linux.

Time to change the machine- perhaps 5 minutes.  No hard drives to fail,
no other media required, no worrying about the latest chipset changes in
video and network cards.  It was/is a great idea.

Alas, it never happened.

--
/--------------------------------------------------------------------\
|   Mark A. Davis,  |Lake Taylor| Voice: (757)-461-5001x431 8-4:30ET |

|Information Systems|Norfolk, VA| from USENET remove anti-spam "yy." |
\--------------------------------------------------------------------/

[snip]

Quote:>A much more interesting concept would be an "Xterminal on a card".  I
>thought of the idea a few years ago- a high speed graphics card, a
>network adapter, and a large (perhaps 4MB) EEEPROM to store the Xserver

Quote:>and/or bootup instructions, all on a single PCI card.  Pop it into any
>obsolete X86 machine and you have an instant Xterminal.  Base the
>Xserver and kernel on Xfree & Linux.

SammyTheSnake
--


http://www.geocities.com/Athens/Forum/3353/
Today I am struggling to get back into a working state of mind...

QNX is VERY small kernel, their Xhost solution might have to be trimmed
down a little bit, but using flash memory as swap would help greatly.

->Linux has been ported to the MIPS, including the 4000 family.  The
->kernel can fit in less than 2MB of RAM, and with lots of tweaking and
->paring down the kernel, probably less.

Much less -- Unless the MIPS kernel is just plain bigger than the x86
kernel, you can make one that sits at around 600-700K.  Being a RISC
chip and all, I'd expect some bloat in the code but I think 2MB is out
of control.

->A very small x-host.  TinyX could serve as a base model.

But we have 64DD to play with -- it has 64MB of storage (20 of which
is writtable); so I know we can put xfree86 in there.

->Need to write drivers for graphics and sound DSPs, as well as keyboard
->and mouse drivers, so that keyboard and mouse can be hooked up through
->controller ports.

Is there a keyboard for the N64?  I believe that there is a mouse
already.

->Cartridge to store kernel and X-host  (2MB should do it, compressed; 4MB
->would allow you flash the ROM with larger ROM images in the future to
->"upgrade")

I think the shared libraries ought to be on the cartridge as well
(because it is so fast)

->8MB or 16MB of flash memory to serve as cache and virtual memory.  The
->kernel could page to the flash memory, giving the illusion of much more
->memory (flash memory is fast, so it shouldn't affect the performance too
->badly)  Kernel could also use as small cache for network operations.

Good.  Then put the rest of the filesystem on the 64DD (it would even
allow for downloading upgrades and/or saving settings in X; getting
Netscape and what have you).

->10BaseT on cartridge.  Switch available to set to hub or direct (direct
->connects directly to another Ethernet card, hub connects to standard
->network)

The 64DD will come with a modem; I don't think a 10BaseT cartridge
would be feasable.  We could have a serial cable run from one of the
joy ports to a serial-to-network machine (using PPP):  that wouldn't
be nearly as difficult.

->BOOT SEQUENCE: (POSSIBLE)
->
->1.  Plug cartridge in.
->2.  kernel boots, loads drivers for keyb/mouse adapter, sound and
->graphics
->3.  load TCP/IP support

We may need a PPP/DHCP step right here.

->4.  find server to connect to (XDM, etc.)
->5.  load Xhost
->6.  load WM, programs from server
->7.  click shutdown
->8.  turn off power and remove cartridge

->You could also use bootp and tftp to load the kernel and Xhost, cutting
->down on ROM needed.

That would be better.

->And anyways, it would ROCK if we could point to a N64 and say, "Right
->now, I'm recompiling my kernel on that N64."

The PlayStation would be much easier to do this with.  ;)  All the
tools are already in place (and you can even use GCC and/or Metrowerks
to do it)

--
ASCII stupid question, get a stupid ANSI

Quote:>Re N64 X-terminal...

>Sounds like a job for QNX!

--
Tracy Reed      http://www.veryComputer.com/
Q: Where would Microsoft take you today?  A: Confutatis maledictis,
flammis acribus *is... Micro$oft has a TV ad for their Internet
Exploder which uses "Confutatis Maledictis" from Mozart's Requiem. As the
announcer asks "Where do you want to go today?", the choir sings:
"Confutatis maledictis, flammis acribus *is" which is Latin for "The
damned and accursed are convicted to the flames of hell."

I see what you are saying... an OS is over kill for it...  Basically, if I
get it, you are saying is that the abstraction level of the "os" is
basically not there.  What is happening is that the software basically does
the work of the OS.  It seems that is the best way to get performance, but
do you think it might be a tad bit wasteful when it comes down to the size
of the extra code in each game?  Interesting stuff, never really put too
much thought into this!  :)

But, I think we all agree that Unix can just be compiled and ported to the
N64 in some form or another... I mean, that is the biggest reason Unix is
such a big os (in terms of UNIX/COMPUTER)

Quote:> >and/or bootup instructions, all on a single PCI card.  Pop it into any
> >obsolete X86 machine and you have an instant Xterminal.  Base the
> >Xserver and kernel on Xfree & Linux.

> The problem is that there are 4 different card interfaces (although 8- + 16-
> bit ISA are partially compattible and VESA is all but unused) so which do you
> use for the card?

--
/--------------------------------------------------------------------\
|   Mark A. Davis,  |Lake Taylor| Voice: (757)-461-5001x431 8-4:30ET |

|Information Systems|Norfolk, VA| from USENET remove anti-spam "yy." |
\--------------------------------------------------------------------/

Quote:>> >and/or bootup instructions, all on a single PCI card.  Pop it into any
>> >obsolete X86 machine and you have an instant Xterminal.  Base the
>> >Xserver and kernel on Xfree & Linux.

>> The problem is that there are 4 different card interfaces (although 8- + 16-
>> bit ISA are partially compattible and VESA is all but unused) so which do you
>> use for the card?

>I would make an ISA and a PCI version.  Since another target market
>would be for construction of terminals from new equipment as well as
>older equipment.

SammyTheSnake
--


http://www.geocities.com/Athens/Forum/3353/
Today I am struggling to get back into a working state of mind...

It's arguable either way; certainly on what amounts to an XTerm, we
don't need to have the "standard" stuff that distributions like Red Hat
set up for you such as:
 - Web server
 - News server
 - cron daemon

The point is that essentially the only thing that we intend to run on
the box is *one program,* that being an X server (probably an XFree86
variant).  When that's the only program contending for CPU and memory
(and as it manages graphics, it's *obviously* the only thing doing
graphics), one can argue that you can reasonably leave out the
Linux/UNIX kernel, drop the critical bits of functionality from the
kernel into the X server, and treat the X server as the OS.

I would counterargue as follows:

While there are components of the OS kernel that can get thrown away,
such as the process scheduler and things like file system "drivers," I
would comment three things:

a) In the "N64 tiny kernel," you still need the TCP/IP networking drivers,
which are a significant chunk of code, as well as memory management, and
some portion of device drivers.  

I don't think you save as much memory as people would hope for.

b) The "N64 tiny kernel" would need to be managed as a separate body of code
from Linux or any other kernel, with associated code management,
development, and debugging work.

This means that later Linux improvements can't be as easily pulled into
the "N64 tiny kernel."

c) The "N64 tiny kernel" is thus quite strictly limited in power.  

With "regular Linux," it would be a no-brainer to compile browser/Java
engine/clock/configuration package and toss it onto the N64 box.

With "N64 tiny kernel," adding additional applications would effectively
require adding back some of the functionality that was thrown away, and
hacking the new components into the system.

It might well be worthwhile for some commercial enterprise to make a
cartridge that turns a N64 into a NC using some relatively
closed-architecture "microscopic kernel." I don't think it's worthwhile
for Linux folk to try to build that.
--
The *Worst* Things to Say to a Police Officer:  Excuse me. Is "stick
up" hyphenated?

If you use your own CPU, why not integrate the KB/Mouse and leave the
PC away completely?

If you use the CPU on the motherboard, why bothering about integrating
the
network and video card? It makes the project more difficult, and if
there
is a new, better cheaper {network|video} chipset, you can't just switch.

You will have to move the bytes around outside the card if you use the
mainboards CPU and ram, and if you use an ISA bus for this, forget it.

OTOH, a PCI EEPROM card of acceptable (variable) size, mimicing a
harddisk,
and equipped with a RW/RO jumper (A use for that old turbo switch!)
would
be a nice idea to keep a system silent enough to work with.

just a few cents worth,
Christian Treczoks

Quote:> If you use your own CPU, why not integrate the KB/Mouse and leave the
> PC away completely?

But I like that idea, though- an X86 form-factor motherboard Xterminal
which can pop into any X86 type case and use the standard power supply,
with perhaps a few different types of memory support.

Quote:> If you use the CPU on the motherboard, why bothering about integrating
> the
> network and video card? It makes the project more difficult, and if
> there
> is a new, better cheaper {network|video} chipset, you can't just switch.

Quote:> You will have to move the bytes around outside the card if you use the
> mainboards CPU and ram, and if you use an ISA bus for this, forget it.

> OTOH, a PCI EEPROM card of acceptable (variable) size, mimicing a
> harddisk,
> and equipped with a RW/RO jumper (A use for that old turbo switch!)
> would
> be a nice idea to keep a system silent enough to work with.

--
/--------------------------------------------------------------------\
|   Mark A. Davis,  |Lake Taylor| Voice: (757)-461-5001x431 8-4:30ET |

|Information Systems|Norfolk, VA| from USENET remove anti-spam "yy." |
\--------------------------------------------------------------------/

 - steve

--

-- cary