Xenix 2.2 vs. VGA

Posted on April 15, 2022 by Michal Necasek

The other day I started wondering why certain old versions of 286 and 386 XENIX look a bit weird in emulation:

XENIX 2.2 on a VGA, unable to reprogram fonts

The characters are cut off, because XENIX sets up an EGA text mode with 8×14 character matrix but uses 8×16 VGA fonts.

Investigation showed that the XENIX console driver rather closely follows the inner workings of the EGA BIOS, no doubt because finding out exactly what IBM’s EGA BIOS did was not difficult.

Specifically, text modes normally access memory in EGA/VGA plane 0 where character codes and attributes are stored. Fonts are stored in plane 2 and the video hardware needs to be reprogrammed to let the host CPU access that plane. For whatever reason, the EGA BIOS uses a rather heavy-handed but very straightforward method: It defines two “fake” modes in its internal mode table, namely mode entry 0Bh for color and 0Ch for mono modes. The EGA BIOS simply internally sets mode 0Bh or 0Ch, uploads the font bitmaps, and then sets the real desired mode.

XENIX 2.2 uses the exact same method. If the BIOS does not fill out mode table entries 0Bh/0Ch, XENIX will be unable to program the fonts and the original VGA 8×16 font will remain in place, but there won’t be other ill effects.

So obviously the BIOS could just supply the EGA compatible mode table entries 0Bh/0Ch. And indeed that helps with some XENIX versions, such as 2.2.3c, which now gets the right 8×14 font:

XENIX 2.2.3c properly reprogramming fonts

But oops! With other XENIX versions, such as 2.2.3b, the result is much, much worse:

XENIX 2.2.3b with garbled fonts

Why would that be? Finding out requires a little more digging…

Continue reading →
Posted in 286, 386, PC architecture, PC history, VGA, Xenix | 14 Comments

Vague Standards are Trouble

Posted on April 7, 2022 by Michal Necasek

Through the course of time I’ve been going over the IDENTIFY data of various old IDE hard disks. Today I happened to come across a Conner CP30254H drive, apparently made in June 1993 or so.

This is a circa 250 MB drive, but looking at the contents of IDENTIFY words 57-58 (current CHS capacity in sectors), I see the value 2,195,324,935 which just does not look right, as it’d be about a terabyte; completely impossible for a drive without 48-bit LBA support. The drive reports 895/10/55 CHS geometry, so the capacity really should be 492,250 sectors. That’s rather far off from the reported value.

Now, 492,250 decimal is 782DA hex, whereas 2,195,324,935 decimal is 82DA0007 hex. Obviously not a coincidence. So what does the ATA standard say? The ATA-2 standard (1996) is quite clear (section 7.1.15): Some parameters are defined as 32 bit values (e.g., words 57 and 58). Such fields are transferred using two word transfers. The device shall first transfer the least significant bits, bits 15 through 0 of the value, on bits DD15 through DD0 respectively. After the least significant bits have been transferred, the most significant bits, bits 31 through 16 of the value, shall be transferred on DD15 through DD0 respectively.

The Conner drive is clearly doing it wrong. Except… a drive made in 1993 obviously can’t conform to a 1996 standard. So what does the original ATA standard which was finalized (but not yet officially ratified and published) in 1993 have to say about this?

Continue reading →
Posted in Conner, IBM, IDE, PC history | 4 Comments

FantasyLand on VGA

Posted on April 3, 2022 by Michal Necasek

In 1984, Joel Gould of IBM Cambridge (that is Cambridge, Massachusetts rather than Cambridge, UK) Scientific Center wrote a demo program named FantasyLand. This demo was meant to show off the capabilities of IBM’s brand new Enhanced Graphics Adapter, or EGA.

The demo was strictly a demo and was never sold. A few years ago, the demo resurfaced and perhaps the best way to experience it is PCjs, because PCjs faithfully emulates an EGA card. That last bit is important.

The FantasyLand EGA demo

I’ve attempted to run the FantasyLand demo on a number of VGA cards and in the end concluded that it cannot run properly. Even though the VGA is in general highly backwards compatible with the EGA, the FantasyLand demo exposes a couple of minor points where that’s not the case.

Continue reading →
Posted in IBM, PC hardware, PC history, VGA | 16 Comments

Reconstructing the EGA BIOS

Posted on March 19, 2022 by Michal Necasek

A few weeks ago I had a sudden need to understand certain finer points of the operation of EGA/VGA BIOS. I found common reference materials to be inadequate—they tend to do a good job of documenting the data structures the video BIOS uses, but do not even attempt to explain what those structures are for and how exactly the video BIOS uses them.

