Hi,
On 7/7/11, Eric Auer wrote:
>
> as freebasic (and freepascal, openwatcom, djgpp...)
> are quite complete by now, you could consider using
> your games in the "qbasic-style mode" of freebasic,
Apparently it still isn't 100% compatible but good enough for general
use. (And the -lang fb is "bet
Op 8-7-2011 2:21, Garrison Ricketson schreef:
> Hello everyone,
> It has been a long time since I have sent anything to these news letters,...
> This is a little off subject, in relation to Free Dos, hope it is ok,
> Dose anyone know what is involved, and if it is possible to put a Dos
> game on a
Hi Garrison,
as freebasic (and freepascal, openwatcom, djgpp...)
are quite complete by now, you could consider using
your games in the "qbasic-style mode" of freebasic,
maybe with some porting... You could use the dosbox
Java applet port to run things in a web browser, or
somehow couple freebasic
Hello everyone, It has been a long time since I have sent anything to these
news letters,... This is a little off subject, in relation to Free Dos, hope it
is ok, Dose anyone know what is involved, and if it is possible to put a Dos
game on a web site, so it can be played online, ? I use Free D
Hi Eric,
My main point was to use 0x10 to allow right to left display of Unicode for
Arabic, Syriac, Hebrew etc. If each application processes its own input and
output
and we are only concerned with displaying their output, then whether they use
0x10 or write directly to video memory is irrelevan
> 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
Hi Jeffrey,
>> HOWEVER, the array, int 10 and CON are all officially assuming a
>> "one byte is one character" scenario so your layout is likely to
>> get messed up when you use UTF-8 and you cannot use UTF-16 anyway.
> In color text modes, alternating bytes are used for character and attribute.
> 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
>
Hi Eric,
> HOWEVER, the array, int 10 and CON are all officially assuming a
> "one byte is one character" scenario so your layout is likely to
> get messed up when you use UTF-8 and you cannot use UTF-16 anyway.
In color text modes, alternating bytes are used for character and attribute.
So if you
>> 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,
(this may be *slightly* off-topic, but I couldn't resist, sorry,
I'm always wanting to share useless trivia)
EDIT: I'll just change the subject line, hopefully nobody will get
(too) mad, then.
On 7/6/11, Bret Johnson wrote:
>
> There are a couple of problems with that approach. The first
Hi Jeffrey,
> Would chaining interrupt 0x10 be reasonable? If I am not mistaken the FreeDOS
> kernel
> uses interrupt 0x10 function 0x0E to print characters to the screen. A TSR
> could be
> written to handle function 0x0E and pass the other functions to the BIOS.
Of course. In the old days of
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
19 matches
Mail list logo
