Codepage 437 not correct??

[BDS107]

Hi,
It looks like codepage 437 isn't quite the same as it was in MS-DOS back then.
I live in Belgium and there we have an AZERTY keyboard with the keys é (ASCII 233), è (ASCII 232), §çàùµ£€ etc. These are not displayed correctly.
I live in a region where these French characters are not really necessary, but the idea that it is not correct bothers me.
I've been messing around with the _MAPUNICODE unicode_code& TO ascii_code& statement but this didn't help.

The codes below (from the wiki page) are therefore probably not correct
'Microsoft_pc_cp437
199,252,233,226,228,224,229,231,234,235,232,239,238,236,196,197
201,230,198,244,246,242,251,249,255,214,220,162,163,165,8359,402
225,237,243,250,241,209,170,186,191,8976,172,189,188,161,171,187
9617,9618,9619,9474,9508,9569,9570,9558,9557,9571,9553,9559,9565,9564,9563,9488
9492,9524,9516,9500,9472,9532,9566,9567,9562,9556,9577,9574,9568,9552,9580,9575
9576,9572,9573,9561,9560,9554,9555,9579,9578,9496,9484,9608,9604,9612,9616,9600
945,223,915,960,931,963,181,964,934,920,937,948,8734,966,949,8745
8801,177,8805,8804,8992,8993,247,8776,176,8729,183,8730,8319,178,9632,160

It works fine with another old program in DOSBOX.

Anyone have any ideas?

[mnrvovrfc]

I've totally given up on "_MAPUNICODE" for a similar issue. If you've read the majority of my posts you could haphazard a guess what was going on. Some characters (not "emoji" can't effin' stand them) look cool enough to be in cheap video games, that I've seen on Gucharmap.

EDIT: Might have to do with the font being used. @BDS107 are you using "_FONT 8" or something like that?

[mnrvovrfc]

Eh, just tried the "_MAPUNICODE" example with the "CP437" page and it gives me a Greek letter for CHR$(233). It would be nice to have the same "codepage" that is used by NPPP which has "y" with dieresis for CHR$(255), for example. I was going to post the screenshot but I read the first post again. Also I'm not on Windows at the moment. The problem is that many old QB programs depend on the characters drawn in the "CP437", that is, if the said example program worked correctly because the actual example was trying to show off a different code page.

EDIT BINGO!

https://en.wikipedia.org/wiki/Windows-1252

https://qb64phoenix.com/qb64wiki/index.php/Code_Pages

You want "Windows-1252" not "CP437".

EDIT #2: Must use an "actual" font not "_FONT 14" or alike LOL. Sorry about misinforming like that.

[RhoSigma]

Two very important things to note here:

1.) What you do with _MAPUNICODE does affect the program in which you code it only, not the IDE. Also you need to use a unicode enabled .ttf font via _LOADFONT, it does not work with the build-in fonts _FONT 8/14/16.

2.) What's _MAPUNICODE for your written programs, can be done for the IDE in the Options>Language menu, but again you also need the IDE to use a unicode enabled .ttf font, which you select in the Options>Display menu. Don't forget to tick the "Use custom font" box before entering the fontname and size.

Additional to note, the whole thing only affects to output via PRINT or _PRINTSTRING, but not the input routines INPUT, LINE INPUT, INPUT$ or INKEY$.

However, me and another user did create a workaround for INKEY$ in the old forum here:
https://qb64forum.alephc.xyz/index.php?t...#msg105704

Which might help if you put it in your programs and use it instead of INKEY$. However, it does not change the IDE input behavior.

Another alternative is here:
https://qb64phoenix.com/forum/showthread.php?tid=21

[BDS107]

I've totally given up on "_MAPUNICODE" for a similar issue. If you've read the majority of my posts you could haphazard a guess what was going on. Some characters (not "emoji" can't effin' stand them) look cool enough to be in cheap video games, that I've seen on Gucharmap.

EDIT: Might have to do with the font being used. @BDS107 are you using "_FONT 8" or something like that?

IIn the IDE I use LUCON.TTF and there I also have the problem.
In my program I also use lucon.ttf but it also appeared in several fonts..

[BDS107]

However, me and another user did create a workaround for INKEY$ in the old forum here:
https://qb64forum.alephc.xyz/index.php?t...#msg105704

Which might help if you put it in your programs and use it instead of INKEY$. However, it does not change the IDE input behavior.

Another alternative is here:
https://qb64phoenix.com/forum/showthread.php?tid=21

The procedure in the old forum does work. But wow, what a complex case for something that should actually work without extra code.
By the way, it doesn't work in the IDE either.