• Please review our updated Terms and Rules here

Intel 8085 Assembly -- Unsupported OpCodes

SwedaGuy

Experienced Member
Joined
Feb 26, 2007
Messages
306
Location
Waupun, WI
I came across a rather obscure text document during a google search that indicated there were OpCodes in the 8085 processor that were unsupported and therefore undocumented in the Intel manuals. As some of you may know, I've been deeply involved in and 8085 assembly project for the last couple of years, so I am intrigued by the notion of secret goodies. Also, in an attempt to make my emulator as complete as possible, I would be interested in filling in some "blanks"

The following two instructions are pretty self explanatory, but what is the 'K' flag? How is it set/reset during processing? What event or events alter it? Also, it has to be bit 1, 3 or 5 (base 0) of the F register, but which one?

DDh JNK (Jump if 'K' Flag is NOT set)
FDh JK (Jump if 'K' Flag is set)

A few other oddballs:

08h DSUB (BC Pair is subtracted from HL Pair affecting all flags)

Sounds self-explanatory, but why are there no other double byte subs?

10h RRHL (Rotate Right HL Pair)

Why is there no instruction for rotating HL Left? Or rotating other pairs right? Or am I just missing these instructions somewhere? There are other vacant OpCode numbers available...

18h RLDE (Rotate Left DE Pair)

Same as above, why can DE only be rotated Left, and why are there no other instructions for rotating pairs left.

28h ADI HL (Add immediate an 8-bit value to HL Pair)
38h ADI SP (Add immediate an 8-bit value to Stack Pointer)

Don't need much help on these...unless someone has some juicy tidbits that aren't included in the description.

CBh RSTV (Does a RST 8 when the overflow flag is sent)

I'm assuming a Restart 8 is actually a Restart 7, and this was a typographical error on the part of the person who transcribed this originally.

EDh LHLX (Load HL pair with contents of address stored in DE pair)
D9h SHLX (Stores the HL pair contents to the address specified in DE pair)

These appear to be indirect references to addresses, in which case I am wondering if the bytes stored by SHLX are stored in reverse order as with the other double byte instructions. I'm assuming yes, but some clarification would be nice...

So...any Intel gurus out there that can get me further information? I'd like to make my emulator as complete as possible, but most of this is just for the curiosity value.
 
My first exposre to the 8085 was in 1976 and we had the benefit of the ear of the Intel Applications engineering staff. Those "undocumented" opcodes were a very poorly-kept secret; almost as "secret" as the LOADALL instruction in the 80286. :)

As a matter of fact, when Tundra Semi licensed the Intel design for the 80C85, they fully documented the "enhanced" instructions that had been there all along. They're still your best reference for exactly what's what.

Get the datasheet at:

http://www.datasheetarchive.com/pdf/972187.pdf

You've got a couple of things wrong, however. The 10H instruction is an arithmetic (i.e. sign extended) right shift of HL, not a rotate. Very useful.


Note that one of the new flags (V) is a 2's complement overflow flag and the other (UI) is an underflow for DCX instructions or an overflow for INX instructions. This last flag can be useful, as 16-bit INX/DCX instructions otherwise alter no other flags.

RST 8 really means that: a CALL to location 40H. Note that the 8085 also has externally-triggered "half" restarts, like RST 5.5, 6.5 and 7.5, calling 2CH, 34H and 3CH, respectively.

As for "why this set of registers and no others?", there are two reasons. The first is that the number of unused single-byte opcodes in the 8080 instruction set is really quite small, so you've got limited resources. On a deeper level, you have to understand the philosophy behind register use on the 8085. (A) is considered to be an 8-bit accumulator, while (HL) is used as a 16-bit accumulator. (DE) is pretty much intended to be used as an address pair (the use of (M) referring to an indirect (HL) address is more of an artifact of the 8008 architecture than of 8080).

We really wanted to use these instructions, as some of them, such as the load of DE with SP+offset would have been really useful for accessing stack-resident variables. Same goes for 16-bit loads and stores of HL to the address pointed to by DE. The problem was that Intel stated that these were dead-end instructions not likely to be implemented on future (i.e. 8086) designs and, in any case, would not be supported by Intel. So we stuck with 8080 code,with the only exceptions of RIM and SIM to handle TRAP conditions.
 
Last edited:
Do you know if there are any undocumented opcodes in the 8086/8088 processors?

There was, but as said, but enough partially documented or figured out at a later point in time. I don't have the list in front of me, but I can see what I can put up later. A couple were even used in minor programs out there.
 
