Close

20230215a -- Keyboard and ISR

A project log for ROM Disassembly - AlphaSmart Pro

Wherein I disassemble the ROM from a vintage typewriter-thing

ziggurat29ziggurat29 02/18/2023 at 17:364 Comments

I had previously thought that ISRs are not materially used, but this turns out to not be strictly true.  It is true that most of the ISRs are stubs, but while chasing down all the 8000/C000 references, I found a reference in the maskable interrupt service routine:

E521             isrIRQ_E521:
E521 86 FF           ldaa    #$FF
E523 B7 80 00        staa    $8000  ; set all kbd (high) cols high (inactive)
E526 B7 C0 00        staa    $C000  ; set all kbd (low) cols high (inactive)
E529 3B              rti

Knowing (well, believing at any rate) that 8000/C000 are the keyboard column latches, and in the context of this code:

E406             sub_E406:
E406 14 21 02        bset    TCTL2_21 2      ; TCL2; Edge3 falling edge
E409 14 23 01        bset    TFLG1_23 1      ; TFLG1; IC3 enable
E40C 07              tpa
E40D 84 7F           anda    #$7F            ; clear the 'stop disable' flag
E40F 06              tap
E410 7F 80 00        clr     $8000           ; drive all kbd columns low
E413 7F C0 00        clr     $C000           ; drive all kbd columns low
E416 0E              cli                     ; enable interrupts
E417 CF              stop                    ; place system in low-power mode; waiting for interrupt
E418 01              nop                     ; (can't fiddle with mask bit yet)
E419 0F              sei                     ; disable interrupts for processing
E41A 39              rts                     ; get to it!

It seems that the design is to drive all columns low (normally only one is low at any time during scanning), enable interrupts, then issue a STOP to halt the processor and put it in low power mode.  An interrupt will rouse it from sleep, service the interrupt (and raising all the keyboard columns) and resume processing.  Resuming means disabling interrupts and carrying on until such time as there is nothing left to do, then returning to this code to park the processor.

Not exactly interrupt-driven keyboard support, but interrupt assisted.  OK, so what is providing the interrupt?  My educated guess is the 7430 8-input NAND gate.  (You can see it in the top board picture just above the keyboard connector with the row (alternatively column!) connector:

Recall from a prior post that the keyboard seems to be a garden-variety matrix design, with 16 columns driven by a pair of 74574 octal D, and 8 rows read by a 74573 with pullups.  Also these 8 rows feed into a 7430 8-in NAND.  So, if /any/ key is down in the selected column ('selected' means a 0 bit on the column line), then one of the row lines will be low, and the NAND will go high.  So the 7430 serves as 'there is some key pressed'.  And in the context of the sub_E406 setting 8000 and C000 all low (activating all columns) would make any key whatsoever cause a 'keydown detect'.  Such a notional 'any keydown detect' causing an interrupt would wake the system, service the interrupt, raising the column lines high, and proceeding with the main loop, which would then perform a proper keyboard scan, dispatching handling as appropriate.  So I think we've figured out the main system architecture.

If you examine that closeup, you'll see that pin 8 of the 7430 -- the output pin -- is on the component layer, and you can trace it around in [Eric]'s@EricHertz photo until it tantalizingly disappears between pins 21 and 22 of the CPU, never to be seen again.

*sigh*.  Well, there's other flies in this ointment of a theory, anyway, because the /IRQ lines is active low (or falling edge).  The logic of the 7430 as keydown detector is effectively active high.  So there would need to be some inversion somewhere.  But in the absence of physics, we have philosophy, so I'm holding on to this hypothesis.  There's a 7404 inverter nearby (though out-of-the-way for that trace), and a curious transistor looking thing right next to the /IRQ line.  If it were a transistor, it could invert.  However there are no resistors nearby as would be expected, and moreover the silkscreen indicates 'LV1'.  'Q' is typically used for transistors (and indeed there is a transistor on the other side of the CPU so marked, replete with resistors).  So I think this is some other kind of device.  It's also next to the /RESET line, so this line of inquiry could be a red herring.

Welp, for now we'll file this mystery away with all the others and motor on.

Discussions

Eric Hertz wrote 02/20/2023 at 01:50 point

LOL

just as I decide to get out the beeper, you solve that riddle almost conclusively and discover another.

I have been trying to think of a way to "highlight" the bits wherein a beepout-question is raised, a bit of note-taking, (and a subsequent strikethrough if resolved in a later log). It might come down to my printing all your logs and keeping them with the machine. Why not?

Interesting about the key-interrupts. It certainly would be a good way to save power if the CPU basically halts after processing each key. That's one idea I'd kinda pondered in another project, but couldn't really figure how the matrix could be scanned to create such an interrupt for ["Where's the"] Any key. Nice sleuthing with the 8in NAND.

We'll see what the next logs say, then maybe I'll [set up the printer and] grab the beeper, if you haven't solved this mystery already!

  Are you sure? yes | no

ziggurat29 wrote 02/20/2023 at 14:20 point

lol; I have a couple days backlog to edit and post.  I'm nearing the end of hardware extrapolation from the software side. One of these pending posts is an update of hardware-so-far.
Physical validation of my extrapolation is definitely welcome.
Mysteries that remain are:
* keyboard emulation jacks.  I presently think PDb0 double-duties as clk, and PAb0 might be related, but I'm not really deep in that section of the code yet.
* the '138 is not critical to figure out, and I can only do so much from the software only perspective, but I'd like to know how its inputs are connected to the address bus and where the outputs go. I've worked out a couple plausible answers, but I can't disambiguate working from the code alone.
*  keyboard matrix! the software uses scan codes natively, so it's tricky for me to puzzle out the matrix yet.  I found a couple mappings by correlating to known menu choices (e.g. '1,2,3,4,y/n') but not enough to figure out the full matrix yet.  But translation has to be in there at least for the alphanumerics to convert to ascii.  In an earlier post I mention having seen a table that looked like a candidate, but I have found no references to that yet!
Buzzing out the keyboard matrix is certainly doable, but seems like a really arduous chore being as it is 16x8.
One kooky idea I had was to write a custom firmware that simply emits the key scan code over the PS/2 port.  This notional firmware would present on the screen 'press XXX', you press it, and then it squirts out 'XXX = yyy' via keyboard emulation, and you just go through the whole keyboard that way, left-to-right, top-to-bottom.  Don't know if you have an 2732 eprom, eraser, and programmer on hand....

  Are you sure? yes | no

Eric Hertz wrote 02/20/2023 at 19:24 point

Mwahahahaha! Discussion has led to custom firmware! I knew it would, eventually...

But i mean, if you're already using the LCD, then why send the result to the PS2 port? Oh, maybe for logging? 

I'm OK with pen and paper if it's easiest... then there's no issues with, e.g. a certain row/col combination doesn't cross causing the system to wait forever, or e.g. custom/meta-keys not getting considered.

But I dunno about beeping them all by hand. This is a bit of a recurring problem (e.g. a bunch of old laptop keybs I have waiting for projects, or maybe even an intermediate remapper circuit to use one of those in place of this one's beat-up keyb). 

Maybe I'll ponder that a bit, while beeping-out the others in the list.

I'd be OK with Press keys left-to-right, top to bottom, write-down some hex-value on lcd for each. But if you've got another idea or already got a test-program to send, by all means! 

I'll get to some beeping.

  Are you sure? yes | no

ziggurat29 wrote 02/20/2023 at 20:01 point

lol; yes, custom firmware. What's the fun in a toy but to make it dance to a tune it's never heard?  I don't think the SDCC supports the 6811 directly, but I think the '11 is supposed to be object code compatible with the '08 which to wit is supported.

Yes, the thought was to use the device as intended, and have a text editor open on the PC, thus logging all the collected data, and then I can subsequently machine-process that data into a sane row/col matrix.

Your alternative of just showing on the screen the scan code and then your manually writing it down also works, though seemed to still be a bunch of manual labor, but easier firmware to cook up.

getcha sum ABS compatible lube and fix those sticky keys!

  Are you sure? yes | no