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.
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?
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.
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.
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.
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.
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!
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.
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!
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.
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].
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.
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").
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.
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.
>"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."
45 comments
[ 3.4 ms ] story [ 94.0 ms ] threadTen 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.
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.
But yeah, LED is the way to go. Normal "black light" LEDs won't work, I tried. Do as parent says.
Arc eye is a truly horrible thing that I would wish on nobody.
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.
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.
1 - https://www.inp.nsk.su/~bolkhov/files/fonts/univga/
2 - http://sciops.net/downloads/vga/ (my site)
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
http://www.alexandrugroza.ro/microelectronics/essays-researc...
A good example is Turbo Vision: https://en.wikipedia.org/wiki/Turbo_Vision
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.
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!