ICEBP Finally Documented

Posted on May 25, 2018 by Michal Necasek

After more than 30 years, Intel finally documented the INT1 instruction, also known as ICEBP (opcode F1h), in the latest (May 2018, -067) edition of the SDM. This was probably forced by security concerns, because from a security standpoint, having undocumented instructions which trigger special interrupts from user mode is insane, and Intel does not need more bad press than it already has.

The situation was fairly ridiculous, with most system software developers well aware of what ICEBP does, despite Intel’s abject failure to document what has been a part of the x86 architecture since the 386 (released in 1985). It helped that AMD’s 64-bit architecture manuals provided enough information about INT1/ICEBP for well over a decade.

Things got doubly ridiculous when Intel’s hardware virtualization (VT-x) documentation needed to talk about a “privileged software exception” without providing the slightest hint how such a mysterious thing might happen (why yes, executing ICEBP!). That, predictably, caused problems.

To recap, INT1 aka ICEBP (opcode F1h) is a single-byte breakpoint instruction similar to INT3 (opcode CCh), with the interesting property that it does not set any bits in DR6 and triggers a #DB exception without any privilege checks. It is intended for use with hardware debuggers (In-Circuit Emulators or ICEs) and conceptually behaves much like a software-triggered unmaskable hardware interrupt. That is why it needs to be handled specially by hypervisors, because it’s not quite like other exceptions and not quite like a hardware interrupt. It is however perfectly usable by software debuggers with no ICE in sight. System-level debuggers may even prefer using ICEBP to avoid conflicts with application-level debuggers.

Documenting an instruction after more than 30 years might, or at least should, be a world record. Intel is expected to break its own record once it fully documents the SALC instruction (opcode D6h), which has been with us since 1978 (introduced in the 8086). For decades Intel pretended SALC does not exist, in recent SDM editions the instruction is mentioned by name together with its opcode and a brief description, but not documented in the instruction reference and left out of the opcode map.

Posted in 386, Documentation, Intel, Undocumented | 14 Comments

SpaceMaker Update

Posted on May 17, 2018 by Michal Necasek

Jeff Parsons has been able to locate an executable compressed with Realia SpaceMaker which significantly pre-dates all hitherto known SpaceMaker or EXEPACK survivors. It’s an editor called DVED.COM version 6.02, found on disk 191 of the PC-SIG Library 8th Edition CD-ROM. The DVED.COM file is timestamped September 14, 1983 and its accompanying READ.ME file is dated September 18, 1983.

DOS timestamps are not necessarily trustworthy, and timestamps from before the PC/AT era (and built-in clocks) are notoriously unreliable. But in this case, the version history in the READ.ME file clearly talks about DVED “V6.02 (September 14th, 1983)”, which matches the COM file’s timestamp.

The 1983 DVED.COM file is certainly compressed with SpaceMaker. It has the same MEMORY$ signature, no long runs of zero bytes, as well as stub loader code at the beginning and end of the file that’s very similar (but not identical) to what SpaceMaker 1.06 (1986) produces.

Could DVED.COM have been compressed at some point well after 1983? Yes, but there’s an excellent reason to believe that’s not the case. DVED stands for Dewar Visual Screen Editor, and it was written by the same Robert B.K. Dewar who also wrote SpaceMaker. The  on-line help for DVED in fact explicitly mentions SpaceMaker as a product available from Realia (DVED itself was a freebie). If anything should have been compressed with SpaceMaker, it’s DVED.

The 1983 version of DVED.COM can be examined live on pcjs.org, just load PCSIG08:DISK0191 into the machine and run DVED.

Can anyone find an even older executable compressed with SpaceMaker (or anything else for that matter)?

Posted in PC history | 10 Comments

Realia SpaceMaker

Posted on April 30, 2018 by Michal Necasek

A recent exploration of Microsoft’s EXEPACK posed the question whether EXEPACK was the first executable compressor, at least in the world of PCs. It wasn’t.

That distinction almost certainly belongs to Realia SpaceMaker, which was probably released sometime in late 1982. Why “probably”? SpaceMaker is so old and so obscure that the oldest (and only) surviving version (1.06) is from 1985, in fact newer than the earliest known EXEPACK.

SpaceMaker was covered by the trade press, though not exactly extensively. Peter Norton mentioned it in his Hard Disk Housekeeping article in the January 8, 1985 issue of PC Magazine. That is the most solid piece of evidence that SpaceMaker is older than EXEPACK. SpaceMaker was written about in December 9, 1985 issue of Fidonews (The PC’s Space Program, by Gene Plantz). It was also mentioned in the January 1986 issue of Compute! magazine (page 119, Last Minute Gifts).