Partly it’s IBM’s fault. The technical references covering VGA products did not quite explain everything in detail either. For the EGA, IBM solved the BIOS documentation problem the old-fashioned way—by publishing the complete BIOS listing.

Now, the EGA BIOS listing included a fairly decent documentation of the INT 10H interface as part of the source code itself (IBM had previously done the same thing with the PC/XT/AT system BIOS). Decent documentation but not great. But naturally anyone who needed to know more could just read the BIOS listings! For the VGA, BIOS listings were never published, although the VGA BIOS did not do too much new that the EGA didn’t do already.

For answering my questions, the EGA BIOS listings were sufficient. Except the available documents weren’t terribly well OCRed and thus were difficult to search properly. That is mostly IBM’s fault too—the listings were printed in rather small font. It’s not hard to see why IBM did that: Even at about 130 lines per page, the EGA BIOS runs over 60 pages of dense text!

To avoid any problems with searching the BIOS listings, I decided to reconstruct the source code of the EGA BIOS from the published listings, using the poorly OCRed text as a basis.

Continue reading →
Posted in BIOS, Development, Documentation, Graphics, IBM, PC history | 32 Comments

Learn Something Old Every Day, Part IV: Ctrl+Scroll Lock is Ctrl+Break

Posted on February 26, 2022 by Michal Necasek

The other day I tried running NSNIPES, a multiplayer networked game that came with old versions of NetWare. The game worked fine, but I couldn’t get out of it. Esc did nothing, any “usual” combinations like Alt+X, Alt+Q or similar had no effect. So I found the game documentation (because of course it was documented in NetWare reference manuals just like any other program shipped with NetWare), and learned that to quit the game, one has to press Ctrl+Break.

Only pressing Ctrl+Break elicited no reaction from NSNIPES. But then I noticed that pressing Ctrl+Scroll Lock did. So… why is that?

There are really two mostly separate questions. Why does NSNIPES treat Ctrl+Scroll Lock as if it were Ctrl+Break, and why does actual Ctrl+Break not work, or only works very intermittently? Let’s answer that one at a time…

Continue reading →
Posted in NetWare, PC architecture, PC history | 3 Comments

KEYBCS2

Posted on February 18, 2022 by Michal Necasek

After writing about the likely origins of IBM code page 852, I thought I should revisit the homegrown Czech alternative solution, the Kamenický brothers encoding and their keyboard driver. Its existence is well documented, and the so-called (somewhat misnamed) KEYBCS2 encoding even has its own Wikipedia article. The encoding itself lives on in various conversion tables, and utilities to convert text to or from the Kamenický encoding are easy enough to locate. Sometimes the encoding is also called MJK—the initials of its authors, Marian and Jiří Kamenický.

But finding the actual KEYBCS2 utility turned out to be ridiculously difficult. I scoured the Internet for it. I could not find it. At all. I found a fair amount of text talking about it, but not the actual utility.

In desperation, I started searching my NAS. I must have had the utility in the early 1990s, but after I switched to primarily using OS/2 in the mid-1990s, the DOS keyboard driver wasn’t all that useful, and OS/2 had its own reasonably well functioning support using CP852 (compatible with the built-in DOS support).

After much searching, I found an archive with KEYBCS2.EXE dated 07/27/90 on my NAS. Sadly, all my attempts to run it ended up in failure:

What is this nonsense?!

Obviously I was not trying to debug the program, but I was forced to do so.

Continue reading →
Posted in DOS, I18N, IBM, x86 | 29 Comments

Where Did CP852 Come From?

Posted on February 15, 2022 by Michal Necasek

In the 1990s, a lot of my documents were written in code page 852 (CP852), also known as PC Latin 2. This code page is sometimes called “Eastern European”, which is a bit misleading, given that it does not cover major Eastern European countries like Ukraine; sometimes it is also called “Slavic”, which is no less misleading because it covers languages like Hungarian or Albanian that aren’t remotely Slavic.

In those days, fighting with code pages was a constant source of annoyance and pain. DOS and OS/2 used CP852, Windows used CP1250, and Unix/Linux used ISO 8859-2. Of course these code pages were all incompatible with each other. The worst problem was early web where content was often offered in some 8-bit encoding but with no hint as to which encoding that might have been (let’s play a guessing game!). It is a real shame that UTF-8 hadn’t come a bit earlier.

In the early to mid-1990s the situation was further complicated by several non-standard encodings, like the Kamenický brothers encoding in Czechoslovakia or the Mazovia encoding in Poland. Those encodings originated in the mid-1980s and tended to preserve most of the CP437 semi-graphic characters; code page 852 did not, on the other hand it covered quite a few languages. Users initially preferred the non-standard national encodings because those worked better for them, but built-in operating system support pushed those out.

