Walter Roberson
*nix forums Guru
Joined: 19 Feb 2005
Posts: 1300
|
 Posted: Sat Jul 15, 2006 3:08 pm Post subject:
Re: Problem with keyboard input for my very little OS
|
|
|
In article <1152947513.258011.200980@m73g2000cwd.googlegroups.com>,
pelletier.thomas@gmail.com <pelletier.thomas@gmail.com> wrote:
| Quote: | Hello everybody. I'm trying to code a very little OS.
But I have a problem with the keyboard input:
It show thechar + "~" :s
|
I do not understand what you mean by that. Do you mean that it
echo each input character but then an extra ~ after each?
The source involves implimentation defined behaviour (to write to
some kind of RAMSCREEN), and relies upon the non-standard functions inb()
and outbp().
I, for one, have no idea what your inb() function does, but if you
examine your kbd_int() function and compare it to kbdmap[] in
kbd.h you will see several problems.
Your kbdmap[] table has 97*4 entries (which appears to be one
per key, not one per character.) You get a uchar via inp(), and
immediately subtract 1 from that (what happens if the value
returned by inp() was 0 ?)
You check that the decremented value is less than 0x80, which will be
true if the original value was as large as (including) 0x80; if that
test is satisfied, you extract kbdmap[] at 4 times the decremented
value and putcar() that. If, though, the input value was
larger than 97 (0x61), then multiplying that input value (minus 1)
by 4 is going to result in an offset that is outside of the
table.
If I recall correctly, if you apply an arithmetic operation
to an unsigned char (such as multiplying by 4) and the result will not
fit within an unsigned char (which would likely be the case for
any input value above 0x40 [which would have been decremented to 0x3f])
the resulting type will be signed int if the result fits within
a signed int, and unsigned int if it does not; if my recollection
is correct, then i*4 will -not- "wrap around" inside the table,
so you would be accessing random garbage in memory.
When you go to do the putcar(), you check only that the (decremented)
input value is < 0x80, and if it is then you putcar() the kbdmap[i*4].
putcar() in turn checks only for the value 0 (end of string) and 10
(0x0A -- 'enter' according to your kbdmap[] comments), and anything
else is output to the screen. Suppose, though, that the input byte
was mapped to 0x08, 0x09, or 0xFF: do you really want to put those
values into video memory?
Looking at your kbd_int() function, I do not see any way in which
you can generate anything other than the lower-case letters, the
digits, and some basic symbols. Suppose the user was trying to
type N (shift-N). That is not one of the possible keycodes in the
first column of your table, so it is not one of the values that can
be returned when you index kbdmap[i*4] (which can only return garbage
or something from the first column of your table.)
My *guess* is that each time the user presses a key, *two* values
are put into the input buffer, to be read with two calls to inp().
The first value would be the key, and the second value would reflect
the modifiers (left-shift, right-shift, control, key up, key down,
perhaps others). If the value of the second inp() was above 0x40 but
below 0x80 then you are going to putcar() a value from beyond the
end of kbdmap[]. Likely by chance, that value happens to correspond
to the character ~ .
But I could be completely wrong about how your low-level keyboard
routine operates -- which is system specific and so not appropriate
for investigation in this newsgroup. For example, I see that you
have specific entries in your table for left-shift, so possibly
when the user goes to type N (shift-N) you get a code for left-shift
followed by a code for n and you may have to keep track of the
state of the shift and control and alt keys yourself. Usually,
though, it doesn't work like that, because most systems want to
be able to detect if the shift key is being held down while other
keys are being pressed, or holding down the shift key may have some
significance to mouse input or window focus or such things, so it
is not uncommon for systems to use a key-down / key-up model instead
of a plain key-down model.
Anyhow, you need to fix your kbd_int() routine.
--
Is there any thing whereof it may be said, See, this is new? It hath
been already of old time, which was before us. -- Ecclesiastes |
|
osmium
*nix forums Guru
Joined: 23 Feb 2005
Posts: 518
|
| Posted: Sat Jul 15, 2006 12:46 pm Post subject:
Re: Problem with keyboard input for my very little OS
|
|
|
<pelletier.thomas@gmail.com> wrote:
| Quote: | Hello everybody. I'm trying to code a very little OS.
But I have a problem with the keyboard input:
It show thechar + "~" :s
Can you help me ?
The source is there : http://thonix.tuxfamily.org/pub/0.0.1/src/
|
I, for one, do not understand your question. There is nothing inherently
wrong with showing the characters you mention. You need to focus our
attention more closely on your problem. I did glance at the code you
posted.
But, unless there is some glaring error, I doubt you will get much help
here. It takes several minutes to reboot my system to try your OS, and then
another several minutes to reboot to the so-called OS I normally use, in
order to respond. One really needs two systems to develop an OS. Although
I have several systems (four in this room and three more in a garden shed),
there is really only one that is the fully functional at any one time. |
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
Forum index
»
Programming
»
C
