Frequently Given Misleading Answers

The other day I came across this FGA item describing how to detect virtualized environments. It includes interesting comments which make Microsoft, Intel, and AMD sound stupid, but perhaps only reflect on the author being either deliberately misleading, or trying far too hard to sound smarter than everyone else.

Quoting the FGA:

According to Microsoft, a flag bit in the ECX register (bit #31, “Hypervisor present”), after executing CPUID with the EAX register set to 0x000000001, will be set to 1 in a (Microsoft) virtual machine and set to 0 on real hardware. This is indeed the official Hypervisor detection mechanism. It’s also the official detection mechanism for VMWare.

But here Microsoft and VMWare are incorrectly relying upon an accident of hardware implementation. Both Intel’s and AMD’s CPUID specifications state that bit #31 of the ECX register is reserved. Intel’s specification even explicitly states that one should not count on the value of the bit. That includes not counting on the fact of it being zero on real hardware. As such, Microsoft’s “official” detection mechanism is bogus.

Sadly, only the FGA itself is bogus. It makes several bold assumptions: Microsoft has absolutely no idea how to design software, Microsoft has zero influence on development of future CPUs, Intel and AMD have no idea how to design CPUs, and Intel and AMD have no idea how their existing CPUs work. Let’s take a look at the claims in detail. Continue reading

Posted in Corrections, Documentation, Virtualization | 9 Comments

Wanted: Console Text Editor for Windows

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

Since 2012 or so Microsoft is pushing concept of running Windows Server headless without GUI and administering everything through PowerShell. I remember sitting through countless TechEd / Ignite sessions year after year and all I could see were blue PowerShell command prompts everywhere. No more wizards and forms, MMC and GUI based administration is suddenly thing of a past. Just take a look at Server Core, WinPE, Nano, PS Remoting, Windows SSH server, Recovery Console and Emergency Management Services. Even System Center is a front end for PowerShell. Nowadays everything seems to be text mode.

This overall is good news and great improvement since previous generations of Windows, but what if you need to create or edit a PowerShell, CMD script or some config file?

Oooops, looks like you are screwed. Seems that Redmond forgot to include most crucial tool in sysadmin’s job – a simple text mode editor. WTF Microsoft?

So, are there any 3rd party alternatives? Yes, and there are and quite a lot of them! Unfortunately none are perfect and most are old and unmaintained. This article aims to be a grand tour of whatever is available out there.

Continue reading

Posted in Editors, Microsoft, NT, Watcom | 16 Comments

Dumping Ensoniq Soundscape ROMs

Let us posit that one has a need to obtain an image of the instrument ROM of an Ensoniq Soundscape S-2000, Elite, or OPUS sound card. There are two basic approaches: A) Desolder or cut off the ROM chip, plug into a PROM reader, extract the data; or B) Design and write software to read the ROM contents and leave the hardware intact. Method A) is crude but effective—very simple but potentially destroys the card. So let’s see how method B) might be done.

First it is necessary to understand the architecture of the Ensoniq Soundscape. This text will focus on the original S-2000 and Elite, with a brief note on the newer Opus and VIVO cards.

Key components of Ensoniq S-2000 (1994)

The S-2000 is a 16-bit sound card with an onboard synthesizer and instrument ROM. The card is compatible with Sound Blaster and AdLib (Yamaha OPL2/OPL3) standards, as well as MPU-401 and General MIDI, but the compatibility is implemented purely in software (firmware in fact). The S-2000 has four major chips, clearly seen in the above photo: Ensoniq ODIE (ES 5706), the system interface and control gate array; Ensoniq OTTO (ES 5506), the wavetable synthesizer chip; Analog Devices AD1848, the audio codec; and Motorola 68EC000, the OBP (On-Board Processor). There is also 128KB of DRAM for use by the OBP, and an instrument ROM with 1 or 2 MB of data (our target).

Much like it was the case with E-mu/Creative, Ensoniq’s sound cards were essentially the respective company’s cut-down synthesizers on an ISA card; in Ensoniq’s case it was the TS-10/TS-12. The Soundscape was clearly not intended for musicians (it was a consumer/gaming card) and therefore had no sampler functionality (no sample RAM), even though the OTTO synthesizer could have handled it without trouble.

Note: For reasons which are not clear, certain people think that just because a chip has ‘(C) SEQUOIA DEV GRP’ etched on it, it must be called “Sequoia”. Sequoia Development Group was in fact a company specialized in developing MIDI equipment and is known to have provided the firmware for the Logitech Soundman Wave card (Yamaha OPL4 synthesizer) or  Samsung KS0164 and KS0165 synthesizer chips. The Ensoniq chip in question is clearly called ODIE.

