VOGONS


BIOS font legal status

Topic actions

Reply 20 of 47, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

It's possible there is no way to revert to the internal BIOS font once a codepage font is loaded, at least not in the same session; but it doesn't seem like something a person would typically need to do, and it's easy enough to restart DOSBox.

MestreLion wrote:

I will gladly include a CGA True Type font in the project if I get one... do you know or have any?

No, but I've made a fairly comprehensive set of IBM fonts in Windows raster format. Raster fonts are so much easier to work with than TrueType when trying to reproduce DOS bitmap fonts.

MestreLion wrote:

As for being aware of the 40-column mode, yes, I am... actually, having ported the game from 83' 16-bit DOS to 2015 32/64-bit POSIX, I've *had* to be aware of that and all other platform-dependent things in Rogue, including the many assembly files, which I "translated" to C and documented as best as I could. I'm also trying to preserve all modes such as the DEMO mode and the "Software Pirate killed by the Copy Protection Mafia", as well as true underline for mode 7.

I'm not aware of a demo mode, is it a feature of Epyx Rogue? I'm more familiar with the original AI Design versions. Yes, the "crack attempt detected" mode of Rogue is hilarious not just for the epitaph, but also the hindrances during gameplay, like invisible monsters. 😀

Reply 21 of 47, by MestreLion

User metadata
Rank Newbie
Rank
Newbie
ripsaw8080 wrote:

It's possible there is no way to revert to the internal BIOS font once a codepage font is loaded, at least not in the same session; but it doesn't seem like something a person would typically need to do, and it's easy enough to restart DOSBox.

That's true *after* you learn the hard way that those are 2 distinct fonts 😜 I've spend *hours* trying to find why my screenshots using xterm didn't match DOSBox. Problem was not about the glyphs per-se, but the y-position ("baseline"?) difference in letters and punctuation. It seems in the BIOS font all letters baseline is 1-pixel higher, and 2 pixels for `:`, and this difference was drving me crazy before I find out what was going on 😜

ripsaw8080 wrote:

No, but I've made a fairly comprehensive set of IBM fonts in Windows raster format. Raster fonts are so much easier to work with than TrueType when trying to reproduce DOS bitmap fonts.

Indeed... I'm having a hard time with FontForge 😀 What is the "Windows raster format" ? Is it the `bdf` or `psf`? If so, yes, I'd be interested, as `xterm` accepts them. Not sure about gnome-terminal tho, but I could try.

ripsaw8080 wrote:

I'm not aware of a demo mode, is it a feature of Epyx Rogue? I'm more familiar with the original AI Design versions. Yes, the "crack attempt detected" mode of Rogue is hilarious not just for the epitaph, but also the hindrances during gameplay, like invisible monsters. 😀

The demo was `#ifdef`'ed in the source code, but after porting the "normal" mode I've also made the demo functional again, now as a compile-time option in the Makefile, and I'm planning on adding it as a command-line option in the future.

It has a level limit (10) and time limit (10 minutes minimum + 1 minute for each level), the rip screen is revamped (no tombstone, different kill message), it does not save score (or game files), and it has a hilarious easter egg when you quaff a Monster Detection potion 😀

Reply 22 of 47, by MestreLion

User metadata
Rank Newbie
Rank
Newbie
ripsaw8080 wrote:

Yes, the "crack attempt detected" mode of Rogue is hilarious not just for the epitaph, but also the hindrances during gameplay, like invisible monsters. 😀

There are no invisible monsters, but monsters get a damage multiplier of 6, so you'll most likely be killed in your first encounter with a Bat 😜

This and the epitaph are just regular media copy protection, but the game also tried to detect if it was running inside a debugger, if the executable was cracked, etc, all of which lead to instant HALT of the PC 😀

Reply 23 of 47, by MestreLion

User metadata
Rank Newbie
Rank
Newbie

If you want to check it out, the code is hosted on github:

https://github.com/MestreLion/roguepc

I haven't "annouced" the project to the community yet, as I'm not sure about the license and legal status of the original code, so the project does not even have a README yet, but feel free to PM me if you want screenshots or instructions on how to run it...

The font I'm working on is from another project of mine:

https://github.com/MestreLion/pyrogue/blob/ma … A437Unicode.ttf

Reply 24 of 47, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