Note that the first known coverage is from 1985. So how do we know that SpaceMaker is from 1982? In the absence of surviving binaries, it’s difficult to prove. But SpaceMaker was advertised in the January 1983 issue of PC Magazine, which probably hit the newsstands in late 1982. And it was listed it as being developed in 1982-1983 (together with the Realia Termulator terminal emulator) in a legal document (page 20 in the PDF) which ought to be a reasonably trustworthy source of information.

If only we could ask the author to clarify the timeline. But alas, we cannot. The author of Realia SpaceMaker, Robert B.K. Dewar, died in 2015. Continue reading →

Posted in Compression, Development, PC history | 13 Comments

Undocumented RDTSC

Posted on April 27, 2018 by Michal Necasek

The other day I wrote a simple DOS program which used the RDTSC instruction in order to obtain precise time measurements (of how long it takes a PS/2 keyboard to send data; more about that some other time). The 16-bit DOS program worked fine in a VM running PC DOS 2000, as well as in NTVDM on Windows running on a system with a Core 2 class CPU. But when I tried running it on an old IBM ThinkPad 760XL laptop with a 166 MHz Pentium MMX processor running PC DOS 2000, it just hung when executing RDTSC. Unless I disabled EMM386, and then it worked fine.

That was a bit of a mystery. The Pentium MMX does obviously support the RDTSC instruction. The only troublesome possibility would be if perhaps someone set the CR4.TSD bit (the Time Stamp Disable bit) which would cause RDTSC (and RDTSCP on newer CPUs which support it) to #GP fault outside of ring 0. But old EMM386 does not even touch CR4, and at any rate the same program with the same EMM386 version worked on a newer CPU. Could the ThinkPad’s BIOS be setting CR4.TSD? Continue reading →

Posted in Documentation, Intel, Pentium | 15 Comments

The A20-Gate Fallout

Posted on April 13, 2018 by Michal Necasek

A recent post explored the motivation (i.e. backwards compatibility) to implement the A20 gate in the IBM PC/AT. To recap, the problem IBM solved was the fact that 1MB address wrap-around was an inherent feature of the Intel 8086/8088 CPU, but not the 80286 and later models—but a number of commercial software packages intentionally or unintentionally relied in the wrap-around.

Interestingly, it is obvious that the address wrap-around was much better known and understood in 1981 than it was in the 1990s. For example in 1994, the usually very well informed Frank van Gilluwe wrote in Undocumented PC (page 269): A quirk with the 8088 addressing scheme allowed a program to access the lowest 64KB area using any segment:offset pair that exceeded the 1MB limit. […] Although there is no reason for software to ever use this quirk, bugs in a few very old programs used segment:offset pairs that wrap the 1MB boundary. Since these programs seemed to work correctly, no actions were taken to correct the defects.

Yet it is known that Tim Paterson quite intentionally used the wrap-around to implement CALL 5 CP/M compatibility in QDOS around 1980, and Microsoft Pascal intentionally used it in 1981. In both cases there were arguably very good reasons for using the wrap-around.

Intentional or not, software relying on 8086 address wrap-around was out there and important enough that by the end of 1983, IBM had implemented the A20 gate in the upcoming PC/AT. But did they have to do that? Continue reading →

Posted in IBM, Microsoft, PC architecture, PC history | 93 Comments

Any Readers in Central Italy?

Posted on April 6, 2018 by Michal Necasek

This is a very long shot, but maybe someone can help me. I’d very much like to buy a piece of used electronics for sale in Italy (L’Aquila province). Unfortunately the seller requires a local pick-up. I don’t live exactly nearby, and don’t speak Italian.

So… if anyone living in the area would be willing to pick up the item and mail it to Germany for me, please leave a comment. I would be most grateful (and obviously pay all the costs).

Posted in Random Thoughts | 3 Comments

Windows 10 ARM64 on QEMU

Posted on March 24, 2018 by tenox

(This is a guest post by Antoni Sawicki aka Tenox)

Microsoft is releasing Windows 10 for ARM64 CPUs and this time, unlike Windows RT fiasco, there will be a full desktop app support including a dynamic binary translator to allow running existing x86 apps on ARM CPU, much like FX!32 on Alpha NT or Rosetta on Mac OS X.

Latest Visual Studio updates now brings official ARM/ARM64 support for Desktop Apps, a little hidden, but here is how to enable it.

