Slashdot Mirror

This definately is not the oldest running software, as it was written only a few months ago, but it surely makes old hardware useful in a "modern" sense: The Contiki desktop OS for 80's 8-bit microcomputers like the C64, the 8-bit Ataris, Apple ][, etc. It features a full Internet suite, complete with TCP/IP stack, web browser and web server! Wonder what the world would have looked like if we'd had software like this back then...

An OS that runs in 512K isn't small after you've seen this. It is a graphical multitasking OS that runs in about a tenth of 512K (around 50K) and still manages to put an Internet suite in there (TCP/IP stack, web server, web browser, etc.). They even mention porting a Java VM for it!

An OS that runs in 512K isn't small after you've seen this. It is a graphical multitasking OS that runs in about a tenth of 512K (around 50K) and still manages to put an Internet suite in there (TCP/IP stack, web server, web browser, etc.). They even mention porting a Java VM for it!

A while ago slashdot posted a story about an Internet-enabled operating system with a web browser for the Commodore 64. It was claimed that the 21 years old C64 was the oldest system ever to run a (real) web browser, and a few days later this was changed to the 23 years old Atari 800 (see the web browser's homepage for the full story). This means that the web is almost 10 years younger than the oldest system to surf it!

A while ago slashdot posted a story about an Internet-enabled operating system with a web browser for the Commodore 64. It was claimed that the 21 years old C64 was the oldest system ever to run a (real) web browser, and a few days later this was changed to the 23 years old Atari 800 (see the web browser's homepage for the full story). This means that the web is almost 10 years younger than the oldest system to surf it!

• Multi-tasking kernel.
  
• Windowing system and themeable GUI toolkit.
  
• Screen-saver.
  
• TCP/IP stack for Internet networking, either with RS-232/SLIP or Ethernet (PPP is under development).
  
• Personal webserver for convenient file transfer. (Only in the C64/TFE version.)
  
• Simple telnet client. (Only in the RS232/SLIP version.)
  
• Web browser for Internet web surfing. (Worlds first web browser for 8-bit systems!
  

Slashdot reported about a graphical operating system for various small systems (Gameboy, Commodore, NES) a while ago, which perhaps could be used on this device as well? It had a TCP/IP stack, web browser, web server, etc: here is the Slashdot article, and here is the OS homepage.

I learned Machine Language programming on the 6502 from "Atomic Theory and Practice" by David Johnson-Davies. The 6502 is a rather neat processor. I even once wrote a compiler for a self made language that would compile to 6502 machine code. For a proof that some rather impressive things can be done with it, have a look at contiki.

They do have the schematics.

You want competition?
You got competition!

URL: http://dunkels.com/adam/contiki/links.html

System information and emulators

Commodore 64/128

The Commodore 64 is based on the 6510 CPU, which is a 6502-derived 8-bit CPU. It has 64k of RAM and 16k ROM which includes a BASIC interpreter and some basic I/O services. Graphics is provided by the VIC chip which has 16 colors and a maximum resolution of 320x200 in hi-res mode. It provides a 40x25 raster of characters in character mode. The three voices of digital sound is produced by the SID chip.

The Commodore 128 is an extended version of the Commodore 64 that contains a 8510 CPU which is capable of 2 MHz operation and can address 128k RAM (hence the name Commodore 128). It also has a Commodore 64 compatibility mode which is extremely similar to a regular C64 but with a few minor differences.

The SuperCPU is a 20 MHz 16-bit 65816-based computer that is plugged into the back of the Commodore 64 or 128. It uses the C64 keyboard and joysticks for input and the VIC and SID chips for audiovisual output. The SuperCPU is capable of addressing several megabytes of memory and is usually used together with a 16 megabytes RAM expansion board.

There are no SuperCPU emulators avaliable.

• The VICE emulator is capable of emulating a large number of Commodore machines. It emulates the C64, the C128, the VIC20, most of the PET models, and the CBM-II. VICE runs under Windows, Linux, FreeBSD, and a number of other host systems.
  
• Joakim Eriksson's Web C64 emulator, written in Java, runs as an applet within a web browser.
  
• Per Håkan Sundell's CCS64 emulator works under Windows and DOS.
  
• The ec64 emulator is developed for Linux and was originally written entirely in x86 assembler.
  
• An article by Simon N Goodwin about C64 emulators.
  
• The Commodore emulators category in the Dmoz has more links.
  

Commodore 64/128

There are plenty of alternative operating systems for the C64, mostly written in 6502 assembler. Some of them are far from complete, however, and only appear as dark shadows on a few web pages - MagerValp's SMOS and my own osT are among those.

• GEOS from 1986 probably is the most well-known graphical operating system for the C64. It is still sold commercially by CMDKEY.com.
  
• LUnix NG is an open-source multi-tasking operating system with TCP/IP/PPP-support, a *nix-like command shell, and a number of *nix-like utilities such as ls and cp.
• Craig Bruce's ACE is a text-based single-tasking operating system for the 64 and the 128. It provides a *nix-like command shell, a text-editor, a terminal program for the SwiftLink RS232 interface, as well as device drivers for a lot of devices
  
• GeckOS/A65 is a multi-tasking operating system with TCP/IP support and a *nix-like command shell.
  
• Wheels is a version of GEOS that requires RAM expansion to run.

With its 20 MHz and megabytes of memory, the SuperCPU is powerful enough to run fully-fledged graphical operating systems that rival early Machintosh or Microsoft Windows systems.

• Wings is a TCP/IP-enabled graphical operating system for the SuperCPU. It includes a MOD music player, JPEG viewer, web page download utility, etc.
• JOS is an older version of Wings.
  

TCP/IP and PPP connectivity

To surf the web, send or read email, etc., the first step is to actually get in touch with the Internet. This requires both physical access to an ISP, either via a modem and a phone-line or an Ethernet broadband connection, and the TCP/IP software running on the C64.

There are a number of programs that make it possible to reach the Internet with a C64/C128.

• LUnix NG contains a TCP/IP stack and a PPP implementation which makes it possible to reach the Internet using a modem and a dial-up ISP.
  
• GeckOS/A65 also contains a TCP/IP stack, but no PPP dialer.
  
• My own uIP TCP/IP stack has been used for some time to run a web server on a Commodore 64. uIP currently does not include a PPP dialer.
  
• Novaterm 10 contains a PPP dialer and enough TCP/IP code to be able to run telnet over the Internet.
  

SuperCPU

All of the above mentioned SuperCPU operating systems have TCP/IP support.

• The Wave is a web browser for the SuperCPU (and not for the Commodore 64/128 as the web page claims) that runs under the Wheels operating systems. Here is another page with information about The Wave (that also falsely claims that The Wave is for the Commodore 64/128). The latter page also includes screenshots of The Wave in action.
  

Small graphical user-interfaces (GUIs)

User interfaces for embedded systems range from the simple buttons on the front of a washing machine to those of fully fledged web browser type interfaces on information stations. The underlying technology varies from simple electronic circuits to full-scale PC compatibles.

• PicoGUI is a GUI architecture designed for embedded systems to desktop machines. It does not require any supporting GUI system and can be used on anything from graphical screens to text based systems. Their smallest target system are handheld terminals and the compiled object code size is on the order of hundreds of kilobytes.
  
• Microwindows/NanoGUI is a graphical user interface system designed to run without support from an underlying system. On 16-bit systems Microwindows is about 64k large.
  

The smallest web browsers are usually specially designed for the limitations of embedded systems and other specialized computers such as car navigation systems, set-top boxes and medical equipment. There are also a few small web browsers for old DOS PCs available.

• Interniche's NicheView Portable Embedded Web Browser is probably the smallest full-featured web browser around with its 35 kilobytes code footprint. There is also an additional JavaScript module available.
  
• AU-systems' AU Mobile Internet Browser supports both HTML/TCP/IP and WML/WAP as well as SSL. It occupies 340 kilobytes of code (plus an additional 190 kilobytes for the protocol stacks) and uses 5 kilobytes of RAM when idle (plus 8 kilobytes used by the protocol stacks). Extra RAM is used when downloading web pages.
  
• The Fusion WebPilot Embedded Micro-Browser supports much of the features found in modern web browsers including frames, authentication, and JavaScript. The web page does not specify memory footprint.
  
• MicroDigial's Graphical MicroBrowser supports tables, frames, images as well as FTP as uses 260 kilobytes of code memory and requires a minimum of 210 kilobytes of RAM apart from that. A demo version is available.
  
• The 2net Alice Web Browser is intended for handheld computers and PC based architectures and requires 400 kilobyte of free RAM and 200 kilobytes of code memory. It includes a TCP/IP stack.
  
• WebBoy is a fully-fledged browser with SSL support intended for 386 DOS boxes with more than 4 megabytes of memory. Includes a TCP/IP stack.
  
• The Arachne web browser runs under MS-DOS or Linux and requires at least 1 megabyte of memory. Does not include a TCP/IP/PPP stack.
  
• Lynx is probably the most well-known text-based web browser around. It is ported to many different operating systems and architectures including MS-DOS.
  
• The Off by One Web Browser has been labeled as the smallest web browser ever, but is quite large in comparison with other small web browsers. It is 1.1 megabytes large and requires support from an underlying Windows operating system.
  
• Mirko Sobe's BOSS-X HTML browser for 8-bit Ataris is not a full web browser, but an off-line HTML viewer with hyperlinking abilities written in three days.
  
• The pre-alpha v0.3 GEMWeb browser supports 640x480x16 VGA.
  
• The Atari Phoenix Web Browser is a non-existant vapor-ware web browser project intended for the 8-bit Ataris.
  

Kudos to these guys. My first thoughts after, "No freakin' way!" were, "How the heck did they get ethernet and a C64 together?"

I figured it was some sort of butt-slow serial hack, but instead they designed their own C64 ethernet cartridge! Nicely done.


Come to think of it, weren't these the same guys we saw a while back here on /. that had some sort of odd C64 hybrid that streamed audio?

*sniff* Hmmm, do I smell burning plastic? Ahh yes, there melts another C64 powersupply.

Oh well, it died an honorable death. Damn /., destroying the remains of our technological history! :)

Blockwars: a realtime multiplayer game similiar to Tetris.

According to the ports page:

The NES port of Contiki is developed by Groepaz and currently works but without networking support because there is no networking hardware for the NES available (yet!).

If you know much about electrical engineering, the nesdev community could use your expertise in creating network hardware for the NES. Even a high-speed serial port would be a good thing.

While you probably meant that as a joke, youe might want to take a look at the Slashdot article about TCP/IP for LegOS. The TCP/IP stack used already includes a simple scriptable web server...

Just try and load your root-kit onto this machine. Whaddya mean ?OUT OF MEMORY AT LINE 10.
Previously discussed on slashdot back here

Recently an Ethernet cartridge for the Commodore 64 was developed (this was featured on Slashdot a while ago along with a web server running on a C64.).

This might be the kind of stuff that brings the C64 into the 21th century - serious on-line gaming!

I beg to differ. Look, on http://dunkels.com/adam/tfe/software.html it says:
A timer IRQ fires 2000 times every second and samples the input pin of the casette interface. The 1-bit value is written into [...]

Then, they re-state the sampling frequency as being "2000 Hz" on http://tfe.c64.org:6510/listen.html
Where did you get the 8kHz from?

Some interesting stuff on http://dunkels.com/adam/tfe/hardware.html:

IThe IO/1 and the R/W signal from the C64 are used to create the ISA control signals using the 74LS139 decoder.

Muwhaahaa! They _actually_ make that chip anymore! :-) Sorry friends, just kidding. I thought using 74 logic was illegal by now. ;)

