How the C64 Keyboard Works (2017)
c64os.com
c64os.com
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.
perhaps this might explain why it is no longer popular:
https://en.wikipedia.org/wiki/Wire_wrap#/media/File:Computer...
and that's for an 8-bit cpu. i can't imagine wire-wrapping a 68000.
also, this would be computer engineering, not computer science.
I understand this as assembling a computer from its basic components using wire wrapping, not the CPU.
68000 is also the transistor count of the 68000 so I agree that it's infeasible for a student project.
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.
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 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.
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.
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.
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.
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...
Anyway, great article!
BTW, this architecture really goes back to the PET 2001 (1977), which even comes with a detailed keyboard matrix diagram in the manual.
[0] https://www.masswerk.at/pet/manuals/PET_User_Manual_(2001-8)... (p 12)
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.
[1] https://sdiy.info/wiki/Elektor_Formant
[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.
Also TIL that C64OS is a thing. Maybe C64 is the design we should be looking into when considering permacomputing.
Absolutely the C64 is a thing for permacomputing, haha.
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)
NM: https://twitter.com/gregnacu/status/1632080241316225027
What about restore?