Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

The Contiki Desktop OS for C64, NES, 8-bit Atari,

Hemos posted more than 11 years ago | from the making-the-jump dept.

Announcements 403

Adam Dunkels writes "This is for those of you who think that a text-based operating system that fits compressed on a 1.44Mb floppy counts as 'tiny': the brand new Contiki operating system and desktop environment for the Commodore 64, with ports to a bunch of other platforms such as the 8-bit Nintendo Entertainment System, the VIC-20, 8-bit Ataris, Atari Jaguar, the Tandy CoCo, and the Apple ][ under development. The Contiki system includes the following: a multi-tasking kernel, a windowing system and themeable GUI toolkit, a screen saver, a TCP/IP stack, a personal web server, and a web browser. The Contiki web browser, which is likely to be the world's smallest browser given its extremely small memory footprint, is the world's first true web browser for an 8-bit system and probably makes the 21 years old Commodore 64 the oldest system ever to run a real web browser! All of the above programs are contained in a single, fully self-contained, 42 kilobytes large binary. The entire Contiki system with all programs running simultaneously is comfortable in 64 kilobytes of memory. The name 'Contiki' is derived from Thor Heyerdahl's famous Kon-Tiki raft which was able to sail across the Pacific Ocean despite being built using prehistoric techniques, something previously thought impossible. There are also screenshots and a FAQ avaliable."

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered


Sick (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#5475814)

I am sick today! Oh God it hurts!

Hi hi :)

Pyjama Farm (-1, Offtopic)

