Finding Undocumented 8086 Instructions Via Microcode

July 17, 2023 by Al Williams 23 Comments

Video gamers know about cheat codes, but assembly language programmers are often in search of undocumented instructions. One way to find them is to map out all of a CPU’s opcodes and where there are holes, try those values, and see what happens. Not good enough for [Ken Shirriff]. He prefers examining the CPU’s microcode and deducing what each part of it does.

Microcode is a feature of many modern CPUs. The CPU runs several “microcode” instructions to process a single opcode. For the Intel 8086, there are 512 micro instructions, each with 21 bits. Each instruction has two parts: a part that moves a source to a destination and another that performs some other operation, such as an ALU operation. [Ken] explains it all in the post, including several hidden registers you can’t see, but the microcode can.

Searching for holes in the opcode table.

Some of the undocumented instructions are probably not useful. They are either impractical or duplicate a function you can already do another way. Not all of the instructions are there for technical reasons. For example, opcode D6, commonly known as SALC for “Set AL to Carry”, seems to exist only as a trap for anyone making a carbon copy of Intel’s microcode. When other companies like NEC made 8086 clones, having an undocumented instruction would strongly suggest they just copied Intel’s intellectual property (in NECs case, they didn’t).

Other cases happen where an instruction just doesn’t make sense. For example, you can pop all segment registers, and though it is not documented, you can deduce that POP CS should be opcode 0F. The problem is there is no sane reason to pop CS off the stack. The instruction works; it just isn’t useful. The opcodes from 60-6F are conditional jumps that are no different from the instructions at 70-7F because of decoding. There is no reason to document both identical instruction ranges.

The plot thickens when you go to two-byte instructions. You’ll find plenty of instructions of dubious value. You don’t hear much about undocumented instructions anymore. Why? Because modern CPUs have enough circuitry to dedicate some to detecting illegal instructions and halting the CPU. But the 8086 was squeezed too tight to allow for such a luxury. Good thing for people like us who enjoy solving puzzles.

You can still get a modern CPU to tell you more about instructions even if it won’t run them. Even the 80286 had some secret opcodes.

String Operations The Hard(ware) Way

April 7, 2023 by Al Williams 7 Comments

One of the interesting features of the 8086 back in 1978 was the provision for “string” instructions. These took the form of prefixes that would repeat the next instruction a certain number of times. The next instruction was meant to be one of a few string instructions that operated on memory regions and updated pointers to the memory region with each repeated operation. [Ken Shirriff] examines the 8086 die up close and personal to explain how the 8086 microcode pulled this off and it is a great read, as usual.

In general, the string instructions wanted memory pointers in the SI and DI registers and a count in CX. The flags also have a direction bit that determines if the SI and DI registers will increase or decrease on each execution. The repeat prefix could also have conditions on it. In other words, a REP prefix will execute the following string instruction until CX is zero. The REPZ and REPNZ prefixes would do the same but also stop early if the zero flag was set (REPZ) or not set (REPNZ) after each operation. The instructions can work on 8-bit data or 16-bit data and oddly, as [Ken] points out — the microcode is the same either way.

[Ken] does a great job of explaining it all, so we won’t try to repeat it here. But it is more complicated than you’d initially expect. Partially this is because the instruction can be interrupted after any operation. Also, changing the SI and DI registers not only have to account for increment or decrement, but also needs to understand the byte or word size in play. Worse still, an unaligned word had to be broken up into two different accesses. A lot of logic to put in a relatively small amount of silicon.

Even if you never design a microcoded CPU, the discussion is fascinating, and the microphotography is fun to look at, too. We always enjoy [Ken’s] posts on little CPUs and big computers.

Silicon Sleuthing: Finding A Ancient Bugfix On The 8086

November 28, 2022 by Al Williams 31 Comments

Few CPUs have had the long-lasting influence that the 8086 did. It is hard to believe that when your modern desktop computer boots, it probably thinks it is an 8086 from 1978 until some software gooses it into a more modern state. When [Ken] was examining an 8086 die, however, he noticed that part of the die didn’t look like the rest. Turns out, Intel had a bug in the original version of the 8086. In those days you couldn’t patch the microcode. It was more like a PC board — you had to change the layout and make a new one to fix it.

The affected area is the Group Decode ROM. The area is responsible for categorizing instructions based on the type of decoding they require. While it is marked as a ROM, it is more of a programmable logic array. The bug was pretty intense. If an interrupt followed either a MOV SS or POP SS instruction, havoc ensues.

Continue reading “Silicon Sleuthing: Finding A Ancient Bugfix On The 8086” →

Exploring Texas Instrument’s Forgotten CPU

September 23, 2022 by Al Williams 21 Comments

