Re: [MSX] Re: How to converte keyboard matrix data to ASCII?

2002-12-28 Thread Laurens Holst
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?

2002-12-28 Thread Daniel Caetano
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?

2002-12-28 Thread Laurens Holst
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?

2002-12-28 Thread Daniel Caetano
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?

2002-12-27 Thread Laurens Holst
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?

2002-12-27 Thread Laurens Holst
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?

2002-02-12 Thread konamiman

>   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?

2002-02-12 Thread Daniel Caetano


  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