In S. P. Morse's 1980 allegory, "In The Beginning", he writes

And Intel said, "Let there be an 8085 with an oscillator on the same chip as the processor, and let an on-chip system controller separate the data from the control lines." And Intel made a firmament and divided the added instructions which were under the firmament from the added instructions which were above the firmament. And Intel called the first set of instructions RIM and SIM. And the other instructions Intel never announced.

Given the context of the creation of the "Intel 8085", I think to satisfy this claim all of the following must be applicable,

  • instructions in the Intel 8085
  • instructions not present in the Intel 8080
  • instructions that are not documented
  • instructions that are neither SIM nor RIM

What instructions is Steven Morse referring to?

1 Answer 1


Ken Shirriff has, as so often, a nice table to start with - especially nice to detect the 'undocumented' ones. All opcodes in lower case are 'undocumented'. With sorting his table according to the 'octal' (2-3-3) decoding logic the 8085 uses (*1), the first are nicely grouped where the 8080 only decoded NOP:

  • (NOP - Not undocumented, but on the 8080 it filled the whole 0-x-0 group)
  • DSUB - 16 bit subtract HL - BC
  • ARHL - Arithmetic Right shift HL
  • RDEL - Rotate (shift) DE Left into carry, fill in zero
  • (RIM - Not undocumented, but added with the 8085)
  • LDHI - Load DE with HL plus Immediat8 (HL+i8->DE)
  • (SIM - Not undocumented, but added with the 8085)
  • LDSI - Load DE with SP plus Immediat8 (SP+i8->DE)

The others are scattered in remaining holes for 16 bit operations and jumps (where they belong anyway)

  • RSTV - ReSTart if V is set
  • SHLX - Store HL indeXed by DE [DE]=HL
  • JNK - Jump on Not K
  • LHLX - Load HL indeXed by DE HL=[DE]
  • JK - Jump on K

JK/JNK are about the (equally undocumented) K-flag (*2), while RSTV is about the (similarly undocumented) V-Flag (*3).

(Jules did already a great write-up about those and how they may these may be translated into x86 in his answer to a related question)

These instructions would have made DE a quite versatile register for 16 bit address calculation in indirect operations (*4). These instructions were present in all 8085, including second source, I ever tested (*5).

I seriously have no idea why they where kept 'secret', as they would have improved HLL handling a lot. Morse offers an explanation in his paper Intel Microprocessors: 8008-8086 (MS-Word Document) published in IEEE Computer, Vol 13, No. 10, page 46, October 1980

Several other instructions that had been contemplated were not made available because of the software ramifications and the compatibility constraints they would place on the forthcoming 8086.

This is not only incorrect, as these instructions were available, but, to me it sounds quite like hindsight, as the 8085 was delivered a full two years before the 8086, about the time the 8086 project started. Further all of the 16 bit instructions are (in some form) present in the 8086 (as well as the Overflow Flag) and translation would have been as straight forward as with the rest. Even more so, the only two instructions officially added, RIM and SIM, are among the ones explicit not supported by the 8086. (*6)

*1 - Less obvious in Pastraiser's 8085 opcode table in classic hex notation - but maybe more like we're used to.

*2 - Which might have been the one intended for signed comparison, but that's a different story.

*3 - The V-Flag signals overflow, much like the V flag on the 6502. With RSTV this might have been intended for easy insertation of overflow exception handling.

*4 - I really used them a lot, as DE now became a quite useful register instead of being a mere second HL usable via XHNG. Address calculation for structures became quite doable without bloating the instruction set.

*5 - Mostly SIEMENS SAB8085, but also Toshiba, NEC, AMD and maybe others.

*6 - My personal speculation is that it wasn't, as so often, not a technical or design decision but made on management level to keep it '100%' 8080 compatible (whatever that meant for management blurb at that time) and thus suppressing the nice add ons engineering had made (*7). RIM and SIM eventually as exception, as they where needed to support the new interrupt feature.

*7 - Which leads to another thought: Having the ability for fast offset calculation to a memory (HL or stack pointer, 16 bit left shift for word address calculation and 16 bit indexed loads) is quite pleasing for HLL programming. So while Mr. Morse does rightfully deserve credit for making the 8086 with HLL in mind, these instructions indicate that others at Intel already tried to push into that direction before him and he knew about - and joined the trek.

  • 2
    Can you explain what you mean by "HLL handling"? Commented Oct 24, 2018 at 6:55
  • 2
    @Wilson HLL = High Level Language? And these new instructions allow easy handling of typical operations for HLL. LDHI/LDSI for addressing in structures or stack, LDHI for array walking, RDEL for turing an index into a word pointer and S/LHLX is handy for loading/storing pointers in structures. All instructions improving the runtime handling of pointers in dynamic data systuctures.
    – Raffzahn
    Commented Oct 24, 2018 at 9:47
  • 1
    I investigated how well the undocumented 8085 instructions could be translated to the 8086 in this answer. I note that LDSI isn't supported (although it can be emulated with two instructions, by using the DI register which is otherwise not required to run translated 8080 code); JK and JNK cannot be translated, while RSTV would need a jump across an INT instruction, but otherwise all of the undocumented 8085 opcodes have direct 8086 equivalents.
    – Jules
    Commented Oct 24, 2018 at 16:14
  • 2
    @Raffzahn Three years ago? But yeah, all the interesting questions are mine. Totally was me. =) I kid, I kid. Commented Oct 25, 2018 at 23:37
  • 2
    Re. your "objection" to "compatibility constraints they would place on the forthcoming 8086" as the reason for "hiding"... My interpretation would be that if they published the details, there would be (an unwanted) pressure – when designing the 8086 – to maintain compatibility with those instructions. By not publishing (which is what I assume is meant by "were not made available"), they didn't have to keep the 8086 compatible. As it turned out, many of the instructions were implemented, but they didn't want their hands tying by having to implement them.
    – TripeHound
    Commented Oct 16, 2019 at 11:15

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .