SYSENTER, Where Are You?

Posted on July 20, 2017 by Michal Necasek

It has only recently been brought to my attention that Intel’s SYSENTER/SYSEXIT instructions have rather unusual past, and their origin is shrouded in mystery and confusion. One facet of the usage of these instructions is also a little unorthodox.

Depending on who you ask, the SYSENTER/SYSEXIT instruction pair was introduced either in the Pentium Pro or in the Pentium II. But that makes absolutely no sense on the face of it, right? Either the Pentium Pro supported these instructions or it didn’t. Well…

The Pentium Pro (aka P6) was introduced in November 1995 and it was the first member of a tremendously successful family of processors which destroyed all of x86’s RISC rivals in the late 1990s, and quite possibly saved Intel after the Itanium and NetBurst debacles. The Pentium Pro and its immediate successors, Pentium II and Pentium III, turned out to be immensely scalable and between 1995 and 2001, raised the clock speed from 150 MHz (original Pentium Pro) all the way to 1.4 GHz (Pentium III-S and other Tualatin PIII variants). Continue reading →

Posted in Intel, PC history, Undocumented | 5 Comments

Of G-Men and Farmers

Posted on July 9, 2017 by Michal Necasek

There’s an interesting story concerning this Midiman GMan General MIDI sound module. It involves Midiman (better known as M-Audio), the Farmers Insurance Exchange, and also Dream/Atmel, Crystal Semiconductor, and Roland. (Apologies for the beat-up specimen.)

Midiman MIDI GMan sound module

The story of course concerns the famous Sound Canvas sound banks that Dream/Crystal offered for use with the SAM 9203, 9233, and related synthesizers. It was well known in the 1990s that the Dream/Crystal instrument banks sounded just like Roland’s, and that Roland eventually sued them. But the details were not well known, and they’re interesting. Continue reading →

Posted in Crystal Semi, Dream, Legal, MIDI, Roland, Sound | 20 Comments

Would You Believe It?

Posted on July 2, 2017 by Michal Necasek

The following article was printed in Computer Shopper, June 1992 issue (page 152). Commentary follows.

The Big Squeeze

Compression Scheme Shatters Storage Logjam

Todd Daniel believes he has found a way to revolutionize data storage as we know it.

DataFiles/16, a zip-style data-compression product released by Wider Electronic Bandwidth Technologies (WEB), allows users to compress data at a 16-to-1 ratio. That’s a major advance when you compare it with Stacker 2.0’s 2-to-1 ratio.

DataFiles/16 relies purely on mathematical algorithms; it works with almost any binary file. Because of the math involved, the ratio of compression is directly proportional to the size of the uncompressed file. In order to get the full effect of 16-to-1 compression, the original file must be at least 64K.

During a demonstration at our offices, Daniel, the company’s vice president of research and development, compressed a 2.5Mb file down to about 500 bytes, four levels of DataFiles/16. Because successive levels compress at a lower ratio as the volume of the file decreases, DataFiles/16 directly zips and unzips files to the chosen level.

After compressing a file, users can compress the data another eight times with DataFiles/16. This gives DataFiles/16 the potential to compress most files to under 1,024 bytes, whether the original file is 64K or 2.6 gigabytes. By comparison, SuperStor 2.0’s new compression technique can be performed only once.

By June, WEB plans to release its first hardware packages utilizing the same method. The two new device-driver cards will operate impeccably, compressing and decompressing data on the fly at ratios of 8-to-1 and 16-to-1, respectively.

A standard defragmentation program will optimize data arrangement, while an optional disk cache will speed access time. Both cards will come in DOS, Macintosh, and Unix versions. The DOS version is scheduled for a July release, and the company says the others will follow shortly.

The implications of WEBs data-compression technique in the communications field have yet to be calculated, but Daniel says a 16-to-1 ratio could save certain companies up to 5 percent of their storage costs. If DataFiles/16 lives up to its early promise, data compression will have taken a quantum leap forward.    — Jim O’Brien

Continue reading →

Posted in PC history, PC press | 56 Comments

Brightening Up

Posted on June 26, 2017 by Michal Necasek

A depressingly yellowed Roland CM-64 led me to try retr0bright for the first time. The short story is that despite a few minor missteps, the experiment was a success. Yes, it really does work! Here’s what the CM-64 looked like (bottom), for comparison next to a much better preserved Roland CM-300 (top).

A sad looking Roland CM-64

I followed the original recipe using 11.9% hydrogen peroxide stabilized with etidronic and phosphoric acid. The problem was that either I used too large spoon or misjudged what a “heaped tablespoonful” means. I ended up with too much Xanthan gum which a) caused severe difficulties for the blender, and b) resulted in a very thick and clumpy gel instead of a smooth substance. Continue reading →

Posted in Fixes, Hardware Hacks, Roland | 7 Comments

VME Fixed on AMD Ryzen

Posted on June 11, 2017 by Michal Necasek

As expected, AMD fixed the problem with VME that affected Ryzen processors. The fix is shipped in the form of a microcode patch as part of AGESA 1.0.0.6, currently being rolled out by OEMs as part of a BIOS update. Which means that depending on the OEM and board, a fix may or may not be available for a given system today.

The patch level for the fixed microcode is 8001126 or higher. The older microcode revision 800111C (part of AGESA 1.0.0.4a) is known to have trouble with VME.

Posted in AMD, Bugs | 17 Comments

Rich Heimlich’s Patch Set Overview

Posted on June 9, 2017 by Michal Necasek

Resurrected from the depths of the Internet, here comes an interesting and useful historical resource.  In 1994 and 1995, Rich Heimlich published several iterations of his “patch set overview” covering mainstream wavetable sound cards, daughterboards, and modules (“mainstream” being defined as under $400, later under $350).