Texas Instruments isn’t the name you usually hear associated with the first microprocessor. But the TI TMX 1795 was an 8008 chip produced months before the 8008. It was never available commercially, though, so it has been largely forgotten by most people. But not [Ken Shirriff]. You can see a demo from 2015 of the device in the video below, too.

The reason the chips have the same architecture is they were built to replace the same large circuit board inside a Datapoint 2200 programmable terminal. These were big beasts that could be programmed in BASIC or PL/B.

Datapoint asked Intel to shrink the board to a chip due to heating problems — but after delays, they instead replaced the power supply and lost interest in the device. TI heard about the affair and wanted in on the deal. However, Datapoint was unimpressed. The chip didn’t tolerate voltage fluctuations very well, since they had replaced the power supply and had a new CPU design that was faster than the chip would be. They were also unimpressed with how much stuff you had to add to get a complete system.

So why did the Intel 8008 work out in the marketplace but the TI chip didn’t? After all, Datapoint decided not to use the 8008, also. But as [Ken] points out, the 8008 was much smaller than the TI chip and, thus, was more cost-effective to produce.

As usual, [Ken]’s posts are always interesting and enlightening. He’s looked at a lot of old computers. He’s even dug into old space hardware. Great stuff!

Continue reading “Exploring Texas Instrument’s Forgotten CPU” →

The MOS 7600 Video Game Chip Gives Up Its Secrets

September 7, 2022 by Jenny List 5 Comments

A good chip decapping and reverse engineering is always going to capture our interest, and when it comes from [Ken Shirriff] we know it’s going to be a particularly good one. This time he’s directed his attention to the MOS 7600 all-in-one video game chip (Nitter), a mostly forgotten device from the 6502 chipmaker which we featured a few weeks ago when it was the subject of a blogger’s curiosity. The question then was whether it contained a microprocessor or not and even whether it was another 6502 variant, and the answer revealed in the decapping answers that but will disappoint the 6502 camp.

On the chip is a mixture of analog and digital circuitry, with some elements of a more traditional game chip alongside a ROM, a PLA, and a serial CPU core. The PLA stores pixel data while the ROM stores the CPU code, and the CPU serves to perform calculations necessary to the games themselves. He hasn’t fully reverse-engineered either, but the two areas of the chip are mask-programmed to produce the different games with which the chip could be found.

So the answer to the original question is that there is a CPU on board, but it’s not a 6502 and the operation is a hybrid between dedicated game chip and CPU-controlled chip. What we find interesting is that this serial CPU core might have as we mused in the previous piece made the heart of a usable 1970s microcontroller, was this a missed opportunity on the part of MOS? We’ll never know, but at least another piece of early video game history has been uncovered.

Can You Hear Me Now? Lunar Edition

May 16, 2022 by Al Williams 9 Comments

Despite what it looks like in the movies, it is hard to communicate with astronauts from Earth. There are delays, and space vehicles don’t usually have a lot of excess power. Plus everything is moving and Doppler shifting and Faraday rotating. Even today, it is tricky. But how did Apollo manage to send back TV, telemetry, and voice back in 1969? [Ken Shirriff] and friends tell us part of the story in a recent post where he looks at the Apollo premodulation processor.

Things like weight and volume are always at a premium in a spacecraft, as is power. When you look at pictures of this solid box that weighs over 14 pounds, you’ll be amazed at how much is crammed into a relatively tiny spot. Remember, if this box was flying in 1969 it had to be built much earlier so there’s no way to expect dense ICs and modern packaging. There’s not even a printed circuit board. The components are attached to metal pegs in a point-to-point fashion. The whole thing lived near the bottom of the Command Module’s lower equipment bay.

Continue reading “Can You Hear Me Now? Lunar Edition” →

The Apollo Digital Ranging System: More Than Meets The Eye

April 25, 2022 by Ryan Flowers 15 Comments

If you haven’t seen [Ken Shirriff]’s teardowns and reverse engineering expeditions, then you’re in for a treat. His explanation and demonstration of the Apollo digital ranging system is a fascinating read, even if vintage computing and engineering aren’t part of your normal fare.

The average Hackaday reader should be familiar with the concept of determining the distance of a faraway object by measuring how long it takes a sound or radio wave to be reflected, such as in sonar and radar. Going another step and measuring Doppler Shift – the difference in the returned signal’s frequency – will tell us the velocity of the object relative to our position. It’s so simple that an Arduino can do it. But in the days of Apollo, there was no Arduino. In fact, there were no Integrated Circuits. And Apollo missions went all the way to the moon- far too distant for relatively simple Radar measurements. Continue reading “The Apollo Digital Ranging System: More Than Meets The Eye” →