Slashdot Mirror
Programming the Commodore 64: the Definitive Guide
Mirk writes "Back in 1985 it was possible to understand the whole computer, from the hardware up through device drivers and the kernel through to the high-level language that came burned into the ROMs (even if it was only Microsoft BASIC). The Reinvigorated Programmer revisits R. C. West's classic and exhaustive book Programming the Commodore 64 and laments the decline of that sort of comprehensive Deep Knowing."
Atari 800 rules!
Expert Java EE Consulting
Now, I can finally stop waiting and get to programming my Commodore 64!
You see? You see? Your stupid minds! Stupid! Stupid!
I started on a Commodore 64 (well a Commodore 128 that ran exclusively in 64 mode..) and learned machine language by breaking protections of the day. Many of the things that were legal back then such as copying software for DRM'd games are now gone the way of the dodo. I honestly see that in twenty years from now a debugger in itself will be seen as a "tool of crime" or whatever wordage they use to keep them out of the general public's hands just like lock-picks today. Hope you like high-level because the day is coming that it will be illegal to be low-level without a government (or more likely Apple) license.
Shh.
Here in 2010 it's not necessary to understand the whole computer
Unless you want more throughput: manipulate more objects at once, serve more users at once, etc. If a Python program is spending most of its time in interpreter overhead, you may need to recode inner loops in C.
Or unless you're programming for an 8-bit microcontroller roughly as powerful as a Commodore PET. Not all "computers" are as powerful as PCs or even smartphones.
Relax. You've obviously read too many kdawson stories recently, and have been trolled into a heightened state of paranoia. Don't worry, it happens to the best of us.
Also, why have you switched off your iphone citizen 533448?
It was possible to fully understand all of the old 8 and 16 but machines. Now you could spend momths trying to fully understand one video card, which would be replaced by something more complex by the time you finished understanding it.
And that was a big part of it, the stability of the platforms during that era. A C64 was exactly the same as every other one, a Tandy Coco was identical to the million others of it's kind. Later models tended to retain as close to 100% backward compatibility as possible so knowledge and software tools retained value. Now you buy a lot of PCs with the understanding that a year from now you won't be able to buy more of the exact model even if you stick to Optiplexes and such that promote the relative stability of the platform. Something will be slightly different. So, understanding being impossible we abstract it all away to the greatest extent possible.
If you want to reconnect with low level look at AVR microcontrollers. If you are really frugal you can get going for $20.
Democrat delenda est
Though my experience was on the Apple II not the Commodore. Little things like writing your own device drivers, drawing graphics via direct access to interlaces vram, (oh the maths!) direct read latch access to the floppy drives, writing hybrid assembly/BASIC apps. It was grand.
It's downright depressing to compare my present-day knowledge of computers, classify myself as somewhere in the upper 2%, and still wish I knew a quarter as much (percentage-wise) about my current computer as I did about my //c.
*sigh*
I work for the Department of Redundancy Department.
...buy yourself some Atmel microcontrollers (ATMega8 is a good choice). This will be instantly familiar to anyone who programmed assembly language on the C64. There are some differences, the Atmels aren't Von-Neumann architecture but Harvard architecture (separate program and data address space) and the CPU has more registers, but there is excellent hardware documentation, the complete command set and detailed register descriptions in the data sheet. There are lots of interesting application notes (IR decoding, interfacing to PS/2 keyboards, LCD output, ...). The Arduino system is based on an Atmel microcontroller, so there is also a big application oriented community in addition to the people coming from the electronics side.
It's not a toy either. These controllers are everywhere. Have fun and learn a useful skill...
Here in 2010 it's not necessary to understand the whole computer, from the hardware up through device drivers and the kernel through to the high-level language that came from your apt repositories.
It wasn't necessary then either. The point is that you could. Now this is no longer possible. There are pros and cons to this, we can acheive more by building on the magical black boxes, but there was something deeply satisfying about knowing a device in such depth. The same can still be acheived in the embedded realm, however, and due to modern advances, it's cheaper and smaller than ever!
To know a computer from the ground up, as it were. Its not some long lost dream or anything, after all your average disposable Crapple Netbook with "clout computing" or Octocore Core i13 and a half is just a fancy C64 with more CPU instructions, more memory, more peripherals that runs faster.
Its just that unless you start off at the low level, learning about transistors and that sort of shizzle and learning assembly language you probably will never bother to learn it. A lot of programmers now think about functions, objects and arrays as if they actually exists - not just a convenient way of presenting blocks of code and data in a way that makes it easy for you to understand. Fuck it, a lot of people fairly high up on the IT scene have no clue in the wide world about TCP or UDP but they sure as hell know how to write a 'Web App' using JSON and the latest Web 2.5 gimmick completely oblivious to any of the lower levels.
The problem is when you have nearly everyone going for the latest abstraction layer, easy low hanging fruits (at the expense of efficiency and everything else - rabble rabble rabble) high level stuff there might be a day 2110 when they're still using HTTP + more abstraction layers but quantum computers aren't getting any faster for what they need and nobody knows knows any of the low-level stuff anymore. If you are the one kid on the block who knows how to write assembly in 2110 you'll be a rich man by 2111, just in time for the end of the world cause the Mayans were off by 100 years.
for certain the drivers/os back then were less buggy - they were smaller and so much less complex. It was a fairly simple matter for someone to have full understanding of the entire OS and sum it up in under 50k. (and I mean BYTES, not LoC)
I work for the Department of Redundancy Department.
One of the most comprehensive protections at that time was called "V-Max!" which stood for Verify Maximum. What were called "nibblers" for disc copy software couldn't touch it even though those nibblers represented the ultimate in disk copy technology at the time. There were two ways to copy V-Max, the first was to get a dedicated hardware copying unit. The second was to apply a bit of knowledge with a debugger cartridge: the V-Max protection was a turn-key system you gave them files and they wrapped the protection around it and provided a fast-loader at the same time. So what you would do is fill all of memory (the whole 64K) with a value you knew say: $AF. Then you would load a V-Max file from the disc, it's loader would automatically take over and while it was loading you would enter your debugger cartridge and change it's exit point to point to itself. So instead of $0800: RTS you would make it $0800: JMP $0800. Then you would wait for the V-Max loader to fully load the file. Then a quick button press on your debugger cartridge and use the memory monitor to find where the file loaded by seeing what memory was NOT $AF. Then from the debugger cartridge save that memory block out again. Completely de-protected file. Since V-Max used standard kernel-load vectors the program itself needed no further modification, the protection was completely gone you just lost the fast-loader function. Which you then re-added yourself into a chunk of memory wherever the game didn't use it. Relocatable code was best for that. Later versions of V-Max also did on-the-fly decompression of files so occasionally while stripping the protection you would run into a situation where your destination disk ran out of space versus the original protected disk. Again, that was worked around by inserting your own custom loader into the kernel load-vectors which also did decompression. V-Max was impossible for copy software of the day to copy but with a little bit of knowledge and a debugger cartridge it was absolutely trivial to defeat.
Shh.
Should anyone wish to download an electronic copy (PDF) of Programming the Commodore 64 by R. C. West they may do so from DLH's Commodore Archive. It's a community supported archive of Commodore-related printed materials (books, magazines, newsletters, manuals etc.) and it could use your support. Enjoy.
This guide is *GREAT!*
I've got 6 web sites and 25 mission critical apps running on a cluster of 10 Commodore 64s. It started out with just one, but as our business expanded, we just kept adding them on. It would be a bear to migrate to MS-DOS or Windows 1.0, but maybe it's time. The acoustic coupler modem is a bit slow, but it's been working for us since 1990, it's hard to justify the upgrage.
If you want news from today, you have to come back tomorrow.
There doesn't appear to be any section on custom high-speed communication with the external floppy drive unit. IIRC, you could upload a small program to the drive, and then you could in particular read data from the drive a lot faster than the 'OS' normally supported. This technique was also used to do copy protection for a bunch of titles, primarily by stepping the drive head 1/2 between tracks then doing reads. Production disk duplication could write to both the track & between tracks [or could write a wide enough track to cover the whole area], but regular floppy drives couldn't write both [you could either write on the track, or between tracks].
Not that I was interested in this stuff or anything.
Sleep your way to a whiter smile...date a dentist!
And why did I spend time removing protection systems? Funny that part is: I owned an MSD floppy drive which was completely incompatible at a machine-language level with the 1541 drives everyone else owned and that all the game-makers wrote their protection systems for. So my floppy drive would load any of the software of the day. I literally bought a game, had to hack away the protection, and then I could play it on my computer. Of course no one will believe me when I say this but damnit, its the truth! Now get off my lawn.
Shh.
Fast loaders worked because the kernel ROM software didn't fully take advantage of the hardware. Between the C64 and the 1541 floppy drive the connector cable had 4 wires for carrying information. The kernel routines built into ROM only used one of those lines to signal from the drive to the computer. The "fast loaders" simply uploaded a program to the drive which used all four lines to signal information. The "fast" loaders weren't fast magic they just removed a deficiency in the kernel ROM routines. The exact number of lines between the computer and drive I'm not sure of but this is the principle the fast loaders worked by. And tape based fast loaders worked because the kernel routines would save a copy of the information to tape and then immediately save a complete other copy to compare against for error correction on load. The tape fast loaders just skipped saving and comparing the redundant copy to get the speed. Disk fast loaders didn't compromise the integrity of the information in the way tape fast loaders had potential to though. Remember computers back then were full of noise when you were talking to tape drives especially.
Shh.
http://www.salon.com/21st/feature/1998/05/cov_12feature.html
Ellen Ullman was a programmer for a full career before she discovered she was also a talented writer. The above link is to a Salon.com article that was basically an excerpt from her excellent book, "Close to the Machine".
She writes about getting a PC and stripping off Windows, DOS, everything, until the (old even for 1998) BIOS is saying "Basic Not Loaded", then building Linux on it.
Her conclusions do sound a smidge "kids these days" when she writes about modern programmers that only know libraries and IDEs, but I know the /. gang will love it:
"Most of the programming team consisted of programmers who had great facility with Windows, Microsoft Visual C++ and the Foundation Classes. In no time at all, it seemed, they had generated many screenfuls of windows and toolbars and dialogs, all with connections to networks and data sources, thousands and thousands of lines of code. But when the inevitable difficulties of debugging came, they seemed at sea. In the face of the usual weird and unexplainable outcomes, they stood a bit agog. It was left to the UNIX-trained programmers to fix things. The UNIX team members were accustomed to having to know. Their view of programming as language-as-text gave them the patience to look slowly through the code. In the end, the overall "productivity" of the system, the fact that it came into being at all, was the handiwork not of tools that sought to make programming seem easy, but the work of engineers who had no fear of "hard."
---
I do recall some /. (or maybe it's in Salon) commenter at the time who replied, "Yeah, and your Dad thinks you're a weenie because you don't know how to wire transistors on a circuit board, and his Dad thinks he's a weenie because he can't wind the copper wire around his own inductors". Which is fair enough. Even log cabins can't be made without manufactured tools unless you can mold a kiln from clay and smelt iron for the axe yourself.
Still, the point of the desire is to have *maximum* control of the level of tool you are able to work directly with. The philosophy was echoed by Neal Stephenson in his essay, "In the Beginning Was the Command Line", the googling of which I will leave to the student. It's on-line.
Dude, back when I was a kid and had a C-64, I wrote a JVM for it. Unfortunately I had trouble, because while the JVM standard defines long as not being threadsafe (as a sop to 32-bit architectures), it defines operations on int, short, char, and Object references as being atomic. So I had to write single-threaded code to simulate multiple threads just to get the garbage collection to work. And my char mappings didn't support Arabic and Chinese- you had to stick with PETSCII.
I was so embarrassed in front of my friends when my games paused intermittently to clear out kilobytes of garbage from the little heap. They were like, WTF, what is it doing, and I said, give me a break, it's Java. The only program I ever really got to work right was my C-64 emulator.
Today we have garbage collectiors in Java and that is why the C64 is completely outdated.
Everyone who still writes code on the C64 instead of Java won't get a job.
You probably don't even know the latest words.
Oh, I don't know about that. There are thousands of embedded systems that need programming and require the kind of thorough knowledge of the hardware that you got from the old C64 days. There are more 8-, 16- and 32-bit systems without enough memory to run something like Java than there are PCs and higher class systems.
Don't pooh-pooh the old ways. They're what's running your world.
A few years ago when I was an undergrad, I did a class project on the C64 just for the hell of it...the assignment was for my Theory of Computation class, and I happened to be taking an embedded systems class at the same time. I ended up implementing a Turing Machine simulator on the C64. I used a C cross-compiler on my PC to develop it, tested it on an emulator, and eventually burned it onto a ROM chip which I put into an actual cartridge that ran on a real C64. It was a REALLY cool project that involved quite a few different aspects of CS, and I ended up taking first place at a undergrad research poster competition at a CS conference.
Yeah but I was running a ribbon cable to my brother's VIC-20 for the garbage collection and extra 5K heap memory because I couldn't get my dad to buy me three more C-64 machines for a quad-core 32-bit CPU. He kept saying, there's nowhere to plug them in; just wait for the C-128 to come out. I was like "but Daaaad, it only has 8 bits!"
Cloud computing was really difficult too. There were a bunch of kids in my highschool running BBS systems but you couldn't really store your documents there because you always got busy signals, the 300 baud VIC modem was a POS, and the cloud had nothing but stupid foul-mouthed kids in it anyway.
Yet every day, I put young pups to shame. It does not matter if it is troubleshooting hardware, or software. It does not matter if it is dealing with programing or configuring. My mental map of the problem is different than theirs.
The skills I learned back in the 80's on a computer that you could understand, I still use today. My "concept" of what a computer is was formed by understanding the whole. RAM, ROM, interrupts, I/O, how the CPU works. All from a machine with 64K or RAM and 20K of ROM.
Under the hood, under all of that abstraction. Is a PC that is very much like a C64. With the C64 people learned mastery of their system. With the PC, so much hardware is out there. It is impossible to learn it all inside out and take advantage of every feature of it. So greater power has always been obtained in the PC world by moving to faster hardware, not by utilizing the current hardware better. It is all abstraction running on very fast, underutilized hardware.
The techs coming out of college for the last 20 years do not understand a computer conceptually like those who learned this stuff in the 70's or 80's. When it comes to trouble shooting all of this abstraction, many folks have no idea that there is anything beneath the abstraction.
I recently attended a college programming class as a requirement for a degree. The instructor gave us a quiz at one point and there was only 5 students out of 60 that passed. Why? Because most students did not know how to write a program on a piece of paper. Without intellisense holding their hand they could not code. I learned to program from the manual that came with my C64. I learned to program better by typing in programs from Compute! Magazine. I have written hundreds of pages of code on paper and typed it into a computer at a later time. It is a skill I take for granted. Without the abstraction of Intellisense most of the class was rendered useless.
Something has been gained, but something has also been lost. When I was a kid I dreamed of computers that could do a 10th of what they do now. I learned everything I could about them. Lived, dreamed, ate, slept computers, computers, computers. Now days. My kids can buy a laptop with 3 gigs of RAM for the price of a C64 and 1541 drive. And what do they do with it? Program? Nope. They learn their friends on FaceBook, not programming. They play games, not write them. They pirate music, not create it.
It looks like those who understand a computer and really make it do something will always remain a small, elite Priesthood.
vi +
And what do they do with it? Program? Nope. They learn their friends on FaceBook, not programming. They play games, not write them. They pirate music, not create it.
Computers used to be primarily for those interested in computers, now they are exactly what they were designed to be, a tool to get things done. There are probably just as many - if not more - young tinkerers and hobbyist programmers, but the computer userbase has grown phenomenally since the old C64 days such that the percentage of that userbase is much lower. The people who use them simply for facebook, games and pirating music are likely not the sort of people who would write fast loaders and the like anyway.