Well, invisible *somethings* appear when the game detects (with a checksum) that the executable is modified. They block your way, and in a corridor are impassable. You get messages like "You don't hit it." or "You hit you."

Windows raster fonts are also referred to as bitmap or console fonts, and typically have a .FON file extension. You can find the IBM pack I made here.

Since you seem to be interested in reworking old DOS textmode games, let me direct your attention to a thing I worked on.

Reply 25 of 47, by leileilol

User metadata
Rank l33t++
Rank
l33t++

I think Fontstruct had some DOS font recreations, but given that's a web-based fontmaking app there's not a lot of flexibility to be had there. It's mostly a pure fake raster-through-vector thing.

Codeman38 also has made the "PC Senior" font which is pretty old now 😀

apsosig.png
long live PCem

Reply 26 of 47, by MestreLion

User metadata
Rank Newbie
Rank
Newbie
ripsaw8080 wrote:

Well, invisible *somethings* appear when the game detects (with a checksum) that the executable is modified. They block your way, and in a corridor are impassable. You get messages like "You don't hit it." or "You hit you."

The codebase I'm working on (the same DOS Rogue source code available on the net) has no such "impassable", invisible "things". With my (quite limited) assembly knowledge, I've found (and ported) roughly 3 kinds of protection:
- Media copy protection, based on floppy signature at some key, corrputed disk sectors. Checked only on game start. If fails, it leads to lead to the "pirated" mode with the epitaph, 6 * hit, etc
- Executable integrity checksum: checked on every new level after the first. if fails, lead to HLT (halts the PC, rebooting required)
- Running inside a debbugger, one-steppers, or any other form of "encapsulating" the game: immediate HLT after 20 clock ticks (~1 sec)

ripsaw8080 wrote:

Windows raster fonts are also referred to as bitmap or console fonts, and typically have a .FON file extension. You can find the IBM pack I made here.

Since you seem to be interested in reworking old DOS textmode games, let me direct your attention to a thing I worked on.

Thanks! I'll take a look if Gnome (or X) can handle FON fonts. And thanksfor the URLs, the 2nd one is surely an interesting project 😀

Last edited by MestreLion on 2015-03-29, 21:33. Edited 1 time in total.

Reply 27 of 47, by MestreLion

User metadata
Rank Newbie
Rank
Newbie
leileilol wrote:

I think Fontstruct had some DOS font recreations, but given that's a web-based fontmaking app there's not a lot of flexibility to be had there. It's mostly a pure fake raster-through-vector thing.

Codeman38 also has made the "PC Senior" font which is pretty old now 😀

Thanks! I've found those Fontstruct fonts when searching for VGA fonts. But the former is a "scanline" font, and the latter is a "bold" version, and the glyphs are not based on neither VGA BIOS nor IBM CP437 (slashed zero for example).

Reply 28 of 47, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author
MestreLion wrote:
The codebase I'm working on (the same DOS Rogue source code available on the net) has no such "impassable", invisible "things". […]
Show full quote

The codebase I'm working on (the same DOS Rogue source code available on the net) has no such "impassable", invisible "things". With my (quite limited) assembly knowledge, I've found (and ported) roughly 3 kinds of protection:
- Media copy protection, based on floppy signature at some key, corrputed disk sectors. Checked only on game start. If fails, it leads to lead to the "pirated" mode with the epitaph, 6 * hit, etc
- Executable integrity checksum: checked on every new level after the first. if fails, lead to HLT (halts the PC, rebooting required)
- Running inside a debbugger, one-steppers, or any other form of "encapsulating" the game: immediate HLT after 20 clock ticks (~1 sec)

The game develops a number of odd behaviors when the executable checksum fails, including the invisible things. In version 1.1 you tend to be killed by the Mafia so quickly that you don't have much chance to notice; but version 1.0 has no Mafia, so you have plenty of time to experience the strangeness.

Reply 29 of 47, by MestreLion

User metadata
Rank Newbie
Rank
Newbie
ripsaw8080 wrote:

The game develops a number of odd behaviors when the executable checksum fails, including the invisible things. In version 1.1 you tend to be killed by the Mafia so quickly that you don't have much chance to notice; but version 1.0 has no Mafia, so you have plenty of time to experience the strangeness.

