PDCurses
PDCurses copied to clipboard
wmcbrine
New port: DOSVGA
This port compiles on MS-DOS, using the DJGPP, Watcom (16 or 32 bit) or Borland (16 bit only) compilers. It expects to find a VGA, and switches it to graphical mode to display the text.
If it finds VESA BIOS Extensions, it can use them to produce a larger display. The font size is fixed at 8 by 16 pixels.
It supports A_UNDERLINE, A_LEFT and A_RIGHT. Blink is mapped to bright background.
A correction to the testcurs.c demo is included, to fix an integer overflow in the extended color test.
Just compiled it, using Watcom 1.97 (haven't tried other compilers as yet), and it runs Just Fine in DosBox on my Xubuntu system. (Very slowly for a 16-bit compile, but at surprisingly decent speed in the much more reasonable 32-bit flat memory model.) I congratulate and thank you. I've had thoughts about doing something of this ilk, but the odds that I'd ever have had the time to do it were low. So I'm happy to piggyback on your work. A comment : I don't know how important international/wide-character support is for you. I see you're using the BIOS font; seems to me that Unifont would provide a straightforward way to get wide-character support... in fact, better wide-character support than most platforms can claim. Unifont provides a 8x16 pixel font for all characters (except fullwidth ones at 16x16), so you'd be looking at a megabyte file for the Basic Multilingual Plane. With possibly another couple of megs if you wanted to add the Supplemental Multilingual Plane so you could have emojis. Again, nice work, and I hope there's a way to get this pulled in.
Thank you, Bill. I started PCem and set up a 286 machine at 6 MHz. The tuidemo program ran veeerrryy slloooowly. I got busy rewriting the rendering functions and now it's much faster, though still slower than I would like on that emulation.
That does help. I now find that it runs slowly on DosBox in 16-bit mode (anything else would astonish me) and fairly fast in 32-bit mode, both on DosBox and a near-antique WinME machine. Keeping in mind that on DosBox, all your video work is being emulated rather than going through hardware, it's pretty impressive that it runs as fast as it does.
OK, just tried this out with my fork and, whaddaya know, it works nicely with only a few modifications.
Only one of those is probably of any interest to you : the font now comes from an array in font.h. Which means we can change fonts, add bold/italic ones, or different sizes, or wide-character fonts. (It does not, unfortunately, give us any real speedup.) I got the font from GNU Unifont; see hexize.c.
Guess I gotta try it out. Unifont is GPL'd code and is doubtful that the mainline will accept it. I wanted to avoid such issues.
Um. You have a point about the licence issue.
SDL1's default font is in common/font437.h, and "is based on the pc8x16s.bdf font from the vgafonts.tar.gz package." However, one can use any font, as described in the README for SDL1.
Looking around a bit turns up the misc-fixed fonts for X11 in the public domain. I'd assume there are other options.
I think I'd best hold off on trying to use misc_fixed until I educate myself on public domain fonts. misc_fixed does have the advantage of providing a variety of sizes, styles, and bold and italic fonts, as well as providing pretty good Unicode coverage.
I should perhaps note here that I've switched from GNU Unifont to a public domain VGA font. So we ought to be legal again. The font can be 8xheight where height <= 16, and you can now specify a font with the PDC_FONT environment variable, similar to SDL1.
Going from there to support of bold, italic, and wide-char fonts should be straightforward, but it'll probably be a while before I do anything more with this. Still hoping this port can make its way into mainline PDCurses.
The font width and height, by the way, are now variables, so one could conceivably even swap fonts while running. I assume any width other than 8 would fail at present, but suggest making it a variable rather than a fixed "magic number" in case that situation changes.
I should have mentioned in the commit for the PSF fonts: this also provides PDC_WIDE support.
I'll hold off on integrating these (very nice!) changes in my fork, both because I'm a little short on time and because it probably makes sense for me to wait until you're "done", rather than try to bring bits in piecemeal. I like the use of PSF2. I'd not realized this, but it will allow for fonts with 2^32-1 glyphs; i.e., unlike many font formats, it's not restricted to SMP only. PSF does restrict us to halfwidth forms, but I even see a way around that. (Store fullwidth glyphs with the first half as one glyph, and the second half as a glyph in the Unicode Private Use Area, adjacent to it in the font.) Much of what you've got in this platform could be recycled for a Linux framebuffer version. We would use your code, slightly modified, for display, and perhaps my VT code for keyboard/mouse input. I've long thought that such a platform would be a good idea for embedded systems where X would be ludicrous overkill; it would work even on really cut-down Linux systems. A "PDFont" (consisting, at least at first, of just the public domain parts of Unifont... which is a lot of it) would come in handy. A lot of PSF fonts provide only 256 or 512 glyphs (even the psf2 fonts, which are entirely capable of handling more glyphs.)
@Bill-Gray I'm confused now, isn't the dosvga port in your repo using the most current code found here? If yes are there some other things than the 4.x feature set that you've adjusted?
True. Back on March 3, there had been quite the flurry of commits for the DOSVGA port, and I thought I'd hold off on pursuing a moving target. It's been stable since then, so on May 1, I pulled the rest of @chasonr's changes (use of PSF2 fonts and wide-char builds) into my fork.
The DOSVGA in my fork is now identical to @chasonr's, except for about a dozen lines.
Is there any option for wide support in this fork? https://github.com/Bill-Gray/PDCurses/pull/136 hints that as soon as wide is defined a bunch of type mismatch errors and truncation warnings occur.