Hi,

It seems something is odd with row 8 of the keyboard, the one with the cursorkeys and the space-bar.
The odd thing is that altough it is constantly checked by the msx bios, it only occasionally (very seldom) is processed. E.g. spacebar and the other keys don't work.
Does this row need some special handling?


-- http://www.vanheusden.com/msx-emul/

which is the model of your MSX ?

an emulated one but let's say a philips msx1 vg8020

I tried 3 versions of msx basic 1:

folkert@debianfvhbps:~/Desktop/msx$ md5sum msxbiosbasic.rom
175678a08f199385828930a79e604bef msxbiosbasic.rom

folkert@debianfvhbps:~/Desktop/msx$ md5sum docs/vg8020*
364a1a579fe5cb8dba54519bcfcdac0d docs/vg8020-20_basic-bios1.rom
a0452dbf5ace7d2e49d0a8029efed09a docs/vg8020_basic-bios1.rom

So, find out what it's caused by, it could be anything from a simple bug in your keyboard handler, up to a minor Z80 emulation inaccuracy.

I was hoping this was common problem noticed more often.
Well, I need to go back to the source then.
thanks anyway

Have fun
How about giving your emu a proper name? like "MSX maar niet heus"

Nah, it is most definately a working msx emulator. Just not finished yet

I think the bios is checking row 8 often so that
ON STRIG(0) GOSUB nnn
can work in basic.
Are keys on row 8 really processed less often than keys on other rows?

Quote:

Nah, it is most definately a working msx emulator. Just not finished yet

Yes yes, what I mean is (aside the surname pun) that's it's not an MSX but an emulator, like Randilyn having named her NES emulator FakeNES.
Found the cause to the problem yet?

The detection of key presses is very simply.....

The Bios, has in RAM two mirrors of the keyboard's matrix

first, reads all rows of the keyboard in an ram area... just 12 bytes IIRC

then, using both mirrors the bios runs a routine to detect when a key changes from 0 (pressed) to 1 (unpressed), then WITH the matrix coordinates it looks up in a JUMP table, so, some keys will be processed as ASCII key, so it jump to a routine that generates the correct ASCII value that takes in account ACCENT flags, shift, control, etc etc .... then with the ASCII value it is sent to the keyb buffer.

The cursors also are ASCII keys that generate, ASCII codes from 28 to 31, that makes the cursor movement in shell.

BUT, ON STRIG, ON STICK(0) , STICK, STRIG, PDL, GAMING, uses other bios routines that accesses directly to keyboard matrix to determine the actual status. That triggers when the KEY status is CERO.

The stick function, looks up a table, of 16 bytes, that return CERO movements, when the opposite directions are pressed at same time, like pressing RIGHT & LEFT will do nothing.

The REPEATING of the ASCII keyb, is done using a only one variable that do the timming, when both mirros in ram are not identical, the timer is reseted to a waiting value, and that variable is counting down each interrupt... until do 2 things... 1) a the mirrors are differents, so the variable is reseted again (like you pressing or depressing keys), or that the timing variable reaches ZERO, when thats happens, the new mirror is filled with 1111111111111111111 forcing to understand that you DEPRESSED all keys, when is done that, the timing variable is reseted BUT with a little count down... so, for the first repeating there is a timing like 1/2 second, and for each next repetition is ¿maybe 1/5 second?..

Keep in mind that keyboard is scanned every INT by BIOS and cursor keys and space are scanned by STICK functions, also.
Maybe you should refresh keyboard in every INT (as a point of start for your emu)

Strange thing is that the keys in row 0-7 do work.
I see it scan row 8 as well.
Funny thing is that in athletic land it all works, but not in basic, msx dos, nemesis 2 or the goonies.
Debugging shows the exact same behaviour by my keyboard emulation.

rewrote the whole thing. no longer buffering keypresses and feeding them then to the emulated msx, now I check for a key when the msx wants to check

works only in msx basic, msx dos 1 and athletic land (so that is better than the previous situation where those keys did not work at all)

debugging of msx basic:

key down: | | here the emulator sees that I pressed a key down
checked row 8: 254 here the emulated msx sees that bit 0 of row 8 is set to 'key pressed'
checked row 8: 254
checked row 8: 254
checked row 8: 254
checked row 8: 254
checked row 8: 254
checked row 8: 254
checked row 8: 254
checked row 8: 254
checked row 8: 254
checked row 8: 254
checked row 8: 254
checked row 8: 254 (takes a while before i lift my finger: 0,3 seconds for a keypress)
checked row 8: 254
key up: | | and here i lift my finger

so this works for the ones i mentioned, not for the others. very very weird

debugging of nemesis 2:
key down: | |
checked row 8: 254
...
checked row 8: 254 <- repeat 26 times (0,32s)
key up: | |

same output. weird isn't it?
it's not that I press the key not long enough.

well, take en account that the PC keyboard works with event at protocol layer...
So at that layer, you get KEY DOWN and KEY UP..... events.

So if you want to know what key is pressed you need to get all EVENTS and to maintain a virtual key matrix... to show what is being holded pressing and what key NOT.

But take in account that KEYs AT PC keyboards that makes that your emulator LOSSES the FOCUS , you will not RECEIVE a KEY UP event, you just will receive a KEY DOWN event before your application losses the FOCUS, and the KEY UP event will goes to the TASK MANAGEr or something.

So, handling loosing the focus of the PC application is needed on that event, that to FILL with 1111111 the msx MATRIX.

Also take in account the ghosting problem that also PC keyboard has....

Yes, I've fixed all of that. The only problem is that altough when the msx asks if any key on row 8 is pressed and I tell it that that is the case, that then the msx ignores this.