Some Research Over the Keyboard Issues on Hang Shift for Keyb sp

[jordi]

I reused a code from stackoverflow and all I get is a hang trying to return from the interrupt, printing the following:

198712617-16c50d4c-e940-4c3d-a7d6-5ec6e44dc546.jpeg (191.53 KiB) Viewed 788 times

This is the code and the compiled .exe I reused: https://github.com/MiSTer-devel/PCXT_Mi ... 6/KEY2.zip

It's like not returning properly from interrupt in the:
out 20h, 20h

which in C is: outp(0x20, 0x20);

Expected behaviour (Dosbox execution):
https://user-images.githubusercontent.c ... 520728.mov

Does the code is ok? it looks like

[jordi]

Microcorelabs, might this be an issue?

[kitune-san]

The PCXT should output a pulse from port B of 8255 after reading the key code.
Otherwise, the next key code reading will not be started.
In KEY2.c, apparently it is not done.

A possible countermeasure would be to trigger the reading of port A to start reading the next key code.
However, this would not be the correct behavior of PCXT.

[spark2k06]

This application also hangs on 86Box/PCem with the IBM PC machine (1982), for example..., it is not useful for testing.

And forget DOSBOX for testing, either use real machines or the best alternative is PCem/86Box, on a machine like Tandy 1000 or IBM PC from 1982.

[spark2k06]

What happens with KEYB SP is simply that it doesn't seem to detect the modifier key release, but it only happens with modifier keys (CTRL, SHIFT, ALT...), normal keys are detected fine. However, with SignalTap I have been able to observe that the core is sending the release of all keys, including the modifier keys... I'm still investigating the cause, meanwhile, if you think of anything, @kitune-san...

[kitune-san]

I am just wondering about the following points:
- What is the instruction that identifies the break bit?
- What instruction resets the Shift, Alt key flag?

[spark2k06]

I am just wondering about the following points:
- What is the instruction that identifies the break bit?
- What instruction resets the Shift, Alt key flag?

I am sending you a private message to provide you with the keyb source code. Let's discuss it...

[spark2k06]

Investigating further together with kitune-san, we have located the bug, which is in the MCL86 core:

MCL86:

20221029_091616-screen.png (180.38 KiB) Viewed 1461 times

PCem/86Box:

Monitor_1_20221029-091708-943943.png (6.18 KiB) Viewed 1461 times

@MicroCoreLabs, could you check MCL86? It seems to fail to do an NOT AH when the previous CMP has previously set the carry flag.

Thank you kitune-san for noticing this detail.

[kitune-san]

Maybe they are clearing the flag here.

2022-10-29 175450.png (39.43 KiB) Viewed 1420 times

[kitune-san]

Maybe they are clearing the flag here.

2022-10-29 175450.png

This line has been changed to NOP.
https://github.com/kitune-san/PCXT_MiST ... 420001e0cd

[Mills]

Maybe they are clearing the flag here.

2022-10-29 175450.png

This line has been changed to NOP.
https://github.com/kitune-san/PCXT_MiST ... 420001e0cd

It seems to work well. I tested Spanish keyboard:

20221029_094433-screen.png (57.98 KiB) Viewed 1384 times

[MicroCoreLabs]

Yes, the NOT opcode should not affect any flags, but I am clearing them in the common 0xF6 code. Your NOP fix may be the best fix, but let me investigate to make sure this solution will not affect other 0xF6 opcodes. Thanks!

[MicroCoreLabs]

Yes, it looks like changing that line of microcode to a NOP is the best fix.

I verified that each 0xF6 opcode sets the Carry and Overflow flags independently so there is no need to pre-zero them when the 0xF6 opcode is recognized. The mistake was when a microcode operation is shared between opcodes I tried to perform it just once to save the microcode memory space, which in this case was incorrect.

[spark2k06]

Yes, it looks like changing that line of microcode to a NOP is the best fix.

I verified that each 0xF6 opcode sets the Carry and Overflow flags independently so there is no need to pre-zero them when the 0xF6 opcode is recognized. The mistake was when a microcode operation is shared between opcodes I tried to perform it just once to save the microcode memory space, which in this case was incorrect.

Thank you! This solution will be available in the next release.

[kitune-san]

Yes, it looks like changing that line of microcode to a NOP is the best fix.

I verified that each 0xF6 opcode sets the Carry and Overflow flags independently so there is no need to pre-zero them when the 0xF6 opcode is recognized. The mistake was when a microcode operation is shared between opcodes I tried to perform it just once to save the microcode memory space, which in this case was incorrect.

The TEST instruction in group 6 (0xF6) does not seem to clear OF and CF.
I think the microcode may need to be modified.

[kitune-san]

Sorry. That was my misunderstanding.

[jordi]

Sorry. That was my misunderstanding.

No sorries, we would not have this core without you!