Ah, yes, thanks for the explanation! I am just thinking, it should be possible to 'autodetect' the matrix-to-key mappings by manually manipulating the value of the NEWKEY (#FBE5) matrix in the system RAM... If you reset the bits in the matrix one by one, and store the resulting ASCII codes in a table, right?
And oh, the ID in the BIOS ROM is probably only used what keyboard layout is presented to the user. This is useful, but in another way :). If you want to use the keys AWSD as a secondary control method (alternative to cursor keys for a 2nd player for example), it would be pretty useful to know whether the player is using a regular QWERTY keyboard or for example a French AZERTY one, in which case you should check for the keys QZSD instead. One more thing, I think that rows 6-10 of they keyboard matrix (which contain the function keys and the cursor keys - used a lot in games I would think) *are* pretty much the same on all the different kind of layouts. Can you confirm this, based on your findings?? This would certainly ease things up for applications not requiring text input (which is mostly the case). Thanks a lot, ~Grauw ----- Original Message ----- From: "Daniel Caetano" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, December 28, 2002 4:25 PM Subject: Re: [MSX] Re: How to converte keyboard matrix data to ASCII? > On Sat, 28 Dec 2002 00:38:10 +0100, Laurens Holst wrote: > > >Hi Daniel! > > Hi Laurens, > > >How did you solve the problem?? > >I am writing an article for the MSX Assembly Page right now, about the key > >matrices, and I am interested in how you proceeded. > > I proceeded the follwoing way: The game only enter in the keyboard interpreter > after check there are keys pressed. So, I clean the keyboard buffer and simulate > a chget, calling the functions: > > call 0d12h ; detect valid key transition and check buffer > call 0d4eh ; check if currently pressed key is valid > > and then I get the ASCII value in the keyboard buffer. (^= Of course after > that I need to "adapt" the result value to something the game understands, > but the important thing - the key translation - was done by the BIOS. > > And, even if those BIOS routines have not their places "standard" (they > are mentioned on MSX RedBook, but they are not mentioned as BIOS normal > entries) it looks like they are in the very same place on all MSX tested. > This approach is used on Uzix too, and the solution was based in the > code Adriano sent to help me. > > It's somewhat weird, but it works. (^= > > >Also, I only have 2 keyboard layout tables, one being an international one, > >the other being the UK one (they both differ on only 1 field). Do you have > >more of them?? > > I had several of them, but I really don't know what I had done. But they > are not "that" useful, because there is no secure way to identify (!) whay > keyboard layout is used on the current machine. I tried and failed. The ID > on the ROM usually do not indicates the real keyboard layout. \^= > > This was one of the reasons to use the BIOS. The other one was the > fact I had not all the tables, and there was no space to place all > keyboard tables inside de game. \^= > > > []'s > > Daniel Caetano > [EMAIL PROTECTED] > > ..."A necessidade de criatividade e' o que contribui para a > mudanca. A criatividade mantem o criador vivo." (Frank Herbert) > http://www.caetano.eng.br/ - This OS/2 system uptime is 0 days 00:46 hours. > > > _______________________________________________ > MSX mailing list ([EMAIL PROTECTED]) > Info page: http://lists.stack.nl/mailman/listinfo/msx > _______________________________________________ MSX mailing list ([EMAIL PROTECTED]) Info page: http://lists.stack.nl/mailman/listinfo/msx
