Operting systems list

[Alienthe]

This web site is a treasure trove for all things related to 6502. Unfortunately some gems are buried a little deeper, such as operating systems. Gecko is one example, filed under Homebuilt 6502 Computers & Hardware.

I would therefore like to propose a new category for links to operating systems.

In addition to Gecko there is LUnix, GEOS, Wheels and more. Is the source available for all these?

Links to in-depth analysis of the OS for well known 6502 machines like C64, BBC and others would probably also be interesting. Also add-ons to these can be interesting, I believe I once saw a unix-shell lookalike for Apple II OS.

I read here that 65816 is more compact in code than 68000. The latter has Linux support, how about the former?

[BigDumbDinosaur]

Alienthe wrote:

Links to in-depth analysis of the OS for well known 6502 machines like C64, BBC and others would probably also be interesting. Also add-ons to these can be interesting, I believe I once saw a unix-shell lookalike for Apple II OS.

Some years ago, Craig Bruce wrote a UNIX-like shell for the Commodore 128, which I actually used for a while. The shell itself performed briskly but was hobbled by the CBM floppy disk drives. When I acquired a Lt. Kernal hard drive subsystem I no longer needed Craig's shell, as the Lt. Kernal DOS provided everything that was needed.

Quote:

I read here that 65816 is more compact in code than 68000. The latter has Linux support, how about the former?

If a port of Linux to the 65C816 exists I've yet to hear of it.

As for code compactness, that would strongly depend on the skill of the programmer. One thing that the 65C816 does have going for it is direct page addressing, which instructions are smaller than the same instructions that use absolute addressing. The MC68000 has no equivalent to direct page addressing. Other '816 assembly language features can also be used to keep code size under control, especially in cases where parameters must be passed into and out of subroutines. On the negative size, the '816 doesn't have any special opcodes for handling 16 bit register operations. One must select register sizes via the REP and SEP instructions, which does add code (and also complicates interrupt servicing).

Something else that works in the '816's favor, but isn't necessarily related to code size, is its short interrupt latency, an important feature in an operating system that uses jiffy IRQs for task preemption. The MC68000 is slow in comparison, as it has a much more complicated interrupt model. It also doesn't support the SEI -- WAI programming mode that the '816 does, which can produce single cycle interrupt response.

[jbevren]

For the 65816, there's a (slim) possibility of resurrecting a long abandoned operating system for the commodore 64 + superCPU combination:

http://sourceforge.net/projects/wingsos/

You have the usual caveats of running an OS with no memory protection of course. One unexpected exception can bring the whole OS down.

Since it's written for specific hardware, it would need a new set of drivers for other systems, and would probably want interruptable storage systems to maintain its multitasking ability.

[BigDumbDinosaur]

jbevren wrote:

For the 65816, there's a (slim) possibility of resurrecting a long abandoned operating system for the commodore 64 + superCPU combination:

http://sourceforge.net/projects/wingsos/

Have you looked at the source code for that? A comment would die of sheer loneliness.

Quote:

You have the usual caveats of running an OS with no memory protection of course. One unexpected exception can bring the whole OS down.

Since it's written for specific hardware, it would need a new set of drivers for other systems, and would probably want interruptable storage systems to maintain its multitasking ability.

Given all that, starting with a blank sheet of paper would be no more work. One thing I've learned over the years is that there is a lot of 65xx assembly language software written with no concept of reusability—or any thought of being understandable to anyone other than the original developer. Even in cases where the source code is heavily commented and the author has gone to the trouble to document the basic program flow, adaptation to a totally different hardware environment is usually not trivial.

[White Flame]

I doubt you'll find official GEOS or Wheels source code. Those were commercial, and afaik haven't released an open version. There might be an "Anatomy of" style book or disassembly analysis website which break it down, but I wasn't a GEOS user and am not sure.

LUnix's sourceforge and web pages are still up, with source code.

Project64 is a great repository of manuals and books deliving into every byte of the Commodore 8-bits. I contributed some books here, including Mapping the Commodore 64, which literally does go byte by byte through the system.

Contiki also got its start on the 6502 with the C64, and I'm sure that's still documented somewhere.

[Alienthe]

WINGsOS appears to have a separate web page: http://wingsos.org/
Not much happening there since 2008.

It seems there is a relationship between GEOS, Wheels and WINGs but the details are a litte hazy.

There is also PicoOS: http://picoos.sourceforge.net/

[White Flame]

Wheels and MegaPatch3 (often called MP3) are two independent upgrades to GEOS. I don't know if Wheels swung an actual deal with Berkeley to license the GEOS base or not. Likely both were derived and developed without vendor support, products of disassembling and patching the binary.

WINGs is not related to GEOS at all in terms of compatibility or design, other than being a "competitor" in the graphical OS space. It was written from scratch.

The WINGs website is also a great example of why not to set a fixed width/height:


(on a 4k monitor)

[cr1901]

Alienthe wrote:

I read here that 65816 is more compact in code than 68000. The latter has Linux support, how about the former?

It doesn't exist to my knowledge, no doubt in part because the '816 version of GCC was dropped long ago, and Linux relies on GNU's extensions to the C standard. The only two other compilers I've heard of compiling Linux successfully are Intel's C Compiler and a modified version of the Tiny C Compiler, both for x86.

However, Clang should be able to compile Linux soon enough... that would probably be the best bet- write an '816 backend to LLVM.