Well, Chuck, you've certainly given me a lot to go on. I downloaded that PDF and started nosing around. I didn't know anything about the Tundra deal...

I'm not surprised some of the information I had was wrong. This text file is something of a mess, at one point even suggesting that one of these instructions can add an eight BYTE value to HL and store it in DE. Hmmm...I think the original author didn't proof read.

I guess the restart at vector 8 was the most surprising. The restart instructions are numbered 0 - 7, with seven restarting at 0038h. In the Intel manuals, 0040h is not referenced as a restart vector of any kind and there is no additional instruction to do an unconditional jump to that location.

Also, what this author referred to as the 'K' flag is really the 'UI' flag. Again, it makes perfect sense as explained in the Tundra manual.

The way you explain the use of the register pairs also makes me understand why some of the instructions can be used only on certain pairs. It would have made more sense if Intel had 'M' referring to 'DE' instead of 'HL', but they didn't always do things in the most intuitive manner.

Thank you for pointing me in the right direction. I think I've got enough info now to add these instructions to the emulator. Whether I use them or not, is a good question, but I'll keep them documented.

Thanks!
 
Do you know if there are any undocumented opcodes in the 8086/8088 processors?

There are a couple:

D6 - Set AL to FF if carry set, 00 if not. Modifies no flags. Works on all x86 processors.
0F - POP CS. Works only on the 8086 and 8088.

Not really undocumented instructions in the strict sense, there are the nonstandard variants of the AAM (D4 0A) and AAD (D6 0A) for "ASCII adjust for multiply" and "ASCII adjust for divide" respectively.

Long ago, someone noticed that the second byte of both of these instructions was 0A or decimal 10. It's quite natural to wonder what the instructions would do if the second byte were something else.

Well, the AAM divides AL by the value of the second byte and puts the quotient in AH and the remainder in AL. The AAD does the converse; multiplies AH by the value of the second byte, adds AL and returns the value in AL, clearing AH.

At one time, Intel grumbled that they wouldn't guarantee the behavior of these instructions on future processors with anything but the second byte 0A, but it was just grumbling. The nonstandard behavior is now firmly documented by Intel, so it's safe to use.

There's one other instruction on the 8086, F1, that is used with the In-circuit emulator (ICE) hardware. The operation of this instruction varies depending on the CPU family (e.g., 286, 386, etc.) and generally it's not terribly useful under non-ICE situations.
 
You're welcome.

Do you have a real 8085 to double-check your work on?

Chips? Yes...unfortunately the hardware I had running this is a little more difficult to scrounge up. I'm working on getting my hands on one from Georgia, but it's a slow process.
 
The Radio Shack/NEC/Kyocera laptops (M100 etc.) used 8085s and they're still fairly common, and there's also a lot of machine language expertise on their various machine-specific forums and mailing lists...

There are also several excellent emulators out there, but I don't personally know how well they emulate the non-docs,

m
 
Chips? Yes...unfortunately the hardware I had running this is a little more difficult to scrounge up. I'm working on getting my hands on one from Georgia, but it's a slow process.

There's no shortage of the things out there it seems to me, if you're willing to settle for less than a disk-based system. Remember that RIM/SIM gives you basic "bit banger" serial I/O, so all you really need is a bit of ROM to get you started and a little RAM as working storage.

You might, for instance, locate an Adaptec 1540 ISA SCSI controller which has an 8085 on it. Just reprogram the EPROM with your code and tack a couple of wires for SID and SOD.

There are several other ISA peripherals that employed the things. And don't forget the S100 boards, such as those from Compupro that used them.

Given the simplicity of the 8085 interface, you could even prototype something simple in an evening.
 
0F - POP CS. Works only on the 8086 and 8088.

Just scanned through my Intel documentation (the iAPX 86, 88 Users Manual), and I realized: That "POP CS" is reserved isn't really pointed out too embrassing.

Table 2-21; "Instruction Set Reference Data" (p. 2-51) states that "POP CS" is not valid.
Table 4-12; "Instruction Encoding" (p. 4-22) states no exceptions.
Table 4-13; "Machine Instruction Decoding Guide" (p. 4-27) notes the OpCode as "Not used"
Table 4-14; "Machine Instruction Encoding Matrix" (p. 4-36) shows a blank space where "POP CS" should be.
The "Insruction Set Summary" (Found in Appendix B) doesn't either show any exceptions.
Earlier versions of DEBUG DOES recall the "POP CS" instruction.
 
