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 > MKEYB. 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 :-) Eric ------------------------------------------------------------------------- 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 http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Freedos-user mailing list Freedosemail@example.com https://lists.sourceforge.net/lists/listinfo/freedos-user