Talk:Code page 437

message: In addition to characters lifted from the Wang word processing set, some of the glyphs may have originated from work Gates did with Microsoft BASIC for Commodore International ... but I can't find any full character maps of all PETSCII glyphs including 0-31 ... http://americanhistory.si.edu/collections/comphist/gates.htm
:In terms of Commodore PET, they started with us from the very beginning. Because we helped Chuck Pedal, who was at Commodore at that time, really think about the design of the machine. Adding lots of fun characters to the character set, things like smiley faces, and suit symbols.
::—Hobart 19:20, 21 September 2006 (UTC)
replies: text: Added with reference. —Coroboy (talk) 00:57, 15 November 2011 (UTC)
thread_title:  Glyph origins 

message: null character should be empty -- the ibm PC did not say "NULL" when the 0 byte was put into the frame buffer. the null, space, and blank characters (0x0, 0x20, and 0xff) were indistinguishable visually.
:I agree - so I changed it. -- 212.63.43.180 (talk) 21:12, 24 January 2008 (UTC)
replies: text: However, characters 0, 32, and 255 were used differently in IBM PC files.  The way the table has been, the NULL, SP, and NBSP texts link to relevant articles where people can read what the specific functions of those characters were -- whereas leaving things blank conveys no information. AnonMoos (talk) 22:33, 24 January 2008 (UTC)
replies: text: I solved the issue by putting two sets of the table for values 0-31. Ricardo Cancho Niemietz (talk) 09:46, 29 January 2008 (UTC)
replies: text: Most of the changes were good, but now the English does need some clean-up... AnonMoos (talk) 11:24, 29 January 2008 (UTC)

text: Sorry, I'm not a native english speaker (I'm from and live in Spain). Please, help requested. Ricardo Cancho Niemietz (talk) 12:54, 29 January 2008 (UTC)
thread_title:  null 

message: While the table header rows and Unicode are in hexadecimal, the CP437 is in decimal. This decreases the obviousness where the two encodings point to the same character. I would recommend making it entirely hexadecimal.
:I disagree. I think it makes it much quicker to understand using the two different bases. ACED.wiki (talk) 18:40, 5 August 2020 (UTC)
replies: text: The numbers are only there because you can type them with Alt on Windows to get these characters, and apparently a lot of people rely on this Wikipedia page as a reference for what those numbers are. Since the number you type on Windows is in base-10, it must be shown in base-10 here.Spitzak (talk) 19:12, 5 August 2020 (UTC)

text: The Alt code is in the tooltip.Spitzak (talk) 17:21, 26 January 2022 (UTC)
thread_title:  Multiple Bases 

message: The character for place 237 in the CP437 table should change from U+03D6 GREEK SMALL LETTER PHI to U+03D5 GREEK PHI SYMBOL.
In CP437, this position was used as U+03D5 GREEK PHI SYMBOL in italics, U+2205 EMPTY SET, U+2300 DIAMETER SIGN and even as a surrogate for U+00F8 LATIN SMALL LETTER O WITH STROKE, but rarely as U+03D6 GREEK SMALL LETTER PHI due to its IBM original shape (it seems merely a circle with a slash) does not ressembles closely this greek lowercase letter.
Also, the character 238 effectively should be changed to U+2208 ELEMENT OF. In addition to be used as U+03B5 GREEK SMALL LETTER EPSILON, in some dot matrix ticket printers is used today as the U+20AC EURO SIGN, in the european countries where the euro is the official currency.
In other hand, the character 236 is the U+221E INFINITY, not a greek letter at all, so you should change its background colour to grey.
As you can see, characters 236 to 253 in CP437 was primary intended all for maths symbols, so the positions 237 and 238 are not "real" greek letters. In despite of that, many people has used these characters as greek letters (to name angles and so on), of course.
And another issue: the character 235, U+03B4 GREEK SMALL LETTER DELTA was also used as U+00F0 LATIN SMALL LETTER ETH, an icelandic latin character.
A popular math software for MS-DOS in the late 80's, "Derive", employs the full CP437 character set to display complex formulae, with very good results.
People is able to do incredible things with a very little means...
Yours Ricardo Cancho Niemietz (talk) 15:53, 25 January 2008 (UTC)
replies: text: I did the changes myself! :-D Ricardo Cancho Niemietz (talk) 14:00, 28 January 2008 (UTC)
thread_title:  The overloaded character number 237 in CP437 

