Cool article that goes into a little depth on the humble, handy 6526. The 6510 and 6581(SID) always win the popularity contests, and there's a lot of ink spilled over them, but it's nice to deep dive on the other very interesting parts of the C64!
I'm always amazed how fewer and fewer "computer science" graduates every year have ever wire-wrapped a simple 68000 computer from scratch, hooked it up to RAM, ports, a bunch of LEDs for output and so on. Or even an already-wired microcontroller. Fewer and fewer computer professionals really know how these things work and have made them work by their own hands. Maybe the Raspberry Pi has re-kindled some of this interest, but I wonder how many people use it as just a cool-looking tiny PC and how many actually play with the GPIOs.
I'm a professor at a R1 university in the CS dept. I wire-wrapped a PDP-8 in school as part of a CS degree, and thought it was super-interesting and fun, and part of me agrees with you.
But the reality is that you can only cram so much into a 4-year degree and wire-wrapping a 68000 seems like it would take many hours. I already feel like there is so much that we are leaving out. For example, our undergrads don't implement a compiler as part of their degree.
*EDIT: Also, it's arguably more computer engineering than computer science, but the my main point is that the undergrad CS curriculum is already super-crowded.
The mention of no compiler I'm surprised at. We worked with a microcode simulator for low level CPU poking examples, partially implemented a pre-written compiler as part of our Computer Science course, likewise wrote a DNS server (these are parts just from memory I as an undergrad found challenging).
We also learnt more useless things with databases like aligning writes with HDD sectors for performance (which at the time I, and others, rolled our eyes at since we knew we'd never need it, although not because of SSDs, but how many people write a database?).
This was a 3 year course at a "red brick" university ~1997-2000 in the UK but by no means one of the best for technology - e.g. the lead of the department, and by extension those under him, refused to teach design patterns (or enterprise patterns).
When I asked why of 2 professors and laid out (what I thought was) factual grounding I was told because patterns are for Java or C++ and language specific (which as you probably know is BS, only implementations are, or patterns that work around a language deficit). I later learned they took this as personal criticism, instead of course criticism.
Offtopic:
I'm still salty 25 years later about being given bad grades for things such as that (i.e. first and 2:1 grades for some coursework, thirds, passes and fails in others usually those I happened to argue in even though marking was meant to be anonymous).
I now have an illustrious career in IT, open source and competitive coding (having won my fair share).
Tldr; I learnt don't argue with people who grade you in a polarised institution until you get the qualification. I wish I could have told myself that at 19.
We have had a compiler elective before, but it was never required, and currently we don't offer it. I don't think there is a lot of demand from students for it, for better or worse. We also don't do networking fundamentals as a requirement, like sliding window protocol, CSMA/CD, how routing works, etc., but we do have an elective that I believe covers these things.
We do require architecture, and still even do Karnaugh maps. I do believe that every CS person should have a fundamental understanding of cache, instruction fetch, decode, MESI, etc., but probably don't need a semester's worth of architecture. If I had my druthers, I would consolidate a number of separate courses into maybe a 2-semester sequence that would basically be: "What every computer scientist should know", and basically cover the coolest and most seminal topics from different areas of CS.
In college, we had to wire wrap an 8-bit (6809) CPU with an EPROM and UART to connect a terminal. It looked nothing like your image. A 16 bit address bus, 8 bit data and only RAM/ROM/UART sharing the "bus" meant that the wiring was actually quite neat and it was transparent what wires were doing what. Inevitably, part of the work involved diagnosing poor wraps which would clearly be impossible with that pile of spaghetti in your image. It was one of the most fun projects we had in the 4 years. I thought it very valuable as it brought software (writing a simple monitor using a cross-compiler) and hardware together.
There are plenty of computer science, not engineering, programs that still have required classes that involve wire wrapping a uc and building something. It is less common as the voracious appetite of the web and web related industry for cs grads caused curriculum to become increasingly geared towards meeting that need. I still find it astounding how much software is required to keep all rhe websites I use running. It doesn't make sense to me, but I know very little about how that sort of software works, so I will simply trust that some of the largest companies in the world wouldn't be paying for it if there was an easier way.
This was a really great and well-explained article. For an article that went deep into hardware internals, it somehow made it all make perfect sense. Kudos to the writer.
It’s pretty fascinating just how “dumb” the keyboard is and how keyboard input is actually being polled. It seems like this could easily lead to missed key presses or slow response, but I don’t recall the C64 keyboard suffering from either of these things. (It’s been some years since I last used a real C64 though.)
Yet, somehow on an exponentially more powerful and capable modern computer it seems that things like instant input response and no missed key presses is somehow asking for a lot.
> somehow on an exponentially more powerful and capable modern computer it seems that things like instant input response and no missed key presses is somehow asking for a lot
I would guess there's still an 8bit CPU polling the keyboard matrix, only inside the now separate keyboard. That being the first layer, it can only get slower as it traverses all the other, new layers.
> it can only get slower as it traverses all the other, new layers
We can easily budget a million cycles across those extra layers and it's still, like, a millisecond. It's not the harsh reality of layering that makes it slower, it's problems with the ways specific layers are designed.
Amiga keyboards (at least some) in fact had a SOC version of the 6502 (with a small PROM and small amount of RAM onboard) controlling them already in the 1980s.
>"The C64's keyboard, by comparison, is absolutely dumb. It has no electronics at all. Just switches in an 8x8 matrix. The actual matrix switches themselves are fed down the keyboard cable and into the computer. And the C64's own CPU needs to spend precious time scanning the matrix."
While "unfortunate" from the perspective that a C64 requires some of its CPU time to actively scan/poll the keyboard -- it also is quite possibly one of the simplest (simple = positive, beneficial, educational, etc.) keyboard designs that could exist for a microcomputer (and for that reason, educationally valuable!) perhaps only short of a "dumb" keyboard connected to an RS-232 interface...
This is also what enables nearly latency-free keyboard response at 60Hz polling, something most modern implementations can only dream of. (The latency of modern keyboard communications is also an issue with emulation.)
BTW, this architecture really goes back to the PET 2001 (1977), which even comes with a detailed keyboard matrix diagram in the manual.
Commodore does a good job there (just before and after the diagram) of selling the advantages and disadvantages:
> Until that key is released, no other keyboard scans are acknowledged unless a later scanned key is struck. The later scanned key is then considered to be the next key closure. The algorithm does not give classical N key roll over but does allow for legitimate rejection of noise and trapping of the keys in the order that they are struck.
> The keyboard is left scanning the last row, which contains the stop key. This allows the routine in BASIC, that checks for the stop key to sample the input I/O device, without having to perform any of the normal functions of scanning. The user can take advantage of this by reading the input character for that row.
I had a C64 in Iran when I was 12. After a few years, a column of keys on the keyboard stopped working. So, every time I turned it back on, my first task was to remap some critical keys to the function row keys.
Back in the day I added a D25 female connector to the side of my C64, wired up a 3.5 octave keyboard (which I built for the 'Formant' [1] synthesizer I made while in high school) with a diode matrix [2]. Made some programs to make it easy to access SID 'patches' and voila, I had a 3-voice polyphonic synthesizer. It surely beat the way I used the C64 before that, the thing lying on the stage as if it were an effect pedal with me playing some pre-programmed notes with my toes. I still have the stuff around somewhere, the keyboard looks quite snazzy in its triangular Meranti multiplex housing with the shoulder strap. I could play it on stage but could of course not move far from the machine since the cable was only 3 m long...
[2] which I more or less 'invented' myself after I found out I could not play chords without adding diodes since a single key press would light up a whole column of keys... it was only later I found out this is the canonical way to do this.
The 6526 (CIA) was the first chip I could fix by replacing the broken one to another functioning one. Those CIAs are at high risks, because they are directly connected to the 2 joystick ports of the C64. You just need to touch some pins at the port and you probably grill your CIA with static electricity.
Unfortunatly the CIAs getting rarer and rarer, because the cannot reproduced by FMPGs until today, so you need to get a space CIA from another machine. Maybe in the future this will work with replications.
One thing that people do to break the first CIA chip is to connect a gamepad from a Sega Master System or for the Mega Drive/Genesis.
They work fine on other systems that accept "Atari-compatible" joysticks, such as the Atari VCS, Atari 8-bit, Amiga, etc. so you'd think they'd work fine here too, but no.
Sega had put the pull-up resistors in the controller instead of on the motherboard, thus providing positive current on each input pins when a button/direction is not pressed. But for the C64, the inputs are supposed to be disconnected when not active, and when CIA #1 is reading the keyboard, the extra current could overload the chip.
You could make an adaptor though with a diode on each input line. (The adaptor should also route Vcc to pin 5 which is Sega's Vcc pin)
Recently an entire C64 was built from scratch using modern parts, I think there were some FPGAs involved. It's unfortunate that the design is so brittle (maybe good idea to mod a protective shutter), but I wouldn't worry about future repairability.
Also TIL that C64OS is a thing. Maybe C64 is the design we should be looking into when considering permacomputing.
https://news.ycombinator.com/item?id=34389496
Hey, if you referring to this video, I made a comment there that the CIAs are straight out of the eighties. It was a little bit clickbait. The C64 was build from scratch, but not all parts were freshly made.
Absolutely the C64 is a thing for permacomputing, haha.
I'm always amazed how fewer and fewer "computer science" graduates every year have ever wire-wrapped a simple 68000 computer from scratch, hooked it up to RAM, ports, a bunch of LEDs for output and so on. Or even an already-wired microcontroller. Fewer and fewer computer professionals really know how these things work and have made them work by their own hands. Maybe the Raspberry Pi has re-kindled some of this interest, but I wonder how many people use it as just a cool-looking tiny PC and how many actually play with the GPIOs.