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."
Frist psot! (Score:4, Funny)
Atari 800 rules!
Re: (Score:3, Funny)
Atari 800 rules!
Here we go again ... "which platform is better" flamewar. Everybody KNOWS that the Sinclair ZX80 was best.
Re:Frist psot! (Score:4, Insightful)
The Apple ][, clearly.
Re: (Score:3, Informative)
Of course Jay Miner put his magic into the Amiga as well.
Re: (Score:2)
Re: (Score:3, Informative)
Indeed (Score:2)
Re:Indeed (Score:5, Interesting)
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.
How Fast Loaders Worked (Score:5, Interesting)
Re: (Score:2)
A disk-drive fast loader could fit into 256 bytes, IIRC.
The trick was to shift bits in an unrolled loop. I remember I stored some values on the stack by using PHA in this loop.
I did write a fast loader for a few games I wrote on the C64 (with was one of the computers I was doing games in the 80s, along with Oric, Thomson TO7 and MO6 and Amstrad CPC). Atari ST appeared in 1987.
Re: (Score:2, Interesting)
The 1541 drives were purposefully slowed down to maintain compatibility with some other Commodore hardware (I forget at the moment exactly which)..... so they weren't so much fast-loaders as they were "doing it the way the engineers designed it to work, not the way the boss made them change it so he could claim compatibility.
Re: (Score:2)
That's in an exhaustive 1541 ROM dis-assembly book. I do not now recall who published or wrote it. It had exhaustive detail on how the drive's rom worked. Using that and some machine code I actually found out you could store a file on the floppy that on power on would boot no-knock code. I used that for several years. Then tech got more difficult and less accessible for a time.
Now with small devices like the Arduino and Make Magazine's controllers many people are learning and better creating things with rea
Re: (Score:2)
It's been so long I cannot recall if the code was in that book or if I used this portion of it to create the program.
http://project64.c64.org/hw/1541_tricks.txt [c64.org]
I can't even find the program that ran on the C64 to stop the knock on the 1541.
Re:Indeed (Score:5, Interesting)
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.
Re: (Score:3, Insightful)
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 an
Sweet! (Score:5, Funny)
Now, I can finally stop waiting and get to programming my Commodore 64!
Re:Sweet! (Score:5, Funny)
Now, I can finally stop waiting and get to programming my Commodore 64!
I know right! I finally got my Beowulf Cluster of c128's running GNU/linux doing seti@home work!!! Sure it's drawing about 200amps but damn it's a sweet setup and only takes about 24 days per unit!
6510 Machine Language (Score:3, Interesting)
Relax (Score:4, Funny)
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?
Re:Relax (Score:5, Interesting)
Re: (Score:2)
Re: (Score:2)
My response was to kick their copy protection out of the game.
What? It's legal! My country's copyright law explicitely states that disassembly and alteration of compiled code is allowed if necessary to make a system or program to interoperate with another one. No kidding. They pretty much prompted me to invoke that portion of our copyright code and crack their game. Without the crack, it is not able to cooperate with the disasselber or the CD-drive emulator I have running that I simply cannot turn off (sorr
Re:Relax (Score:4, Interesting)
Perhaps ultimately more dangerous(because they tend to be subtler) are situations where no law ever bans something, per se; but some quiet mixture of contractual, legal, and technical pressure effectively prevents it anyway. Consider SDI [wikipedia.org] for an instance of that. A digital video transmission standard, available well in advance of HDMI, that was frozen out of the "Consumer" market entirely. It's not like possession was illegal or anything; but most people never even heard of it, nor was it available on any broadly affordable hardware.
In the case of something like debuggers, I'd be very surprised to see any sort of legal ban; but the technological/private sector contractual de facto neutralization is an eminently plausible scenario. Already, in recent versions of Windows, any media application that requires the "Protected Video Path" will throw a fit if there are any unsigned drivers loaded that could compromise that path. An analogous "Protected Execution Path", provided by the OS for programs that didn't want anybody else debugging them or looking at their memory, hardly seems implausible. Not to mention, of course, the increasing percentage of consumer-level computer activity that is occurring on devices were being able to run arbitrary programs isn't even an expectation. Not much debugging going on on Xbox360s, and debuggers don't have to be illegal to not be available through the App Store.
There will always be gaps, of course, for the sufficiently knowledgeable, motivated, and well equipped; but a largely opaque consumer level computing environment seems like an unpleasantly plausible prediction.
V-Max (Score:5, Interesting)
Uphill Both Ways (Score:5, Interesting)
Re: (Score:2)
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: (Score:2)
Re:6510 Machine Language (Score:4, Funny)
A fellow in the local C64 users group was a tester for Maverick (copy protection removal utility).
We had Maverick files to deprotect software that were never released to the public.
"Oh, man! This disk is driving me crazy, I can't copy it!" Was a frequent lament on QuantumLink.
And we would smile quietly to ourselves. "Maybe for YOU."
The SuperSnapShot cartridge ruled. Load an app or a game, go through ALL the dumbass copy protection nonsense, like "what's word 6 in sentence 9 on page 12?" and then configure the app/game, push the button on the cartridge, drop into a menu, and save a bootable RAM image to a floppy.
NO copy protection and everything is just as you liked. It was also a way to quit a game that had no SAVE level option or when you were about to do something that could be very dangerous (gameplay wise.) Just save to disk and take on the level boss. If you died, no big deal. Run the saved image and try again.
And if that didn't work, cheat! Drop into the ML monitor, change a few characters, return to the game and not only did you have unlimited arrows, you had, essentially, a bow and arrow machine gun. (Autofire when holding down the Big Red Shiny CANDY LIKE button on the joystick was always useful when leveling up.)
Although, making the Pac-Man unkillable was considered poor form, all things considered.
All of the 8 and 16bit machines were knowable (Score:4, Interesting)
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.
Re: (Score:2)
It was possible to fully understand all of the old 8 and 16 but machines.
Personally I prefer my butts to be over 18, but to each his own I guess.
Re: (Score:2)
It's not really exact, since the C64 existed in 2 forms: one for the US and one for the Europe.
I vaguely remember that it introduced a difference in the fast disk-loading routine mentioned in a message above, because there was one cycle of difference (yes, simply a NOP).
If somebody is interested, I can dig in my very old source code to retrieve this information (I coded several games for the C64 in the years 1985-1988).
Re: (Score:2)
It was possible to fully understand all of the old 8 and 16 but machines.
Well, a lot of the segment-based memory management features introduced in the 80286 seemed to be so complex and hard to understand that nobody really used them to the extent Intel envisioned. Once the much simpler page-based virtual memory was added to the 32-bit 80386, people tried to forget that those 286 features ever existed.
Re: (Score:2)
Not if you use a 64-bit version of Windows, you can't.
Also I have my doubts about whether you actually could run those on a 32-bit version, but I'm not about to whip out VirtualBox and try.
I miss those good 'ol days (Score:5, Insightful)
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*
Re: (Score:2, Interesting)
I think it's there if you want it. A couple of weeks ago I was writing in assembly language specifically for one of the top ten fastest computers in the world. Sure, there's a shitload I don't know about that cluster -- no idea if there's an RJ-45 port, much less how I'd access it via the assembler, but I could probably find out if I cared and got clearance for it.
It's easy to romanticize simpler times, and there is some truth to them being simpler, but I'm damn excited about today. I mean, really, you can
Re: (Score:2)
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.
Can you get more done with a program today than you could with the Apple II?
Re: (Score:2)
Re: (Score:2)
Err okay... so are you rebooting and launching Visual Studio enough times that it takes longer these days to write a program than it did back in the C64 days?
I must admit I am disappointed. I thought I was going to hear about how all the abstraction and use of libraries/modules/etc meant that we can create useful apps in a fraction of the time that we could in the 80's. I had no idea it actually took longer!
Re: (Score:2)
That's right; one of the usability tests was boot-to-use time. I'm sure it was far from the most important, and there are changes in the way computers are used now that make it almost obsolete. For instance, my MacBook Pro might take over a minute from cold boot to an open terminal window, but I reboot it only rarely. Most of the time I just close the lid and let it sleep, so wake-to-use time is under 5 seconds; less if I already had a terminal window open.
The answer to the grandparent's question is, "ye
Re: (Score:2)
> One of the usability tests that Jef Raskin proposed was the time from turning a computer on to having written a program for adding two numbers together.
So the Openoffice spreadsheet is totally unusable.
Re: (Score:2)
Re: (Score:2)
Those were the good old days.
I could make beautiful music on my Apple II.
No, really, I made music. Like this:
10 POKE -16336,0
20 REM TOGGLE SPEAKER
30 FOR I=0 TO PDL(0)
35 REM DELAY BASED ON POSITION OF GAME PADDLE
40 J=J+1
50 NEXT I
60 GOTO 10
Man... I was so productive back then...
Re: (Score:2)
I remember writing that exact same program. The rising and falling of the speaker tones as I twisted the paddle knob back and forth.
Good times.
Re: (Score:2)
So, top 2%, what are you doing now?
I also place myself in the top 2% and did very well as a freelance programmer for many years. Then I started competing with offshore programmers.
Now I'm not a programmer any more. I miss it, but I need to make a living.
Re: (Score:2)
So, top 2%, what are you doing now?
Today I do warranty repair work for Apple at an AASP. Our shop is small, but I have the satisfaction in knowing we're good and well-respected. From time to time the local (50 miles away!) apple store actually sends customers here because they can't cut it. :)
Hence the wish that I could have anywhere near the mastery level on the mac as I did on the II. But for now I solve problems, I fix things, and I help people. That sums up what I enjoy doing, and usually involves t
Re: (Score:2)
I still have my copy of "Beneath Apple DOS" in my library.
that went out with the lot about 5 yrs ago when I realized it was time to leave that era behind. Very few books, but I think I was up to close to 300 floppies. Had the entire Beagle Bros collection, that was an excellent outfit. I Hear Alan Bird is working for Apple now. Kinda wish I'd have kept those manuals, they were gems.
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...
Its still possible.. (Score:4, Insightful)
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.
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.
Re: (Score:3, Interesting)
On top of that, I have postfix config files, a mach_kernel file, and a bunch of other weird files that are either quite complex (this book about Postfix [oreilly.com]
Re: (Score:3, Interesting)
You are only partly right. All of those things are knowable and learnable within a reasonble length of time - the problem is getting the documentation to know them. Too much documentation is locked up as proprietary info, either behind a paywall or an NDA wall.
Re: (Score:2)
You could learn pretty much everything about a headless Solaris/SPARC system.
OpenSPARC T2 to learn about the CPU (and chipset, it's a SoC,) OpenSolaris to learn about the OS.
Graphics would be the only thing in a normal system that wouldn't be included.
Misty-Eyed Nostalgia (Score:3, Insightful)
It's lovely to remember what was, but not so great to forget what we have today.
Sure, we generally don't know the whole widget from top to bottom, but it's a hell of a lot easier to get a program up and running. It's not just frameworks either - the choice of languages we have today beats the crappy BASIC we had then, or the assembly language tools we had.
The first machine I knew inside-out was the ZX-Spectrum. While I like to remember it fondly, I would never want a return to those primitive times.
It's a bit like object-oriented programming - we hide the details of an object and only deal with the interface. It's more scalable and leads to faster development.
Re: (Score:2)
If you want to know a platform inside out, there's a fully documented open-source linux kernel staring there at you in the face.
Go get any of the dozens of embedded arm kits, any of the GREAT bits of documentation, and dig in. You want to get dirty with the hardware? U-boot is right there.
Want to pay with SRAM and gates? A $100 FPGA will get you all you need. Including a VGA out. We made a fully HDL Pong Game; including the VGA DAC out of a $20 part.
Hell, for ALL that matter, go get a Gameboy (any one) for
Re: (Score:2)
We do not know the whole widget anymore from top to bottom like we did with the 8-bit machines of our childhoods... but if I talk to kids with an interest in computers today, they know a great deal more about the nitty-gritty of modern machines than I do. Sure they aren't taking a soldering iron to the motherboard anymore like I used to do with the C64 to make some sort of interface, instead they stick some components on a
Re: (Score:2)
Re: (Score:2)
you didn't realize what was wrong with for (i = 0; i < strlen(s); i++)
Nothing, with a decent compiler. The loop-invariant code motion pass will ensure that the strlen() call is not invoked more than once. The simplify lib call pass may even remove the strlen() call entirely if the length of s can be determined at compile time.
Re: (Score:2)
It'd be pretty straightforward to circumvent a compiler's idea that the length of s is invariant for each loop pass. Some pointer math could probably do it rather handily.
I'm not saying that that's *right*, but relying on the compiler to optimize away your indiscretions is a rather poor way to write code.
Re: (Score:2)
The bodyless loop can be replaced with "i=strlen(s);", if it has a body then pre-assign a variable instead of calling strlen() at each iteration (which a modern compiler would do automatically anyway). But what is that supposed to prove? That stupid people can write stupid code? That stupid people didn't exist 20yrs ago?
What is "fucking sad" is that you don't realise 's' is an "object" and strlen() is a "string method" that hides it's implementation details behind an API. T
Why lament? (Score:2)
Frankly, it's a great time to be interested in computers: absurd amounts of power for cheap, _along with_ easy access (thank you Internet) to kits, i
Want to read Programming the Commodore 64? (Score:5, Informative)
Kudos to the C-64 (Score:2)
I credit going through elementary school with a Commodore 64, one of the few in my school that couldn't actually afford one, for my advanced engineer position I have now. I spent so much time hacking away basic programs and stuff that I ended up learning so much computer science without even realizing.
Its the only explanation I have for how I've been a software engineer for my entire post school career (the past dozen plus years) while my undergrad degree was a BA in English.
Re: (Score:3, Funny)
Finally! (Score:2)
Those were the days! (Score:2)
Anyway, even Mad Magazine eventually published a program, but it never worked.
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.
The Deep Magic is still there... (Score:2, Insightful)
The deep knowledge is still there - the well is just a LOT deeper, and more complex.
In the days of the C64 - it was reasonable for a skilled and/or curious programmer to get to the bottom of things and learn how everything worked, exactly. It was also potentially USEFUL for him to do this.... it was the only direction you could go, short of inventing a new language.
So - today we still find deep knowledge out there - but it just not be as useful for even a very good programmer to go ALL the way down.
Yes, a
experimenting and learning (Score:2, Interesting)
I had a 1 line game for the commodore series of computers.
Something like the below. You could do it in less than 40 characters with the short cuts. It even worked on the TRS80 line with slight modifications.
I liked walking into their sales rooms with the "don't touch serious stuff" feel and having a game going in 30 seconds.
0 poke 32788+loc,65; loc=loc+peek(151)*2-1; print tab(rand(37)),"XXX"; if peek(32788+loc) == 32 GOTO 0
You had to clear the screen and start it with RUN at the bottom for it to work
poke 3
I miss my Apple ][e! (Score:2)
C64s can still be fun... (Score:3, Interesting)
Deranged facts (Score:2)
Re: (Score:2)
Commodore originally licensed BASIC from Microsoft. They wrangled some deal which gave them full rights with a one-off payment. MS eventually felt hard done by and you see the Microsoft copyright message on the c128 boot screen.
A computer that fits in your head can be great fun (Score:3, Interesting)
I've recently rediscovered the joy of small computers that can be fully understood by one person. The 8 bit machines from the 80s provide opportunities for learning and experimentation that are not present in today's computers. "Retro computing" is growing as a hobby amongst both people who remember these machines fondly from past days and younger folks who just find them interesting. It is strictly a hobby of course, very little "useful" stuff can be done with these boxes beyond the education they can provide.
My favorite retro system is OS-9, a real time multitasking operating system that you can fit in your head. There is an open source version called NitrOS-9 [nitros9.org] which has excellent documentation and most of the code well commented. It runs on 6809 based computers like the Tandy Color Computer and the Tano Dragon.
You can learn a tremendous amount about process scheduling, IPC, memory management, device drivers and low level I/O, etc from playing with this system.
Comment removed (Score:3, Interesting)
Re: (Score:2)
Yeah, because drivers and kernels are perfect and never have bugs.
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)
Re: (Score:2)
Probably, but the Basic was written by Microsoft, and the ROM took 16 Kb (not counting the code when using a disk-drive).
Since an opcode is between 1 and 3 bytes, there would be around 8000 to 10000 LoC.
Re: (Score:2)
Re: (Score:2)
well I was just thinking about applesoft... it occupied $B600-FFFF iiirc, about 18k. DOS for the floppy took just above the card rom all the way up to that, which was what, $D000-$B5FF, about another 12k.
I had a sourced copy of both somewhere around here. Was fun to be able to recompile your BASIC or DOS. (ty BB) People today with their kernel recompiles have no idea they're not the only ones doing that sort of thing.
Re: (Score:3, Insightful)
We're using "yesterday's terminology" here. For the purposes of computer app size, LoC is Lines of Code, not Libraries of Congress.
Re:Invert rose-tinted-glasses (Score:4, Insightful)
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.
Re: (Score:2)
FTFY.
Yes, I know it's harder, but it's the Right Way(TM), in my humble opinion.
Re: (Score:2)
FTFY.
Yes, I know it's harder, but it's the Right Way(TM), in my humble opinion.
I didn't think the official Python implementation had a JIT compiler.
Re: (Score:2)
Who said you needed to use the official Python implementation?
Re: (Score:2)
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.
Instead of going through the expensive and painful process of rewriting parts of your application in a more efficient manner, you could also just through more machines in your server rack and be done with it. Adding/upgrading servers if often a lot cheaper than optimizing your code, and also introduces less new bugs.
Re:Invert rose-tinted-glasses (Score:4, Insightful)
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!
Re: (Score:3, Interesting)
Absolutely. This is the point of, for example, the STEPS project at VPRI, which aims to build an entire working system (kernel, GUI, dev tools, apps) in under 20,000 lines of code. Some of the stuff they've produced, like OMeta and COLA are really impressive.
Adding complexity to a system is easy. Adding features without increasing the complexity is much harder, but much more useful and rewarding.
Re: (Score:2)
Re: (Score:2)
Even in those days I am sure there were lusers happily doing their jobs on a VT100 or similar terminal. Starting with a menu or simple command set was not so different from a GUI today.
Re: (Score:3, Interesting)
Re: (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.
Re:Totally outdated... (Score:5, Funny)
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.
Re: (Score:2, Funny)
Th C=64 was the first computer I owned that I diden't build from scratch AND it had a disk operating system such as it was... Those were good times.
I still have the hesware 46 forth cartridge for the 64.
(I came across it recently in a box full of old junk, manual too.)
I used to love forth but write only languages are such a pain even for the original developer.
I cant imagine trying to maintain someone elses forth code.
Machine code was so much easier.
Anyway, I salute you Tom Zimmer, wherever you are.
Wow that
Re: (Score:2)
Th C=64 was the first computer I owned that I didn't build from scratch AND it had a disk operating system such as it was... Those were good times.
My first was a VIC-20, hardware-hacked from an article in 73 magazine to fill in the 'missing' chunk of memory. Hacked a few games and wrote a bunch of BASIC stuff. It served faithfully for RTTY and slow-scan TV and a second VIC20 controlled a Yaesu FT-757 transceiver including pre-programmed 10M FM repeater splits. Never did 'upgrade' to the C64.
Re:Totally outdated... (Score:4, Funny)
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.
Re:Totally outdated... (Score:5, Insightful)
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.
Web Server / App Farm (Score:5, Funny)
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.
Re: (Score:2)
Re: (Score:2)
The lady doth protest too much, methinks.