message: I just added the image to the top, which is a printout of the code page in order using QEMU. I noticed a discrepancy - positions 16 and 17 are swapped around, relative to the codes given in this article. Note that in the image, there is a right arrow then a left arrow (in the top row). In the table in the article, there is first the left arrow (U+25C4), then the right arrow (U+25BA). Is there an error in the article? I can't find a source for the first 32 characters. EatMyShortz (talk) 12:48, 18 February 2009 (UTC)
replies: text: There are sources on the Microsoft site, the Unicode.org site, or if you insist on paper, you can look at Appendix C of The New Peter Norton Programmer's Guide to the IBM PC & PS/2 by Peter Norton and Richard Wilton (Microsoft Press, 1987 ).  From what I can see if you place 16 and 17 side-by-side, they point at each other, as is also the case for 26 and 27... AnonMoos (talk) 09:33, 19 February 2009 (UTC)
thread_title:  Codes for 16 and 17 

message: Would be nice to have a reference to the fact this code page is used often for ascii art  —Preceding unsigned comment added by 85.146.181.17 (talk) 01:15, 1 July 2009 (UTC)
replies: text: It was actually mainly BBS-type text graphics with ANSI.SYS terminal codes (or other control of video colors), which isn't quite the same thing as plain ASCII art... AnonMoos (talk) 17:43, 1 July 2009 (UTC)

text: Also, many DOS applications made extensive use of these characters to represent menus and other GUI-like elements and rely on them to display properly. sPAzzMatiC 18:22, 6 August 2009 (UTC)
replies: text: See box-drawing character... AnonMoos (talk) 11:25, 29 July 2014 (UTC)
thread_title:  ascii art 

message: The image purports to show the characters in an EGA display.  But the character size in the image is 9 × 16 pixels, the standard VGA size.  Isn't EGA limited to 8 × 14? -- Elphion (talk) 00:28, 5 April 2010 (UTC)
replies: text: Of course, you are right. EGA had not 16 dots high glyphs, and had not 9 dots width mode. :File:Codepage-437.png is VGA. Incnis Mrsi (talk) 11:33, 5 April 2010 (UTC)

text: Like this? I could provide you a simple C program, which make such BMPs (unfortunately, not PNGs) from PSF raster fonts. Incnis Mrsi (talk) 14:17, 27 June 2011 (UTC)
replies: text: Yes, like that. DanBishop (talk) 23:29, 27 June 2011 (UTC)
thread_title:  Is the image really EGA? 