After a search, I found what I assume (and hope) is the authentic original document, here attached, as well as some mangled second-hand versions of it that are likely wrong and at any rate incomplete. If this one is right, then there were 12 undocumented instructions.
 

Attachments

  • Undoc_8085.pdf
    22.4 KB · Views: 4
Here's another undoc opcodes document for the 8085.

Stephen Adolph, who is a wiz with the Tandy Model 100/102/200, Nec PC-8201a/8300, etc... has a pdf file here
Click on the hard disk icon under the 'Action' column to download the pdf.

This is printed, like it was scanned from a book, with register diagrams.

T
 
Not sure why it didn't click when this thread was started, but I just realized what the 8085 processor was and how few computer systems ever used it.

So I have a Tandy 100 but what systems are here that support assembly programming on this processor? (I haven't dived too far into my 100 so maybe it does support coding more advanced stuff than basic, I just haven't seen it).

On a side note, what computer systems use the 80188? (I know a few that use an 80186 but the 80188 is an interesting one I never heard about).
 
After a search, I found what I assume (and hope) is the authentic original document, here attached, as well as some mangled second-hand versions of it that are likely wrong and at any rate incomplete. If this one is right, then there were 12 undocumented instructions.

RIM and SIM were documented in every 8085 instruction set summary (otherwise, how could one deal with TRAP conditions?). That leaves 10 undocumented.

80186s, as mentioned, were used in a few PC systems (e.g. Tandy 2000, Durango Poppy), but by the time the 80188 came out, most manufacturers had moved on to 80286 implementations, or realized how serious the compatibility problems were with the original 5150 architecture.

On the other hand the 80188, and its CMOS cousin, the 80C188 enjoyed a long product life in embedded applications. USR Courier modems used them, as did Cipher tape drives.


I've got a box called an "ASAP FAX" with one. It's got a 1.44MB floppy drive and 256K of DRAM in a small box that runs from a wall wart. It connects to the phone line and between your PC and printer. It can send, receive and print FAXes using your printer. Most interesting is that it's got a BIOS with functionally equivalent entry points to the original 5150 BIOS. As a rainy-day project, if I could figure out a way to interface a terminal to it, I could run MS-DOS.

Another competitor to the 186/188 were the NEC V40/V50 chips. One interesting feature is that these chips had extra lines to tell you what segment (CS, DS, ES, SS) a memory reference was using, so you could conceivably hang 4MB of memory on one.
 
I think the Hp 100LX and 200LX palmtops had an 80C186 CPU in them...

Barythrin, to answer your question on the M100, there was the Rom2/Cluseau ROM, which you can download at club 100, and then there was zbgasm, the cassette-based asm.debugger from Tandy. The zbgasm files are out there, can;t remember where, but If you can't find it, let me know.

The Rom2, if you grab the "developer's version," will ASM straight to a .CO Ml file on the M100/M102. You can actually edit, assemble, and run assembler code right on the M100/M102, and the NEC PC-8201a/8300.

You can save alot of time and trouble, by using Virtual T, the emulator. It is easier to use ROMs and such, and support the hardware that is currently being developed for the line, like ReMem, Rex, etc.. - it's here[/.URL] you can use both option ROMs, and software, and drag file in-and-out of the emulated system - it's quite cool, actually!

EDIT: Ok, found it, zbg is [URL="http://www.xibalba.com/website100/software.html"]here
, under the 'Utilities - Machine Language' section.
Get both zbg.co, and it's loader, zbg.ba

T
 
Last edited:
I'm not sure what computers used the 8085, but they were used in a lot of POS devices, most notably by Micros and Sharp.
 
I'm not sure what computers used the 8085, but they were used in a lot of POS devices, most notably by Micros and Sharp.

Well, this one certainly did.

Bill Godbout used the 8085 on a couple of his S-100 boards also (I'm thinking of his 85-88 combo CPU board). The 8085 has a bus structure that's very similar to the 8088, so the two pair up very nicely.
 
To reiterate. The instructions were never completely undocumented, nor the associated flags. One Intel licensee, Tundra Semiconductor (now part of IDT), even put them in their reference material for the 8085.

No speculation necessary. My guess is that some Intel suit decided that the instructions might not make it into the 8086, so shouldn't be documented. Note that the only "new" instructions originally documented were RIM and SIM and had to do specifically with the extra hardware incorporated into the 8085.
 
Back
Top