Perhaps this has changed from 1.0/1.1 to this codebase (which is supposedly Epyx v1.48... is has slimes, splash screen, rank names, etc). In this, there seems to be no invisible things in the code at all (apart from Phantoms, of course), and the executable checksum and the floppy checksum are independent checks. If you have copied the floppy but did not tamper with the executable, only the "Mafia" stuff would be active (and you would die pretty quickly 😀. OTOH, executable (or environment) tampering just leads to HTL, again with no invisible stuff.

Reply 30 of 47, by MestreLion

User metadata
Rank Newbie
Rank
Newbie

About fonts again: I've noticed the Dosbox codepage 437 glyphs do not match the ones in this IBM pack, so now I'm really confused, as it seems to have 3 distinct fonts for 437, with distinct glyphs and baselines, and I'm not sure which ones should match:

- 1 - On DOSBox start, with keyb=none: "fat" 0 with square center dot. Is this the VGA BIOS font?
- 2 - DOSBox builtin CP437, swtiching to another codepage and then switching back to 437: "thin" 0 with vertical center, lowered baseline
- 3 - CP437.F16 in EGA.CPI from IBM's pack: thin 0, most chars match Dosbox builtin cp437 (2), but baseline better matches Dosbox "VGA" (1)

Glyphs from (2) seem to be a mix from (1) and (3): thin 0, but Ç and É from (1) and 2 are very distinct. its baseline is unique: all letters are lowered 1 px, it's the only one that the top of $ is not aligned with the top, and `:` is further lowered to touch the baseline.

Baseline from (1) and (3) matches, but their glyphs are distinct: 0, Ç, É, double arrow, tau, ² etc.

I really don't know which one I should choose as reference to edit "Perfect DOS VGA". Its glyphs and baseline seem to closely follow IBM's pack (Ive already fixed the few discrepancies). It has the best glyphs for Rogue (the extended tau for stick, the polished 0), but the unique baseline of (2) is very interesting, apart from the lowered `:`

Can someone plese clarify me why (1) (2) and (3) are so distinct? Are they supposed to? Any suggestions on which should I use as a reference for Perfect DOS VGA?

Reply 31 of 47, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

In a real VGA BIOS the 8x16 font has narrow symbols suitable for an 8-dot character clock (640 pixel wide display), and there is a list of alternate wide symbols for certain characters (0, M, T, W, Z, etc.) that are substituted when the display is using a 9-dot character clock (720 pixel wide display), with 9-dot being the default display mode.

DOSBox supports both 640 and 720 pixel wide text display with the machine=vgaonly setting; the other VGA machine types only support 640. The 8x16 font in DOSBox's emulated video BIOS has the 9-dot wide alternate symbols already applied, meaning the narrow symbols are not present. As such, the wide symbols have correct gaps between characters only with machine=vgaonly.

So, I think what you're seeing is the narrow symbols in the codepage sets replacing the wide symbols in the BIOS font.

At some point DOSBox may emulate the narrow versus wide font behavior more accurately, but it's not a priority.

Reply 32 of 47, by VileR

User metadata
Rank l33t
Rank
l33t
MestreLion wrote:

They would surely be very valuable to me!

I'm currently using "Perfect DOS VGA", as this was the *only* TTF font I could find on the internet that strives (not sure if it achieves) pixel fidelity. But it required a *lot* of work (remapping CP437 glyphs to their proper Unicode code points, etc), so it would be awesome if I could compare it with your TTF fonts (and perhaps stop reinventing the wheel) 😀

Also, legal status of "Perfect DOS VGA 437" is debatable, so if you could license your TTF to me with GPL/BSD/MIT/CC I would gladly include it in my project, with full credit of course (the project will be released as GPLv3+)

I didn't get very far with that yet, but I was actually planning to go back to this soon. Maybe once I'm done with my current project around next week.

In the meantime, this sample might illustrate my level of 'ambition'... or futility, heh (click to enlarge):

WIP_BlueTerm_unicode.png
Filename
WIP_BlueTerm_unicode.png
File size
24.54 KiB
Views
2472 views
File license
Fair use/fair dealing exception

^ this one isn't really a BIOS font clone (glyphs are based on the 8x14 EGA font, but I've adapted them to a line height of 12, since I'm aiming at an alternative for Windows' Terminal font). I plan to apply the same methodology to the actual BIOS fonts, though- all those different codepages will be mapped to their respective Unicode positions, as shown. Of course, some re-interpretation would need to be applied, since (as has been noted) the BIOS fonts and DOS codepage fonts do not always match.

