0
\$\begingroup\$

I'm designing a computer using a Z80 processor (I know, not the same as the one the C64 used, it doesn't matter)

I found the following schematic showing part of the C64 circuit, and I'm particularly interested in the keyboard section on the right, attached to the MOS6525 chip. I understand in theory how keyboard like this work (i.e. scan the columns, and read each row to determine which keys are pressed.)

As I said, I understand this, but I'm confused onto how this is implemented in the software. Does the C64 constantly poll the keyboard? Because, I would've assumed there'd be some sort of secondary controller to do this scanning. How would the C64 have enough time to do other things such as running programs, if it's spending so much time polling the keyboard? (and also drawing the screen, and polling joysticks, for that matter?)

Is it all down to the kernel? Does the kernel say something like "poll the keyboard, then poll the joysticks, then run a couple instructions of a program, then repeat"?

\$\endgroup\$
2
  • 1
    \$\begingroup\$ FYI, for the future, questions like this may get more answers on Retrocomputing Stackexchange. \$\endgroup\$
    – The Photon
    Commented Mar 3, 2019 at 0:16
  • \$\begingroup\$ @ThePhoton thank you, that is very useful, I think that'd apply to a lot of my questions here, in fact. \$\endgroup\$ Commented Mar 3, 2019 at 0:16

3 Answers 3

4
\$\begingroup\$

Does the C64 constantly poll the keyboard?

My experience is with the TRS-80, but yes, the main processor typically did the keyboard scan. No such thing as a secondary processor -- remember that the first 8-bit microprocessors hit the market priced at several hundred dollars for a device in a 40-pin DIP. Even when the price dropped, the price of the CPU was a pretty big fraction of the computer's price.

How would the C64 have enough time to do other things such as running programs, if it's spending so much time polling the keyboard? (and also drawing the screen, and polling joysticks, for that matter?)

By doing everything very slowly, by today's standard.

Is it all down to the kernel? Does the kernel say something like "poll the keyboard, then poll the joysticks, then run a couple instructions of a program, then repeat"?

Either that, or the keyboard scan only happened when the user program asked for one.

"kernal" is actually a pretty grandiose term to apply to the operating systems of the day. There wasn't a concept of an OS that would share time between applications. Even DOS running in an IBM PC didn't have a 'kernel' per se -- at best it had a few TSRs running in the background, but there was nothing like a concept of having two user-space programs running simultaneously. Basically, whatever you were running owned the entire machine, and the only thing the OS (such as it was) did was take over for scanning the keyboard or accessing disks (if you had them) or whatever.

\$\endgroup\$
3
  • \$\begingroup\$ actually I was just thinking, if the processor operates slowly to control everything, is that also true with a monitor output, such as composite or VGA? Since they need very fast signals to display properly \$\endgroup\$ Commented Mar 3, 2019 at 0:08
  • 1
    \$\begingroup\$ It's worth noting that even though CPUs of the day were slow by today's standards, they were still very fast by human standards. Polling the keyboard doesn't take many instruction cycles and barely slows down the rest of the program execution. A million clock cycles per second is a lot of instructions. Even the humble ZX81 was able to comfortably poll the keyboard despite the CPU spending most of its time just generating the display (there was no video chip to do that). \$\endgroup\$
    – Ian Bland
    Commented Mar 3, 2019 at 0:33
  • 1
    \$\begingroup\$ It is worth also noting that "machines of the day" didn't have bloatware as modern "object-oriented" systems do, where nearly every line or data structure ends with ASCII string "Microsoft" and every call parces over 100-level of SW hierarchy. Early PDP-11 machines had a bootloader (nearly a BIOS) that had an ability to serve alphanumeric terminal, accept commands from a keyboard, and was able to boot an OS from 8 arbitrary floppy drives, 8 tapes, 8 network devices, 8 harddrives, and I don't remember what else. And all the code took only 256 Bytes of EPROM. 256 Bytes!!! \$\endgroup\$ Commented Mar 3, 2019 at 2:04
0
\$\begingroup\$

Both C64 and PC had video chips, so it is not the CPU that draws video - it is only writing data to frame buffer if something on screen has to change. C64 had VIC-2 video chip with sprites and PC had various video adapters (VGA mentioned being one) but no hardware sprites. So C64 CPU has time to poll/scan keyboard in timer interrupt.

\$\endgroup\$
0
\$\begingroup\$

The C64 has a timer interrupt (several in reality) and the function usually called by it was polling the keyboard.

But that did not matter for about 99% of all software, which accessed the hardware directly as needed. The ROM functions served as a crude manual bootloader mostly.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.