Being able to compile Windows ARM apps, I wanted to try to actually run them, but … on what exactly? There are some developer evaluation boards. Apparently someone managed to run it on Raspberry PI. Most importantly however you can run Windows 10 ARM64 on QEMU.

Windows 10 ARM64 on QEMU

Continue reading →

Posted in Uncategorized | 2 Comments

EXEPACK and the A20-Gate

Posted on March 23, 2018 by Michal Necasek

In 1991, DOS 5.0 brought about what’s perhaps the most common manifestation of A20 control trouble…

Packed file is corrupt

Microsoft published a KB article about this infamous error, but its author clearly did not understand the true cause of the problem. Later, Microsoft published another KB article about the same problem, and its author still didn’t understand the real cause. Both articles correctly state that the problem occurs when the load address of a packed executable is below 64K. Both also claim that the cause is a bug in the unpacking algorithm, without asking themselves why the same problem did not always occur with old DOS 2.x/3.x systems which didn’t take up all that much space and left plenty free below 64K. But the previously mentioned AST technical bulletin quite clearly points at the real problem: “The Gate A20 signal is in the wrong state after the system is booted.” Bingo.

(Note: The KB articles and the AST bulletin all mention a “Packed File Corrupt” message. The actual message is “Packed file is corrupt”.)

The EXEPACK unpacking algorithm, which post-dates the PC/AT, needs to solve the same basic problem as the Pascal run-time—move data higher up in memory while the destination potentially overlaps the source.  Unfortunately it also employs the same solution with potentially “negative” segment registers relying on address wrap-around. Was the wrap-around in EXEPACK intentional, as it was in the MS Pascal run-time? If only we could find out… Continue reading →

Posted in Bugs, Microsoft, PC history | 19 Comments

The A20-Gate: It Wasn’t WordStar

Posted on March 16, 2018 by Michal Necasek

Although WordStar was long suspected to be the reason (or at least one of the major reasons) for implementing the A20 gate hardware on the PC/AT and all the associated problems later on, it is now all but certain that that wasn’t the case.

To recap, the earliest versions of WordStar for the IBM PC were 3.02 (probably April or May 1982), and 3.20 (likely Summer 1982). Whatever version 3.02 did or didn’t do, it was not compatible with PC DOS 1.1 or later, and thus could not have been relevant when the PC/AT was being designed. WordStar 3.20 has now been examined and found not to use the CALL 5 system call interface or do anything else that would cause problems on the PC/AT. WordStar 3.2x did use the word at offset 6 in the PSP to query the available memory, but not the call at offset 5.

Then it turned out that a crucial piece of evidence has been hiding in (almost) plain sight all along. Richard Wells highlighted U.S. Patent 4,779,187, “Method and operating system for executing programs in a multi-mode microprocessor” by Gordon Letwin. The filing date of the patent is April 10, 1985, less than a year after the IBM PC/AT was introduced, when these sorts of problems would have been in fresh memory.

The patent contains the following text: Some programs written for the 8086 rely on [address wrap-around] to run properly. Unfortunately, memory locations extend above 1 megabyte in the real mode of the 80286 and are not wrapped to low memory locations. Consequently, programs including those written in MicroSoft PASCAL and programs which use the “Call 5 ” feature of MS-DOS will fail on the standard 80286 system.

Microsoft Pascal, huh? Two paragraphs later, Pascal is mentioned again, explaining how one might work around the problems: For example, no PASCAL programs are loaded into memory below 64K, and a special instruction is placed in the lower memory locations above 1 megabyte–for example, address 100000h or 100010h.

So… Pascal programs might have trouble when loaded below 64K? What does that have to do with the A20 line? A lot, it turns out. Continue reading →

Posted in 286, IBM, Microsoft, PC history, WordStar | 37 Comments

Microsoft Editor

Posted on March 11, 2018 by tenox

(This is a guest post by Antoni Sawicki aka Tenox)

In a recent blog post I lamented the lack of a good console/cmd/PowerShell text editor for Windows. During the process I made a rather interesting discovery, that in a fact there IS a “native” Windows, 32bit, console based text editor and it was available since earliest days of NT or even before. But let’s start from…

…in the beginning there was Z editor. Developed by Steve Wood for TOPS20 operating system in 1981. Some time after that, Steve sold the source code to Microsoft, which was then ported to MS-DOS by Mark Zbikowski (aka the MZ guy) to become the M editor.

M editor

Continue reading →

Posted in Development, DOS, Editors, Microsoft, NT, OS/2, Source code, Uncategorized | 23 Comments