Oh yeah: if anyone can think of a clever/creative name for those .ttf BIOS-based font sets, I'm looking for suggestions 😀

For now, you could try the 'Nouveau IBM' font, if it hasn't been mentioned yet: http://www.dafont.com/nouveau-ibm.font

The benefit with this one is that it actually scales nicely with those diagonal outlines, but at 12pt you should get the original rendering. There's also the "stretch" version, which is more or less true to the VGA aspect ratio, so it looks even more authentic at larger sizes (of course, the tradeoff is no pixel-perfect rendering on today's square-pixel displays).

[ WEB ] - [ BLOG ] - [ TUBE ] - [ CODE ]

Reply 34 of 47, by NewRisingSun

User metadata
Rank Oldbie
Rank
Oldbie

As has probably been mentioned before, even IBM's fonts differ slightly from source to source:

  • The MDA 9x14 font, for example, is different from the EGA 9x14 font and looks surprisingly ugly. (The EGA BIOS' 8x14 and 9x14 fonts are identical to the VGA BIOS').
  • The thick 8x8 font in the on-board character ROM on the CGA (for text modes) differs ever so slightly from the 8x8 font in the IBM PC's ROM BIOS at FFA6E (for graphics modes). The differences are in characters $05, $06, $0F, and $53 (capital S). It is the ROM BIOS version that is reproduced in the EGA and VGA BIOSes.
  • The 8x8 font in the IBM PC ROM BIOS differs slightly between BIOS versions 81-04-24 and 81-10-19: the earlier version has a garbage pixel in character $04. This is not an issue of a bad image of the ROM, as the different value is reproduced in the ROM BIOS listing of the first edition of the IBM PC Technical Reference book.

The Tandy 1000 fonts are interesting as well. They mainly differ from IBM's fonts in the more rectangular "O" character. The 128 characters in the Tandy BIOS at FFA6E (for graphics modes) are shifted to the right by one pixel compared to IBM's fonts, while the ones in the Tandy's character ROM (for text modes) are not shifted. The shifted characters in graphics modes are the reason why Servo's Mobygames screenshots, produced with a CGA card installed in a Tandy 1000, have incorrect artifact colors around text. (The Tandy 1000's text mode font is actually 8x9, but the ninth line is always identical to the eighth.)

Reply 35 of 47, by Zorbid

User metadata
Rank Member
Rank
Member
VileRancour wrote:

For now, you could try the 'Nouveau IBM' font, if it hasn't been mentioned yet: http://www.dafont.com/nouveau-ibm.font

The benefit with this one is that it actually scales nicely with those diagonal outlines, but at 12pt you should get the original rendering. There's also the "stretch" version, which is more or less true to the VGA aspect ratio, so it looks even more authentic at larger sizes (of course, the tradeoff is no pixel-perfect rendering on today's square-pixel displays).

FWIW, on my Mac, at least, it looks like the original at 16pt, without AA.

Reply 36 of 47, by Great Hierophant

User metadata
Rank l33t
Rank
l33t
NewRisingSun wrote:
As has probably been mentioned before, even IBM's fonts differ slightly from source to source: […]
Show full quote

As has probably been mentioned before, even IBM's fonts differ slightly from source to source:

  • The MDA 9x14 font, for example, is different from the EGA 9x14 font and looks surprisingly ugly. (The EGA BIOS' 8x14 and 9x14 fonts are identical to the VGA BIOS').
  • The thick 8x8 font in the on-board character ROM on the CGA (for text modes) differs ever so slightly from the 8x8 font in the IBM PC's ROM BIOS at FFA6E (for graphics modes). The differences are in characters $05, $06, $0F, and $53 (capital S). It is the ROM BIOS version that is reproduced in the EGA and VGA BIOSes.
  • The 8x8 font in the IBM PC ROM BIOS differs slightly between BIOS versions 81-04-24 and 81-10-19: the earlier version has a garbage pixel in character $04. This is not an issue of a bad image of the ROM, as the different value is reproduced in the ROM BIOS listing of the first edition of the IBM PC Technical Reference book.

