R260 - keyboard failure (and more?)

discuss the archimedes & risc pc, peripherals and risc os/risc os on pi
User avatar
IanJeffray
Posts: 1933
Joined: Sat Jun 06, 2020 3:50 pm
Location: Scotland
Contact:

Re: R260 - keyboard failure (and more?)

Post by IanJeffray »

timw wrote:
Tue Nov 23, 2021 11:52 pm
If the keyboard isn't detected then it won't see the Ctrl press, and a hard reset turns into a soft reset
I guess that makes perfect sense - particularly now it's doing the "No keyboard detected" thing on a reset now. I hadn't considered that CTRL would be polled on startup rather than when the reset button was pushed.
User avatar
IanJeffray
Posts: 1933
Joined: Sat Jun 06, 2020 3:50 pm
Location: Scotland
Contact:

Re: R260 - keyboard failure (and more?)

Post by IanJeffray »

Ok, here's a capture from clips on C79, C84 - the capacitors right at the keyboard connector. Obviously polarity is inverted via IC3, and I think I've got RX/TX the other way round here - but it all decodes cleanly and looks like a good signal both ways.
Kbfail_caps.png
timw
Posts: 53
Joined: Tue May 10, 2016 7:55 pm
Contact:

Re: R260 - keyboard failure (and more?)

Post by timw »

IanJeffray wrote:
Thu Nov 25, 2021 10:39 pm
Ok, here's a capture from clips on C79, C84 - the capacitors right at the keyboard connector. Obviously polarity is inverted via IC3, and I think I've got RX/TX the other way round here - but it all decodes cleanly and looks like a good signal both ways.

Kbfail_caps.png
Puzzling, because it does look like the keyboard is rejecting a valid normal reset sequence (responding with &FF to the &20 read ID request).

I was looking at the RO3.71 source as well, and there's a lot of RO2 code still in there, so I should think that RO3 is similar. It's quite a fun read - here's the loop to do the keyboard reset:

Code: Select all

fartaboutfornewkbd

kickthebastardagain
        MOV     R11, #HRDRESET
        BL      SendAndPollRxBit        ; get a byte to R11
        BL      PollTxBit
        CMP     R11, #HRDRESET
        BNE     kickthebastardagain
        MOV     R11, #RST1ACK
        BL      SendAndPollRxBit        ; get a byte to R11
        BL      PollTxBit
        CMP     R11, #RST1ACK
        BNE     kickthebastardagain
        MOV     R10, #RST2ACK
        B       send_ack_byte
After this loop, if the keyboard responds with RST2ACK (&FD) then RISC OS sends NACK (&30, which is valid according to the R200/A500 SM) and then &20 to request the ID. It might be useful to compare the timing with the working machine (I guess you've checked the tracks to the keyboard connector). One strange thing is why this is only a problem at reset!

The keyboard driver is also interesting reading:

Code: Select all

; Keyboard receive interrupt

; We now have to wait around for a period of 16 microseconds (or so they say)
; because the 'hardware engineers' can't design their hardware properly.

; This is doubly annoying because I have no idea what speed this processor is
; going at, so I don't know how many S-cycles this is, and there aren't enough
; hardware timers around to waste one doing this thankless task.

; In addition, because I am on the IRQ vector, the other IRQ users have
; probably wasted at least 16 microseconds anyway - at least the code seems
; to work perfectly well without this delay loop.

; Nevertheless, until the time Acorn can afford to employ some REAL
; hardware engineers, I shall do a delay of (about) 16*8 S-cycles,
; just to put their small minds at rest.

        MOV     R0, #16*8/5             ; delay for an unspecified period
IrqRxDelayLoop
        SUBS    R0, R0, #1              ; this breaks my heart,
        BNE     IrqRxDelayLoop          ; it really does !
Post Reply

Return to “32-bit acorn hardware”