Continue reading
Posted in Ensoniq, Software Hacks, Sound Blaster | 13 Comments

WordStar Again

While trying to work on my DOS 5.0 article, I looked at DOS 5.0 build 224 from June 1990, which is the oldest surviving beta of DOS 5.0. And the README contains the following intriguing text, which reminded me of previous WordStar ruminations:

DOS 5.0 and WORDSTAR

Due to a known problem, some older versions of WORDSTAR don't
work correctly with this pre-release version DOS 5.0. We know
what the problem is, but the fix was not incorporated in time
for this beta release.
WORDSTAR 2000 seems to work fine with DOS 5.0.

This is of course maddening because it does not mention which version of WordStar might have trouble. Version 3.x? Version 4.x, which is in fact newer than WordStar 2000? Some other version? There were more than a few. Well, let’s try WordStar 3.24 (early 1983) since that’s what I happen to have on hand:

WS 3.24 does not like DOS 5.0 build 224

Yep, there certainly is some kind of problem. But lack of memory? Unlikely. So what is it then? Continue reading

Posted in DOS, PC history, WordStar | 74 Comments

DOS 5: TMI

For several years now I’ve been trying to continue the DOS history series and write (or rather finish) a DOS 5 page. While tracing the history of DOS 1.0 or 2.0 is quite difficult and the amount of source material is very limited, with DOS 5.0 there’s the opposite problem, too much information. Way too much.

Thanks to various lawsuits, thousands of internal Microsoft documents were made public. Dozens if not hundreds are relevant to DOS 5. There are documents which outline the development plans in detail, and there’s even a fairly comprehensive post-mortem report which is a great source of information about what actually happened (as opposed to the usual Microsoft pie in the sky unrealized plans, like a DOS 5 release in late 1989).

Finding the relevant documents is not easy. Some are long e-mail dumps where only a few bits are pertinent. Others are awful scans which defeat any OCR, but are still readable by someone who has a bit of context information. There is a lot to go through.

The next problem is how to condense the huge amount of raw information into something informative, readable, and accurate, without ending up like the infamous Wikipedia FAT entry which bears no resemblance to an encyclopedia article and makes a solid argument that too much information its just as bad as too little.

But I’m trying.

Posted in DOS, PC history, Random Thoughts | 14 Comments

About That Warranty…

Readers have been wondering what kind of valuable warranty users of Microsoft’s Quick Pascal 1.0 (and other products) might be voiding by running it on top of DR DOS 3.3x or 3.40. I don’t have the original Quick Pascal 1.0 package, but I have a BASIC 6.0 package from 1988 which likely used identical wording. Here’s the scan:

Microsoft’s warranty for BASIC 6.0

In other words, the “valuable warranty” was a very limited 90-day warranty that actually promised next to nothing. In practice Microsoft might refuse to support DR DOS users, but those would probably have little difficulty showing that the same bug occurs when running on top of MS-DOS. Continue reading

Posted in Digital Research, Microsoft, PC history, Undocumented | 16 Comments

How to Void Your Valuable Warranty

Try installing Quick Pascal 1.0 on DR DOS 3.40:

No valuable warranty for you!

What is going on there? It’s a long story…

In 1988, Microsoft became increasingly worried by a new upstart OS from an old rival, DR DOS. Over the years, Digital Research (DRI) had added DOS compatibility to its CP/M-86 based operating systems. Eventually DRI came up with the idea of ditching the CP/M functionality and offering a DOS compatible operating system.

Ordinarily DRI would not stand any chance, but in 1988, the DOS business was not business as usual. IBM took over the development of DOS in 1986 and produced DOS 3.3 and DOS 4.0. Microsoft’s systems group heavily focused on OS/2 and to a lesser extent, Windows 2.x. Microsoft was still licensing MS-DOS to OEMs as before, but there was just a skeleton crew maintaining DOS at Microsoft. Continue reading

Posted in Digital Research, DOS, Microsoft | 43 Comments

There’s Another Possibility

Four years ago we pondered why on Earth a DOS floppy boot sector might start with 69h, supposedly a “direct jump” opcode. Which is the IMUL instruction on 80186 and later, and not documented on 8086. In the meantime, it turned out that one of the basic assumptions was invalid: The boot sector does not have to begin with executable code, and in fact need not contain any executable code at all.

