Re: [MSX] Re: How to converte keyboard matrix data to ASCII?
Daniel Caetano wrote: > On Sat, 28 Dec 2002 18:06:12 +0100, Laurens Holst wrote: [...snip...] >> 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). > > You are right, it looks like those positions on key matrix are > fixed. Some people said the numbers on row 0 and 1 are fixed too. Hmz, but those rows contain the number keys. And since you said in the original message that when pressing an "A" an "8" would come up (ofcourse it was an example, but...), that would mean those rows aren't really default either... Ah, well. I'm glad at least half of the row layouts can pretty much be assumed to be equal. Anyways, thanks a lot for your help. The official grand opening of the MAP has come a little closer again :). ~Grauw ___ MSX mailing list ([EMAIL PROTECTED]) Info page: http://lists.stack.nl/mailman/listinfo/msx
Re: [MSX] Re: How to converte keyboard matrix data to ASCII?
On Sat, 28 Dec 2002 18:06:12 +0100, Laurens Holst wrote: Hi, >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? Hummm... it may works. I had never tried though. (^= >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. Yup. This can be useful in those cases. >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). You are right, it looks like those positions on key matrix are fixed. Some people said the numbers on row 0 and 1 are fixed too. []'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:32 hours. ___ MSX mailing list ([EMAIL PROTECTED]) Info page: http://lists.stack.nl/mailman/listinfo/msx
Re: [MSX] Re: How to converte keyboard matrix data to ASCII?
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: > > call0d12h ; detect valid key transition and check buffer > call0d4eh ; 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
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: call0d12h ; detect valid key transition and check buffer call0d4eh ; 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
Re: [MSX] Re: How to converte keyboard matrix data to ASCII?
Argh, sorry peepz :) This was not supposed to be sent to the mainlinglist... Ofcourse if anyone else knows more about this he can mail me ^_^. Byte! ~Grauw - Original Message - From: "Laurens Holst" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, December 28, 2002 12:38 AM Subject: [MSX] Re: How to converte keyboard matrix data to ASCII? > Hi Daniel! > > 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. > > 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?? > > Thanks in advance, > > > ~Grauw > > > - Original Message - > From: "Daniel Caetano" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Wednesday, February 13, 2002 7:26 AM > Subject: How to converte keyboard matrix data to ASCII? > > > > > > People, > > > > I'm translating Snatcher to portuguese and then to English. > > At this time, the translation is going very well, and I'll > > release betas as soon as the final programming problems > > finish. > > I found a little problem that I'm not being able to solve. > > The game reads the columns and lines of the keyboard to find > > what key is pressed. It's the only way, since it replaces > > the interrupt. But this is not the point. > > At one place, the game converts the data (line and column > > got on the key matrix) to a character value, based on a > > internal table. This table originaly pointed to Kanji/Hiragana > > characters (Japanese language). I converted them ASCII values > > and it really works... well... in some machines. > > > > The problem resides in the fact the relation > > line/column -> ASCII is NOT defaut. It seems to be different > > on several machines, even if they are from the same country > > and have similar keyboard. > > The result is: in some computers, the keys act as expected > > (when you press the "A" key, the A appears on the screen). > > But on other computers, when you press the "A" key, something > > different appears (say, an "8" is shown). > > > > Once there is no default way to convert a line/colum from > > keymatrix to a ASCII code (the BIOS has a table, but it's > > position is not the same in every computer), I think the solution > > is to preload the proper convertion table in the upper memory (say, > > on the PLAY queue space) and point the game to look there. > > This would be ok IF I knew a way to detect what the hell > > kind of keyboard the machine uses. > > One way to detect it is asking to the user to push some keys, > > but this is very annoying and not compatible with the work I'm > > doing on Snatcher. > > > > I'm writting here in the hope someone know a misterious way > > to detect the keyboard type. > > > > Before someone ask me, I know the byte 0x002C of ROM says me > > the keyboard type. But this means nothing. On computers with > > the same value for this byte, the answer of the key matrix was > > different one from another. )^= > > > > BTW, Snatcher is non-standard in many aspects. This is one of > > them. Konami never thought to release this game outside its > > county (this explains why they do not worried about differente > > keyboard types than the japanese one). > > > > I hope someone can help me, and I can continue the translation. > > > > Thanx in advance. > > > > Daniel Caetano > > > > PS: The actual stage of translation is somewhat more advanced than > > Oasis was. But as soon as this problem is fixed, the translation > > will not be hard, since I had developed several programs that > > automatically replaces the texts and relocate them when they > > do not fit in the space. > > > > > > []'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://soulmatrix.dynodns.net/ - This OS/2 system uptime is 0 days 05:42 > hours. > > > > > > -- > > For info, see http://www.stack.nl/~wynke/MSX/listinfo.html > > ___ > 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
[MSX] Re: How to converte keyboard matrix data to ASCII?
Hi Daniel! 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. 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?? Thanks in advance, ~Grauw - Original Message - From: "Daniel Caetano" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, February 13, 2002 7:26 AM Subject: How to converte keyboard matrix data to ASCII? > > People, > > I'm translating Snatcher to portuguese and then to English. > At this time, the translation is going very well, and I'll > release betas as soon as the final programming problems > finish. > I found a little problem that I'm not being able to solve. > The game reads the columns and lines of the keyboard to find > what key is pressed. It's the only way, since it replaces > the interrupt. But this is not the point. > At one place, the game converts the data (line and column > got on the key matrix) to a character value, based on a > internal table. This table originaly pointed to Kanji/Hiragana > characters (Japanese language). I converted them ASCII values > and it really works... well... in some machines. > > The problem resides in the fact the relation > line/column -> ASCII is NOT defaut. It seems to be different > on several machines, even if they are from the same country > and have similar keyboard. > The result is: in some computers, the keys act as expected > (when you press the "A" key, the A appears on the screen). > But on other computers, when you press the "A" key, something > different appears (say, an "8" is shown). > > Once there is no default way to convert a line/colum from > keymatrix to a ASCII code (the BIOS has a table, but it's > position is not the same in every computer), I think the solution > is to preload the proper convertion table in the upper memory (say, > on the PLAY queue space) and point the game to look there. > This would be ok IF I knew a way to detect what the hell > kind of keyboard the machine uses. > One way to detect it is asking to the user to push some keys, > but this is very annoying and not compatible with the work I'm > doing on Snatcher. > > I'm writting here in the hope someone know a misterious way > to detect the keyboard type. > > Before someone ask me, I know the byte 0x002C of ROM says me > the keyboard type. But this means nothing. On computers with > the same value for this byte, the answer of the key matrix was > different one from another. )^= > > BTW, Snatcher is non-standard in many aspects. This is one of > them. Konami never thought to release this game outside its > county (this explains why they do not worried about differente > keyboard types than the japanese one). > > I hope someone can help me, and I can continue the translation. > > Thanx in advance. > > Daniel Caetano > > PS: The actual stage of translation is somewhat more advanced than > Oasis was. But as soon as this problem is fixed, the translation > will not be hard, since I had developed several programs that > automatically replaces the texts and relocate them when they > do not fit in the space. > > > []'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://soulmatrix.dynodns.net/ - This OS/2 system uptime is 0 days 05:42 hours. > > > -- > For info, see http://www.stack.nl/~wynke/MSX/listinfo.html ___ MSX mailing list ([EMAIL PROTECTED]) Info page: http://lists.stack.nl/mailman/listinfo/msx
Re: How to converte keyboard matrix data to ASCII?
> I'm writting here in the hope someone know a misterious way > to detect the keyboard type. If you cannot solve it, do it the hard way: release different translation versions for each different MSX computer/keyboard layout. Or, just make a patch program for the game disks, so the user can select and try the different layouts until he founds the correct one for his machine. Yeah, not a very elegant solution, but if there is not another one... Konami Man escribiendo desde el curro (¡qué malo soy!) [EMAIL PROTECTED] http://www.konamiman.com __ Launch your own web site Today! Create a Web site for your family, friends, photos, or a special event. Visit: http://www.namezero.com/sitebuilder -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
How to converte keyboard matrix data to ASCII?
People, I'm translating Snatcher to portuguese and then to English. At this time, the translation is going very well, and I'll release betas as soon as the final programming problems finish. I found a little problem that I'm not being able to solve. The game reads the columns and lines of the keyboard to find what key is pressed. It's the only way, since it replaces the interrupt. But this is not the point. At one place, the game converts the data (line and column got on the key matrix) to a character value, based on a internal table. This table originaly pointed to Kanji/Hiragana characters (Japanese language). I converted them ASCII values and it really works... well... in some machines. The problem resides in the fact the relation line/column -> ASCII is NOT defaut. It seems to be different on several machines, even if they are from the same country and have similar keyboard. The result is: in some computers, the keys act as expected (when you press the "A" key, the A appears on the screen). But on other computers, when you press the "A" key, something different appears (say, an "8" is shown). Once there is no default way to convert a line/colum from keymatrix to a ASCII code (the BIOS has a table, but it's position is not the same in every computer), I think the solution is to preload the proper convertion table in the upper memory (say, on the PLAY queue space) and point the game to look there. This would be ok IF I knew a way to detect what the hell kind of keyboard the machine uses. One way to detect it is asking to the user to push some keys, but this is very annoying and not compatible with the work I'm doing on Snatcher. I'm writting here in the hope someone know a misterious way to detect the keyboard type. Before someone ask me, I know the byte 0x002C of ROM says me the keyboard type. But this means nothing. On computers with the same value for this byte, the answer of the key matrix was different one from another. )^= BTW, Snatcher is non-standard in many aspects. This is one of them. Konami never thought to release this game outside its county (this explains why they do not worried about differente keyboard types than the japanese one). I hope someone can help me, and I can continue the translation. Thanx in advance. Daniel Caetano PS: The actual stage of translation is somewhat more advanced than Oasis was. But as soon as this problem is fixed, the translation will not be hard, since I had developed several programs that automatically replaces the texts and relocate them when they do not fit in the space. []'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://soulmatrix.dynodns.net/ - This OS/2 system uptime is 0 days 05:42 hours. -- For info, see http://www.stack.nl/~wynke/MSX/listinfo.html