I suppose they say, once you have a hammer, everything looks like a nail. Indeed they are right, because now I have a ROM programmer, I couldn’t stop pulling
teeth chips just to dump them. Aside from motherboard BIOS chips, the next major peripheral to have removable ROM chips is usually the graphic card. I’m not sure exactly why, as I’ve never upgraded a ROM on a graphic card by exchanging chips as many of the cards that featured this were not particularly sophisticated by today’s standards (i.e. PCI/ISA 2D boards with rudimentary VGA/SVGA framebuffer modes and limited 3D capability if you were lucky). The only time I’ve upgraded BIOSes was for modern Nvidia cards with NVflash for compatibility or overclocking. Regardless, I trawled through my collection, which includes some of the cards pictured in this old post of mine, and dumped the ROMs for examination.
Diamond Stealth SE PCI
The first patient to undergo a ROM dump was the Diamond Multimedia Stealth SE PCI. As far as I remember, this was a relatively popular card based on the S3 Trio32 chipset. In my collection, I found two different ROM revisions – 1.01 and 1.02. I decided to start my adventures by looking at the version 1.02 ROM.
Looking at the ROM header, we can confirm the dump was correct, and it is dated 05/01/95 (American format, possibly). It starts with 0x55AA magic number, probably to signify a “bootable” ROM, so it starts and prints the banner message which tells you all about the card and its BIOS. It also has “IBM ” at 0x1E, which we will see later, is probably a requirement for IBM BIOS compatibility.
Anyhow, lets rummage for interesting things. First, I took the data and expanded each bit to 8 bits, producing a 512 x 512 image which sequentially shows the bits, MSB first, horizontally across, from top to bottom.
Many times, code comes up as noise, but the periodic patterns themselves hide something more … basic, and at least, to me, relatively interesting. Because VGA cards have text modes (e.g. what you see in native MS-DOS), they have a ROM based character generator with the fonts stored in ROM tables. How can we see the bitmapped fonts?
A little data juggling is required. I drew this by hand because … well, it’s just easier. But the idea is simple – since the ROM is byte width, it’s not likely that any character is made of any less than 8-bits wide. The issue is to “stack” each byte with the consecutive byte for a given number of rows to form the character. This would give you an impractically long image, so with a little more thought, we can preserve the 512 x 512 aspect by putting 64 characters across.
The program that combines the two functions I have called stride8x16, and can be rebuilt to handle different character heights. Again, the code is hacky, but I did it in 10 minutes …
#include <stdio.h> #define HEIGHT 16 #define WIDTH 64 #define ROMSIZE 32768 #define ROWS (int)ROMSIZE/(WIDTH*HEIGHT) #define OFFSET 0 // Offset allows for tuning of byte offset for alignment purposes // by Gough Lui (goughlui.com April 2016) int main (void) { int tempcount=0; int base=0; int row=0; int romdata[ROMSIZE]={0}; int mask=0x80; while (tempcount<ROMSIZE) { romdata[tempcount]=getchar(); tempcount = tempcount+1; } tempcount=0; while(row<ROWS) { while(base<HEIGHT) { while(tempcount<WIDTH) { while(mask) { if(romdata[(base+(tempcount*HEIGHT)+(row*WIDTH*HEIGHT)+OFFSET)%ROMSIZE]&mask) { printf("%c",0xFF); } else { printf("%c",0x00); } mask=mask>>1; } tempcount=tempcount+1; mask=0x80; } tempcount=0; base=base+1; } base=0; row=row+1; } return(0); }
Running the same data through there, we get a clear image of the characters in the 8×16 and coincidentally, 8×8 table as 8 is a multiple of 16:
We can see there are slanted fragments of characters, as they are not 8×8 or 8×16, but rather, 8×14. Rebuilding the program and running it through allows us to see the 8×14 table:
Pretty neat. There is some other periodicity I can see in the ROM which isn’t clearly visible as a bitmap, but due to my lack of knowledge of x86 machine code, and no great desire to try and master it right now, I’d have to suspect that they could be character pointer tables, hence the periodicity in the data as they are adjacent addresses.
STB PowerGraph 64
This was an S3 Trio64V+ based card, and interestingly, it has a BIOS version 1.8 that has acknowledgements for Phoenix Technologies, better known as a motherboard BIOS supplier, in addition to S3 and STB.
It is dated 12/10/1995, probably American date. Looking at it sequentially, it is slightly different with the font tables stored differently, and more “random noise” code area with less periodicity.
Stacking the bytes 16 high gives us the following image, clearly showing the font tables.
ExpertColor DSV3325DX S3 Trio VirgeDX
Another card based on an S3 Trio family chipset, so lets take a peek in the version 1.01.03 375 EDO M70 BIOS:
This one is dated later, 23rd June 1997.
The resulting data is as follows, as usual, the font tables are similar, and the code is somewhat different.
Matrox MGA-IMP+P
Switching vendors entirely, lets take a look at the only removable Matrox ROM I have.
It has quite a lot of text in the header section of the ROM, which gives away that it is version 4.0 with references to Matrox Electronic Systems and LSI Logic Corporation.
Compared with the other ROMs, this one has a large patch near the beginning that has a pattern to it. I wonder if this is a pointer table, or some bit-mapped logo which I haven’t discovered the h/w parameters or encoding for.
SiS 6326 AGP PCI card
By now, you’re probably getting a little bored of this, but this is where things start getting a little interesting. The SiS card is an odd one, as it’s an “AGP” branded chipset on a PCI bus. It has a date of 2nd Feburay 1999 and is version 1.26.
Looking at the ROM sequentially, it looks like any other:
But once we stack characters, we discover a little easter egg:
The end portion of the ROM has a custom character based bitmap logo. The actual logo is 10 characters wide by three lines tall. This is probably used for the sign-on message on booting the VGA BIOS.
TPO-32PCIV Tseng Labs ET4000-W32P
This was one of Tseng’s later efforts, which was the beginning of the end for Tseng in the graphic accelerator market. This card’s BIOS was version 8.00 and is dated 17th May 1995. It differs from the others because it doesn’t have the IBM string where we would expect it for IBM graphics compatibility, but yet the card works … so maybe the BIOS in most clones aren’t as picky about having “IBM “.
Tseng’s ROM looks similar to the others visually.
But stacking characters for this ROM required using the offset feature in my code because the beginning of the font table was about half-a-character in (5 bytes), whereas most of the others were a multiple of 16 or “close enough”. There also seems to be a little bit of free room at the end.
UMC ISA 85C408AF SuperVGA
I kept the chip from this card, but tossed the card because it was stripey with a likely soldered DRAM failure which I didn’t have any tools to attempt a repair at the time. This one gives us a good clue as to the IBM string, clearly stating it was needed for compatibility reasons. I suppose, in the ISA days when many of the PCs were genuine IBM, this may have been necessary to ensure their product worked.
The BIOS is version 1.04 dated 29th September 1993, this time with acknowledgement to Award Software, another company popularly known for supplying motherboard BIOS code.
This BIOS seems to have a strange “break” in the font table area with a blank patch of unprogrammed area, suggesting maybe there is a hardware “glitch” which needs them to store the tables this way, or maybe it optimizes their pointer calculations. I don’t know for sure.
Here, we see the same characters we have come to expect. As I didn’t use the offset to align the characters, they are slightly rotated upward.
What’s the Difference?
I suppose the fact is that of cards with a identical chipset, using a BIOS from another card is potentially possible. Depending on the features and the construction of the card, it may even be possible to unlock features of certain chips by changing the BIOS, just as some overclockers have done in the past. In fact, nowadays, many graphic cards use BIOSes which are very similar to or identical to the reference BIOS with tweaks to timings to cater for different memory, clock-speed, and voltage control features. The BIOS can affect compatibility with computers, so I suspect newer versions may fix certain bugs.
One difference that was spotted was subtle differences in font table characters. This would manifest itself in slight differences how screens containing these characters would look across different cards.
For example, comparing the Tseng and Diamond character sets, we can see some one-pixel differences, and something strange with the = sign as well.
A similar result is had when comparing the Diamond and Matrox character sets. Within the same chipset, the font tables were generally the same though.
However, that being said, it dawned upon me that the exchangeable VGA BIOS could actually serve an important purpose. As early computing was mostly done in the console, and prior to the advent of Unicode which is a godsend for languages other than English, displaying different characters in a different code-page in text mode required a different font table. I suppose a different ROM BIOS could be supplied with custom fonts or symbols pre-loaded on it to make it “default” rather than requiring the font tables to be loaded into RAM and selected.
Conclusion
Given that I’m no computer scientist, I approached the examination of the VGA ROM BIOS with a more artistic intent to look at the bits visually, which led me to actually find the bit-mapped font tables. I suppose that’s something better than just leaving a few ROM dump files on the hard disk.
Bravo! Neat post.
I immediately wanted to see if all the fonts from each ROM could be put into a .ttf file somehow (Fontographer?) for healthy preservation. Then the difficulty of doing it had me at a loss of where to start except by screen grabs and patient pixel painting. Seems like there should be a better way, eh?
Wish I could do the same sort of analysis of my old XT hard drive controller cards.
Thanks for the comment!
I’ve never made a font before, so I’m not sure, but it should be possible somehow provided there is a program that can take in either raw bitmaps, or we can carve out 16 byte chunks (offset required) and prefix it with a .bmp 1bpp header to force the following data to be interpreted as a bitmap (although we may have to reverse the order of the 16 bytes because if memory serves me right, BMPs paint bottom to top). Anyhow, as I have no experience in that area, I’ll probably leave that to someone else :).
– Gough
I was one of the founders of the three founders of STB Systems. I wrote most of our original VGA BIOS and our BIOS compatibility test program (you would be surprised how few BIOSes actually met the IBM reference implementation or didn’t clobber some register that they should have preserved). When the VESA extensions came out we licensed the Phoenix BIOS and used that as our code base.
Most VGA chip vendors would supply you with a BIOS that worked with their chips. We tended to use our own BIOS.
The IBM string exists because a few program checked for it… I don’t remember which ones, but a couple of very popular programs would not run in VGA mode without it.
I still use our VGA fonts in some micro-controller programs… I created most of our original fonts, based upon the font I created (with the help of a very picky artist / typographer) for our STB-80 video card for the Apple. I even have one converted to a vector graphics format that I use quite a bit.
Delighted and honoured to have your insight :).
– Gough
This is incredibly interesting information and my reaction is similar to lui_gough’s; thanks so much for posting.
In case you see this comment (I definitely hope you do) and can set aside a few moments to reply at some convenient point, I had a few things I wanted to ask.
Apologies for the length – it’s not often random people on the ‘Net get the opportunity to ask questions like these!
—
If you happen to still have that BIOS compatibility test program lying around, I’d just like to say that that it would be a very interesting tool to have available when exploring and learning more about the retro scene and seeing where everything was at a decade+ ago.
Besides that, depending on how extensive and generalized the utility was, it would very likely be invaluable to independent developers working on VGA emulation for personal experience, and also likely of assistance to projects like SeaBIOS and Bochs’ VGA BIOS. I realize that the VGA specification and VESA et. al. are openly and comprehensively documented, but considering that this program was written to critically analyze actual period hardware, I’m guessing there are probably some standards-breaking real-world edge cases that were added in to ensure compatibility over conformance. This is obviously exactly the kind of thing emulator developers would stand to benefit the most from.
Assuming you can part with the program (and I completely understand if that’s not possible), sending it directly to one or more of the aforementioned projects’ maintainers would be one low-noise way to share it, or maybe it could be posted to the VOGONS or OSDev forums where it would be immediately snapped up and quietly preserved. In the case of a source release, I wouldn’t be surprised if reading the code would directly translate to conformant implementation – but a binary release would also provide invaluable insight as well, so source would just be a bonus.
I’m not (yet) associated with the projects or communities I mentioned, so I’m admittedly not aware if their developers already have access to [obscure] tools like this. That said, I would be very surprised if if this utility was not of at least some assistance. (I just realized that depending on who learns you were a VGA BIOS developer, you may get a mildly active inbox, though…)
—
Another thing I was curious about – you say you used Phoenix BIOS as your code base. By this, do you mean that Phoenix made a video BIOS reference implementation in addition to their standard BIOS – or did you actually start with the core Phoenix BIOS and build a VGA BIOS from that?
If you mean the second, I’m very curious how that worked out / was useful, as I’m completely ignorant how a system BIOS implementation would help in making a VGA BIOS.
(As an aside, I think it’s very very cool that you used your own BIOS, and didn’t use vendor-supplied implementations.)
—
Many thanks for mentioning the reason for the IBM string – that kind of concrete explanation from an authoritative source isn’t easy to find. Filed away!
—
Finally, I had a couple questions about the fonts specifically.
Most of the VGA chipsets I’ve used have had near-identical textmode fonts, and this page also highlights the significant level of font similarity between different character generator ROMs.
Now, you mentioned that the STB cards’ fonts were based off an earlier font for the STB-80. I think I’m missing a piece of the puzzle here; the only way I can consider that your font was based off an earlier design, vs the fact that most VGA cards have 99% similar fonts, and make it compute is to suppose that the STB font differed in the special characters, or that there’s another font hiding in the BIOS, but these theories aren’t very satisfactory.
I’m currently under the (totally assumed) impression that the fonts in almost all VGA cards “appeared out of nowhere” (if you will) somewhere between IBM’s open release of the AT-compatible EGA, and their not-so-open release of the PS/2+VGA and co., and that ROM dumping may have been instrumental in making the now-ubiquitous VGA font widely available 🙂 – anything you can say about this would be highly appreciated. (For example, was it that was actually your font that influenced the market, and that all cards are based off your font?)
The reason I ask about this is that I’d like to create a central location/repository for bitmap fonts lifted from various different types of hardware and software, simply to preserve the historical data and make it available to inspire future designs (especially considering that – as you noted – real typographical design work went into the glyphs, and losing that effort would be sad).
The only obvious issue is copyright. The US copyright office currently considers vector font data to be copyrightable computer software, but that simple bitmaps are insufficiently unique to be copyrightable – although this may be changing going forward. That arguably makes bitmap font data generally public domain, which is a huge win… *for now*.
I noticed that you said “our fonts” (and on that note it’s pretty awesome to learn you were the font (co-)designer), which leads me to believe that the work may possibly still be owned by a commercial entity – perhaps Nvidia (who bought 3dfx, who bought STB). With that in mind, any thoughts you can mention on the subject of VGA fonts in general and your fonts in particular will be very interesting to many people – for example the guys over at, who would probably love copies of the font files you mentioned (it looks like they dumped an STB card already).
I personally do recognize ownership of bitmap font data (despite US copyright office policy), and I’m curious what you might have to say on the subject about usage of your own fonts or VGA fonts in general (although I realize you’re not a lawyer), considering that you were a part of the scene back in the day; a lot of people are up in arms about how to deal with the ownership issue, because authoritative data is incredibly rare. Mentioning your opinions about this on the VOGONS forum (; perhaps in the “PC Emulation” section) would very likely be highly welcomed.
– David
PS. While a public response would benefit many, it’s possible you may prefer to forward some info directly. That’s fine – [email protected] (yes swap the domain)
PPS. Googling for info about the STB-80 yielded very very little relevant results, most of it out of magazines archived in Google Books. This is (unfortunately) a perfect example of the kind of information loss I was mentioning that want to preserve. Besides STB-80 font data, there are definitely people out there who will appreciate any period info/code/font data you might be able to release that’s just buried collecting dust.
PPPS. I had to ask – on the subject of easter eggs, there are almost certainly some fun things (or test modes) in STB cards, right? 😀
I’ve been considering dumping the ROMs of much of my hardware, and it’s something I’ll probably do. But I’m not sure about what I should do with the archive once I create it. Much of the ROMs would still be copyrighted, so I can’t really offer them for download, despite how useful that may be for someone with a dead ROM chip. I think what you’ve done here has been an interesting way to look at them, especially given the graphical content on them.
The VGA ROMs are interesting, I suspect the IBM string got dropped from newer cards as newer software didn’t check for it, especially after windows became the norm. Some of the other suspected tables may have been tables of parameters for graphic modes. Interestingly the way the current font was located in ROM by a program was by looking up a pointer in the interrupt vector table, finding the character to display was done using arithmetic rather than using what would be a large table.
Programming PC graphic cards usually involves a few calls to a interrupt (10h) to set up the graphics mode. Afterwards, the program typically accessed the video memory/registers directly. The interrupt offered many graphics functions but usually they were not used as they had to be compatible with the IBM graphics ROM, were written for the lowest CPU expected (8088 for a long time) and were often slower than writing the code yourself. The Interrupt code resides in the graphic cards ROM.
Sparcie
I agree, copyright is a big potential issue, but at the same time, some of the vendors are well defunct and the threat of legal action may be relatively limited, and the damages that can be claimed are probably non existent. That’s why I decided to post up this particular posting, as I thought it would be a nice educational project just to show how the bit-mapped character generator fonts were stored in different ROMs, and some of the random other characteristics we can uncover by examining them.
I suppose the fact some of the old-version and abandonware sites are luckily still existent, and so it probably shows that companies aren’t too busy chasing small fish which aren’t causing any harm. But on balance, if I receive any complaints, I will probably take things down …
Ah yes, okay, yeah that makes sense – base address of font table + ASCII value * row height makes great sense especially when row height is a power of 2, making for easy binary shifting.
That begs the question, what are the other “periodic” patterns we can see in the images, since they normally indicate repeating bit patterns of some sort with similarities … which are very unlikely to be redundant, but maybe could be another form of image (multi channel colour?) or bitmapped data, or maybe some arithmetic tables for vector operations (e.g. log/exponent?). I have no idea, but I’m not experienced enough to actually understand each and every “bit”.
Anyhow, thanks for the comment, as usual :).
Sincerely,
Gough.
I wasn’t so much worried about the images being a copyright issue as much as making code/fonts available. I am considering making some of the ROMs available from some of my hardware, in case someone with similar equipment needs a ROM image. Perhaps I could do this, just limited to older hardware/machines.
There are lots of different types of look-up tables used by programmers, log and exponent like you mentioned but also trigonometric functions like sine, cosine and their inverses. However I doubt they’d be these kinds of tables as they aren’t necessary for any of the VGA BIOS functions that I can think of. They could be straight up bitmaps in any number of colour depths, probably either 4 bit or 8 bit colours. If the image was encoded at all, RLE (run length encoding) would be the likely method as there wouldn’t be code space for other decoders. The other suspects I can think of is perhaps default palette information for all the diferent graphic modes, or perhaps a table of parameter information for graphic modes.
The VGA palette if stored in ROM would probably take about 768 bytes if they store it the way I think they would.
The only real way to know would be to examine the data, know where it fits in the PC memory map, and look for code that references it. Maybe the raw data itself may be enough of a clue.
Sparcie
Many of the periodic tables are probably video mode setting / VESA video mode descriptors.
The PC BIOS used interrupt vectors 1F and 43 as pointers to user defined character generator tables. There were BIOS calls for getting and setting these pointers. Also calls to return the pointers to the VGA card’s character generator tables. BIOS call INT 10 AH=11 AL=xx were the font manipulation functions.
Thanks for posting.
Thank you very much for this post! Thanks to you, my 8086 emulator can now use whatever font is present in either the VGA BIOS or the main/XT BIOS.