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.
discuss the archimedes & risc pc, peripherals and risc os/risc os on pi
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.
Puzzling, because it does look like the keyboard is rejecting a valid normal reset sequence (responding with &FF to the &20 read ID request).IanJeffray wrote: ↑Thu Nov 25, 2021 10:39 pmOk, 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.
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:
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!
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
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 !