BEWARE this layout is currently FAULTY. The read and write signals for the Embedded ethernet board were switched.

Now, there's nothing funny about that. I'm actually quite surprised about the tools that schematic capture people use. The symbols never seem to have been created correctly and it's amazing how hardware designers do not seem to use their tools to pick up errors for them, despite the incredible cost of making a mistake.

As a guy that comes from a software background, I look at it this way: one pin on the chip is write. It's obviously an output for that chip. This has to go to an other chip, for which it obviously has to be an input. For the read, it's again, obviously, the other way around. Now I understand humans fucking up, but the design software should pick this up: "you are connecting an output to an output".

I have used these schematic capture programs, and I know that they WILL pick up these kind of errors, as long as they have been specified in the symbols for the chips. But to name just one example, Intel, they create their symbols with all pins being passive. In other words the software can't pick up on errors like this.

I guess it's the same reason programmers don't use lint, but it's a lot cheaper for use to make mistakes during the development cycle (most of the time).

Believe me, I'm not trying to make fun of a couple of guys hobbying around. That's all cool. But I've seen the same thing done by contractors that get paid a decent amount of money to do these designs.

Lisa? MAC SE?!

Of course your modern day super computers can handle a web server. OTOH, it's only recently that web server technology has filtered down to the humble computers that people can actually afford to buy.

