[HN Gopher] VGA ROM Fonts (2020)
___________________________________________________________________
VGA ROM Fonts (2020)
Author : Lammy
Score : 82 points
Date : 2021-05-03 09:58 UTC (13 hours ago)
(HTM) web link (www.alexandrugroza.ro)
(TXT) w3m dump (www.alexandrugroza.ro)
| bogomipz wrote:
| 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...
| a_e_k wrote:
| https://en.wikipedia.org/wiki/Code_page_437
| EvanAnderson wrote:
| 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
| bogomipz wrote:
| Ah yes, interesting. I guess seeing them sort of "out of
| context" stumped me. Cheers.
| h2odragon wrote:
| 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.
| SavantIdiot wrote:
| Do you recall "DOSBLOOD.EXE", a font loader TSR that made the
| letters look like they were dripping?
| gfaure wrote:
| 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?
| h2odragon wrote:
| 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...
| mrlonglong wrote:
| 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.
| caf wrote:
| We used to erase those eproms with sunlight. Took a lot longer,
| but seems a lot safer than that rig!
| swineyy wrote:
| 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.
| progman32 wrote:
| 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.
| jleahy wrote:
| 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.
| tyingq wrote:
| 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.
| VLM wrote:
| 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.
| pestatije wrote:
| Yes, that rig looks too close to a Darwin award.
| SavantIdiot wrote:
| After 30+ years of XGA and higher I've forgotten what coding on
| an 80x25 terminal felt like. Cramped. The answer is "cramped".
| rbanffy wrote:
| 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.
| swiley wrote:
| C# feels cramped unless you have huge desktop monitors.
| sedatk wrote:
| Luckily, that's changing. C# 10 is converting namespace
| blocks into directives like Java. That means one fewer
| indent.
| zorked wrote:
| Do people indent namespaces in C#? In C++ it's common
| practice to not indent.
| kjs3 wrote:
| 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.
| rbanffy wrote:
| 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.
| bluedino wrote:
| 80x43 seemed world-changing to me on a 286 with a 14" monitor.
| 80x50 was a bit squished.
| SavantIdiot wrote:
| 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!
| tyingq wrote:
| 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.
| sedatk wrote:
| Not on PC though.
| tyingq wrote:
| 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.
| zozbot234 wrote:
| SVGATextMode could make these available, depending on your
| video card. With modern kernels, the text mode can be set
| on boot.
| SavantIdiot wrote:
| 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!
| tyingq wrote:
| 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
| EvanAnderson wrote:
| 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.
| trollbridge wrote:
| 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.
| afturkrull wrote:
| On that website, why don't the text word wrap when I zoom in?
| tyingq wrote:
| 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.
| pdenton wrote:
| For actual fonts you can use in your terminal emulators and
| whatnot, visit https://int10h.org/oldschool-pc-fonts/download/
| khm wrote:
| 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)
| Lammy wrote:
| 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
___________________________________________________________________
(page generated 2021-05-03 23:02 UTC)