Can you download again please - I updated the download in the last few muinutes

  matherp said  

Can you download again please - I updated the download in the last few muinutes

Of course, give me a second, I'll try it again with all keyboards!  

  matherp said  

On my USB keyboard, I only ever see duplication of the "H" character and when it is duplicated I get the nonsense code A010101010101 on the screen and it is this which causes the duplication.

Google does not suggest this is a generic error code but it is definitely the keyboard that is generating it.

Peter, see:
https://www.usb.org/sites/default/files/documents/hid1_11.pdf
Universal Serial Bus (USB)
Device Class Definition for Human Interface Devices (HID)
Firmware Specification—6/27/01

page 62 (72/97 in PDF) reads:
"The keyboard must report a phantom state indexing Usage(ErrorRollOver) in
all array fields whenever the number of keys pressed exceeds the Report
Count. The limit is six non-modifier keys when using the keyboard descriptor
in Appendix B. Additionally, a keyboard may report the phantom condition
when an invalid or unrecognizable combination of keys is pressed."

page 74 (84/97 in PDF) reads:
"- The Boot Keyboard shall report “Keyboard ErrorRollOver” in all array fields
when the number of non-modifier keys pressed exceeds the Report Count. The
limit is six non-modifier keys for a Boot Keyboard.
- The Boot Keyboard shall report “Keyboard ErrorRollOver” in all array fields
when combination of keys pressed cannot be accurately determined by the
device, such as ghost key or rollover errors."


the value for ErrorRollOver can be found in:
https://www.usb.org/sites/default/files/documents/hut1_12v2.pdf
Universal Serial Bus (USB)
HID Usage Tables
10/28/2004 Version 1.12

on page 53 (53/168 in PDF), table 12:


ie, 0x01 in each of the 6 array positions: "010101010101". hopefully this should help.


cheers,
rob   :-)


addendum:
if my reading of the documentations is right, there is NO order to the 6 slots. it is up to the host to figure out the order of keypresses by comparing one report to the next. see page 72 from the first PDF:

"The order of keycodes in array fields has no significance. Order determination
is done by the host software comparing the contents of the previous report to
the current report. If two or more keys are reported in one report, their order is
indeterminate. Keyboards may buffer events that would have otherwise
resulted in multiple event in a single report."
Edited 2025-07-08 00:36 by robert.rozee

Same problem, but to be sure I generated the MD5 checksum, so that you can compare the version:

Md5 Checksum online tool: https://emn178.github.io/online-tools/md5_checksum.html

It gives me "3971224a263653cd6881573a34df4d7a" for your file.

Here sadly the same problems, new image:

Please just run a single finger across vbnm as fast as possible - what happens?

  Quote  

"The order of keycodes in array fields has no significance. Order determination
is done by the host software comparing the contents of the previous report to
the current report. If two or more keys are reported in one report, their order is
indeterminate. Keyboards may buffer events that would have otherwise
resulted in multiple event in a single report."

This means if the first time two keys appear is in the same report there is no way the software can determine their order - what a crap I/F!

it is up to the host to poll the USB keyboard every 1ms and compare the previous report to the current one. from there the host builds up a map of what keys it believes are down and what are up. when the host sees the "010101010101" report it then (presumably) is expected to throw out the map it has previously built up and start afresh.


cheers,
rob   :-)
Edited 2025-07-08 00:53 by robert.rozee

Ok done.

With a single finger I wasn't able to produce any false chars or missing or swapped chars. Then I tried to write in my maximum speed in german and english (a bit slower), here I can't replicate any of the mentioned "problems". It only appears if there is rollover involved. And this (rollover?) problem with the group of "VBNM" starts really quickly, I must not type fast that the problem occurs. But what (for me counts) I wasn't able to re-create any of the mentioned problems with normal writing.

Before your fixes, I wasn't able to write the word "save" for example. Now with an english text and some keywords I tested, the problem isn't re-producable under normal circumstances. So for me, as said a few post ago, absolutly usable now. Although the problems persist under the mentioned circumstances, I think we have to live with that - which is fine because:

only a few people have those problems
and as it is now with the fixes, it is even for me highly unlikely that I run into problems again.

So I think further fixes will be just for sports (is it even called this way in english?)  


Edited 2025-07-08 01:00 by Amnesie

  Quote  

then (presumably) is expected to throw out the map and start afresh.

That doesn't work because as we have proved in an earlier test version it creates duplicates as a key can appear both before and after the error code.
Even with a 1mSec scan it is perfectly possible for two keys to be pressed and the order in the array ought to indicate their order but again, the evidence from the difference between Amnesie's keyboards and mine is that they seem to report in the opposite order.

Currently it seems like the last version last night is the best with the only issue that after a 0x010101010101 Amnesie sees a swapped pair of characters. I don't.

  matherp said  

Currently it seems like the last version last night is the best with the only issue that after a 0x010101010101 Amnesie sees a swapped pair of characters. I don't.

I have no clue about all of this, but I think the same. That is the best version.

To sum up:

- You fixed the missing chars (this was the worst problem!)
- the dublicate chars (was a bad problem, too)


Now there are still swapped chars and when typed really really fast with rollover there is a missing char again (latest firmware ONYL)

So yes, last night version was the best, under normal circumstances I see no way of having any problems with it.
Edited 2025-07-08 01:11 by Amnesie

if two keys are pressed down in the time interval between reports (ie, both within a 1ms period) then who is to say that one was pressed before the other? the clue is in the "H" of HID: human. a human can not determine the order of two events that occur within 1ms of each other, hence the time-ordering is irrelevant for any practical human-machine interface.


cheers,
rob   :-)
Edited 2025-07-08 01:11 by robert.rozee

  matherp said  

Currently it seems like the last version last night is the best with the only issue that after a 0x010101010101 Amnesie sees a swapped pair of characters. I don't.

I have no clue about all of this, but I think the same (only from testing). This is the best version.

To sum up:

- You fixed the missing chars (this was the worst problem!)
- the dublicate chars (was a bad problem, too)


Now there are still swapped chars and when typed really really fast with rollover there is a missing char again (latest firmware ONYL)

So yes, last night version was the best, under normal circumstances I see no way of having any problems with it.

My whole summary is: PS/2 is such a great thing for it's simplicity .. but I understand, we can not live in the past forever  
Edited 2025-07-08 02:11 by Amnesie

  robert.rozee said  

  matherp said  

"- The Boot Keyboard shall report “Keyboard ErrorRollOver” in all array fields
when the number of non-modifier keys pressed exceeds the Report Count. The
limit is six non-modifier keys for a Boot Keyboard.
- The Boot Keyboard shall report “Keyboard ErrorRollOver” in all array fields
when combination of keys pressed cannot be accurately determined by the
device, such as ghost key or rollover errors."

Hi Robert

I thought it was possible to allow NKRO with a custom report descriptor and the boot keyboard has the limitations to accommodate an easy interface for the Bios.

Myths about USB NKRO and how USB HID works

Cheers,
Steve

Link should probably be here

John

Once more unto the breach, dear friends

This is the Thursday lunchtime code with one tiny tweak. Assuming nothing untoward I intend to do a patch release of V6.00.02 with this change and a couple of other bugs fixes (PLAY SOUND n,R)


PicoMiteRP2350VGAUSBV6.00.02.zip