message: The section "Entry on keyboards" says that "programs that support only Windows-1252" attempt to transliterate the "Greek" characters when entered via keyboard.  Is there some support for this?  (I've never seen this behavior -- what I get is always the corresponding Windows-1252 character.) -- Elphion (talk) 16:30, 5 April 2010 (UTC)
replies: text: Hearing no response, I've removed the statement from the article. -- Elphion (talk) 01:05, 28 June 2010 (UTC)
thread_title:  Entry on keyboards 

message: The table shows the character at position 0xE1 equating to U+00DF (LATIN SMALL LETTER SHARP S) which contradicts the text: "Table rows 14 and 15 (E and F), codes 224 to 255 (E0 to FF) are devoted to mathematical symbols, where the first twelve are a selection of Greek letters commonly used in physics." — Ksn (talk) 04:07, 20 November 2010 (UTC)
replies: text: It's actually ambiguous or "overloaded" (see section "Multiple-meaning character glyphs"). AnonMoos (talk) 11:50, 20 November 2010 (UTC)
thread_title:  The character at 0xE1 

message: i changed the text "and tan cells are international letters." to "and pink cells are international letters.", since the cells in question are pink.  —Preceding unsigned comment added by 72.91.177.153 (talk) 00:45, 26 November 2010 (UTC)
thread_title:  tan is not pink 

message: I've not seen N° 158 as Pts, only Pt
86.148.227.195 (talk) 11:44, 30 April 2015 (UTC)
replies: text: I have seen both. It depends on the font you're using. --Matthiaspaul (talk) 11:59, 6 June 2016 (UTC)
replies: text: To my knowledge, all the original MDA/CGA/EGA/VGA DOS fonts used to only render the character as Pt, but many subsequent (Unicode-compatible) fonts use the Pts form, which is why your browser might be showing you the s as part of the actual character here: ₧—ReadOnlyAccount (talk) 01:46, 18 November 2023 (UTC)
thread_title:  158 Pts? 

message: User:TiredTendencies has claimed that in Windows Alt codes, the leading zero is for typing the codes from CP 437, while no leading zero is for getting newer codes (ie CP1252). My impression is that this is incorrect, the opposite is true (leading zero for the new codes, and no leading zero for CP 437), and was purposely done this way because users had memorized the CP 437 codes, but this is based on the text in Alt codes. Can anybody confirm what the actual situation is?Spitzak (talk) 17:44, 6 September 2016 (UTC)
replies: text: In Windows 7, Alt(0+code) gives me my current codepage (ISO Latin 1), while Alt(code) gives me CP 437. -- Elphion (talk) 21:24, 6 September 2016 (UTC)
thread_title:  Alt codes and leading zero 

message: in the article as it currently stands it says: " Many file formats developed at the time of the IBM PC are based on code page 437 as well."  I'm pretty familiar with old dos file formats and I have no idea what this refers to.  Unless somebody can point out one file format based off of the codepage and explain why I'm inclined to take it out. Jethro 82 (talk) 01:34, 9 September 2019 (UTC)
replies: text: I think "file formats" is probably the wrong way to say what is meant, namely, that software often assumed that the characters stored in the files were from this codepage.  Software also typically assumed that this was the active codepage when presenting material on the screen.  The control characters and the box-drawing characters were especially heavily used to format the screen, and characters hard-coded in the software files were correspondingly assumed to display as 437 characters. -- Elphion (talk) 06:45, 9 September 2019 (UTC)

text: I may not be remembering this right, but I think it was the monochrome adapter on the original PC that had a horizontal resolution of 720, with the 8-bit wide glyphs padded with one extra column of bits that was either blank or a duplicate of the rightmost one, as described in the article. I remember clearly the "Hercules" 3rd-party graphics adapter for the original PC using 720 pixels wide, likely so it would display on the Monochrome monitor. I *think* the VGA used 640 pixels in all modes but there is a good chance I am not remembering that correctly.Spitzak (talk) 19:41, 9 September 2019 (UTC)
thread_title:  File Formats 

message: Under the Internationalization section, I see that it says:
Code page 437 has a series of international characters, mainly values 128 to 175 (80hex to AFhex). However, as it was primarily intended for the English language, it covers only English, German, Swedish and the pre-1999 Turkmen Latin alphabet in full, and so lacks several characters important to many Western languages (mostly capital letters):
I actually changed this from the original already (stating that the reason why it doesn't cover many Western languages is because it was primarily intended for English - which may not even be accurate.)
The thing is, I am not sure how we can briefly yet accurately illustrate the fact that in reality, the scripts of some other Western languages (Basque being an example that I found), as well as some non-Western languages (Malay being an example that I found) are covered in full by Code page 437 (or just happen to be). It is not just the 4 languages mentioned (and honestly, Basque is probably as notable, if not more notable than Turkmen, from my limited point of view, being Asian and living in Hong Kong for my whole life and not speaking or learning any of the mentioned languages in this article except English)
Also, Dutch should be mentioned in the bullet point list as it is a semi-major Western language (#10 most speakers according to ).
I have added a note in hidden text (removed in the pre tag text above) as well.
Also, another interesting thing we should consider adding to the article (of course, only if we can find sources or actual evidence) was that (unlike most other cases where the encoding is based off the alphabet of a language or languages) it seems like the pre-1999 Turkmen Latin alphabet actually was built around code page 437, which is why it has unusual letters, including currency signs! I don't have any good source except where I found it (on a Wikipedia page: List of Latin script alphabets - see note number 60 about Turkmen, and that statement is unsourced) Hkbusfan (talk) 11:11, 26 April 2020 (UTC)
replies: text: I agree it is silly to list obscure languages where the set of letters they use happen to be in 437. This was certainly not anything the designers of 437 were thinking of. Mentioning that things like French are missing letters is probably useful as I suspect the designers at least thought their set would be helpful for some European languages.Spitzak (talk) 18:30, 26 April 2020 (UTC)
replies: text: Just to let you know, sorry that this is a very long paragraph and I don't know how to split it (if even possible) into smaller paragraphs and add bullet points (which were intended in the part where I listed the changes) but still have indents (when I tried, it added pre format (or what looked like pre format) to everything after the first paragraph. Anyway, what you said is very true. Thanks for the reply. The international characters were added because the designers thought that they were helpful: to quote one of the designers, Dr. David Bradley: "Since we were using 8-bit characters we had 128 new spots to fill. We put serious characters there — three columns of foreign characters, based on our Datamaster experience." (This is in one of the sources of this page.) Unfortunately, the letters were not really that helpful in practice (I'm guessing/assuming). I guess that they could often use lowercase to substitute uppercase (which would work fully in some of the languages listed: Spanish, Catalan, and Italian), but that would probably look sloppy (well, I don't know any of those languages but can imagine how it would be sloppy). However, I don't think that Malay, Basque or Dutch (the first 2 of which are supported fully by code page 437) are exactly "obscure" (were you talking about Turkmen or these 3 languages?) Maybe Malay should not be mentioned as it is an Asian language (and this character set was probably meant for use in Western languages, at least originally) At least Dutch should be mentioned in the section under languages with missing important letters, as it is a "major" Western language (though I read it rarely uses diacritics). And Turkmen may not really be notable enough to get a mention as a fully-supported language. (though maybe that was mentioned in the article due to its possible link to the code page - as in the fact that it uses letters that are not expected for a language, including £ and ¢!) Do you think that we should remove the explicit mention of Turkmen and reword that sentence making it say that the mentioned languages are not all of the supported languages (or maybe just say "among Western languages" or something similar)? Here is what I plan to change some time today or in the next few days: Reword it so it says something like "Only a few Western languages are supported, including...", add Basque and remove Turkmen (not adding Malay, because it is not Western OR European), maybe change "Western" to "Western European" in the sentence (if I do this, my rewording will use the term "Western European" too), and finally add Dutch to the "Western" languages for which code page 437 lacks important letters. After doing that, I may add Turkmen back (maybe not in the same sentence, and maybe not in the next few days) if I can find a detailed reliable source (not including that note I saw on the  List of Latin-script alphabets page which doesn't link to an external source) stating that the Turkmen alphabet was intentionally designed with code page 437 in mind. Do you think the aforementioned changes are fine? And sorry, there were 2 typos (that I am aware of) in my text. First, I spelt "scripts" with 2 c's. Second, I forgot the hyphen in List of Latin-script alphabets making it a red link. By the way, I was also the one who added the capital letter mention to that sentence. Hkbusfan (talk) 09:33, 29 April 2020 (UTC)

text: For French, the characters included were actually very carefully chosen: A wide range of lower-case diacritic letters, and the two upper-case diacritic letters which could be considered most essential (C-cedilla and E-acute). It's not as if they didn't bother with French... AnonMoos (talk) 14:16, 30 April 2020 (UTC)

text: This is why the paragraph should be fixed. The designers obviously *intended* to support French, but a few symbols used by French are missing. They almost certainly did not intend to support Basque/Malay/Turkman, despite the fact that the resulting set just happens to cover those languages (partially because at least the last one was *designed* to fit in this character set!).Spitzak (talk) 16:05, 30 April 2020 (UTC)
replies: text:  I agree with these points. They did actually try supporting French (and other languages), but not fully. Hkbusfan (talk) 00:38, 3 May 2020 (UTC)

text: If one looks at https://en.wikipedia.org/wiki/ISO/IEC_646 and compares with https://en.wikipedia.org/wiki/Code_page_437#Internationalization one sees that all small French characters from IEC 646 are supported. That œ is not supported in CP437 could be because it was not included in the 7-bit fonts for French. Mikael4u (talk) 13:32, 27 July 2023 (UTC)

text: Finnish is also fully supported by CP437. This is perhaps important since Linux is from Finland, and they had no problem with the code page in the ROM on the early i386 PCs (CP437). The standard Finnish keyboard layout is also identical to the Swedish, on what is printed on the keys. Finnish is a Uralic language. Mikael4u (talk) 12:19, 27 July 2023 (UTC)
thread_title:  Inaccuracy in article 

message: I regularly work on a software project that uses 437 code points.  I used to be able to easily use this page for reference, since it had the characters and their byte values visually together, without involving extra work and opportunities for human error.  Now, not only have the updates to the table made it obnoxious to work with, I can't even use a useful version back in the page history, since templates it depended on have been deleted.  Thanks, I hate it. —chaos5023 (talk) 07:09, 23 January 2022 (UTC)
thread_title:  This page used to be useful 

message: Maybe it would be interesting to mention that this code page is the current base of Dwarf Fortress 's tileset. AdalwinAmillion (talk) 09:49, 20 March 2022 (UTC)
replies: text: I'm pretty certain this is the "base" of virtually every character-based game designed for the IBM PC.16:37, 20 March 2022 (UTC)
replies: text: The game was not designed for the IBM PC. AdalwinAmillion (talk) 21:15, 20 March 2022 (UTC)
replies: text: But many were and they used 437's semigraphics to great effect. Dwarf Fortress was designed to mimic that particular aesthetic for which using 437 was a good fit. You could try to pass it as a cultural impact (the infamous ‘in popular culture’ section; weird thing to have in an article about a code page, but for 437 it's imaginable), but I don't think sufficient significance could be established. Are there any secondary and tertiary sources describing how its use of 437 rather than any other character set was an important part of its success? If all they do is just mentioning that this is what it uses, then it's a tangentially related trivia at best. Trivia sections are discouraged. – MwGamera (talk) 11:58, 21 March 2022 (UTC)
thread_title:  Usage in Dwarf Fortress 

message: Theta (0xE9=233) should probably be lower case theta θ, and not as now upper case theta Θ. The reason is that these symbols are for mathematics and physics and lower case theta is much more used in e.g. polar coordinates. In upper case theta the bar (-) is separated from the O, but it's not in the early computer fonts, since it is a lower case theta. Nowadays it is, but it is because this misunderstanding has spread. Mikael4u (talk) 00:01, 27 July 2023 (UTC)
replies: text: Sounds right, I added a note to the table copying your text. Spitzak (talk) 04:13, 27 July 2023 (UTC)
replies: text: You say that IBM claims 0xE9 is upper case theta, but it seems to be Microsoft that does this, see "0xe9 0x0398 #GREEK CAPITAL LETTER THETA" in https://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/PC/CP437.TXT . IBM designed CP437 and the purpose was probably that 0xE9 should be lower case theta as that is much more useful in science. Mikael4u (talk) 13:45, 27 July 2023 (UTC)
replies: text: Yea I have no idea where that unicode code point comes from, I just copied the other footnotes, all of which say "IBM says...". Spitzak (talk) 15:55, 27 July 2023 (UTC)

text: See the IBM references linked in the article. This might be a multiple-use character like many others, but it is IBM that claims its GCGID is GT620000 "Theta Capital" and the image in CP00437.pdf shows an upper case theta with separated stroke inside just like you describe. – MwGamera (talk) 12:44, 3 August 2023 (UTC)
thread_title:  Probably lower case theta 

message: The first paragraph in the Display adapters section has issues and contradicts information elsewhere in the article. The problems are the claims about the 9px width of some of the fonts. While it is correct that in certain modes these fonts' characters are rendered in a 9x14 and 9x16 matrix, respectively, none of these fonts have any 9px wide characters actually stored in the ROM. What's stored is one byte per character line – 8 bits and pixels. That a ninth column is displayed onscreen is a function of logic built into the relevant graphics cards (mostly MDA and VGA). That extra column is mostly empty, except for characters C0–DF as explained here. While it is just arguable the current article phrasing is not strictly incorrect (on grounds of the "9×14 pixels-per-character font stored in the ROM" being a font for the 9×14 character matrix, but not an actual 9x14px font), that defence is really stretching it, and at the very least, the present phrasing is highly misleading. —ReadOnlyAccount (talk) 02:19, 18 November 2023 (UTC)
thread_title:  Misleading: 9×16 and "9×14 pixels-per-character font stored in the ROM" 

message: It very slightly bothers me that the article includes the "csPC8CodePage437" moniker (which is in some source, but I have no idea how common that concatenated and camelCased name ever was – sus), but then leaves that pseudorandom-seeming string unexplained. One really has to dig through the cited source to find explanations (in different places) that make it clear that cs is for character set and PC8 for PC 8-bit. (There is an entry further down the page that annotates "PC8-Danish-Norwegian" as being the "PC Danish Norwegian 8-bit PC set".) —ReadOnlyAccount (talk) 19:28, 3 December 2023 (UTC)
thread_title:  csPC8CodePage437RTFMBBQROFLMAO 

message: Given that the placement indicates a primarily mathematical usage, this redirect without a note seems a bit awkward. It seems the character used to redirect to Unicode subscripts and superscripts up until recently, which seems more appropriate here Nethy00 (talk) 23:07, 14 January 2024 (UTC)
thread_title:  " ⁿ " (U+207F, FXC in table) redirects to phonetics article