> I personally think that the invention of
> INT 15.4F was a mistake, though I'm sure IBM thought it was a really good
> idea, at least at the time.
I personally think that the invention of
INT 15.4F was a fantastic idea; actually it was really necessary.
DOS is supposed to use the BIOS for all
> I believe you that you tried almost everything; I still think that
> 0x shouldn't hurt, and CLI is even a bug
Tried both of those -- didn't help. Came to a "reasonable" value of 200, which
was far more long enough to work on any computer I had for testing, but did not
take too long (and s
> Returning "ignore this scancode" or returning the scancode
> untranslated would not crash anything, at most drop a key.
That's true, as long as the INT 15.4F code could do that re-entrantly (i.e.,
not crash when it received the re-entrant request). INT 15.4F handlers are
usually pretty simple
>> are you sure 200 is enough ?
>>
>> this should *ALWAYS* succeed, so IMHO it might be worth trying 0x
>> instead. (and you nowhere log if this test fails)
>>
>> I can also imagine some situations where CLI might hurt ('flaky').
>> in particular if some data are still in the keyboard receive
> are you sure 200 is enough ?
>
> this should *ALWAYS* succeed, so IMHO it might be worth trying 0x
> instead. (and you nowhere log if this test fails)
>
> I can also imagine some situations where CLI might hurt ('flaky').
> in particular if some data are still in the keyboard receive buffer
>
>> use the 8042 keyboard controller command 0xd2 to simulate scancode
>> received. that's documented (again in the IBM technical reference)
>>
>> this will simulate a scancode all the way through interrupt handler,
>> int15.4f, ...
> That is exactly what I call "Method 1" does. The problem is,
> use the 8042 keyboard controller command 0xd2 to simulate scancode
> received. that's documented (again in the IBM technical reference)
>
> this will simulate a scancode all the way through interrupt handler,
> int15.4f, ...
That is exactly what I call "Method 1" does. The problem is, function
Hi Bret,
>> I disagree here. You would only need reentrant handling if it could
>> happen that int 15.4f is called while int 15.4f already is busy.
>> This is unlikely for two reasons ...
>
> Agreed: Unlikely, but absolutely not impossible.
> Drivers should be designed to handle even unlikely ev
> Particularly in the case of USB, where the USB keyboard may be the
> only one the computer has, simulation at the scancode level is the
> only viable option. Simulation at the BDA level would almost be pointless.
use the 8042 keyboard controller command 0xd2 to simulate scancode
received.
that's
> We (well, at least I) have a severe dilemma going on here.
let's call it 'disagreement'
>> int 15.4f is supposed to be called from the BIOS from the INT 09
>> handler, and NOBODY else.
> Obviously, MS believes that INT 15.4F can be called from outside
> INT 09, based on what they've published o
> I disagree here. You would only need reentrant handling if it could
> happen that int 15.4f is called while int 15.4f already is busy.
> This is unlikely for two reasons ...
Agreed: Unlikely, but absolutely not impossible. Drivers should be designed to
handle even unlikely events without crash
Hi Bret,
>> int 15.4f is supposed to be called from the BIOS from the INT 09
>> handler, and NOBODY else.
>
> I've done some more research regarding this, and it is never stated
> anywhere that this function can ONLY be called from the INT 09
> handler. That is merely an assumption on your par
We (well, at least I) have a severe dilemma going on here.
> int 15.4f is supposed to be called from the BIOS from the INT 09
> handler, and NOBODY else.
I've done some more research regarding this, and it is never stated anywhere
that this function can ONLY be called from the INT 09 handler. T
Hi,
On 7/5/11, Eric Auer wrote:
>
Unicode (now at 6.0) is pretty damn huge. I don't know if...
>>>
>>> While Unicode is huge, DOS keyboard layouts tend to be limited to
>>> Latin and Cyrillic and some other symboly which is a tiny subset.
>>
>> Well, determining which "subset" (for us) is th
Hi Rugxulo,
>>> Unicode (now at 6.0) is pretty damn huge. I don't know if...
>>
>> While Unicode is huge, DOS keyboard layouts tend to be limited to
>> Latin and Cyrillic and some other symboly which is a tiny subset.
>
> Well, determining which "subset" (for us) is the main problem.
You could
I'm curious to know how are all these related to *USB* keyboard???
Off-topic: in the old day, in order to type in Chinese, we loaded
in some "modules". end-off-topic
On Tue, Jul 5, 2011 at 08:55, Rugxulo wrote:
> Hi,
>
> On 7/3/11, Eric Auer wrote:
That could work with
Hi,
On 7/3/11, Eric Auer wrote:
>>>
>>> That could work with a suitably compressed representation, e.g. only
>>> using the start of Unicode char space, or only discontinous subsets.
>>
>> Unicode (now at 6.0) is pretty damn huge. I don't know if...
>
> While Unicode is huge, DOS keyboard layouts
> The basic problem is that INT 15.4F is a BIOS function that can be
> called by any program at any time.
completely wrong.
int 15.4f is supposed to be called from the BIOS from the
INT 09 handler, and NOBODY else.
> It's true that it is always
> supposed to be called by the INT 09 handler (thou
Hi Rugxulo, long Unicode story ahead :-)
>>> Regarding FD-KEYB 3.0, I've been think of some ways that it could be
>>> improved. I think one thing that would help immensely is to turn the
>>> "translation" into a two-step process. The first step would be to
>>> translate the input scancodes to U
Hi,
On Sun, Jul 3, 2011 at 10:46 AM, Eric Auer wrote:
>
>> Regarding FD-KEYB 3.0, I've been think of some ways that it could be
>> improved. I think one thing that would help immensely is to turn the
>> "translation" into a two-step process. The first step would be to
>> translate the input sca
> I think it could "bounce off" attempts to use it recursively but
> I do agree that it should not do I/O, so it can only be used in
> combination with something else which does the I/O and/or buffers.
Not true. It does not ONLY need to be used in combination with something that
does the I/O. I
Hi!
> The basic problem is that INT 15.4F is a BIOS function that can be
> called by any program at any time. It's true that it is always
> supposed to be called by the INT 09 handler...
> all kinds of issues that must be taken into account in the
> implementation, including the fact that it mu
On 07/02/2011 04:21 AM, Aitor Santamaría wrote:
> ...
>> I actually have several programs that simulate keystrokes (MOUSKEYS,
>> JOYKEYS, SCANCODE, and USBKEYB). However, in order to simulate keystrokes
>> properly, the BIOS must be "compatible" with the keyboard simulation as
>> provided by th
> The "standard" use of FD-KEYB, with lesser memory footprint, does use
> INT 15h, 4Fh for its function (as I think mkeyb) does.
In fact, most of the KEYB replacements I've seen use INT 15.4F, which is
precisely why they are incompatible with KEYB. I recently had a rather
lengthy, though incom
Hello,
2011/4/18 Bret Johnson :
>> Also interesting that some BIOSes are not fully compatible with DOS
>> keyboard (layout drivers).
>
> The incompatibilities aren't related to the keyboard layout drivers as such.
> They are related to the way my programs simulate keystrokes (the way the my
> p
Hi,
Interesting thread, although I am a bit late.
2011/4/18 Bret Johnson :
>>> - MS-DOS keyb.com should be used instead of FreeDOS keyb.exe.
>
>> Of course we cannot do that because we have no license for that.
>> Can you be more specific? Are there any particular problems with
>> FreeDOS KEYB? A
Hi Eric,
On Tue, Apr 19, 2011 at 20:10, Eric Auer wrote:
>
> Hi STF!
>
>> No, but I've dug a little bit deeper in the ISO file, and I think the
>> problem is elsewhere, but of course, correct me if I'm wrong. It
>> seems that the real O/S is loaded from isolinux/data/fdboot.img. This
>> fdboot.
Hi STF!
> No, but I've dug a little bit deeper in the ISO file, and I think the
> problem is elsewhere, but of course, correct me if I'm wrong. It
> seems that the real O/S is loaded from isolinux/data/fdboot.img. This
> fdboot.img is actually a gzip file containing another file called
> IMAGE.
>And apparently, it's this file which doesn't support USB keyboard in
> some computers. But I'm unable to see how to replace kernel (or even
> sys.com) inside it.
>
> Is there any plan to release a new fdbasecd.iso?
>
Yes. Soon, but no definite date yet.
Jeremy
-
On Sat, Apr 16, 2011 at 22:34, Rugxulo wrote:
> Hi,
>
> On Fri, Apr 15, 2011 at 1:20 PM, STF wrote:
>> On Sat, Feb 5, 2011 at 08:23, dos386 wrote:
* I connected a USB keyboard to a DELL OptiPlex GX620
(there is no PS/2 port in this model)
>>>
>>> BIOS-level emulation
>>>
* When th
> Maybe on some machines USB has IRQ uses which are not reliably
> enabled during HLT? Maybe even NMI/SMI?
Hard to say exactly what the problem might be, though I don't suspect it has
anything to do with HLT, NMI, or SMI. It is interesting (and encouraging, at
least to me), though, that it only
Hi Bret,
interesting to have a laptop which already has USB but does not yet
have USB keyboard BIOS support indeed... I hope you can find out a
bit more about USB versus FDAPM. Maybe on some machines USB has IRQ
uses which are not reliably enabled during HLT? Maybe even NMI/SMI?
Also interesting
Marcos has already responded to some of this, but I will as well.
>> Bret's USB keyboard driver worked perfectly for my two notebooks
>> (Compaq and IBM, both year 1999) and one desktop (Pentium 166).
> It is unusual that the BIOS did not already do the keyboard for you.
I'm not surprised at all
Hi Marcos,
> Bret's USB keyboard driver worked perfectly for my two notebooks
> (Compaq and IBM, both year 1999) and one desktop (Pentium 166).
It is unusual that the BIOS did not already do the keyboard for you.
> *However*:
>
> - There is an incompatibility with FDAPM. I forgot the details,
Hi,
On Fri, Apr 15, 2011 at 1:20 PM, STF wrote:
> On Sat, Feb 5, 2011 at 08:23, dos386 wrote:
>>> * I connected a USB keyboard to a DELL OptiPlex GX620
>>> (there is no PS/2 port in this model)
>>
>> BIOS-level emulation
>>
>>> * When the computer was booted with the CD, I was asked to press
>>>
On Sat, Feb 5, 2011 at 08:23, dos386 wrote:
>> * I connected a USB keyboard to a DELL OptiPlex GX620
>> (there is no PS/2 port in this model)
>
> BIOS-level emulation
>
>> * When the computer was booted with the CD, I was asked to press
>> Enter to boot to CD. Please notice that I pressed Enter t
On Sat, Feb 5, 2011 at 08:23, dos386 wrote:
>> * I connected a USB keyboard to a DELL OptiPlex GX620
>> (there is no PS/2 port in this model)
>
> BIOS-level emulation
I had already checked BIOS for something like "legacy" but
there's nothing like that in this model, so I could but suppose
BI
> * I connected a USB keyboard to a DELL OptiPlex GX620
> (there is no PS/2 port in this model)
BIOS-level emulation
> * When the computer was booted with the CD, I was asked to press
> Enter to boot to CD. Please notice that I pressed Enter to boot to CD,
> so it seems the Enter key (thus the k
38 matches
Mail list logo
