I know also that the MCGA-based PS/2 Model 30 has its own 8x19 and 9x16 fonts, which look similar to the "standard" IBM VGA font, but have shorter descenders and more pronounced umaluts, rounder 0 and Os, the latter with a strikethrough.

In the Hercules/EGA machine type, the machine uses a zero character with a strikethrough, but in any VGA machine type, it uses a zero with a strikethrough.

When I was talking about the 225 line mode, I meant that in order to get all the text characters to be shown within the viewable screen area on a real monitor, you have to adjust the vertical size knob. However, 200-line graphics modes are squished unless you adjust the vertical size knob again (located usually on the back of the monitor). This is not too big of a deal on early Tandys because you could set "TV Mode" and order the video controller to use 200-line text modes or you could use the Tandy MODE command MODE 200 to get the same result in DOS. However, on later Tandys, starting with the TL, using MODE 200 with an 80-columns will give you an unusable rolling display.

That should only be a problem for people who adjust their screens to have the edges of the 200 line images touch the bezel. Most people will have adjusted the 224 line image to touch the bezel and will have accepted 12 lines of overscan top and bottom in graphics modes.

The model 30 BIOS ROM contains five extra8x16 fonts:

1. A double-width serif font that is identical, byte-for-byte, to the VGA's 8x16 font.
2. A thin serif font that may pass as an 8x16 counterpart to the CGA's thin 8x8 font.
3. Three thin (and butt-ugly) sans serif fonts with different X-Sizes. (Are those ISO fonts?)

The MCGA is described in IBM's technical reference as only supporting 8x16 fonts in text mode and 8x8 fonts when using BIOS in graphics modes. That is why I doubt that any of these fonts should be considered 9x16. A typical sign of a 9x16 font is that when viewed as an 8x16 font, there is no space between consecutive Ms. This is not the case with any of the five fonts in the PS/2 model 30 BIOS ROM.

There seems to be a separate section of the model 30 ROM which has the standard VGA 8x8, 8x14, 9x14, 8x16 and 9x16 fonts as well, in addition to the five listed above. I'm not sure which one gets used in what circumstances.

The 8x8 font in the Tandy 1000 video hardware seems to be the ugly ScummVM font. Because the ROM chip also has a 8x14 font, I suspect that it comes from a later Tandy that also supports 640x200x16 mode.

Attached find pictures of all the PC fonts I have.

Well, my 8x12 font is now usable as a TSR (for DOSBox or real VGA), thanks to ripsaw's code. At 640x480, this gives you 40 rows of text, and scales nicely with aspect correction. Sticking this here for download, in case anyone finds it useful.

Slight necrobump, but I finally had some time to go ahead with those TrueType font conversions, so this probably belongs here.

@MestreLion:
Looks like you haven't updated your port lately, but perhaps you'd like to beta-test the attached .ttf fonts with it? All three use TrueType outlines, but should perfectly conform to the bitmap glyphs in 80-column text mode (which is useful for Rogue).

These particular versions use CP437 encoding, and Windows groks them as "OEM/DOS" -- this solves the encoding issues that you get with most .ttf DOS-throwback fonts out there, but I'm curious to know if that's also true under Linux. If a different mapping is required, I'll make it work. The size you want to use here is 16px (which is 12pt, at 96 DPI).

About those Tandy 1000 fonts:

I'm still not 100% clear on which of the two different 8x8 Tandy fonts are used where (machine model, BIOS vs. character ROM). This post over at the VCF does sort out the model question, but according to that, all those charsets come from the BIOS (BIOS versions 01-0X-00 have the older font, and 02-0X-00 have the revised one). Perhaps Great Hierophant or NewRisingSun could confirm whether or not that's correct.