turgid (580780) | more than 11 years ago | (#5475819)

Sounds like someone needs a relaxing break at the pyjama farm. Quick, call the doctor!

Re:Pyjama Farm (0)

Anonymous Coward | more than 11 years ago | (#5475946)

Monday 6:30AM in California, as I awaken I find this site slashdotted. WTF?

Moderators on Crack III (1)

turgid (580780) | more than 11 years ago | (#5476105)

Look, if might be flamebait or even funny or troll, but it certainly is On Topic. It is referring to the aparent insanity of the developers. Get a grip of your lives.

this begs the question.... (5, Funny)

onthefenceman (640213) | more than 11 years ago | (#5475824)

where do I plug the RJ-45 cable into my NES?

Nowhere, just yet (3, Insightful)

yerricde (125198) | more than 11 years ago | (#5475866)

According to the ports page [dunkels.com]:

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.

Re:this begs the question.... (1, Insightful)

Anonymous Coward | more than 11 years ago | (#5475869)

Develop an Ethernet adapter for the NES, and you can. Or develop an RS232 adapter and settle for SLIP/PPP.

bling (-1, Offtopic)

craqboy (588418) | more than 11 years ago | (#5475827)

pretty neat stuff first post?

images?! (1)

domodude (613072) | more than 11 years ago | (#5475838)

how does this handle images?

Re:images?! (2, Informative)

lemmingstar (588359) | more than 11 years ago | (#5475890)

There is a seperate effort to display jpegs on the C64, which is pretty much completely working. They are talking about integrating this into the browser.

Simalarly for GIFs.

If you want to see something similar to what it does atm try:

# lynx http://slashdot.org


# links http://slashdot.org

Provided you have either program installed.

duh (0, Funny)

Anonymous Coward | more than 11 years ago | (#5475834)

Imagine a beowulf cluster of these! ;o

Re:duh (2, Funny)

Anonymous Coward | more than 11 years ago | (#5475868)

I'm going to beowulf cluster all the idiots that say, "Imagine a Beowulf Cluster of these!"

Together we'll have the biggest pile of morons that ever existed!

aaaaaarg (0)

Anonymous Coward | more than 11 years ago | (#5475837)

it's called a _realtime os_ you fscing moron, and it's being done at least 56 times the last century.

Please, start accepting and posting better titles or what!

Re:aaaaaarg (0)

Anonymous Coward | more than 11 years ago | (#5475854)

You go fit a TCP/IP stack, a web browser, a PPP implementation, and a GUI to control them, in 64k on a stock C64, and then you can say it's been done. Until then, kindly STFU.

oh come on, (1, Interesting)

Anonymous Coward | more than 11 years ago | (#5475839)

how well do you expect a C64 to stand up to a slashdotting? There're 5 posts and it's already jammed.
Nice project though. I just wish it was available for the Amstrad CPC, then I could ressurect my old dinosaur.

Re:oh come on, (0)

Anonymous Coward | more than 11 years ago | (#5475959)

Exaactly. This is ridiculous. CmdrTaco! You need to do something!

Can't wait... (1, Funny)

borgdows (599861) | more than 11 years ago | (#5475841)

...for Doom3 on my Commodore 64!

I'm sure Carmack is able to do that!

Re:Can't wait... (0)

Anonymous Coward | more than 11 years ago | (#5475986)

how can you ever mod this post as a flamebait??!?

This fucking 0wns. Period. (1, Insightful)

Anonymous Coward | more than 11 years ago | (#5475844)

This is the closest we've ever been to having a fully native Internet suite for the stock C64. All we need now is a PPP implementation :P

And don't bring up The Wave or any of the other SCPU-only tools - this is straight 1MHz 6510 :P

Oh cool! More Java errors! (1, Funny)

Anonymous Coward | more than 11 years ago | (#5475849)

At last, the effort to bring browser crashes due to poorly written Javascript strings has been brought to the otherwise unafflicted Commodore 64.

Thats something! (2, Interesting)

watzinaneihm (627119) | more than 11 years ago | (#5475850)

That should be something, 'cause I can put a commie emulator on my box and run this code from there and I bet the footprint will still be smaller than Lynx.
Or I coud run an emulator from DOS to get multitasking maybe?

Re:Thats something! (2, Insightful)

Surak (18578) | more than 11 years ago | (#5475887)

Anytime you run emulation of any kind there is a considerable amount of overhead, even in the case of emulating an 8-bit computer on a 32-bit platform.

BTW--links [mff.cuni.cz] has a smaller footprint than lynx and supports graphics under SVGAlib or X.

Re:Thats something! (5, Funny)

Jim the Bad (192095) | more than 11 years ago | (#5475904)

commie emulator

You mean a version of Eliza that says things like "Comrades, we must seize the means of production!" and "Down with Capitalism!"

Sorry, I'll get me coat...

and our kids will say ... (0)

Anonymous Coward | more than 11 years ago | (#5476033)

Cool .. older OS used to fit in 1 small 650 MB RW-CD ... and would run on 32 MB RAM ...

Just curious... (4, Funny)

dolo666 (195584) | more than 11 years ago | (#5475853)

Will this work on the TI 99/4A or will I need a few extra 16k memory expansion cards to get up to snuff?

I still don't understand why any of you use these big computers. We only need 32k to do everything! I'm using one now and although I had to split this message over a cassette tape, it's still better than using those computers that Bill Gates said were too memory rich.

Re:Just curious... (1, Informative)

Anonymous Coward | more than 11 years ago | (#5475994)

Actually you people joke about stuff like that, but I have a 386 Laptop running FreeDOS that does almost everything that I need a computer to do.

C64 is the oldest? What? (4, Informative)

Asprin (545477) | more than 11 years ago | (#5475858)

Check me if I'm wrong on this, but I believe the Atari 400/800 are a couple of years older than the C64, which would make *it* the oldest system to run a web browser. I had one (an 800) with 32 whopping-mo-fo-kilobytes of RAM in, like, 1981.

Yeah, that's right, I was a badass.

Re:C64 is the oldest? What? (4, Insightful)

Asprin (545477) | more than 11 years ago | (#5475889)


Drat, It looks like the Atari version is "under development". C64 still wins (temporarily)!

The oldest one that runs a browser, yes... (1)

erinacht (592019) | more than 11 years ago | (#5475892)

The C64 port is ready now, it says on the site that the "oldest" will be put back to the appropriate year when the other ports are ready

Re:C64 is the oldest? What? (0)

Anonymous Coward | more than 11 years ago | (#5475901)

From the article: "The Contiki web browser is probably the first web browser ever to run on an over 20 years old computer system - the Commodore 64 is from 1982. (This record will be broken when some of the other ports are ready."

Unless there is another web browser available for the Atari 400/800, then the C64 may very well be the oldest for now.


Re:C64 is the oldest? What? (1)

TopShelf (92521) | more than 11 years ago | (#5475952)

Makes me wish I hadn't given away my Atari 400 so many years ago. Started with 8K, and paid $200 to expand to a massive 16K back in 1980 (heck, I had to leave it at the store for 2 weeks!). That was a highly underrated computer, in my humble opinion...

Re:C64 is the oldest? What? (1)

esarjeant (100503) | more than 11 years ago | (#5476000)

I believe both the VIC20 and the PET are older than the C64. While there isn't any networking support on these yet, it does basically work (or so they claim....)

No PPP (0)

Anonymous Coward | more than 11 years ago | (#5475862)

TCP/IP stack for Internet networking, either with RS-232/SLIP or Ethernet (PPP is under development). There's no PPP yet folks, so no dial-up access. On the plus side, there is telnet :)

Use SLIP for now (3, Interesting)

yerricde (125198) | more than 11 years ago | (#5475897)

There's no PPP yet folks

Some dial-up Internet access providers still support SLIP (serial line IP), the protocol that PPP largely replaced.

Bigger is not necessarily better. (5, Insightful)

Mossfoot (310128) | more than 11 years ago | (#5475870)

This gets me to thinking about how much programing is probably "junk" programming these days. Anyone remember the sequal to Elite? Elite 2: Final Frontiers I think it was called. That had thousands of systems, planets, bases, stations, etc... set up in a game that had "realistic" physics. You could actually land on the planets yourself!

It was 1 disk big (1.44 floppy).

Now I look at Freelancer. A big CD full of great graphics. Yet at the same time I see it as not nearly as complex and thought out as Elite 2.

This is an interesting attempt not to make bigger programs, but tighter ones. Making the most of what you have. It feels like there is so much available on computers these days, that programs aren't concerned with getting the most out of it, just using as much of the bells and whistles as they can. Imagine using the same mentality on a modern computer!

Re:Bigger is not necessarily better. (1, Informative)

Anonymous Coward | more than 11 years ago | (#5475908)

Umm, most of that space is used for graphics, the actual code is around a meg or so.

Re:Bigger is not necessarily better. (0)

spot35 (644375) | more than 11 years ago | (#5475920)

I must tend to agree. I believe the majority of the bloat in the programs these days comes from the languages used. Granted the compilers are pretty good at optimising the output from the languages but the techniques utilised to improve maintainability and extensibility lead to larger programs.

I'm sure that the reason is that developers have a lot more memory and processing power to play with these days and as a result don't spend as much time in optimisation.

But then again, a lot of the bloat in programs like Word are for features that only so called 'power users' will use. If these were removed then the size would be greatly reduced. However, you'd get a backlash from the power users asking where their favorite function had gone. Maybe they could release a lite version and a power version (Maybe they do?)

Re:Bigger is not necessarily better. (0)

Anonymous Coward | more than 11 years ago | (#5476108)

Yes, I despise all of the senseless bloat in todays modern software. I even see books on writing Visual Basic applications for PDA's! But with fater internet connections and bigger hard drives and burnable DVD's I really don't see code bloat going away, it will just get bigger. At least there appears to be an underground of people forming who like small stuff... Oh, and QNX rawks!!

Re:Bigger is not necessarily better. (5, Interesting)

Hanno (11981) | more than 11 years ago | (#5475936)


I recently tried an emulator and had a look at some of the games that I spent hours and days on as a teen. Games such as Mercenary [zzap64.co.uk].

And frankly, most of those games that I had the fondest memory of, from today's perspective, plain and simply suck.

Re:Bigger is not necessarily better. (0)

Anonymous Coward | more than 11 years ago | (#5475954)

You played sucky games then.

Re:Bigger is not necessarily better. (1)

sql*kitten (1359) | more than 11 years ago | (#5475942)

This is an interesting attempt not to make bigger programs, but tighter ones. Making the most of what you have. It feels like there is so much available on computers these days, that programs aren't concerned with getting the most out of it, just using as much of the bells and whistles as they can. Imagine using the same mentality on a modern computer!

I think JWZ said it best [jwz.org]. Scroll down to the "Random Commentary" section.

Re:Bigger is not necessarily better. (1)

Gadzinka (256729) | more than 11 years ago | (#5475958)

This is an interesting attempt not to make bigger programs, but tighter ones. [...] Imagine using the same mentality on a modern computer!

Actually this mentality is used on modern computers. To be precise, on game consoles. It's too easy for the PC game to require user to upgrade his memory or video card. For game consoles this is not possible. So the console games with time run faster, smoother on the same hardware.


Re:Bigger is not necessarily better. (1)

jez9999 (618189) | more than 11 years ago | (#5476075)

Or, they won't. Ever played Goldeneye on the N64, with no memory expansion in? Most overhyped piece of shite i've ever seen.

Re:Bigger is not necessarily better. (1)

Quarters (18322) | more than 11 years ago | (#5475962)

Comparing the size of the Elite 2 (1 floppy) and the size of Freelancer (3 CDs) and coming to the conclusion that the size increase is due entirely to code-bloat is ridiculous. It's the graphics. Players want super realism at high resolutions with tons of voice work, character animation, lip syncing, special effects, etc... now. I'm sure that if you did a size breakdown of Freelancer you'd see that the majority of the space it is taking up on the HD is devoted to graphics and sound assets.

Re:Bigger is not necessarily better. (1)

John Courtland (585609) | more than 11 years ago | (#5475966)

I would have to say that probably about 95% of the data on that CD was not executable code. It's hard to compress graphics in a way that doesn't totally suck up performance and keep high quality. Now don't get me wrong, when I code, I consult Michael Abrash's "Zen of Optimization" quite often to get the most out of my cycles. But graphics are just big, that's all there is to it. I guess you could have the program generate most on the spot, but you would still need RAM to hold it, and cycles to generate it. Vector-based graphics are basically like that.

Windows, Office, et. al are better examples. They really don't need hi resolution graphics, or animation. So why does Win XP take 1.6 GB? Who knows. But I would bet you can blame quite a bit of it on poor coding practice.

Re:Bigger is not necessarily better. (0)

Anonymous Coward | more than 11 years ago | (#5476025)

But not all of those 95% are graphics.

Elite 2 contained detailed data (surface temparature, size, distance from the start, etc..) about thousands of planets. In order to accomplish this all that data was randomly generated when the game was launched with the fixed random seed.

Re:Bigger is not necessarily better. (0)

Anonymous Coward | more than 11 years ago | (#5475977)

Elite 2 was rubbish. Utterly boring. I'm glad games are bigger if they're better than that.

Re:Bigger is not necessarily better. (1)

Stephen Williams (23750) | more than 11 years ago | (#5475984)

Elite 2: Final Frontiers I think it was called.

Frontier: Elite 2. I lost weeks of my life to that game when I was in school.

It was 1 disk big (1.44 floppy).

I had the Amiga version, which fitted on a single double-density floppy (~837KiB, due to the Amiga's formatting scheme). IIRC, there were two disks in the box, but the game only took one of them; the other contained a load of sample saved games.

The Frontier binary was only a few hundred kilobytes in size. Loaded in one load; no multiloading, no overlays.


Re:Bigger is not necessarily better. (0)

Anonymous Coward | more than 11 years ago | (#5475999)

First off, as the previous AC said, most of the space in Freelancer/modern 3d games is graphics (textures to be precise).
Elite 2 solved this by using procedurally generated planets and textures (could you imagine the amount of storage required for the thousands of planets available otherwise? ugh!). The most impressive feat IMO is the programming behind it - the game was written in 100% pure 68000 assembly! It was probably a necessity to get it working - I mean, it even ran on the Amiga, with full texture mapping, 3d spline-based graphics (first game to use them, IIRC), the works - and the most realistic physics ever in a space sim (there still isn't a game that is even close to matching Elite 2 for realism!).

Re:Bigger is not necessarily better. (1)

SacredNaCl (545593) | more than 11 years ago | (#5476090)

Back then I was really jealous of my friends Amiga. He could view porn in full color, and even brief porn movies. All I had was monochrome ascii art porn and "beep" sound.

Amiga was a pretty impressive system for the time period.

Re:Bigger is not necessarily better. (1)

Enfors (519147) | more than 11 years ago | (#5476106)

The most impressive feat IMO is the programming behind it - the game was written in 100% pure 68000 assembly!

... as was most Amiga games. You make it sound like that's something unusual.

Re:Bigger is not necessarily better. (1)

Apreche (239272) | more than 11 years ago | (#5476093)

If you notice in many compilers have an option to optimize for size or speed. Optimizing for size results in a smaller executable while speed results in more fps.

I'm sure you can see that nearly every program today is optimized for speed. Since hard drives in pcs are so big, people wont be pissed off because something takes up 1 gig of space, they'll be pissed because its taking too much time to do stuff. And programmers, like me, who want to be able to creat things easier are using tools like Visual Studio and Object Oriented langauges that result in programs that work fine, but have very large footprints.

Yeah, it's really neat that when we had shit hardware we were able to write such sweet machine code that we could make it do really cool stuff. Stuff like Descent, and Descent 2, which ran under DOS. The same platform and the same 486 DX4 that ran the 2D dos games like raptor:call of the shadows, which was also pretty awesome.

If you have the time and effort you can make pretty much any hardware do incredibly cool stuff. There will almost always be a way to use less memory and get more out of it. But, it's easier to go buy a 100$ hard drive, stick it in, and install your giant game. I remember in Descent 2 when you chose how much HD space you wanted to give to the game, during install. The last option was labeled something like CRAZY!!! - 200MB!!! Yeah, crazy then, when my disk was 720MB. Now? I've got more mp3s than that. More than 10 times as many.
Stuff like this is cool but not practical in a real world money making situation. It took long enough for them to get MOO3 out there, you don't want them spending an extra 5 years so they can squish it small enough to run on the Atari 800XL.

Re:Bigger is not necessarily better. (1)

Ed Avis (5917) | more than 11 years ago | (#5476095)

Feh. The original Elite fitted on a 100 kilobyte floppy. Apart from the cassette version (with fewer ships) which ran in 32 kilobytes, including 10K or so for video memory.

Slashdotted already? (0)

Anonymous Coward | more than 11 years ago | (#5475875)

Their web server must have been running on a C64 or something

VIC 20! (3, Funny)

fozzy(pro) (267441) | more than 11 years ago | (#5475880)

I don't know why i would need to multi-task on a VIC 20 but i'm going to pull her out and see if can get her going. I have a slew of tapes/tape drive or the old beauty. If i can get my EE and CE roomates and buddies to rig up an interface to ethernet then we have a low power webserver pretty soon. It's not hi traffic, but it's not like I get hits like Slashdot.

Writing support for a HD or faster storage then tape would be the best, but no time right now. Getting a basic webserver over a serial modem should be fairly trivial. Porting a Java shouldn't be and i've always wanted to get JAVA to run on C64, VIC 20, or TRS....Not the embeded version.

Re:VIC 20! (2, Interesting)

turgid (580780) | more than 11 years ago | (#5475928)

I had a ZX81 with a 16k RAM pack and a "proper" keyboard. I also had a multi-tasking FORTH ROM (8k) which was mounted on a daughter board with the BASIC ROM so you could switch between them (with a power off). The FORTH was a native Z80 compiler (not interpreter) and it had user-definable "screens", sort of primitive windows, that programs could output to and update independently. It had a screen editor. It was made by a company called Skywave Software, based in Bournemouthm England IIRC. The multi-tasking was real-time, down to a resolution of 0.02 seconds (the timer ticked at 50Hz). Jobs could be scheduled to start at any time etc. It was such cool fun.

Re:VIC 20! (1)

nikitin2k (525326) | more than 11 years ago | (#5476109)

"If i can get my EE and CE roomates and buddies to rig up an interface to ethernet then we have a low power webserver pretty soon. It's not hi traffic, but it's not like I get hits like Slashdot."

Oh, if you get a webserver running on a VIC 20 you can count on it getting slashdotted!

C64 (1)

H3g3m0n (642800) | more than 11 years ago | (#5475881)

All the prwdy images are /.ed =( I think i still have a C64 somwhere around here, maby i'll pull it out. I don't have any of the special cables for networking though. There are other OSes for C64 including multitasking unix based ones.

Cool, but.. (2, Insightful)

erlando (88533) | more than 11 years ago | (#5475884)

Seriously, why..? The C64 was a cool piece of machinery in its day but honestly... Who other than sentimental geeks would WANT to browse the web on a C64? Or run anything else than Iridium or Krakout or any of the other cool games..?

I'm not putting the C64 down. I've owned one myself and I've been pretty impressed by some of the things that have been done on it (including Contiki). But I can't help thinking that such talent that it takes to do this could be put to better use.

Maybe it's just me. Come to think of it it probably is..

Re:Cool, but.. (0)

Anonymous Coward | more than 11 years ago | (#5475909)

Think about it. Buy a C64 used for like $5-$10, get a 1541 for about the same, buy an X1541 cable for very little, buy an RS232 interface, download this for free, slap it on a disk, and you have a quite low cost Internet-capable machine. Sure, it might not be as pretty as Winblows, but a few years back, if you said 'I bet a stock C64 could connect to the Internet by itself', you'd be laughed at.

It's all about pushing the classic hardware to its limits. It's the same basic concept that pushes demo coders to do more and more things, like increasing the color resolution, and even increasing the apparent pixel resolution (check out the interlace-scrollers in Krestage and Krestage 2 by Crest).

Re:Cool, but.. (5, Insightful)

djupdal (629381) | more than 11 years ago | (#5475923)

Because it is fun.

Programming on old 8-bit systems is very different from programming for windows/unix. You must know the hardware better and do optimisations you would not even think about on a modern computer.

Some people find that challanging and fun. Not everything needs to be useful.

Re:Cool, but.. (0)

Anonymous Coward | more than 11 years ago | (#5476037)

Some people find that challanging and fun. Not everything needs to be useful.

You're clearly not getting with the program here. Did you miss the memo about it ? Do you care about
producing vital assets at all ? Ever heard of GNP ?

You must be a terrorist or you're supporting the terrorist with your laid-back inactivity. Get with the program citizen!

Re:Cool, but.. (4, Funny)

selderrr (523988) | more than 11 years ago | (#5476049)

Not everything needs to be useful.

That's ridiculous. Hobbies must be useful. That's why we all collect stamps & hotelsoap.

Re:Cool, but.. (0)

Anonymous Coward | more than 11 years ago | (#5475931)

By asking, you've proved you'll never be a hacker.

Re:Cool, but.. (0)

Anonymous Coward | more than 11 years ago | (#5476124)

By admitting that you think this is cool, you've proved you'll never lose your virginity.

Re:Cool, but.. (2, Insightful)

kennylives (27274) | more than 11 years ago | (#5476004)

Fun programming exercise?
Interesting engineering challenge?
A way to show off mad skillz?
A way to develop those skills?
To make statement regarding bloat in modern systems?
It's art?
Because it's there?

... or maybe you'd care to define "better use"?

You're right though, I wouldn't want to run a web browser on there to do anything 'real', but this is the sort of thing that'll get me to haul the old SX64 out of the closet once more (yes, I am one of those "sentimental geeks"). Not because it's some kind of newfound productivity. And not because I neeed another webserver.

Simply because it's fun.

Re:Cool, but.. (1)

gmuslera (3436) | more than 11 years ago | (#5476018)

The best part of C64 is 64kb. You there have in such huge space a multitasking kernel, a GUI, a tcp/ip stack and a web browser. Imagine if linux kernel + XF86 + Mozilla run under not 64k, but 640k, or even 6.4Mb.

When the hardware resources were expensive even if available, programming was something more optimal that it is now.

Also things like that with such hardware requeriments could be good for embedded market

Re:Cool, but.. (0)

Anonymous Coward | more than 11 years ago | (#5476065)

Seriously, why..? The C64 was a cool piece of machinery in its day but honestly...

Amen! I'm not sure why people are still stuck with these relics from the past. I'm sure Open Source would be a lot better of if those developers would throw away their C64s and start working on KDE.

If you want Open Source to prevail then start contributing! You can't do that with a C64

Re:Cool, but.. (0)

Anonymous Coward | more than 11 years ago | (#5476084)

Seriously, why..?

For fun. For the challenge. As an excercise to improve ones skill. There are many reasons why someone would do something like this. Asking why someone would do something like this shows that you do not have a very good understanding of true geek culture, you may think that you do but your posed question shows otherwise. Do you also question why people get Apache running on a toaster or why they get FreeBSD running on a sewing machine?

Ohh That Poor Commodore (2, Funny)

Myriad (89793) | more than 11 years ago | (#5475893)

A link off the Contiki Screen Shots [dunkels.com] page listed:
The first two screen shots are actually historical - they show a Commodore 64 web browser browsing web pages served by a Commodore 64 web server :-) The Commodore 64 web server is hosted by Ullrich von Bassewitz and can be seen in action at http://c64.cc65.org/.

*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 [blockwars.com]: a realtime multiplayer game similiar to Tetris.

Re:Ohh That Poor Commodore (1)

master0ne (655374) | more than 11 years ago | (#5476044)

well, weve managed to /. the images, im still getting text, images will not load (and i know its not this computer) :-D

At last (5, Funny)

kinnell (607819) | more than 11 years ago | (#5475899)

The Commodore 64 market has been screaming for an up to date operating system and web browser for decades. This should breathe new life into a sector which has been seen by many as obsolete, and may well trigger a renaissance in C64 development and application support.

Re:At last (0)

Anonymous Coward | more than 11 years ago | (#5475969)

"The Commodore 64 market has been screaming for an up to date operating system and web browser for decades"

Maybe a little louder next time?

Pushing the limits (5, Informative)

Pastey (577467) | more than 11 years ago | (#5475906)

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 [dunkels.com]! 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?

Server is slow... FAQ and tech (4, Informative)

Anonymous Coward | more than 11 years ago | (#5475907)

What is Contiki and what is it good for?
Contiki is an Internet-enabled operating system and desktop environment for a number of smallish systems such as the 8-bit Commodore 64. In short, Contiki is the software needed to access the Internet and browse the web. What makes Contiki special is that it makes it possible to do this even from really constrained systems, which previously have been belived to be too small to be able to run this kind of software.

Is this about retro or nostalgia?
No. This is not about playing old games to revive childhood memories. It is about pushing the limits and doing things previously thought impossible.

What do I need to run Contiki?
A standard system to which Contiki is ported. In general, there are no expansion boards, CPU accelerators or extra memory cards required, not even a disk drive. An RS-232 (serial) card or Ethernet connection is required for Internet connectivity, however.

The typical system requirements for the Contiki system is about 20 kilobytes of RAM for the base functionality and about 50 kilobytes for full functionality (desktop icons, web browser, web server, etc.)

Do I need to upgrade my system to run Contiki?
No. Contiki is designed to work with unexpanded systems, so there is no need for megabytes of RAM or main board upgrades.

Does Contiki require megabytes of memory, or 16-bit CPU accellerator upgrades?
No, in general, Contiki does not require any upgrades, accelerators or expansion kits.

Does Contiki need assistance of a powerful server to reach the Internet?
No. Contiki does not require assistance of a powerful PC or *nix server to use the Internet. Everything (TCP/IP, HTTP, HTML, etc.) is done by Contiki on the 8-bit system.

Is the Contiki web browser really the first browser for 8-bit systems?
Yes. While there are other programs such as the HyperLink hyper-text document viewer that allow an 8-bit system to browse the web, these programs require a powerful *nix server to translate the Internet content to a simpler format that the 8-bit system understands.Contiki does not require assistance of a powerful server, but is fully self-contained.

There are also web browsers that claim to run on 8-bit system, but in reality require radically more powerful 16-bit CPUs and megabytes of memory. The Wave is such a browser.

Is it possible to use Contiki with a modem and a dial-up Internet account? Does Contiki support PPP?
Lawrence Chitty is currently working on PPP support for Contiki.

Is it possible to use Contiki with a broadband or DSL connection?
Yes, if you have an Ethernet card for your system, it is possible to use Contiki with a broadband or DSL connection.

Does Contiki support pre-emptive multitasking?
No, Contiki does cooperative multitasking. The reason for not supporting pre-emptive multitasking is that it would unnecessarily increase the complexity not only of the operating system, but also of the applications that would run under it. Pre-emptive multitasking is primarily useful in general purpose multiuser operating systems such as *nix, or in real-time systems where response time is critial. Contiki does not fit in either of those categories.

Where does the name "Contiki" come from?
The name "Contiki" is taken from Thor Heyerdahl's famous Kon-Tiki raft. Kon-Tiki was built using prehistoric techniques in order to prove that ancient Polynesians actually were able to sail from South America to the Polynesian islands. Similarly, Contiki runs on prehistoric computers, yet it is able to do much of a modern PC usually does.

Are there any other uses for Contiki?
The small size of Contiki could make it useful in small networked systems which are required to be very inexpensive. Such a system could be comprised of a low-cost, low-power, 8-bit microcontroller like an AVR, an Ethernet chip such as the CS8900a, an LCD display and three touch buttons - perhaps something similar to the Mosaic Industries EtherSmart Controller. Contiki would make it possible to surf the web from a device with only a small low-cost 8-bit microcontroller, without needing to use an expensive 32-bit CPU.

Contiki would not make a good environment for an end-user device such as a handheld PDA or a mobile GSM phone, however, as it don't have the kind of features expected from a web browsing environment of today. There is no Java, no Flash, and it even lacks support for images. Most modern handhelds, PDAs and mobile phones have quite a lot of computing power; many of them are even able to run a graphical version of Linux. For systems of that size, there are better environments than Contiki available.

At the heart of the Contiki desktop environment is the event driven Contiki kernel. Using non-preemptive multitasking, the Contiki event kernel makes it possible to run several programs in parallel. It also provides message passing mechanisms and timers to the running programs.

In the Contiki event kernel, a process is defined by three entities: the initialization function, the event handler and the idle loop. The idle loop is optional and is called repeatedly whenever the system has nothing else to do (i.e., when no events occur and no timers are scheduled). The event handler is called when an event occurs. The initialization function is used to initialize the program and to register to which events the process is listening. A process the does not have an idle loop must listen to at least one event, or else the process will never be scheduled and will therefore not ever run again.

Events can be emitted by all processes and can be directed either towards a particular process, or towards all processes. If the processes are listening for the event, the event handler function will be invoked for each process. An emitted event is accompanied with a pointer that can be used for message passing between processes.

Timers are implemented using events; each event can be scheduled to occur at a given time in the future. The Contiki event kernel will emit the event when the timer goes off. Because the Contiki event kernel never preempts a running process, there are no guarantees about the time-out times.

The figure the left is an illustration of how the Contiki event kernel works. There are four processes in the system and when the system starts, each process' initialization function (here called init()) is called. After the initialization in done, no events are scheduled, so the idle functions of the processes are being run. Only process 2 implements an idle function, and it will be called repeatedly until event 1 is emitted. Processes 1 and 3 have registered a listener for event 1, and each process' event handler function is invoked in response to the event being emitted. Both event handler functions run to completion, after which no events are scheduled so the idle loop is run until event 2 is emitted some time later. Process 4 has registered a listener for this event, so its event handler function is invoked.

As a more concrete example of how the Contiki event kernel works, consider the Contiki desktop environment. Here, there are several processes running: the GUI and windowing system (i.e., the CTK toolkit), the TCP/IP stack, and all of the programs such as the web browser and e-mail client. Both CTK and the TCP/IP stack implements idle functions, whereas the other processes only implements event handlers. The CTK idle function checks for keypresses and TCP/IP stack's idle function polls the network device driver for incoming packets.

The Contiki Tool-Kit (CTK) provides graphical user interface primitives such as windows, dialog boxes, buttons and text editing to Contiki and its programs. CTK is designed to be highly modularized which makes it possible to change the appearence of it in a lot of ways and to adapt it to many platforms.

Frontends and themes
CTK is divided into two separate modules; the CTK backend, which handles how the user interacts with the windows, buttons, menus, etc., and the CTK frontend which draws the windows onto the screen and grabs keypresses from the user. It is this division that makes CTK portable.

It is also possible to create different CTK looks, themes, by changing the CTK frontend. Currently, there are three CTK themes:

The textbased "base" theme of CTK. It is designed to be extremely portable; in order to port it to new platforms, it is sufficient to implement as few as three C functions.

A modern looking grayish theme with squared buttons and windows, and a vertical gradient background. Only runs on the Commodore 64 version of Contiki and was the first graphical theme to be implemented.

A blueish theme with rounded buttons and window borders for the Commodore 64.

Similar to most other desktop GUI systems, windows are central to the design of CTK. Windows are the container of all other user interface elements. In CTK, windows can be moved and closed, but they cannot be resized or iconified. The visible windows form a hierarchy where the bottom windows are overlapped by the front windows. The frontmost window receives the user input and is usually drawn in another color than the back windows.

Dialogs are a special kind of windows that do not have a normal window border, and are always on top of the other windows, and focused. Dialogs always appear at the center of the screen and cannot be moved around.

The CTK menus are similar to the Mac OS ones in that there is only one menubar and not one menubar per application. The default configuration is to have the menu bar at the top of the screen (like Mac OS), but since this it up to the actual frontend implementation, it could very well be drawn at the bottom of the screen.

Like most GUI toolkits, CTK uses user interface widgets to manage the user interface. There are six widget types in CTK: separators, labels, buttons, hyperlinks, text entry widgets and icons.


Separators are passive widgets that only serves the single purpose of separating widgets from each other. Separators have a configurable width, but always has a height of one.


The CTK label widget is a passive widget that displays text. Both height and width are settable.


CTK buttons are active widgets that, when pressed, emit a ctk_signal_button_pressed signal to the process that created the button.


CTK hyperlinks are active widgets that emit a ctk_signal_hyperlink_active signal when pressed and a ctk_signal_hyperlink_hover signal when they are selected. The signals are sent to all processes that are listening for the signal. This makes it possible for both the web browser process and the e-mail client process to listen for hyperlinks, and the e-mail process can choose to handle mailto: links, whereas the web browser handles hyperlinks starting with http://. The ctk_signal_hyperlink_hover signal lets the web browser change the status bar message when a hyperlink is selected.

Text entries

The CTK textentry widget is an active widget that is the primary text input method of CTK. The text that the text entry widget edits may be wider than the actual width of the widget, and the widget will scroll the text when the cursor moves off the right of the widget. The text entry widget can be multiple characters high.


The primary use of the CTK icon widget is to have desktop icons. When pressed, the CTK icon widget emits the ctk_signal_button_pressed signal.

The Contiki desktop environment uses version 0.9 of the uIP TCP/IP stack to provide Internet communication. uIP is designed to allow limited systems to enjoy full TCP/IP communication.

uIP provides the following protocols:

ARP (IP address to Ethernet MAC address protocol)
SLIP (Serial Line IP)
IP (fragment reassembly turned off for Contiki)

ICMP echo (ping)
Unicast UDP

In addition to the above protocols, a PPP implementation is currently being developed by Lawrence Chitty.

DNS - Domain Name System
In order to run the web browser, Contiki must implement the DNS protocol. DNS maps host names (like www.google.com) into a numerical IP address (like by using a globally distributed database.

The DNS client in Contiki has a cache of hostname and IP address pairs so that a DNS lookup will not have to be made each time a Contiki program asks for an IP address. The size of the cache is configured at compile time and typically is about 10 entries large.

The DNS client implementation is not very heavily tested andmay fail with certain DNS names.

More information
For more information about the uIP TCP/IP stack, see the uIP homepage at: http://dunkels.com/adam/uip/.

NES Install? (5, Interesting)

jmt9581 (554192) | more than 11 years ago | (#5475910)

How the heck do you get a new operating system onto a gaming console like the NES?

Are the game controller ports used as serial ports?

Do you use a specially made cartridge?

Contiki programs (3, Informative)

Anonymous Coward | more than 11 years ago | (#5475925)

The Contiki screen saver is started when there has been no user input for a configurable amount of time, usually for five minutes. The screen saver is part of the architecture specific files for Contiki and there currently only is a screen saver for the Commodore 64 version.

The Commodore 64 screen saver shows two small pillars of fire at the left and right edges of the screen. The fires are drawn using 8x8 pixel blocks, colored in firery colors (red, yellow and white). The screen shots below gives an idea of how it looks, but the fires of course look better when actually running.

The Contiki web browser is not only the world's first true web browser for 8-bit systems, but also the smallest browser available and sets a new record for the oldest computer ever to browse the world wide web.

The Contiki web browser contains the essentials of what's needed to browse the web. It does DNS lookups, talks HTTP (over TCP/IP) to fetch web pages over the Internet and renders HTML pages with text, hyperlinks and forms. There is currently no support for pictures or JavaScript.

Regular web browsers require several megabytes of RAM and disk space. The Contiki web browser only needs a few kilobytes of RAM and no disk at all. With a code footprint of 9 kilobytes and with a total of only 4 kilobytes of RAM required, it might very well be the world's smallest web browser.

The Contiki web browser is probably the first web browser ever to run on an over 20 years old computer system - the Commodore 64 is from 1982. (This record will be broken when some of the other ports are ready.)

While it has been possible for some time to use an 8-bit platform for web browsing, previous browser-type programs for 8-bit platforms have required assistance of special programs running on much more powerful Unix or PC servers to be able to reach the Internet and display web pages. This is how Cameron Kaiser's C64 HyperLink hyper-text document viewer, the Uzix FudeBrowZer for MSX, and the VIC 20 WAP browser work. Other browsers have claimed to be running on 8-bit platforms, while in reality they require much more powerful 16-bit CPUs and more memory than most 8-bit systems can handle. The Wave is an example of such a browser.

The Contiki web browser does not need any special proxy programs or Unix servers. Instead, it connects directly to the Internet, downloads and displays web pages and provide a user interface, without extra software or special power-servers. It is therefore the world's first true web browser for an 8-bit system.

User agent string
If you see something like the following in your web server logs, you know you've had a visitation from the Contiki web browser:

User-Agent: Contiki/1.0 (Commodore 64; http://dunkels.com/adam/contiki/)
Ideas for the future
In the current version, the main limiting factor is the memory usage. By optimizing the web browser code and introducing loadable program modules, more memory will be made available for feature enhancements. Some of the possible future features are:

Buffering for faster scrolling. The current version of the Contiki browser does not buffer the downloaded web pages. Instead, it parses the HTML on-the-fly and only stores what's actually shown on the screen. This means that in order to scroll down a page, the page has to be downloaded from the web server again. By buffering a larger part of the web page, scrolling could be made radically faster. Adding support for this will be straightforward as the current architecture already is designed for this extension.

File and full disk downloads. Being able to directly download files from the Internet down to a C64 disk or tape would be a very nice feature to have. Also, the ability to directly download a full D64 image to a C64 disk would be a nice way to get new software and demos for the C64. Since latest version of cc65 now supports file I/O, this feature could probably be quite easily added.

Improved forms support. Currently, only forms with a GET action is supported, and only the input types submit, text and image.

Tabbed browsing. Starting with Mozilla and Galeon, many modern browsers have started using a feature known as tabbed browsing. With tabbed browsing, multiple browser sessions can be kept in parallel and accessed using special buttons at the top of the browser window. Adding tabbed browsing to the Contiki web browser will probably require a more sophisticated memory management on the Contiki web browser's part as well as more RAM, but should otherwise pose no fundamental problems.

Viewing JPEG images. The amazing JPX/Juddpeg C64 JPEG viewer by Adrian Gonzalez and Steve Judd shows that it is possible to render JPEG images on a C64. Their code could perhaps be incorporated into the Contiki browser which would facilitate viewing inline JPEG images in the web pages. The main problems with JPEG decoding is that it probably requires a lot of CPU cycles, and might use too much memory to be possible to incorporate in the Contiki browser.

Viewing GIF images. There are several GIF viewers available for the Commodore 64, and it might similarly be possible to integrate one of these into the Contiki browser. GIF image decoding should be less CPU intensive than JPEG decoding, and uses less memory since it does not require as much memory for tables as JPEG decoding.

SID player plugin. Downloading SID tunes to listen to while browsing should be possible. By reserving the memory between $1000 and $2000, a lot of SID tunes could be used.

Flash plugin. Olivier Debon's Flash player is quite small - only about 9k when compiled for the x86 - so it just might be possible to port it to the C64.

Java virtual machine for running Java applets. While this idea is more far fetched than the above ones, it should be noted that Brian Bagnall actually is working on porting/implementing a Java virtual machine for the C64.

The Contiki personal web server provides a convenient way to transfer files from Contiki to any other computer over the Internet. The web server currently only works with the Ethernet-equipped Commodore 64.

The web server works by sending a full C64 disk image as a D64 disk image over the Internet. The D64 disk image can be downloaded using a regular web browser. Future versions of the web server will make it possible to download selected files and read the directory over the Internet.

The Contiki telnet client is intended to make it possible to do text-based remote logins to Unix servers from Contiki. It is currently under development and when finished, the Contiki telnet client will implement a VT100 compatible terminal which will allow screen based programs such as vi and emacs to be run from Contiki.

Currently, the Contiki telnet client only is good for doing other stuff than actually running telnet. It can be used as a poor man's e-mail program, for instance.

Or it can be used to read and post Usenet news.

HTTP and HTML purists can even use it as a very simple web browser.

Apart from the two applications that come with Contiki 1.0 (the web browser, the web server and the telnet client), there are a few applications under development:

An e-mail program.

An IRC client.
More applications are expected to be developed.

The Contiki e-mail program will eventually support reading and sending e-mail from Contiki. It currently is possible to send mails, but getting incoming e-mails have not yet been implemented.

The Contiki e-mail program first will need to be configured with identifying information and the names of the e-mail servers that will be used for sending and receiving e-mail.

Once configured, one can start typing in short e-mails.

Of course, we don't want to accidentally erase the message we spent so much time typing in. As can be seen from the screen shot, the program isnt bug free yet (where is that "No" button?).

And off we go! The e-mail is converted from the Commodore PETSCII encoding into regular ASCII before sending, hence the captialized text in the mail.

Apple ][ (-1, Redundant)

Anonymous Coward | more than 11 years ago | (#5475934)

Now there's a trip down nostalgia lane. The Apple ][ was the last Apple for normal people. Shortly after its demise, Apple became dominated by homosexuals. Now Apple is known as the Gay Computer. Too bad to see a company hijacked by such a shrill minority.

Imagine the biohazard horrors to found in a used Apple Mac! You better be up to date on all your shots before handling one: AIDS, Hepatitis, staphycocus. My God the list goes on and on. Not to mention the residue of bodily fluids encrusted in the keyboard.

Apple? No thanks. I value my mental and physical health.

not to be confused with... (0)

Anonymous Coward | more than 11 years ago | (#5475935)

Kontiki [kontiki.com] - another dot-bomb by Kleiner Perkins

Darn... (4, Funny)

CoolVibe (11466) | more than 11 years ago | (#5475948)

Where was this stuff 10 years ago? I wouldn't have dumped my c64 for that stupid x86 hardware. *sigh*

Seriously, this is very cool stuff. I might dig up my old CBM from the attic to play with this. Now only to be able to hook my oceanic 1541 drive to my PC or my Mac somehow. Or are there ways to simulate a c64 disk drive from a PC with a resoldered C64 disk cable?

How _does_ one transfer software from PC to a real hardware C64 nowadays? Can some people in the know drop some pointers to FAQ's and links?

Re:Darn... (1, Informative)

Anonymous Coward | more than 11 years ago | (#5475972)

Get one of the X1541 cable variants, the XE1541 would probably be best for you. It connects a CBM serial drive to the parport on a PC. Get Star Commander to transfer disks (although I dunno if the Oceanic will support SC's turbo/warp speed, you might be stuck with the bog slow normal speed).

Re:Darn... (0)

Anonymous Coward | more than 11 years ago | (#5475973)

You build a simple 5 wire cable from parallel port to C1541 serial bus, plus driver software for your OS. Search Google and Usenet. Software exists for DOS, Linux, Windows, etc. etc. It is very simple to do.

Re:Darn... (0)

Anonymous Coward | more than 11 years ago | (#5475980)

Linux people generally use [shuttle.de]

Sinclair Spectrum Contiki Developer Wanted! (4, Funny)

erinacht (592019) | more than 11 years ago | (#5475951)

Please some clever person with no value on their time: Make a version for the spectrum, the world needs this! The speccy is a (modified) Z80, so is the NES (as I remember) - it should be possible and possibly quite easy that would be so cool! Web browsing on a rubber keyboard, those fancy CBM machines are almost "real" computers by comparison

Re:Sinclair Spectrum Contiki Developer Wanted! (1)

djupdal (629381) | more than 11 years ago | (#5476069)

Just a little fact; the NES uses a 6502, and so is much more similar to the C64 than the Spectrum is. You are perhaps thinking of the Gameboy which uses a modified Z80.

Contiki Links (4, Informative)

Anonymous Coward | more than 11 years ago | (#5475974)

Contiki Links

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 [cmdrkey.com] 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 [t-online.de] 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 [dreamfabric.com] emulator, written in Java, runs as an applet within a web browser.
  • Per Håkan Sundell's CCS64 [computerbrains.com] emulator works under Windows and DOS.
  • The ec64 [uni-halle.de] emulator is developed for Linux and was originally written entirely in x86 assembler.
  • An article [mooli.org.uk] by Simon N Goodwin about C64 emulators.
  • The Commodore emulators [dmoz.org] category in the Dmoz has more links.
Operating systems and desktop environments

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 [zimmers.net] from 1986 probably is the most well-known graphical operating system for the C64. It is still sold commercially by CMDKEY.com [cmdrkey.com].
  • LUnix NG [sourceforge.net] 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 [csbruce.com] 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 [6502.org] is a multi-tasking operating system with TCP/IP support and a *nix-like command shell.
  • Wheels [ia4u.net] 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 [igs.net] 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 [sweetcherrie.com] is an older version of Wings.
Internet software

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 [sourceforge.net] 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 [6502.org] also contains a TCP/IP stack, but no PPP dialer.
  • My own uIP [dunkels.com] TCP/IP stack has been used for some time to run a web server on a Commodore 64 [cc65.org]. uIP currently does not include a PPP dialer.
  • Novaterm 10 [ros.com.au] contains a PPP dialer and enough TCP/IP code to be able to run telnet over the Internet.
Application programs


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

  • The Wave [ia4u.net] 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 [videocam.net.au] 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.
Commodore 64/128

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 [picogui.org] 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 [microwindows.org] is a graphical user interface system designed to run without support from an underlying system. On 16-bit systems Microwindows is about 64k large.
Small web browsers

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 [iniche.com] 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 [aumobilesuite.com] 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 [dspos.com] 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 [smxinfo.com] 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 [2net.co.uk] 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 [aleph.com.br] 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 [arachne.cz] runs under MS-DOS or Linux and requires at least 1 megabyte of memory. Does not include a TCP/IP/PPP stack.
  • Lynx [browser.org] is probably the most well-known text-based web browser around. It is ported to many different operating systems and architectures including MS-DOS [fdisk.com].
  • The Off by One Web Browser [offbyone.com] 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 [12move.de] 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 [geocities.com] browser supports 640x480x16 VGA.
  • The Atari Phoenix Web Browser [tripod.com] is a non-existant vapor-ware web browser project intended for the 8-bit Ataris.

This was released WAY back (4, Funny)

siliconeyes (154170) | more than 11 years ago | (#5475985)

You guys are so behind times man! Katz's buddy Junis from Afghanistan was beta testing this a year back!

Wow!(obligatory joke) (0, Redundant)

YeeHaW_Jelte (451855) | more than 11 years ago | (#5476001)

Can't wait to see what a beowulf cluster of these will do!

Re:Wow!(obligatory joke) (0)

Anonymous Coward | more than 11 years ago | (#5476011)

PLAYED OUT. Bigtime.

I am the developer of this OS ! (0)

Anonymous Coward | more than 11 years ago | (#5476005)

What should I do with my life?

Distro media (1)

per unit analyzer (240753) | more than 11 years ago | (#5476014)

Are they going to distribute Contiki on cassette tape? (Unfortunately my subscription to Cursor magazine lapsed years ago.)

I'm dying to dig my old Commodore PET out of the basement to get Contiki up and running, though I haven't the foggiest idea how I'm going to to get usable code off of the net and onto a CBM disk. Anyone know where the latest verion of gcc for the PET is located? :-)


Better than Chinese landfills (& C64 Apple ][ (1)

Thorrablot (590170) | more than 11 years ago | (#5476053)

This is really clever - Kudos to Adam and his crew for breathing new life into old technology!

Not only will this allow a new lease on life to old equipment (which otherwise would likely be leaching arsenic into a third world water table somewhere), it's also an opportunity for low-income folks to get onto the net.

My college days were spent writing educational software for these 8-bit, 6502-based systems (typing tutors, etc.) These were great machines to "cut your teeth" on - ROM-based BASIC interpreters, software bootstrapped OS, 320x200 graphics in "8" colors - including black and white (Okay - C64 had more than Apple ][, I admit...) Ahh... 10 HGR2 : HCOLOR 3 : HPLOT 20,20 TO 300, 200...

These ~1Mhz systems are going to have their work cut out for them trying to multitask, but I presume that their TCP/IP traffic is going to be limited to the comm technology of their day (1200/2400 baud)

Also - I think the Apple ][ has the drop on C64 in age - Commodore had the PET our before the 64, methinks... [apple2history.org]

I'm waiting for the BBC Micro version (1)

mustrum_ridcully (311862) | more than 11 years ago | (#5476056)

Ooh, wonder if they'll do a version for the BBC Micro (http://www.nvg.ntnu.no/bbc/) and I wonder if I could knock up an RJ45 to Econet socket adpator ;-)

No reason why this isn't possible, port lynx to the beeb, get the tcp/ip stack sorted, port ppp and finally see what modem I can get running off the RS423 port. Then cram it onto a 40-track 320kb floppy.
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account