This goes back to a distinction which used to be important but over time got all but forgotten: There is a difference between a “DOS compatible” and an “IBM compatible” (or PC compatible) machine. DOS-compatible systems are a superset of IBM-compatible ones. In the early to mid-1980s, there was a fairly large class of 8086/8088 machines which used DOS (and therefore, FAT-formatted floppies) but were not PC compatible. In fact DOS-compatible machines came first, in the form of SCP’s S-100 bus systems running MS-DOS, née 86-DOS, predating the original IBM PC.

It was far from obvious in the early 1980s just how dominant the IBM PC and derived designs would become. A number of vendors offered 8086/8088 machines running DOS (often DOS 2.11) but not using IBM-style ROM BIOS and not necessarily using even remotely IBM-compatible hardware and peripherals. Some of the better known examples were the DEC Rainbow 100 (dual-chip Z80/8088), the Apricot PC, or the NEC APC-III.

Most of the DOS-compatible machines quickly gave way to PC-compatible ones, simply because of the immense wealth of software and hardware produced for PCs (and not for the DOS compatibles). One of the notable exceptions was the NEC PC-98 series whose last model was introduced in 2000. NEC’s PC-98 served the Japanese market, to a significant extent insulated from most of the rest of the world until the Windows 9x era. Another Japanese DOS compatible system was Fujitsu’s FM Towns, introduced as late as 1989 and built until 1997.

There was of course yet another, even more distant class of a system, which one might call “FAT compatible”. For example the Atari ST was built around a Motorola 68000 CPU, but its operating system (TOS) used FAT-formatted floppies.

What does this have to do with DOS boot sectors? A lot. All these systems used FAT-formatted floppies, either optionally or exclusively. They also showed that the FAT filesystem is reasonably flexible. Around 1981, SCP used 8″ single-and double-sided FAT floppies with 128-byte and 1024-byte sectors. Apricot used single-sided 3½″ floppies with 512-byte sectors and 70 tracks. FM Towns used 3½″ floppies with 1024-byte sectors. There were lots of possibilities. Continue reading

Posted in DOS, Floppies | 57 Comments

AMD64 APM Archive Online

Thanks to Konstantin Belousov, the OS/2 Museum AMD64 APM (Architecture Programmer’s Manual) is now available online. Big thanks to blog readers who recently supplied several missing revisions of the documents.

This is a nearly complete archive of all published AMD64 APM documentation starting with April 2003, currently up to and including December 2017. Missing is Volume 2 (System Programming) revision 3.16 from June 2010 which only lasted a week or two before being replaced by revision 3.17.

Possibly missing is Volume 6 (“new instructions”) revision 3.02. Why “possibly”? Because it’s not clear if that revision was public, and chances are it was not.

Also included are several pre-release revisions from 2002, before the first AMD64 Opteron CPUs were released in April 2003. Again it is very unclear which revisions were public because the pre-release documents have no revision history. Note that the pre-release documents refer to the AMD x86-64 Architecture rather than AMD64 Architecture.

Missing manuals are always welcome!

Posted in AMD, AMD64, Documentation | 2 Comments

Undocumented 8086 Opcodes, Part I

This is a guest post by Raúl Gutiérrez Sanz

This multi-part document is about undocumented 8086 processor opcodes and their behavior. Most of the document will likely apply to the 8088 processor as well, but this has not been verified. It doesn’t apply to any other processor/controller, like the 80186, 80286 or newer, as they use the undocumented 8086 opcodes to implement new instructions. For the same reason, it does not apply to NEC V20/V30 processors either. And even when 8086 opcodes remain undocumented on new processors, their behavior is unlikely to be the same (not least because starting with the 80186, undefined opcodes generally raise an invalid instruction exception).

Sometimes it is not easy to determine which opcodes are documented and which ones are not, because some of them appeared or disappeared at some point from the official Intel documentation. So, while most opcodes listed in this document have never been officially documented, you may find some of them in certain Intel documents, or at least in some versions.

On the 8086, all undocumented opcodes do something, but typically not something very useful. After all, if they did something useful, they would have been documented.

This document will be split into three sections:

  • Section I—Holes In the Opcode Map
  • Section II—Holes In the Addressing Scheme
  • Section III—”Nonsense” Instruction/Operand Combinations

For some undocumented features, the categorization is admittedly arbitrary.

Continue reading

Posted in 8086/8088, Intel, Undocumented | 13 Comments