The Tandy 1000 fonts are interesting as well. They mainly differ from IBM's fonts in the more rectangular "O" character. The 128 characters in the Tandy BIOS at FFA6E (for graphics modes) are shifted to the right by one pixel compared to IBM's fonts, while the ones in the Tandy's character ROM (for text modes) are not shifted. The shifted characters in graphics modes are the reason why Servo's Mobygames screenshots, produced with a CGA card installed in a Tandy 1000, have incorrect artifact colors around text. (The Tandy 1000's text mode font is actually 8x9, but the ninth line is always identical to the eighth.)

Then the EGA is using its own 9x14 font when emulating MDA?

I find the Tandy "b" and "d" characters have a larger loop than the IBM characters.

I can understand why Tandy went with 225-line text modes, but they will be cut off on TV monitors and play havoc with the aspect ratio for the 200-line graphics modes. Couldn't they have made it the optional mode and the 200 line mode the default mode?

http://nerdlypleasures.blogspot.com/ - Nerdly Pleasures - My Retro Gaming, Computing & Tech Blog

Reply 37 of 47, by MestreLion

User metadata
Rank Newbie
Rank
Newbie
VileRancour wrote:

In the meantime, this sample might illustrate my level of 'ambition'... or futility, heh

That's a very sweet project! And I look forward to its completion, or a beta release... a ttf font with VGA glyphs, mapped to unicode, from people who know what they're doing (ie, not me 😜), would be a wonderful asset to the rogueligue community

VileRancour wrote:

For now, you could try the 'Nouveau IBM' font, if it hasn't been mentioned yet: http://www.dafont.com/nouveau-ibm.font

It was not mentioned here, but I've found it when searching the net for a VGA TTF font. It's an awesome font in many ways, and it was the *only* font I've found which glyphs are already mapped to unicode codepoints. It also have a clear CC-by-sa license, perfect for FOSS projects like mine. As a welcome bonus, it contains glyphs from several codepages, much beyond the 256 from CP437 I needed. (well, actually rogue only needs a dozen or so besides letters and puncuation).

But its main issue (and ironically also its main feature) are the glyphs themselves: they are *gorgeous*, have a very consistent style, perfect aspect ratio, and a unique design that's... very different from VGA/CP437 original ones 😜

As redrawing glyphs in a TTF font using FontForge is waaaay more work than re-mapping glyphs to their proper unicode codepoins, I chose to use 'Perfect DOS VGA 437' as base.

Reply 38 of 47, by NewRisingSun

User metadata
Rank Oldbie
Rank
Oldbie
Great Hierophant wrote:

Then the EGA is using its own 9x14 font when emulating MDA?

MDA:
font-mda.png
EGA:
font-ega.png
Obviously, the glyphs themselves are identical, but the spacing is weird on the MDA, especially between the I and B of "IBM". Watch this IBM-made video to see this on a real 5151 display.

Great Hierophant wrote:

and play havoc with the aspect ratio for the 200-line graphics modes.

Graphics modes remain at 200 lines. The Tandy video hardware uses 224 lines with an 8x9 font only for text modes.

Great Hierophant wrote:

Couldn't they have made it the optional mode and the 200 line mode the default mode?

Connecting a PC compatible to a TV was probably becoming unusual by late 1984/1985, especially when the Tandy 1000 with RGBI monitor could be had so cheaply.

Reply 39 of 47, by Joey_sw

User metadata
Rank Oldbie
Rank
Oldbie

Speaking of Bios or Graphic Card's fonts, i remember this weird experience:

Computer: 8088 XT
Graphics Card: CGA
Porgram used: BASIC-ROM or BASICA (that requires basic-rom to be present)
Problem: none

But, when i change the CGA card with some 3rd party VGA card (i believe it was 256KB RealTek VGA),
I suddenly found that INPUT statements in basica/basic-rom aren't working when its on screen 1 or 2 (mode 4 - 6).

Not quite remember what i was doing back then,
but i was arrive to conclusion that its happens because font that used in PRINT statement are slightly different on
what I type during the INPUT statement when it was on screen-mode 1 or 2.

iirc, i do not find the same problem when i use GW-Basic or QBasic on same 8088 with RealTek VGA.
I only have that particular problem with games/program that use BASICA to execute the .BAS files.

-fffuuu