> 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 Eric,
I just did a few extra tests in my IBM ThinkPad 380Z to be able to
give more specific answers.
But first let me stress that, except for the two previous
remarks, Bret's keyboard driver works very reliably for me. The
memory stick driver is even better, because it does not have
problems
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,
> Have you tried Bret Johnson's USB stuff (e.g. keyboard)? I think I
> heard one person (RaYeR?) a while back say it worked for him.
Bret's USB keyboard driver worked perfectly for my two notebooks
(Compaq and IBM, both year 1999) and one desktop (Pentium 166).
*However*:
- There is an inco
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
Hi,
I've found that FreeDos 1.0 has problem working with USB keyboard
in some computers, in particular, a DELL Optiplex GX620.
If you want to know how I got to this conclusion, here you are:
* I downloaded the fdbasecd.iso (version 1.0) and burned it to CD
* I connected a USB keyboard t
41 matches
Mail list logo
