VGA ROM Fonts (2020) | Hacker News Reader

VGA ROM Fonts (2020)

alexandrugroza.ro

88 pointsLammy45 comments

Font loader TSRs... Blast from the past there. You don't have to have the font table resident in the "resident" kernel of the TSR, hook timer and 21h and use the timer to check if the VGA font table has been changed; when it has, raise a flag and next 21h hook can safely re-read that data from a file and cram it into video ram again.

Do you recall "DOSBLOOD.EXE", a font loader TSR that made the letters look like they were dripping?

This sounds fascinating, although "DOSBLOOD.EXE" only returns one Google result, being this comment. I assume it would work by constantly modifying the bitmap font?

iirc thats what it did, cycled through a "palette" of bitmap fonts, but i dont recall if it did the whole block or individual characters...

lol. that's funny. no it wasn't animated, just drippy letters. and it was 1995 so i might have misspelled it, memory and all.

After 30+ years of XGA and higher I've forgotten what coding on an 80x25 terminal felt like. Cramped. The answer is "cramped".

It depends on the language. Modern languages feel like that because they evolved on high resolution workstation screens with GUIs that could use smaller fonts. You can do 132x50 on most SVGA cards, but you’ll want a bigger screen for that (and the fonts will be ugly 8x8 or 6x8 ones).

Writing BASIC on 80x25 feels constrained, but 80x35 is much better. Java would be a lot more concise if it was designed with VT-100s in mind.

C# feels cramped unless you have huge desktop monitors.

Luckily, that’s changing. C# 10 is converting namespace blocks into directives like Java. That means one fewer indent.

Do people indent namespaces in C#? In C++ it's common practice to not indent.

Yes, it's traditional with C# to indent every multi-line block. There are teams and individuals who opt for some exceptions (like switch/case), but none of them are universally adopted. I haven't seen a single example over the last two decades where namespaces aren't indented. The defaults go a long way.

Ya...bog standard VGA can do 80x50; VESA SVGA can do 132x50 (or more, I think). I seemed to remember 8514/XGA had something like a 132x50 mode with decently readable fonts (8x16?), but I can't find a reference. 132x50 + tmux/screen is pretty usable.

You could also plug in a Hercules mono card and get a 2-monitor setup, if you had software that could grok it. The color and mono video memory lived in different, non-overlapping memory regions. Couple of shops (Xerox. Amdek? Moniterm?) had 1280x800 monochrome setups that could be a second monitor like this. Those were pretty sweet.

I remember I did a lot of BASIC on 40x24. At some point I got myself a Videx 80-column card and could do graphics on the attached TV and crisp 80x24 on a green screen.

I worked with a guy in the early 1990's that wrote a chipset simulator for evaluating IO/RAM tuning in C++. He was extremely verbose, which was nice to a point: he exceeded the Turbo C++ limit for 256-character max variable names. Needless to say his code did not print nicely into 80 columns.

80x43 seemed world-changing to me on a 286 with a 14" monitor. 80x50 was a bit squished.

I came from 40 column Apple //e and had to pr#3 to active my 80 column card. And let's not talk about the 280x192 HGR2 graphics, almost as painful as CGA, except that was at least linearly addressed!

132 column mode was pretty common on old terminals, and not too terrible if you had a 12+ inch CRT. Typically, still 24 rows though.

Not on PC though.

It was available, but quirky and sometimes app specific. I do remember running Wordstar in 132 columns and some TSR to have DOS in 132 columns. There was "MODE CON COLS=132 LINES=50" also.

That's interesting, I haven't seen that. I don't think MODE CON magically changed text mode resolution beyond 80 or 40 cols either. It was mostly about having proper line wraps with INT 21h output, IIRC.

If you're talking MS-DOS, 132 column mode was very common on apps where it made sense (wordstar, visicalc), but was usually invoked with an app-specific driver of some sort, not BIOS calls.

SVGATextMode could make these available, depending on your video card. With modern kernels, the text mode can be set on boot.

Really? I started college using VT100s in the lab to access the mainframe, and 80 columns was taxing enough to stare at hours on end. Can't imagine a 65% increase in horizontal density!

On a vt320, which does have a larger 14" CRT, couldn't find a good picture of a 132 column on 12": https://i.imgur.com/IYULtxAh.jpg

I had a vt320/vt420 on my desk for years. YMMV...but 132 column mode was a bit cramped even when my eyes weren't aged.

>"Thus I began designing the font of my dreams. Some might find it beautiful, some might find it ugly. But I love it. It is the first iteration of the font and I'm happy with it. I did a lot of work on these fonts and I find then usable for now. The base font for my design was the original one that I recovered from the ET4000/W32i ROM. Then I tried hard to remember what the old fonts looked like. I also drew inspiration from the ATI VGA Wonder 16 ROM font."

PDS: I think they're awesome!