BTW, it seems like the newer Tandy fonts (both 8x8 and 8x14) were sourced from the DOS 3.3 .CPI files, which obviously differ from the IBM BIOS/hardware fonts (haven't done a diff test, but at least at a glance the Tandy and .CPI fonts seem to be identical).

VileRancour wrote:

Slight necrobump, but I finally had some time to go ahead with those TrueType font conversions, so this probably belongs here. […]
Show full quote

Slight necrobump, but I finally had some time to go ahead with those TrueType font conversions, so this probably belongs here.

@MestreLion:
Looks like you haven't updated your port lately, but perhaps you'd like to beta-test the attached .ttf fonts with it? All three use TrueType outlines, but should perfectly conform to the bitmap glyphs in 80-column text mode (which is useful for Rogue).

These particular versions use CP437 encoding, and Windows groks them as "OEM/DOS" -- this solves the encoding issues that you get with most .ttf DOS-throwback fonts out there, but I'm curious to know if that's also true under Linux. If a different mapping is required, I'll make it work. The size you want to use here is 16px (which is 12pt, at 96 DPI).

Such necros are more than welcome! 😁

Yes, the project has kinda stalled when it reached a fully-functional state (if you don't mind playing without save/reload, Ironman-style 😉. I've added a list of 12 issues, fully detailing areas the project need work and love (and help!) at https://github.com/MestreLion/roguepc/issues

About your font: glyphs and metrics look great, congrats!

About the encoding: to be usable in Unicode terminals (Mac OSX, Linux, BSD, etc), the CP347 glyphs need to mapped to their corresponding Unicode codepoint. For example, the "happy face" at 0x0001 must be at 0x263A, and the "clubs" symbol at 0x0005 must be 0x2663. The non-ASCII characters actually used in Rogue are listed at https://github.com/MestreLion/roguepc/blob/ma … c/curses.c#L192, and the full list I've used as reference for mapping the CP437 to Unicode is https://en.wikipedia.org/wiki/Code_page_437#Characters.

For "Perfect DOS VGA CP437" I manually edited in FontForge most of the 255 glyphs to change their Unicode Value to the correct one, which in turn triggered an automatic update to their names and references, so the "happy face" is officially called "'smileface' WHITE SMILING FACE". But I'm a total dummy in FontForge, so not sure if there's an easier way to do this massive remapping.

Also, if you're willing to share this font with my humble project, don't forget to add a license TXT or something to the zipfile. I strongly recommend Creative Commons' CC-BY-SA 3.0 (https://creativecommons.org/licenses/by-sa/3.0/), as it's the most suitable for non-software intellectual work used in open source / free software projects.

Once again, thank you very much for this!

MestreLion wrote:

About the encoding: to be usable in Unicode terminals (Mac OSX, Linux, BSD, etc), the CP347 glyphs need to mapped to their corresponding Unicode codepoint.

In that case you could just go with the 'true' Unicode variants I've been working on - here's a beta version of the CGA one. I thought this would be overkill as it has >700 glyphs for various scripts, but one of your github issues is support for UTF8 text input, so might as well kill two birds with one stone. 😉

One thing to keep in mind though. I had to deviate a little from the "canonical" CP437->Unicode mapping, for two reasons: (1) CP437 is ambiguous, and (2) I sourced the non-Latin characters from international CGA ROMs where possible, and some of them conflict with the original US CGA charset (CP437). For instance there's the full Greek alphabet from a Greek CGA card (courtesy of our fellow vogoner keropi), and the glyph for "τ" differs from the CP437 CGA "τ"... which happens to be the 'stick' in Rogue.
Of course, I wouldn't dare desecrate the One True Charset, so the original CP437 "τ" is still there 😁 I just mapped it to, uh, lemme check... 0x1D1B ("Latin Small Letter Capital T", it sez 'ere):

That's why I was hoping that the plain cp437 .ttf would "just work", but I guess you could either change the mapping in your code, or in the font itself using FontForge or similar. Anyway, looking at your list, I'm pretty sure that would be the only 'problematic' character.

For "Perfect DOS VGA CP437" I manually edited in FontForge most of the 255 glyphs to change their Unicode Value to the correct one, which in turn triggered an automatic update to their names and references, so the "happy face" is officially called "'smileface' WHITE SMILING FACE". But I'm a total dummy in FontForge, so not sure if there's an easier way to do this massive remapping.

You can actually load custom encodings in .txt or .ps formats and then use the Force Encoding option to do it in one fell swoop. If it wasn't for that, I'd probably have given up by now...

Also, if you're willing to share this font with my humble project, don't forget to add a license TXT or something to the zipfile. I strongly recommend Creative Commons' CC-BY-SA 3.0 (https://creativecommons.org/licenses/by-sa/3.0/), as it's the most suitable for non-software intellectual work used in open source / free software projects.

Hm, I was gonna go with CC-BY-NC-SA 4.0 (which is what I put in the font's Names table), but it's not set in stone. I suppose the "NC" would conflict with GPL projects? Any reason to prefer 3.0 over 4.0?

VileRancour wrote:

MestreLion wrote:

About the encoding: to be usable in Unicode terminals (Mac OSX, Linux, BSD, etc), the CP347 glyphs need to mapped to their corresponding Unicode codepoint.

In that case you could just go with the 'true' Unicode variants I've been working on - here's a beta version of the CGA one. I thought this would be overkill as it has >700 glyphs for various scripts, but one of your github issues is support for UTF8 text input, so might as well kill two birds with one stone. 😉

CGA80normalUnicode_BETA_TrueType.zip

Yessss!! In this font the glyphs are in the "proper" codepoints, sweet! I didn't have the time (yet) to do a comprehensive check, but some of the key chars are in the expected codepoints, so great!. I've also noticed you've kept the sub-0x0020 codepoints with their CP437 glyphs (are they glyph aliases?), an interesting approach.

VileRancour wrote:

One thing to keep in mind though. I had to deviate a little from the "canonical" CP437->Unicode mapping, for two reasons: (1) CP437 is ambiguous

Well, for practical purposes it's not. I mean, as Wikipedia says, one could argue if CP437 0xE1 is supposed to be a german "SS" or a greek "B"eta, but the solution is for the font to have both Unicode values share the same glyph... so you get the same CGA/VGA DOS glyph regardless if you asked for U+00DF or U+03B2. So when there's ambiguity, just include all possibilities. Also, there is a somewhat "official" CP437->Unicode 1:1 mapping, used by the Linux Kernel, projects like DosBox, VirtualBox, etc, that matches the table shown in Wikipedia.

VileRancour wrote:

(2) I sourced the non-Latin characters from international CGA ROMs where possible, and some of them conflict with the original US CGA charset (CP437). For instance there's the full Greek alphabet from a Greek CGA card (courtesy of our fellow vogoner keropi), and the glyph for "τ" differs from the CP437 CGA "τ"... which happens to be the 'stick' in Rogue.

Of course, I wouldn't dare desecrate the One True Charset, so the original CP437 "τ" is still there 😁 I just mapped it to, uh, lemme check... 0x1D1B ("Latin Small Letter Capital T", it sez 'ere)

Lol, that requires some creativity! 😜 You'll have lots of trouble with this approach, as even ordinary letters such as "a" and "b" etc have different glyphs, and most importantly, different *baselines* when comparing the original CP437 with DOS codepage fonts such as 850, 852, etc. Sooner or later you might need to to create different font files, one where the original CP437 glyphs take precedence over the tweaked regional ones (even if each font include all glyphs)

VileRancour wrote:

That's why I was hoping that the plain cp437 .ttf would "just work", but I guess you could either change the mapping in your code, or in the font itself using FontForge or similar. Anyway, looking at your list, I'm pretty sure that would be the only 'problematic' character.

I'm trying to avoid such "custom" mappings in code, as the game have no control over the font (or even *know* which font is being used!). So I'm sticking with 0x03C4 for the stick (no pun intended), as per the "official" mapping.

VileRancour wrote:

For "Perfect DOS VGA CP437" I manually edited in FontForge most of the 255 glyphs to change their Unicode Value to the correct one, which in turn triggered an automatic update to their names and references, so the "happy face" is officially called "'smileface' WHITE SMILING FACE". But I'm a total dummy in FontForge, so not sure if there's an easier way to do this massive remapping.

You can actually load custom encodings in .txt or .ps formats and then use the Force Encoding option to do it in one fell swoop. If it wasn't for that, I'd probably have given up by now...

Nice!!!! Omg, it took me hours to do that manually! What a life-saver hint, thanks!

VileRancour wrote:

Also, if you're willing to share this font with my humble project, don't forget to add a license TXT or something to the zipfile. I strongly recommend Creative Commons' CC-BY-SA 3.0 (https://creativecommons.org/licenses/by-sa/3.0/), as it's the most suitable for non-software intellectual work used in open source / free software projects.

Hm, I was gonna go with CC-BY-NC-SA 4.0 (which is what I put in the font's Names table), but it's not set in stone. I suppose the "NC" would conflict with GPL projects? Any reason to prefer 3.0 over 4.0?

Yes, NC conflicts not only with GPL but with any other free software license, such as the populars MIT, BSD, Apache, etc. An option if you really want to go the NC route is granting a CC-BY-SA (without the NC) license for individual projects (such as Rogue), while keeping the NC for everything else. But that's an approach usually frowned upon in the FOSS community, so I don't recommend it. I personally think BY (attribution) and SA (Share-Alike) are far more relevant for an author than NC.

As for 3.0 over 4.0, I was just not aware there was a 4.0 already 😀 After a quick research, it seem to be a nice and welcome upgrade

MestreLion wrote:

I mean, as Wikipedia says, one could argue if CP437 0xE1 is supposed to be a german "SS" or a greek "B"eta, but the solution is for the font to have both Unicode values share the same glyph... so you get the same CGA/VGA DOS glyph regardless if you asked for U+00DF or U+03B2. So when there's ambiguity, just include all possibilities.

That could be a good approach for the "pure" CP437 versions, but as noted, the expanded/multi-language fonts are merged from different sources, and the "beta" glyph from the Greek hardware font is not the same as the "beta" in the US/437 hardware font. I've had much deliberation about this approach, but alas, there seems to be no way to have the cake (=support multiple languages using international hardware charsets) and eat it too (=stay 100% true to CP437) with one single Unicode font. You've already come to the same conclusion anyway, heh.

Also, there is a somewhat "official" CP437->Unicode 1:1 mapping, used by the Linux Kernel, projects like DosBox, VirtualBox, etc, that matches the table shown in Wikipedia.

There are at least two such official mappings... one that interprets 0x00-0x20 as graphical symbols (1) and one that maps them to control codes (2). My 'expanded' font does both, as you've noticed - I'm not about to investigate which environments use what mappings (under which conditions), so I'm just covering all bases... mainly for the sake of oldschool ASCII art that uses those chars. It'd probably be a good idea to add this double-mapping to the "pure" CP437 version of the font, too, but I'd have to test whether or not that breaks things in Windows (fonts aren't recognized as "DOS/OEM" across the board unless mapping #2 is present, but that's just my observation so far).

Lol, that requires some creativity! 😜 You'll have lots of trouble with this approach, as even ordinary letters such as "a" and "b" etc have different glyphs, and most importantly, different *baselines* when comparing the original CP437 with DOS codepage fonts such as 850, 852, etc.

That's one of the first things I noticed when I started working on this, but it's not a real "problem" because on the bottom line, the DOS .CPI fonts simply aren't what I'm going for. As you say, they're inconsistent in style and baseline placement (vs. cp437, but even between different DOS versions). Plus they're not relevant in all cases- e.g. CGA/Hercules/MDA and most of their clones had no soft-font support, so no DOS codepages at all. I just go with original hardware fonts where possible, fill in the rest as appropriate, and map CP437 glyphs to alternative encodings *in case* they conflict with international ones.

OTOH, as already mentioned, the later Tandy 1000 models seem to have actually sourced their hardware fonts from the PC/MS-DOS 3.3 .CPIs, so I might create a separate unified set for those and use the PC-DOS codepages for the regional chars. 😉

Sooner or later you might need to to create different font files, one where the original CP437 glyphs take precedence over the tweaked regional ones (even if each font include all glyphs)

For now I'm sticking to one "strict" CP437 version without regional alphabets, and one expanded version where the international glyphs take precedence. For many of the less-common cards, CP437 is all that's available anyway (at least to me), so I think only CGA/EGA/VGA/MDA/Tandy will get the expanded versions and all that silly AST/Kaypro/ATI/Amstrad etc. stuff will be 437-only.

Of course, with a CC license, you (or anyone else) would be free to mix and match things to your choosing, although the two variants should still give you enough flexibility without resorting to that. CC-BY-SA sounds good, but this is all theoretical at this point, since it remains to be seen whether I ever get this damn thing done. 😁