I thought I'd post this as the C64 was one of the most popular 8 bits of all time. No doubt many HN'ers are familiar with it, perhaps a few aren't. The site linked is fairlight, an awesome old school demo group from back in the c64's (and Amiga's) heyday. The documents on the site are pretty much everything you need to get started, and the examples (last link at the bottom) are great at getting you up to speed on some common effects.
The best thing about this is that in learning how to code on the 64 you'll learn MOS 6502 assembly, which also enables you to get a head start on programming the Atari 8-bit computers and the consoles (2600 etc.) and the Apple I & II.
If you're looking for a weekend (or two) project, then you could do a lot worse than this.
So HN, what can you do with 64k of RAM and 1 Mhz CPU?
Another fun way to learn is to run games and demo's in WinVICE, accompanied by the ICU64 visualiser ( http://icu64.blogspot.com/ ). It allows you to narrow down where in memory code is running and what it is doing, in a fun, visual way. I taught myself C64 programming by examining other people's code and figuring it out (and sometimes copying it, too). It's a lot easier to do this with ICU64.
I've written a decompiler with a custom template for the 6502 (the idea is all CPUs are fundamentally the same, from x86 to 6502, so you just define a CPU as instructions affecting flags, etc, and have custom functions for, eg., Vax CPUs).
So I reverse engineer a C64 game by first decompiling the assembly code into vanilla C, without any definitions or names. Then I do things like make the emulator refuse to write to an address I'm curious about. Then I can see what the address does, and make a definition (a name!) for that address.
What you get in the end is C-like code with all your definitions making it readable as the original source code.
The only problem I'm having is a really robust flow-control system - JMPs can get hard to parse if they're crazy. But other than that, RightBack is a great decompiler. It's also written in Common Lisp.
A lot of really impressive C64 code is timing sensitive. The coder counts exact number of cycle a piece of code takes and attempts to, for example, synchronize it to the CRT rasterbeam, because the horizontal and vertical refresh frequency are known and because there is a VBL interrupt.
So for example you change the background color at just the right time as the rasterbeam renders the screen to get a rainbow. Similar stuff is done with quickly changing sprites so that you can get way above the, I don't know, 8 or so sprites that are supposed to be the max possible to do in hardware.
You would lose insight into this by converting the code to C.
However, it would be useful for the higher-level logic - like a print function. You decompile calls to this function, no matter how the function works.
BTW my recommendation is to take a look at a 21st century file not on the page first:
25C3: Everything about the C64 in 64 minutes:
http://chaosradio.ccc.de/25c3_m4v_2874.html
OK, fixing the links by typing the basenames into Google. I better see some HN C64 intros.
Bacchus/FLT (alias of the person maintaining that site) hasn't touched anything there in lord knows how long. For those still interested in more accurate information, check out http://codebase64.org/ and for those who wish to speak to the majority of what is currently left of the "C64 Scene", head over to http://csdb.c64.org/ or drop by in #c-64 on IRCnet.
The best thing about this is that in learning how to code on the 64 you'll learn MOS 6502 assembly, which also enables you to get a head start on programming the Atari 8-bit computers and the consoles (2600 etc.) and the Apple I & II.
If you're looking for a weekend (or two) project, then you could do a lot worse than this.
So HN, what can you do with 64k of RAM and 1 Mhz CPU?