> Writing code on C64 is not like writing in a text editor or even like BASIC line numbers. You type your code directly into RAM and instructions are being assembled as you type
Um, no. Maybe you do stuff like that. Most C64 devs used assemblers. We stored source on disk and ran assemblers on them.
For the first C64 game I wrote [1] I actually used the Atari Macro assembler since it was pretty well made and supported relatively large programs. Then I'd transfer the result over to the C64 by the joystick ports with some custom cables and software I wrote.
On the next big project we had dev environment that ran inside Super Text [2] on the Apple II and stored source on a networked Corvus HD. Pressing some combination of keys would start a compile directly from inside the editor. I don't remember how we transfer it. (getting old)
>> You type your code directly into RAM and instructions are being assembled as you type
> Most C64 devs used assemblers. We stored source on disk and ran assemblers on them.
From my perspective, devs that were able to do that were extremely lucky. I gave up trying to program my (contemporaneous) ZX Spectrum in raw machine code with a tape deck for storage after one too many catastrophic failures, and I didn't take up programming again until ten years later when a friend donated me an old PC compatible.
I did a "loader" in basic that saved to either disk or tape. This was pretty common and was explained in magazines and books at the time (I don't think I'd have come with this idea on my own as I was 7-10 years old).
For most kids, programming was BASIC, or BASIC combined with some assembly loaded as DATA blobs. The problem was getting an editor, monitor, source level debugger like for instance http://djupdal.org/cbm/64asm/ but there were things like The Final Cartridge. My dad used it to cheat at games but I found a lot of use to it.
The C128 integrated a memory monitor and disassembler. It was a lot easier to do something decent in C128 without proprietary tools. Sadly it never caught on. But even to develop for the C64 it was a great machine. For most kids it was a lot better to program-play. Like the Spectrum, it had graphic primitives in BASIC. Believe it or not, there was no graphics mode in the C64 that didn't involve playing with memory maps (for sprites) or assembly/machine code.
I didn't do much with the Speccy as I was a Commodore kid but I loved playing with its graphics in BASIC. I never got to do anything more sophisticated than that in that platform. I believe most pros back then did cross-compiling from 128K+ machines to the 48K or the Plus.
Now I collect all these machines but I haven't taken the time to go back and see how would I do things now. There's a lot of stuff I didn't know back then, for instance Forth, which would have worked a lot better besides "machine code" than BASIC.
What I find most amazing is that I remember all this stuff with precision (I can still remember POKE codes) and I barely remember anything else from these years. I have vague memories from even friends, teachers, cartoons...
That's kind-of sad to hear. I picked up programming when I was 8 on QBASIC, and absolutely loved it. 8-year old me would stay late nights till 3 a.m. programming.
I have to admit, Microsoft got a lot of stuff right with the QBasic that was bundled with MS-DOS. Hitting F1 would bring up an amazing help system that documented various features of the language with code snippets. I remember discovering the "DRAW" command, and how much fun I had with it. I came across it on the documentation; and the code snippet is what made it really easy to learn how to use it. But the doc was well-written too -- sufficiently simple for an 8-year-old whose native language is not English, to understand.
Now imagine that I had some *nix -- vi/emaccs alone would put me off, erm, any text editing, not to mention programming. Also, just the way Unix is, where things often break silently, and the system assumes you know what you're doing -- just isn't suited to an 8-year old.
I'm kind-of disappointed at the state of programming right now. Many of the popular languages of today -- JS, Java, Obj-C, C++, etc. are no where as simple as the BASIC dialects are. Python though, is actually a good candidate. With a nice Turtle-like library, it would be a perfect beginner's intro language to programming!
You should try DrRacket. The book "How to design programs" uses it to get you straight into simple graphics. Both the book and DrRacket are available for free as in beer and speech online.
ZX Specturm had ZEUSS (http://en.wikipedia.org/wiki/Zeus_Assembler) macro assembler which we used to wrote games. Tape was different story; we made HW interface so it would use external 5.25 floppy instead :-)
They cost about a month's pocket money at the time. You also had to load them from tape before you could work, which made them mostly an impediment (unless you could afford better hardware). You were mostly better off remembering as many opcodes as you could and looking up the rest as you needed them (or at least that's how it seemed to me).
I always found that far too painful, and almost impossible to spot bugs. And maybe I was just lucky that I was working part-time by then, but a fiver or so for an assembler app didn't seem a huge expense even then.
I would agree that getting microdrives did make a huge difference, but even when I was still on tape it was a hell of a lot easier for me to do that than keying in hex values.
I had the French Silk assembler. PAL was also popular. Neither was very expensive, even for an eight year old like me, saving up his lawn mowing money.
With which I wrote several programs during my high school years. The thing that sucked about the Atari Assembler Editor is it worked like basic. Lines were numbered. You'd type LIST to see your program each line prefixed by a number. LIST 100-200 would list lines 100 to 200. Etc.. But you could renumber lines to insert stuff if you ran out of line numbers.
Which I also had in my high school years before going pro. It was pretty similar to modern assemblers.
I don't remember the price but I wasn't rich so it couldn't have been that expensive. It's possible I pirated the Atari Macro Assembler (thought I don't think so) but I couldn't have pirated the Atari Assembler Editor Cartridge :-)
I guess he just used what he had on hand. By the time the freeze cartridges were out, you could get pretty good native assemblers (like Ocean's Laser Genius, which can even be scripted in a sort of Forth dialect). Then you'd use the monitor on the freeze cartridge to debug the code generated by the assembler.
I wrote many intros using the Power Cartridge monitor, before I learned about assemblers. For small projects it's fine!
I grew up writing my own games on the C64, and one of the fun things that always got me was how close the video RAM was to the memory containing your program itself.
So if you had a game where you moved a little character around the screen with the joystick, and you neglected to handle the case where he went off the screen to the top or bottom, you could crash him right into your source code (which was being actively interpreted).
It'd dump you out abruptly, you'd list your program and find that a section had been monched and now contained a bunch of random special characters. Ouch.
That hardly ever happens to me anymore, writing front-end code for the browser. But still I make a point of checking my bounds, just in case!
In this day and age, you use PCs to develop games for C64. You're able to do stuff you couldn't before because now you have the capacity to precompute an compress a bunch of tables and such. And you use modern developer tools (assemblers, etc -- all on the PC) and test the stuff on emulators. (It still works on the real HW.)
I know this because a colleague in the office is still active in the demo-scene (yes, it's still active) and participates each year in competitions.
This is truly impressive in this day and age. I used to write little games like this on the C64.
I do wonder why he is using a tape drive, though. That is taking retrocomputing a step too far. We had a 1541 (IIRC) from day 1 when I first got the C64 back in 1983, four years before the author was born. Tape is too painful; and should be reserved for someone who wants to retrocompute on the VIC-20.
I was trying to explain how delightfully 'tangible' the C64 was the other day - POKE something into memory and bang, stuff happens. It never ceased to amaze me how much improvement could be achieved over the baseline h/w and s/w setup too - order of magnitude faster disk access, 80 columns, etc. etc.
Oh God, those hours. Can't decide whether they built character, or caused permanent trauma. And in the odd case that the program worked, I would keep it on as long as I could, since the record button on my tape drive was broken.
Since it's posted on ludumdare, it should say "in 72 hours". (Or 48 hours if he entered it into the competition. Since it looks like he posted on Monday, he must have done the 72 hours jam and not the 48 hour competition.)
I once attempted a Gameboy Color game running a Java Gameboy Color emulator running as an applet for the Ludum Dare. This was like 2006. Didn't complete anything but was a hell of an experience.
At first i didnt get why he didnt have time to finish the first game he planned. Turns out this was a submission to the ludumdare game programming contest where you build a game in 72 hours.
Um, no. Maybe you do stuff like that. Most C64 devs used assemblers. We stored source on disk and ran assemblers on them.
For the first C64 game I wrote [1] I actually used the Atari Macro assembler since it was pretty well made and supported relatively large programs. Then I'd transfer the result over to the C64 by the joystick ports with some custom cables and software I wrote.
On the next big project we had dev environment that ran inside Super Text [2] on the Apple II and stored source on a networked Corvus HD. Pressing some combination of keys would start a compile directly from inside the editor. I don't remember how we transfer it. (getting old)
[1] http://www.mobygames.com/game/c64/centipede_
[2] http://en.wikipedia.org/wiki/Muse_Software