Programming the Commodore 64: the Definitive Guide 245
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."
Re:Totally outdated... (Score:3, Informative)
Today we have garbage collectiors in Java
Garbage collectors in Java are good for collecting objects that own only memory but lousy for collecting objects that own resources other than memory. Resource leaks happen whenever someone forgets to close() something in a finally block, just as they do in C++ when someone forgets to delete or delete[] in a destructor or in the exceptional path of a constructor.
Everyone who still writes code on the C64 instead of Java won't get a job.
Unless you're in charge of making a PC or phone port of classic C64 games. Then you need to know both Java and C64 assembly language.
Just say embedded (Score:1, Informative)
All the stuff we learned on the VIC-20 and Commodore 64 (and PET) still applies in the embedded world. If you could program them, you can totally do a PIC or an Atmel AVR (or Arduino).
If you miss the 8-bit era... (Score:4, Informative)
...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...
Re:Invert rose-tinted-glasses (Score:4, Informative)
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)
Want to read Programming the Commodore 64? (Score:5, Informative)
Re:Its still possible.. (Score:5, Informative)
Octocore Core i13 and a half is just a fancy C64 with more CPU instructions, more memory, more peripherals that runs faster
Possible, but nowhere near as easy. I've read most of volume 3A of Intel's architecture reference while doing background reading for my Xen book, but the complete architecture reference is well over 3,000 pages. The GPU reference - if you can get it - is a similar length, and that's before you get to the OS. The Design and Implementation of the FreeBSD Operating System is 720 pages. It's a good book, but it skips over a lot of details. The copy of the X11 protocol reference that I read was several hundred pages, and it's a few revisions old. The OpenGL reference was a similar length. But now you can do 2D and 3D graphics and, once you've read the C spec (not so bad, only a couple of hundred pages) and spent some time familiarising yourself with your C compiler and standard library you can draw things.
To get the level of understanding that the original poster is talking about, on a modern computer, means reading and remembering around 10,000 pages of reference books, and gaining familiarity with the source code that they mention. And that's just going to give you one CPU architecture and the core bits of the OS.
Best covered by Ellen Ullman in 1998 (Score:5, Informative)
http://www.salon.com/21st/feature/1998/05/cov_12feature.html [salon.com]
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.
Re:Frist psot! (Score:1, Informative)
But it took the XE series to get the BASIC right so that bugs were removed and a shorthand parser added to save a bit of typing. The XLs still needed cartridges to get the better version. (I think the Commodore folks mostly missed out on that kind of thing.) And by the time Atari had the 8-bit formula mostly right, all the attention and support moved to the 16-bit ST computers. (Commodore fans did share in this kind of thing with the transition to Amiga. Yet they still had a bigger 8-bit user base to fall back on.)
Strangely enough, sometimes you also needed an interpreter software to run XL software on an XE. I think that was necessary because some programmers found about the few XL bugs and considered them a feature. We had (have?) our rivalry, but I feel Commodore folks missed out on some of the fun.
Re:Uphill Both Ways (Score:5, Informative)
I literally bought a game, had to hack away the protection, and then I could play it on my computer.
The more things change, the more they stay the same. Sort of like how my Linux computer won't play a Blu-Ray from walmart, but it does just fine with one from the pirate bay.
Re:Frist psot! (Score:3, Informative)
Of course Jay Miner put his magic into the Amiga as well.
the vic20 manual that came with it WAS GREAT (Score:1, Informative)
...at age 12
allowed me to make my own databases
graphic animations and even up and down moving sprites
i even parsed commands to do htngs like move an army and make a hockey game and boxing game.
12
what do your kids do
besides twitter , waste money on phones , and use myspace and facebook
Comment removed (Score:3, Informative)