Hi! It seems there was some delay in some emails here
so some of my replies today might be out of context.

> >> lh DISPLAY CON=(VGA,,1)
> > Maybe vga,437,1 instead?

Sorry that was just a guess - basically because I use
the VGA,437,1 setting and it works for me :-)

> From his AUTOEXEC he does not seem to be using
> codepage 437 at all, but 850

As far as I understood, the number mentioned when
you load DISPLAY is about the hardware codepage,
not about the codepage loaded by DISPLAY...?

> I wouldn't use LH, because it is highly unlikely
> that you'll have an UMB as big as for almost the
> 64KB that DISPLAY needs to run (because it does
> not know beforehand how many buffers you'll need),
> even if after running it just uses about 11Kb
> (9Kb of which are data).

I believe it always needs only 11 kB as long as it
has enough XMS to put those 64 kB? So and if you
do not have XMS, you also have no UMB... What I am
trying to suggest: If DISPLAY does not say to DOS
(via the DISPLAY exe header) that it needs 64 kB
then it will still work: Because either you have
UMB - then you probably also have XMS - or you do
not have UMB - then you load DISPLAY into low DOS
memory which is almost always 400 kB or more :-).

> >> mode con codepage prepare=((850) a:\dos\ega.cpx)
> >> mode con codepage select=850
> >> a:\doskeyb br,850,a:\dos\keyboard.sys /ID:275
> > Try MKEYB instead, just in case

This was, again, just a guess.

> Wouldn't it be more sensible to advice him
> NOT TO USE an unstable kernel?

True. I would suggest to use stable 2038 or 2036.
Then the "country sys filename" option of the
COUNTRY line in config sys will be ignored and
CHCP will not work. But DISPLAY and MODE will
still work fine and you have a stable kernel :)

> I think it does not good to the project that whenever
> there's a problem you just suggest to use the programs
> that you prefer "just in case"

Sorry about that. It was more meant to say "try replacing
programs by other programs which do the same, it might
help, and if it does not, then neither the original nor
the alternative program are likely to be related to the
original problem". In another situation I would probably
have suggested to load no drivers at all... But then you
no longer have your 850 font, of course :-). I did not
mean to suggest that some version is "good because I do
like it" and the other is "probably broken because I do
not like it". Sorry again, not my intention...

Talking about alternatives: You can try both classic FreeDOS
HIMEM and EMM386 and the japheth.de HIMEMX and JEMM386, or
the "both in one" JEMMEX. Again not because I think that we
have one good and one bad version. But it MAY be the case
that changing versions has good influence on the problem :-)

> From his configuration, he is configuring a codepage. The difference
> between FD-KEYB and MKEYB is precisely the support for the codepage
> management (present in FD-KEYB) as opposed to the smallest size of

Hmmm okay. You mean when using CHCP? But if you do use CHCP
then unfortunately it requires the unstable kernel. On the
other hand, giving DISPLAY / MODE / KEYB the right options
manually already works without CHCP and with any kernel :-)


This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
Freedos-user mailing list

Reply via email to