>"This is my Micro-Labs Tseng Labs ET4000/W32i ISA card. I find it very beautifully laid out.' [...] "The card clocks are built around the CHRONTEL CH9294 dual PLL graphics clock generator integrated circuit. These are still available on various sites. The RAMDAC is an AT&T ATT20C490-80 part. These are also available on-line. The ET4000/W32i chip is also available on-line. Which makes me think: what if I'd build my own VGA card? I still have the Tseng Labs datasheets catalog and this VGA controller along with a sample schematic is described in depth. I could improve that design by using modern memories which would be cheaper and easier to source. But this is another topic. For the moment it is only food for thought."

PDS: I think it's a great idea!

Excellent article, all in all!

Well worth re-reading in the future!

For actual fonts you can use in your terminal emulators and whatnot, visit https://int10h.org/oldschool-pc-fonts/download/

Those are missing tons of Unicode glyphs, for obvious reasons. Dmitry Bolkhovityanov maintains an expanded-coverage font[1] which has been converted to many useful formats[2].

1 - https://www.inp.nsk.su/~bolkhov/files/fonts/univga/

2 - http://sciops.net/downloads/vga/ (my site)

Thanks for this. I've been using Zeh Fernando's "Perfect DOS VGA 473" (and derivatives like http://laemeur.sdf.org/fonts/) for ages but have been looking for a replacement since those only cover CP473/Windows-1252.

Also very happy to see an outline version on your site since BDF fonts aren't very usable after Pango 1.44 broke support for them: https://gitlab.gnome.org/GNOME/pango/-/issues/386

We used to erase those eproms with sunlight. Took a lot longer, but seems a lot safer than that rig!

Yes, that rig looks too close to a Darwin award.

The irony is real erasers, sometimes even UL and OSHA approved, have cost less than ten eprom chips since the 80s, and have always cost a quarter to a tenth what an eprom programmer costs, so all the effort and danger is not saving very much.

Ten eproms seems like a lot to people born after the eprom era, but when every build and test cycle requires at least one (or maybe 2 for a 16 bit system, etc) then you can see why people tended to accumulate a hoard of eproms so they'd always have clean erased ready to use ones while actively programming, and erase was done in bulk either because the eraser held 16 chips at once or the erase process could be done in parallel with downtime (while watching TV or something).

Also in some cases during the transition era of UV to EEPROM hardware I remember some EEPROMs were pin for pin compatible with some EPROMs and nobody likes waiting for UV, EEPROMs are simply faster. Obviously not all EPROMs have an identical or faster EEPROM twin, but "many" do.

The UVC lamp setup seems dangerous as fuck - exposed live AC voltage AND mercury???

If you're in need of erasing EEPROMs, just do yourself a favor and buy 10mW UVC 265nm LED. A single LED should suffice to erase a single EEPROM chip within 10-15 minutes.

Most popular UV EPROMS have an electrically eraseable EEPROM equivalent, so you can usually avoid it altogether. In the case of the 27C256 in the article, a 29C256 would be a pin compatible drop-in.

Psh, I've used a TIG welder's arc as an impromptu EPROM eraser. Worked great. It's on video somewhere but I'm not posting it here :)

But yeah, LED is the way to go. Normal "black light" LEDs won't work, I tried. Do as parent says.

I have a history of doing incredibly dangerous things and it terrifies me. The exposed wiring isn’t the worst in my opinion, it’s the uncased high intensity UV-C light source.

Arc eye is a truly horrible thing that I would wish on nobody.

This is as good of a place as any to ask this:

Years ago when I envied demoscene programmers I tried to do animation by way of the redefining VGA font table quickly. I never succeeded in getting that to work for any reasonable frame-rate. Is anybody aware of examples of software that did that and were able to achieve a reasonable frame-rate? I'd love to look at the code, even >25 years later, just for fun.

I can’t think of any, but it would be trivial to do, just update bitplane 2. On some cards you need to update it during vsync.

Can anyone say what the characters in rows B, C and D in their character map here would be used for?

http://www.alexandrugroza.ro/microelectronics/essays-researc...

Those are line-drawing and shading characters. They were used all the time in MS-DOS programs (to great good, in my opinion) for textual "windowing" UIs (a "TUI").

A good example is Turbo Vision: https://en.wikipedia.org/wiki/Turbo_Vision

Ah yes, interesting. I guess seeing them sort of "out of context" stumped me. Cheers.

https://en.wikipedia.org/wiki/Code_page_437

My terminal shell is still 132x43 despite not having used a real VT220 for decades. I have an Amstrad pc1512 emulator that I use for fun sometimes, that one has a really nice font that I loved.

On that website, why don't the text word wrap when I zoom in?

Because the css is forcing display:table, display:table row, and display:table cell on some divs and a fixed 1024px width. Remove all that and it zooms in/out fine. No idea why it's styled that way.

Reply on news.ycombinator.com