Iain Laskey wrote:
> In article , ndary@bigfoot.com (Nir Dary)
> wrote:
> > i agree, i would love to see an 8-bit version of Unix
> > can it be done?
> Nope. Unix needs all kind of funky memory management stuff that the 6502
> simply doesn't have. I couldn't get on to the URL quoted but I suspect
> someone has implementd some Unix commands but not actually got Unix
> running them.

Actually, that depends. You're pretty close to being right (none of the 8-bit
machines we all wasted our youth in front of have an MMU, and therefore any
hardware support for virtual memory), and yet, I think you're ultimately wrong.

What is the criteria for an operating system to be considered a "Unix"? Is 
Unix by definition a virtual memory-based OS? Or is it the file/device   
model, or the process model that make a unix a Unix? Does it have to be   
written in C, and have C libraries in an area of its filesystem that's
called /usr/lib? Ultimately, if you can't quickly tell the difference
between an actual unix machine and a contender for the title, does it
matter? OS'es are a funny kind of software - people like to think of them
as much more precisely "defined" than they actually are.

Don't forget, there are people out there older than your parents who wrote
multi-user OS'es for machines that predated silicon. Think how they must
feel - their OS supported 50 simultaneous users with 3 1/2K of drum memory
and CPU made out of bailing wire and after-market auto parts, and now if 
they buy a PC, they have to get a Pentium II and add an extra 128MB of RAM
just so they can run Windows.

I think one of the most commonly agreed upon things a Unix should have is
the ability to preemptively multitask, and I bet the Commodore 64 can do
that just fine. After all, all you need is a CPU that supports interrupts
and a programmable timer w/ an interrupt line. Sure, context switches will
be a little slow, but what the heck, right?

After that, you'd want at the very _least_ a standard for creating
relocatable code, and there's certainly nothing stopping you from doing  
that on the C64. You just need to write a special assembler, or maybe make
up a mini high-level language compiler that supports the system... Presto,
now your programs can be loaded dynamically, right on top of one another.
At least until your address space fragments all to hell, that is. (Hey,   
you could always write a memory defragmenter daemon... it would probably
seem oddly reminiscent of the Java garbage collector!)

If you want to go hog wild you can implement a basic driver model, and set
up "devices" for the screen, keyboard, and disk... then your per-process
tty devices are not far off. Maintaining a system for handling standard   
data channels is pretty easy, since you already have your binaries coming
to you for relocation instructions. You can just link them against some  
input/output libraries too. Presto.

A real filesystem is a very complicated thing - but we don't need a _real_
FS, just a 12 hour kluge - after all, what're we accessing? Single-sided
single-density floppy disks. Of course, we could always download the
filesystem code directly to the 1541's CPU, since it's faster than the C64

What's left? A shell, you say? Writing a shell is easy. My high school art
teacher could probably write one. I wrote a shell one afternoon. It took
me three hours. This is just further proof that the people who wrote tcsh 
had industrial quantities of crack cocaine available to them at extremely
low cost throughout their development period.

Now, I bet I could already fool you. I can boot up the machine (hey, I    
could code a bootstrapping routine and burn it into an EEPROM and make a  
cartridge out of it! - cough - pass the pipe, please...), I've writtem a
few basic utilities to interface data from the kernel (ps, kill, mem), a
few more linked to the disk driver (ls, rm), and I have a few user
programs that I've made (anybody wanna port nethack to my new
platform?)... I can launch them, run them in the background, kill them,
etc... That's Unix in single-user mode anyway. And as everybody knows,
multi-user capabilities were added to unix during an all-night drinking
binge at AT&T's Bell Labs - so throwing in a few extra bits of state to
process and filesystem records should be easy. Add a password file and a
login program and viola - multi-user unix.

Of course, there's no memory protection, but hey, there isn't any in
Win98, either! If one wanted to, they could probably release an MMU
cartridge with a little cache thrown in, and then I just need to write
some paging routines to manage it! Now not only can I shut down a program
that references an illegal address, but I can run Emacs! All I need is
about 700 floppy disks (1,400 if I don't cut the little write-protect   
notch out of the other side to make them flippable) and a bit of elbow
grease, and I'll be swapping my way to glory, all with my lovable little  
8-bit machine.

Of course, I don't really _need_ an MMU as long as I don't want to
thoroughly enforce my memory protection; I can always implement a
page-mapper in software have all my binaries use a "dereference" function.
Then I at least get to do paging. Of course, now I'll be needing qualudes
instead of speed, because this will make my system rather slow... but it
doesn't matter! I can just whip out my LIQUID NITROGEN TANK and SUPERCOOL 
80 TIMES ITS NORMAL SPEED. Then I could go right out and sign up to help
crack all of  RSA's secret keys! Free credit card numbers for all!


Log in or register to write something here or to contact authors.