Thanks to a very helpful reader (Mike Senior—thanks!), the OS/2 Museum can now publish the ThinkPad Power Series 850 Hardware Maintenance Service and Reference manual in the form of a PDF. This is IBM document number 30H2383. The manual might be of help to owners of antique PowerPC portables. The PDF isn’t perfect but it should be quite useful.
Anyone who needed to take apart a ThinkPad knows that although the process isn’t necessarily terribly difficult, it is complicated enough that dismantling a ThinkPad without the corresponding HMM is a perilous journey. And no one wants to break a PowerPC ThinkPad.
There’s very little else to say, just that although the HMMs for Intel-based ThinkPads have long been available in electronic format (for all ThinkPads, even ones much older than the 850), the ThinkPad 850 HMM was for some reason never available electronically, and the HMM is nowadays even harder to find than the actual ThinkPads.
By sheer coincidence, two new computers arrived in my family at almost the same time, and they couldn’t be more different. At first sight, the most striking difference is the quality of their displays, and it says a lot about the state of the computer industry today.
Lenovo Ideapad Z50-75
The first system is a Lenovo Z50-75, a cheap laptop purchased because the OS/2 Museum needed a modern (but not necessarily fast) AMD processor. The CPU is an A10-7300, a low-performance, low-power “APU” with four CPU cores and six GPU cores. In general, the laptop is pretty good for the price, but has one huge downside: The display. Continue reading →
An important fragment of PC history was unearthed a few days ago: An image of a Compaq Deskpro 386 supplemental disk from August 1986, containing among other things CEMM.EXE, Compaq’s original expanded memory emulator shipped with the Deskpro 386. The image is available on pcjs.org (in the 3.10 directory).
Why is CEMM important? It was essentially by definition the first publicly available utility using the 386’s new Virtual 8086 (V86) mode, and it was the first 386 memory manager. Eventually CEMM morphed into EMM386 shipped with DOS and was the “standard” counterpart to memory managers such as Quarterdeck’s QEMM, Qualitas’ 386MAX, or Helix’s Netroom. EMM386 née CEMM was itself a very important piece of software. Continue reading →
In the past two weeks or so, I’ve been fighting with the site instead of adding content. The hosting company was complaining of too high resource usage on a shared server… but was unable to provide me with detailed access log.
In late September the site was Reddited (thanks to the MS C 5.1 floppy fun article) which triggered a significant though brief spike in traffic. To lighten the database load, I set up a WordPress caching plugin, which unfortunately had a nasty side effect—it forced me to change the permalink format, which made it look to all search engines like the whole site changed.
The caching did make a difference, but doubled site traffic for about a week. I also set up an image lazy load plugin to further reduce the load. There’s also some kind of suspicious traffic hitting the server—I don’t believe for a second that 25% of the site’s readers suddenly went back to MSIE 6.0, but it could be something like this. Oh, and IP blocks have been set up for the busiest bees spamming from beyond the Great Firewall.
Normal service should resume soon. Long term (well, probably next year) the site most likely needs to move to a VPS with a fixed resource cap so that if the limit is hit, no other accounts on a shared server are affected. The challenge will be finding something cheap enough or raise funds somehow.
Unauthorized Windows 95 Developer’s Resource Kit, by Andrew Schulman
IDG Books, November 1994; 593 pages, ISBN 1-56884-305-4; $39.99
A testimony to the incredible level of hype surrounding Microsoft’s “Chicago”, Unauthorized Windows 95 was published nearly a year before Windows 95 was available for purchase (October 1994 vs. August 1995). The book was written based on preview builds of Chicago including the official Windows 95 Beta-1 (May 1994). Although Microsoft made minor changes after that point, everything Mr. Schulman wrote about the architecture of Windows 95 applies to the released product. Continue reading →
For the adventurous, it is possible to install Windows 95 in a VM configured with SCSI storage (hard disk, CD-ROM) attached to an emulated BusLogic HBA. This works in VirtualBox, but there’s a catch—the emulated PCI BusLogic HBA must have ISA compatibility disabled. If it does not, the installation will hang:
After several minutes, there may be a blue screen complaining about inability to write to the hard disk.
Let’s start with the solution. In VirtualBox, the following needs to be run prior to starting the VM (split into two lines here for readability):
The problem is most likely caused by a bug in the BusLogic drivers shipped with Windows 95, although it might be more accurate to say that the drivers are not just clever enough. But what’s really going on? Continue reading →
Several years ago, after attempting to get a very old 286 version of Xenix running in a VM, I concluded that it was probably incompatible with any 386 and later processor. Recently I revisited this issue and examined the problem in detail.
The operating system in question is IBM Personal Computer XENIX 1.0. It’s historically significant, not so much because it was the second OS licensed by IBM from Microsoft, but rather because it was the first protected-mode OS available for a PC (the IBM PC/AT to be exact). IBM PC XENIX 1.0 was finalized around October 1984, just a few moths after the IBM PC/AT (“Salmon”) was introduced (August 1984). The PC/AT and PC XENIX 1.0 were in fact announced on the same day.
This flavor of Xenix is quite picky about the hardware it runs on. It was designed to run on the first-generation PC/AT with 20 MB fixed disk, and has trouble even on later IBM PC/AT models (different hard disks, EGA).
But the reason why IBM PC XENIX 1.0 can’t run on a 386 is different. It’s related to the way the OS manages the segment descriptor tables and it shows a lot about how it took Intel years to properly manage the x86 architecture in a forward-compatible manner. Continue reading →
A while ago I ran into an odd problem: A virtual machine running QEMM 9.0 (aka QEMM 97) would crash more or less every time it tried to read something from a floppy. No such problem was observable in any other environment. But what does QEMM have to do with reading from a floppy, anyway? Quite a lot.
It is well known that EMM386, QEMM, and their cousins provide upper memory (UMBs) and optionally emulate expanded memory (EMS) through the 386 paging unit. Memory above 1MB, normally not accessible from real-mode applications, is allocated and mapped below the 1MB boundary using paging. In the case of UMBs, memory pages are more or less statically “moved” (remapped) to addresses between 640KB and 1MB in order to fill gaps or even overlay unused ROMs. In the case of expanded memory, pages are swapped in an out of the page frame as requested through the EMS services.
In either case, 16:16 segmented memory addresses used by DOS and BIOS do not necessarily correspond to physical addresses, and that poses a problem for software which needs to operate with physical addresses, such as those used for DMA (direct memory access). Continue reading →
Recently I had a need to test the behavior of floating-point exceptions (FPEs) in environments where traditional FPE reporting is used.
To briefly recap, in the original PC equipped with an 8088/8087 pair, floating-point exceptions, which are generally asynchronous events, were reported through an NMI. In the PC/AT (80286/80287), IRQ 13 was used instead, but the BIOS interrupt handler executed INT 02 for compatibility with the PC. This method stuck around in AT compatibles.
Using Open Watcom C/C++, I verified that FPE delivery works as expected in a 32-bit extended DOS executable using the default DOS/4GW extender. The run-time library installs a default handler on interrupt vector 2 and unless overridden by the user, a floating-point exception terminates the program.
The exact same executable behaved differently with the CauseWay and DOS/32A extenders—it was as if the exception never happened. The CauseWay and DOS/32A extenders are supposed to be compatible with DOS/4GW, but clearly there are differences… but where exactly? Continue reading →
While working on an unrelated problem, I noticed a strange behavior of one of my OS/2 VMs running OS/2 Warp 4.52. To cut a long story short, if an unhandled floating-point exception occurred in a DOS window (VDM, or Virtual DOS Machine) while executing real-mode code, the DOS box would crash because it would try to execute an invalid instruction. The IRQ13 (INT 75h) handler provided by the BIOS would run, and then execute an INT 02h instruction (for compatibility with old PCs). But interrupt vector 2 pointed to a place in the middle of the VDM’s conventional memory that wasn’t even allocated. It should be pointing to the BIOS and execute harmless code.
I quickly realized that only one of several very similarly configured VMs did this. At first I suspected a problem with the way the DOS box in the troublesome VM was set up, but that wasn’t the case. The OS version wasn’t it either. What’s more, the VDM was simply reflecting the contents of physical memory (the former real mode IVT at physical address zero)… and the IVT was modified very early in the boot, before even showing the OS/2 boot logo or boot menu.
Finally realization dawned: The OS/2 kernel debugger was doing this, and that’s why most of my VMs didn’t have the problem. But why would this happen at all? Continue reading →