And now I started wondering: When did CP852 become available to users, and where did it actually come from? The first question can be answered reasonably accurately, while the second remains unclear.

Continue reading →
Posted in DOS, I18N, IBM, Microsoft, OS/2, PC history | 47 Comments

XMVM Surgery

Posted on February 11, 2022 by Michal Necasek

Last week I was prompted to take a look at the Intel Code Builder compiler from 1991, a 32-bit compiler targeting 386 extended DOS and shipping with its own DOS extender. It is what one might call an extremely obscure compiler; it had to compete with established offerings from MetaWare, Watcom, or Zortech, and soon also with the compiler heavyweights Borland and Microsoft.

One of Code Builder’s very few claims to fame is that early alpha releases of id Sofware’s DOOM were built with Intel Code Builder 1.1, before id switched to Watcom compilers for the DOS releases of DOOM.

There is one poorly preserved archive of Code Builder 1.0 available. As others have noticed, it won’t even build the trivial hello world program that comes with it:

Linker error caused by missing XMVM

There should be a file called XMVM installed with Code Builder, but it’s just not there. Since it is required by default for linking of 32-bit executables, nothing works unless the /XNOVM switch is passed to the compiler/linker.

The OS/2 Museum happens to have an archive of the Intel 386/486 C Code Builder Kit v1.0 installer which clearly explains why the other copies have no XMVM file. It is in the installer archive… corrupted, and cannot be uncompressed:

XMVM is missing because installer was corrupted

The compiler can be installed, but the XMVM file will be missing.

But wait! If the XMVM module is linked into executables produced by Code Builder, perhaps there is a way to recover it from Code Builder itself?

Continue reading →
Posted in 386, Development, Intel, PC history, Software Hacks | 10 Comments

Another Trip to Drive Geometry Hell

Posted on January 24, 2022 by Michal Necasek

Recently I took another close look at the IDE.DSK driver in NetWare 3.12. Among other things, I wanted to know how it differs from ISADISK.DSK. On some systems, the two drivers are interchangeable and either will work. But there are also systems that only one or the other driver can handle.

The ISADISK.DSK driver should really be called ATDISK.DSK because it’s written to the PC/AT fixed disk programming interface. As such, it will work with ST506 style MFM/RLL drives attached to an AT-compatible controller. It will also work with ESDI drives attached to an AT-compatible controller (such as the WD1005A or WD1007V). And it will also work with IDE drives.

However, ISADISK.DSK will only work with up to two drives supported by the system’s BIOS. ISADISK.DSK looks at the drive type information in the CMOS and relies on the FDPT (Fixed Disk Parameter Table pointed by interrupt vectors 41h/46h) to query geometry information. Said geometry is used internally and also fed to the INITIALIZE DRIVE PARAMETERS command.

For that reason, ISADISK.DSK will work with IDE drives as long as the FDPT geometry is compatible with IDE, i.e. does not have more than 16 heads; the BIOS limit on sectors per track, 63, is lower than IDE’s 255, so that won’t be a problem.

Continue reading →
Posted in IDE, NetWare, PC history | 8 Comments

Another Myth Busted

Posted on January 19, 2022 by Michal Necasek

More than once I came across a story of a heroic MicroPro programmer who in an all-night session managed to port WordStar from CP/M to DOS by patching a single byte. This is how the legend was retold by Joel Spolsky:

Now, here’s a little known fact: even DOS 1.0 was designed with a CP/M backwards compatibility mode built in. Not only did it have its own spiffy new programming interface, known to hard core programmers as INT 21, but it fully supported the old CP/M programming interface. It could almost run CP/M software. In fact,  WordStar was ported to DOS by changing one single byte in the code. (Real Programmers can tell you what that byte was, I’ve long since forgotten).

Joel Spolsky,

Now, that story is slightly misleading. The “spiffy new programming interface” accessible through INT 21h pretty much was the CP/M programming interface, and it wasn’t until DOS 2.0 that the INT 21h interface was significantly enhanced.

But the gist of the story does not even make sense. Although DOS was designed to make porting from CP/M easy, it was never a question of patching a byte here or there, since CP/M ran on 8080 CPUs and DOS ran on 8086/8088 processors. The processor families are certainly related, but not at all binary compatible. 8080 assembly source code could be machine translated to 8086 source and reassembled, but the code quality was reportedly less than ideal.

And yet… there is a kernel of truth in the story, even though it morphed into something highly implausible. Not unlike there really are Wang word processor symbols in the IBM PC character set, even though the stories told by Bill Gates are very difficult to take seriously.

Continue reading →
Posted in CP/M, DOS, PC history, WordStar | 5 Comments