The introduction to the first overview from March 1994 explains the motivation: You must really dissect what phrases like “It’s the best sound card I’ve ever heard”, mean. I find phrases like that are often VERY true. It is the best card that person has heard, but they often forget to mention that they’ve only heard one or two.

As the proprietor of a games QA company, Rich Heimlich was in a unique position because both software and hardware developers had need for his services. Given the cost of the hardware, there were probably very few people who could do such a hands-on comparison; even in the first overview the total cost of the gear covered was probably around $2,500, and it only went up from there with more products covered, ending closer to $6,000 in the final published overview (the later editions helpfully includes street prices). Continue reading →

Posted in PC history, Sound, Wave Blaster | 33 Comments

PC DOS 1.0, But Not Quite

Posted on May 26, 2017 by Michal Necasek

Last week a most interesting image of a 160K disk arrived at the OS/2 Museum. The files on the disk image are rather old. When the disk boots up (not trivial, see below), the following message appears:

Almost like PC DOS 1.0

Astute readers will notice that that’s exactly the same message as PC DOS 1.0 (August 1981) shows, but this COMMAND.COM did not prompt for the date. That’s because this disk is not from August but rather early June 1981—newest file is timestamped June 6, 1981—which may make it the oldest known surviving piece of software written for the IBM PC (not counting the IBM PC ROMs which are dated April 1981). It’s certainly the oldest known surviving PC operating system. It comes with a short text file which provides further insight into the development history of PC DOS.

Even better, the disk can be explored at pcjs.org live in its native habitat. Note that the original disk had AUTOEXEC.BAT which immediately asked for the current date and launched Advanced BASIC; for improved ease of use, the batch file was disabled by renaming it to AUTOEXEC.BAK. Continue reading →

Posted in DOS, IBM, Microsoft, PC history, Pre-release | 42 Comments

How Many Gravis UltraSounds?

Posted on May 20, 2017 by Michal Necasek

The question came up a while ago. Just how commercially unsuccessful was the Gravis UltraSound? There appears to be no public information about the sales volume of the UltraSound. But now, looking at a sample of 3 (three) classic GUS cards, it occurs to me: Could the serial number be exactly that? I know that’s extrapolating a lot from very little.

Lots of folks put pictures of their GUSes on the Internet. Not too many show the reverse side where the S/N sticker is usually located. So let’s start with mine:

  • GUS 2.4, PCB week 47/92, S/N: K33579
  • GUS 3.7, PCB week 50/93, S/N: K103633
  • GUS 3.73, PCB week 16/94, S/N: K119146

If the serial number is a true serial number, it would mean there were somewhere upwards of 120,000 GUS Classics made, perhaps around 150,000 (in 1994, the GUS MAX took over).  The 2.4 is an early revision (2.2 was the first production rev), so it has a relatively low serial number. The 3.7 and 3.73 are fairly close to each other in age so makes sense their serial numbers wouldn’t be very far apart. The 2.4 and 3.7 are a year apart so there’d be a much bigger gap.

GUS MAX does not appear to have a real serial number. The S/N looks to be a production week/year (mine says “Serial Number 0695”).

What serial number does your GUS Classic have? With enough data, it should become apparent if the serial number looks like a simple counter incremented for each card, and it should be possible to estimate how many there were. Please list the version, the date code etched on the reverse of the PCB, the serial number, and other identifying information if it seems relevant. Continue reading →

Posted in PC history, Sound, UltraSound | 49 Comments

VME Broken on AMD Ryzen

Posted on May 12, 2017 by Michal Necasek

That’s VME as in Virtual-8086 Mode Enhancements, introduced in the Intel Pentium Processor, and initially documented in the infamous NDA-only Appendix H.

Almost immediately since the Ryzen CPUs became available in March 2017, there have been various complaints about problems with Windows XP in a VM and with running 16-bit applications in DOS boxes in Windows VMs. Multiple versions of Windows are affected. Some (but not all) other operating systems are affected as well, for example OS/2 Warp running in a VM on Ryzen when attempting to open a DOS window:

OS/2 Warp VM DOS session on Ryzen

After analyzing the problem, it’s now clear what’s happening. As incredible as it is, Ryzen has buggy VME implementation; specifically, the INT instruction is known to misbehave in V86 mode with VME enabled when the given vector is redirected (i.e. it should use standard real-mode IVT and execute in V86 mode without faulting). The INT instruction simply doesn’t go where it’s supposed to go which leads to more or less immediate crashes or hangs.

How did AMD miss it? Because only 32-bit OSes are affected, and only when running 16-bit real-mode code. Except with Windows XP and Server 2003 it’s much worse and these systems may not even boot. Continue reading →

Posted in AMD, Bugs | 35 Comments

SGDT/SIDT Fiction and Reality

Posted on May 4, 2017 by Michal Necasek

PSA: Actual hardware behavior takes precedence over vendor documentation. Or, as they say… trust but verify.

A reader recently complained how Intel and AMD do not implement the SGDT and SIDT instructions the same way. AMD documentation states that these instructions ignore any operand size prefixes and always store full 32 bits of base address. Intel documentation on the other hand states that with 16-bit operand size, SGDT/SIDT stores 24 bits of the base address and the 4th byte is zeroed, and while using 32-bit operand size, all 32 bits of the base address are stored.

What a mess, right? How is a poor developer supposed to write code that works on all CPUs, and why the heck is AMD inventing its own things? Yet the reality is a bit different… Continue reading →

Posted in 286, 386, AMD, Documentation, Intel | 37 Comments