The Contiki Desktop OS for C64, NES, 8-bit Atari, 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."
this begs the question.... (Score:5, Funny)
Nowhere, just yet (Score:3, Insightful)
According to the ports page [dunkels.com]:
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.... (Score:5, Funny)
Thats something! (Score:3, Interesting)
Or I coud run an emulator from DOS to get multitasking maybe?
Re:Thats something! (Score:3, Insightful)
BTW--links [mff.cuni.cz] has a smaller footprint than lynx and supports graphics under SVGAlib or X.
Re:Thats something! (Score:5, Funny)
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...
Just curious... (Score:5, Funny)
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... (Score:3, Funny)
Liar. We all know that porn quality on an old B&W screen like that would be horrendus!
C64 is the oldest? What? (Score:5, Informative)
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? (Score:5, Insightful)
OOPS! RTFA!
Drat, It looks like the Atari version is "under development". C64 still wins (temporarily)!
Re:C64 is the oldest? What? (Score:2)
Kim-1 would be older still.. (Score:2)
Re:C64 is the oldest? What? (Score:4, Informative)
> on a 1970's vintage VAX
Sure - Netscape, and before that, NCSA Mosaic, ran just fine on VAX/VMS systems with an Xwindows UI. The first VAX systems are from 1978 (VAX-11/780), and there are still quite a few of these in active use today.
Bigger is not necessarily better. (Score:5, Insightful)
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. (Score:5, Interesting)
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. (Score:4, Interesting)
Take the aforementioned example: Elite 2. Have you played it recently? The gameplay is STILL rock solid after all this time. The graphics engine is dated, sure, but what other game gives you such an open-ended experience? You could do almost ANYTHING you wanted! The universe was open to you.
Actually, I'd submit that that is one of the main reasons that games like Grand Theft Auto do so well - the fact that they are so open-ended and leave the decisions up to the player. Scripting is great if it's well done, but how many of us have wished we could have done something different and see the game adapt?
Overall, it's very sad how many games today are released hoping that eye-candy alone with crap gameplay will sell copies. *cough*Unreal2*cough*
Brink back some of these ideas from classic gaming! Older games were often head-and-shoulders above modern titles in originality and gameplay because they HAD to be. The platforms at the time were primitive and couldn't rely on eye-candy as a selling point.
I remember a recent posting here on
Re:Bigger is not necessarily better. (Score:3, Interesting)
If memory serves, the actual spaceship combat (a big draw for the original) wasn't that much fun...it was too realistic for a game, hyper fast speeds, long distance zapping with beams.
But yeah, it was a hell of a universe to be able to fit onto a 1.4 floppy!
The beauty of older video games (Score:3, Insightful)
These days, with games being created by tens or hundreds of people, what you get is the median quality of everyone's artistry, and it's a lot harder to produce a unique or artful product.
How beautiful to go back and play Crystal Castles coin-op, or Adventure on the Atari 2600, and really hear one person's unique voice.
Re:Bigger is not necessarily better. (Score:2)
I think JWZ said it best [jwz.org]. Scroll down to the "Random Commentary" section.
Re:Bigger is not necessarily better. (Score:2)
Re:Bigger is not necessarily better. (Score:2)
When I was still in college I had a typical sort of assignment. Could use any language you wanted. Basically was just a simple sort/db.
I wrote all of the sorting routines in inline assembly. The bulk was in C.
It was small, efficient, fairly portable (so long as you stuck to x86 chips) and faster than anything anyone else had in the class.
I got a C, because "No one uses assembly anymore, it's not efficient." The rules of efficiency have been rewritten, it seems to be drifting towards not how good your program is, but how fast you can crank it out.
Re:Bigger is not necessarily better. (Score:2)
How does being limited to a single CPU family equate to any sensible meaning of 'portable'?
Re:Bigger is not necessarily better. (Score:2)
I admire some one who can code anything pratical in assm. That may mean I have to admire a lot of people here on
Re:Bigger is not necessarily better. (Score:2)
Yes, I have. Worshipping the tin god and all.
Already would've been, everyone else used non-ANSI C syntax.
I'm aware. I was anal retentive and young, I used to optimize my code down to the bit and would stay up nights figuring out how to make it as tight as possible. I thought I could write a better quick sort.
The point was, that type of thinking isn't encouraged.
Re:Bigger is not necessarily better. (Score:2)
It was 1 disk big (1.44 floppy).
True, it had thousands of planets and solar systems, full of nothing. All you need to do to generate millions of systems is a plasma fractal algorithm and a random seed. Elite 2 sucked immensely, and frankly Elite 1 wasn't so interesting as it sounds. You spent ages accellerating to get to your destination, then spent an equal amount of time decellerating. Fighting pirates feels like you're moving a fixed turret, because you're screwed if you actually maneuver to fight them, because you'll lose your orbital approach or just head in too fast to dock.
Gotta agree with the other poster, it's just sepia tinted memory at work -- grab an emulator and you'll find that you just don't have the patience or tolerance for these limited and primitive games any more. I was playing the Bards Tale II on my emulator the other day, but I just couldn't bring myself to haul out the graph paper to make those dungeon maps like I used to.
Re:Bigger is not necessarily better. (Score:2)
glquake.exe - 426KB.
zqwcl.exe - 516KB
zqwcl-gl.exe - 460KB
PAK0.PAK 18MB
PAK1.PAK 33MB.
So the bloat really isn't much in terms of code. Which isn't surprising since there are just so many lines of code you can or need to write - if you use a whole bunch of code very often, you don't duplicate it everywhere - you start calling it something and referring to it by name in the rest of your program. Programming is a bit like data/decision compression.
BTW have you ever played Sundog on the Apple II? Or Autoduel? Or Ali baba?
Re:Bigger is not necessarily better. (Score:2)
Re:Bigger is not necessarily better. (Score:2)
Re:Bigger is not necessarily better. (Score:2)
Re:Bigger is not necessarily better. (Score:2)
Amiga was a pretty impressive system for the time period.
Re:Bigger is not necessarily better. (Score:3, Insightful)
It's not like it's 8088 asm!
When I was a kid I was punching 6502 machine code on my Apple II for fun - the only annoying part was calculating the branches. Even modified DOS a bit - more storage space, faster seek times, different sector headers (not the usual D5AA96 D5AAAD ), some reset protection and so on.
Not all assembly languages are that difficult or ugly.
VIC 20! (Score:4, Funny)
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! (Score:3, Interesting)
Re:VIC 20! (Score:2)
If you can create a Java interpreter for the 6510, James Randi will pay you a million dollars for demonstrating the existence of supernatural phenomena. The Cubs will probably win the world series right afterwards.
Lee
Cool, but.. (Score:3, Insightful)
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.. (Score:5, Insightful)
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.. (Score:5, Funny)
That's ridiculous. Hobbies must be useful. That's why we all collect stamps & hotelsoap.
Re:Cool, but.. (Score:2)
Because someday, someone will find out another way to put them to use. (insert tongue in cheek smiley here)
Re:Cool, but.. (Score:2)
Re:Cool, but.. (Score:2)
This is a bit of wisdom sorely needed these days.
Re:Cool, but.. (Score:3, Insightful)
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.. (Score:2)
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.. (Score:2)
And if Yoda says it's true, it must be true...
Re:Cool, but.. (Score:3, Interesting)
My digital TV system from the cable company gives me quick news and info in NICE BLOCKY TEXT.
The C64 has blocky text too....
I have about 7 64's in the garage. I can take one, rig up RS232 & SLIP through my Linux router, and plug the 64 into the extra AV port of the TV. Now I can get more information IN THE SAME BLOCKY TEXT than I can with digital cable.
Sure, I can do that with my desktop PC, but i'd have to get off my lazy ass to do it. I'd rather just switch channels with the remote and grab the wired up 64 from the end table and start surfing.
Re:Cool, but.. (Score:3)
Ohh That Poor Commodore (Score:3, Funny)
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
*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 (Score:3, Informative)
The last time the c64 web server was noted in Slashdot, it survived a *long* time. I remembered people posting, puzzledly, stuff like "jesus christ, article has been here for hours and that thing is still up?" =)
...and it's up right now! uIP stack rules. Long live 6510!
At last (Score:5, Funny)
Pushing the limits (Score:5, Informative)
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
Server is slow... FAQ and tech (Score:4, Informative)
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.
Processes
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
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
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.
Examples
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:
ctk-conio
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.
ctk-eyecandy
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.
ctk-blueround
A blueish theme with rounded buttons and window borders for the Commodore 64.
Windows
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
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.
Menus
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.
Widgets
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
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.
Labels
The CTK label widget is a passive widget that displays text. Both height and width are settable.
Buttons
CTK buttons are active widgets that, when pressed, emit a ctk_signal_button_pressed signal to the process that created the button.
Hyperlinks
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.
Icons
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
TCP
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 216.239.51.101) 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? (Score:5, Interesting)
Are the game controller ports used as serial ports?
Do you use a specially made cartridge?
Re:NES Install? (Score:5, Informative)
Contiki programs (Score:3, Informative)
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.
Smallest
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.
Oldest
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.)
First
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.
Darn... (Score:5, Funny)
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... (Score:2)
Try software and instructions from FUNET's archive [funet.fi]. I have used a cable to connect the 1541 to PC serial port and there was a DOS program used to transfer data back and forth - unfortunately for me, I have the Less Supported Cable (I wish my father had made an x1541 cable for me instead of a Trans64 cable, that might have also been supported by Linux software...). I believe there also are programs that make PC appear to C64 as a disk drive.
Sinclair Spectrum Contiki Developer Wanted! (Score:4, Funny)
Re:Sinclair Spectrum Contiki Developer Wanted! (Score:2)
Contiki Links (Score:4, Informative)
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.
SuperCPUThe 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.
LinksCommodore 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.
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.
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.
SuperCPU
All of the above mentioned SuperCPU operating systems have TCP/IP support.
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.
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.
This was released WAY back (Score:4, Funny)
Death Match ahoy! (Score:4, Funny)
An amazing project. (Score:5, Insightful)
What else is interesting about this is that it goes to show how foolish and blind nearly the entire computer industry is when it comes to technology advances. People can't upgrade to a 10GHz processor fast enough, when all they need to do is check their email. Companies are constantly wasting servers and replacing them with newer models. This is not necessary. Today's software is written so poorly that super high-end hardware is needed to make up for lazy/poor programmers. Look at what these ancient systems can do. That "old" PIII or PII or K6 sitting on your desk is a power house. What's the problem? The software you're running on it is likely to be wasting 75% of the CPU cycles it eats.
It's a shame there aren't more developers or at least software architects out there with this guy's talent. We'd all be saving a hell of a lot of money I think. Then again, hardware prices would increase in proportion to its long-term value. Then again, there's a lot of savings in many ways (largely environmental -- less junk being dumped into the wild at the beginning and end of a computer's life cycle). Of course, I wonder if most of the blame goes to businesses just trying to get software out the door as soon as possible without stopping to think about good design (in all senses).
Re:An amazing project. (Score:5, Interesting)
the problem today compared to back when all code had to be small, tight and efficient is that there is a much greater demand for programming. the actual number of good, top flight coders is always going to be small as it was back then but these days you have a lot more code that needs to be churned out so a lot of it gets done by journeymen programmers (and i include myself in that)
Re:An amazing project. (Score:2)
No. The market has determined that programmer brains are far more valuable than cpu cycles. It's cheaper to upgrade a cpu than it is to upgrade a brain.
In all reality, it's probably just that he spent a lot of time on it. Programmer time is expensive to businesses. I'm sure if people were willing to spend more money on software, they could save a little money on hardware.
Good engineering practices don't equate to small code. For example, reuse of existing libraries may increase overall code size compared with something written from scratch, but is usually a better engineering choice, as the libraries can be tested individually, and mature long before use in any particular application.
Yes, I'm talking mainly about desktop computers, which usually requires different constraints for the applications than embedded devices. Don't mix the two up, the skills demonstrated here could apply very well to embedded programming, but they are less useful in a desktop environment.
Re:An amazing project. (Score:5, Interesting)
How true. A couple of years ago I was given some code to review, written by an 'experienced' (i.e. paid more than me) programmer. I tryed to run it on a ppro 200, which was just painful. After about an hour of hacking it I'd got the CPU utilisation down to <60%. By the end of the day I had got it down to <20%. After that I came to the conclusion that coders should not be allowed fast machines for testing. You may need a powerful workstation for compiling (although with incremental compiling and good code this is debatable) but testing on a fast machine really does encourage bad code.
It was quite entertaining watching this guy's reaction when he read my changes to his code. 'How does that work? ... That wouldn't work! ... Oh. ... Hmmm ... Wow.' Almost as good as the expression on my project manager's face when I pointed out that they'd missed out the standard IP clause from my contract, an observation that was quickly followed by an offer of sponsorship.
Re:An amazing project. (Score:3, Insightful)
Uh, no, I'd say Opera is a much better demonstration of that fact... Mozilla and IE are how big?!!!
It's not secret that modern programmers waste huge ammounts of performance. Just look at KDE. However, that doesn't mean you have to use what is commonly being churned out.
I am an OpenBSD user myself, the OS performs amazingly, and is very very small. I could fit the OS and all the programs I use in 512MB... (OpenBSD, OpenBox WM, GIMP, MPlayer, Web Browser). The only place things get hairy is with the web browser. Opera is nice, but I despise it's horrible UI, and no fast browsers have even the basice features I need, so I typically use Mozilla or Konqueror, which would be a bit slow on a 100MHz PC. If the Dillo developers just add a few more features, and improve stability, we'd have a good web browser too. Then again, Konq-embedded works fairly well if you are willing to give up on those minor features, like printing, multiple windows, folders to organize bookmarks, etc.
Since the OS, and the programs I use are very quick, I would be happy with a 100MHz machine with a 512MB hard drive. With soft updates, I could do just fine with an old 4500RPM hard drive a well.
--
Now, ignorng the unfortunate browser situation (since it will likely improve), there is just one problem... Multimedia. No matter how great you are at programming, you can only get so much performance out of a 100MHz CPU. Playback has some reasonably modest requirements (I can play downscaled, downsampled DivX video on my 106MHz handheld), but encoding is the big problem. Even if every program you use is incredibly fast, you still need to get a fast damn processor to encode multimedia at reasonable speeds, and large storage to save it.
So, although everything else would be fine on a 100MHz system, I still have to have a 750MHz Athlon (which oddly enough runs mencoder as fast as my 1.2GHz P3 Celeron in my notebook) to encode video. For other people, video games are their poison, and since they need such a fast system to run their games, they don't care that Windows XP is eating up such a huge ammount of their CPU, RAM, and HDD.
My point is just that so many people just don't care about the requirements, that it is more cost effective to make an ineffecient program. Unfortunately, many people who don't play games, or encode multimedia, want to use these ineffecient programs, and so they have no choice but to jump on the upgrade bandwagon as well. At least, that's the current state of affairs.
Truly artistic (Score:2, Insightful)
Re:Truly artistic (Score:3, Funny)
Windows and the VIC (Score:3, Funny)
Also, I don't see how this would work on my VIC-20. I still remember when it's powered up it says "3583 bytes free". Not quite enough free space! I have an 8K expansion cart, but that still doesn't bring me up to the required amount of RAM.
Re:Windows and the VIC (Score:2)
It's pretty hard to do proportional fonts on the Commodore 64 due to it's screen layout. Even in bitmapped mode, the screen is still addressed in square 64-pixel blocks.
I suppose you'd need a relatively large abstraction layer to do proportional fonts properly. This would explain the high system requirements for the Wave [cmdrkey.com] browser, which does do proportional fonts and runs under GEOS/Wheels. (requires SuperCPU w/1 MB SuperRAM)
Re:Windows and the VIC (Score:2)
Ethernet over Serial Connection? (Score:2)
(Currently looking at c64 and 1541 drive sitting on my closet shelf.)
Finally I have a use for that XE1541 cable [ntrautanen.fi] I bought two or three years ago.
The name is badly chosen (Score:2, Informative)
Jaw drops... (Score:5, Insightful)
Kernel, GUI, screen saver, TCP/IP stack, web server, telnet client and web browser in 42 KB? Wow... I suppose the TCP/IP stack is based on his uIP code that's around 5 KB large, using 500 bytes of RAM. =) And I like how the GUI is skinnable. =)
Another cool part is of course that I've studied at the same university as him. hehe.. He was rather well-known there as a "decent" programmer. =) You know, those that writes a complex algorithm, compiles it once, and it works.
Can I cluster my Atari's (Score:4, Funny)
credit due (Score:2, Insightful)
Yah but it still won't run... (Score:2)
Written in C? (Score:2)
Re:Written in C? (Score:4, Informative)
Re:Written in C? (Score:4, Informative)
It's not really C that you're referring to, it's the way most compilers use the stack.
Actually, there are C compilers available for PIC microcontrollers (and similar devices) that are even more limited than the 6502: 8 byte hardware stack (not directly accessible from code), Harvard architecture, etc. These work quite nicely, although they can't use the stack for much, instead using and intelligently reusing registers for parameter passing and local variables. All of this requires call-tree analysis, which precludes recursion. But then you'd be insane to write recursive code on a machine with an 8-byte stack.
So Where's the CP/M port? (Score:2)
Not the first C=64 browser (Score:4, Interesting)
http://hem.passagen.se/harlekin/
Look at FairligHTML. (1997!)
Re:Not the first C=64 browser (Score:4, Informative)
Wow! (Score:3, Insightful)
In this day of ever increasing memory and hardware demands for new software, it's nice to see that there are people out there still trying to do new stuff on old hardware.
Old computers never die - They just get TCP/IP stacks written for them!
He would have sued... (Score:3, Interesting)
In his older years, Heyerdahl also developed the rather obnoxious habit of threatening with lawsuits against anybody who might disagree with him. He was a big childhood hero of mine, but he pretty much ruined that with a threat directed at a website I edit.
So, if he had lived, he would certainly have sued these people, and BTW, I should probably stop here, so that I don't risk a lawsuit myself.
you'll need broadband to live with it... (Score:3, Insightful)
so, to scroll a page, it has to reload the page and rerender it.
being on 56k is bad enough. i like to forget what 300 baud was like. *shudder*
Wow! (Score:3, Funny)
Tight code? You wanna know what tight code is? (Score:3, Interesting)
It referred to a few legendary (back then) programming feats, including one about the guys at the Jet Propulsion Lab.
They found they had 1/2/I forget which/ Kb of RAM left on the Pioneer/Voyager/I forget which/ spaceprobe they were writing the software for.
So they wrote an image pattern recognition program that would study the atmosphere in jupiter/saturn/I forget which/ planet.
Ok so I don't remember all the details but it sounded like really, really, REALLY tight code.
---
You want a
C64 is NOT oldest system ever to run a web browser (Score:4, Insightful)
Re:images?! (Score:2, Informative)
Re:images?! (Score:2)
Re:images?! (Score:2, Informative)
Simalarly for GIFs.
If you want to see something similar to what it does atm try:
# lynx http://slashdot.org
or
# links http://slashdot.org
Provided you have either program installed.
Re:duh (Score:2, Funny)
Together we'll have the biggest pile of morons that ever existed!
Re:duh (Score:2, Funny)
Based on my non-scientific calculations... The number of people that have said "Imagine a Beowulf Cluster of these!" has been said is so large that it approaches infinity. ie. it's a constantly growing number with no certain end, a lot like Pi. This is true especially since people are likely to be saying this for a long time to come. Given that assumption, it's fairly safe to say that a cluster of all those "idiots", as you put it, would be quite powerful. No matter what their level of intelligence, the sheer processing power would be pretty enormous! Infinitely enormous, in fact. With this in mind, I think what you have proposed is extremely dangerous. A few years ago on Slashdot this [slashdot.org] story suggested that as processing power increases, and CPU size decreases, CPUs generate more heat. The idea being that eventually a laptop could become a small sun, or even a black hole might apply to this cluster as well. That would be pretty damn scary! So, to the original poster above; Congrats dude. You've just suggested creating a device that could threaten the entire planet. Depending on which side of the fence I'm on, (I won't say which) you're a terrorist, or... a redeemer. As my friend Gordon would say, "Yup. The volcano for all of them (them being his enemies -ed.) as soon as I take over the world."
Use SLIP for now (Score:3, Interesting)
There's no PPP yet folks
Some dial-up Internet access providers still support SLIP (serial line IP), the protocol that PPP largely replaced.
Re:No PPP and maybe no ethernet (Score:3, Interesting)
Moderators on Crack III (Score:2)
Re:Moderators on Crack III (Score:2)
Re:I'm waiting for the BBC Micro version (Score:2)
Phillip.
Re:Neat (Score:2)
From the article:
It is also possible to create different CTK looks, themes, by changing the CTK frontend. Currently, there are three CTK themes:
That would be a 'yes' then.
Re:Ataris and such... (Score:3, Insightful)
Get the point?
Never debase people for trying to build a better mouse trap.