(Check the link, yes it's a C=64...) I guess the poor machine will be slashdotted to hell even though this is a late entry in an old thread. So, a short summary:

c64.cc65.org is a web server hosted on a C=64 connected by SLIP through a serial cartidge to a Linux computer (which in its turn is connected through ADSL). The IPstack and all processing is on the C=64. The C=64 has not been expanded in any way, save for the IO cartridge (SwiftLink 38400bps serial).

The page is small, but there is a few images on it... The server was created by Adam Dunkels as a part of his uIP TCP/IP stack for the C=64.

If you think this is cool, you might want to check out this. It is a Commodore 64 that is running as a web server, and has been up 24/7 since november 2001. It is connected to the Internet via a 38400 bps SLIP link so it is quite slow.

For those of you who doesn't remember the Commodore 64, it was a very popular home computer in the 80's and early 90's. It has 64k RAM and an 8-bit 1 MHz 6502 CPU.

The C64 web server is running the small uIP TCP/IP stack that is less than 4k large and uses only a few hundred bytes of dynamic RAM. Since it is written in C, it has been ported to numerous other systems such as the 8-bit Ataris and a number of embedded processors such as the Hitachi H8S.

Take a look at http://c64.cc65.org/. It is a good old C64 working as a web server. It runs the uIP TCP/IP stack, which is written in C and is really tiny; the code is around 4k large and it uses some 200 bytes of RAM.