• Please review our updated Terms and Rules here

Intel 8085 question

alank2

Veteran Member
Joined
Aug 3, 2016
Messages
2,256
Location
USA
I've been having some fun making an emulator for this just to see what I can get it to do. Well, I should say I've got an 8080 one working and now thinking of making an "8085" mode for it.

SO far though I've had a plan of not supporting/implementing undocumented flags or instructions, which I get that there are pitfalls for a decision like that.

This is where my question in - other than rim/sim, there doesn't need to be much difference in the "documented" side of things between it and the 8080. When people got their hands on the 8085, did they typically respect and only use what was documented, or did they typically use K flag in INX/DCX because it worked even if it wasn't documented. Or, was 8085 code differentiated from 8080 code precisely because it utilized undocumented instructions/flags?
 
In the CP/M world the undocumented 8085 instructions weren't really known about for the majority of people until quite late in the day. I can only think of two examples of their being used: i. An enhancement for BDS C to speed up things using undocumented 8085 instructions ii. I'm pretty sure there was a compression/decompression program that made use of them but I can't remember what it was.

Either way it's great to hear that you're thinking of extending you're emulator to make it 8085 compatible. Will you be releasing the source code?
 
Do you think the same thing applies to the V/K flags? That they were not frequently used.

This is mostly a learning adventure see what I can do and how the compiler turns it into assembly, I'm not sure if I'll release it or not.
 
As far as I know, there was no real software written exclusively for the 8085 undocumented features. There could have been in some embedded code, I imagine. But in the world of personal computer software, using 8085-unique features (which were disclosed long after the introduction of the 8085) and uncertainty about those features being fully implemented in second-source vendors' versions kept the use out of the real world. After all, you usually wanted the code to run on 8080 and Z80 platforms as well.
RIM/SIM were pretty much OS-level details, mostly to manage the integrated interrupt/trap facilities of the chip. They were also used on simple embedded projects and trainers for limited serial I/O. I've also seen where RIM/SIM could be used for a simple one-bit interface to, say, reset an external flag.
 
Thanks Chuck - are you aware of any slight ALU differences between them?

I'm running Mike's 8085exm on it which masks out the undocumented bits (0xd5) keeping only S Z A P C. My minimax8085 matched perfectly.

1654709615550.png
 

Attachments

  • 1654709712775.png
    1654709712775.png
    99.4 KB · Views: 5
No, not any common ones. Overflow, of course, has (undocumented) detection in the 8085, but it hardly matters if the program isn't aware of it.
We wrote almost all of our code on Intel MDS boxes with 8080s under ISIS II.
 
I'll have to dig a bit deeper to find out what is going on then. I was trying to remember if there was some slight thing with the unmasked flags that was different, but for compatibility there really shouldn't be.
 
The behavior of the 8085 AC (auxiliary carry) is different from the 8080 after certain instructions (usually ANA/ANI). I don't know if that matters, as it behaves correctly after ADD/ADI/ADC/ACI.
 
That is probably what is causing it to fail - do you know what the differences are?
 
Found it!


There is some difference in the handling of the auxiliary carry flag by the logical AND instructions In the 8080 processor and the 8085 processor. The 8085 logical AND instructions always set the auxiliary flag ON. The 8080 logical AND instructions set the flag to reflect the logical OR of bit 3 of the values involved in the AND operation.

Problem fixed - crc's match now!
 
There's a lot of misinformation on the 8085 out there. For example, the claim that only 5 bits in the flags register on the 8085, as mentioned here and repeated endlessly on the web. In fact, that's not true, nor has it ever been so--just some uninformed person thinking that the 8085 flags register is exactly the same as the 8080.

In fact, this describes the true picture. For an official version of the undocumented 8085 features, I think that the documentation for the Tundra 80C85 (licensed Intel copy) is the best datasheet.

We were a very early user of the 8085 and had a fairly close relationship with Intel. We still had no inkling of the added features initially. When we finally discovered them, we had already set our course with the 8086 and there was no clear migration path for those.
 
I've read some places that that was the reason they were not documented - no path to 8086 for them.

This is an interesting site on the two undocumented flags:

After messing with them again and again I finally came to the conclusion that trying to support these two undocumented flags would bloat an emulator quite a bit without any real pay off.
 
Please do and give your findings about it.
Just noticed I have to check on the undocumented instructions this weekend, ARHL was incorrectly interpreted.
 
Last edited:
Will have a look at that document, thanks.
Still working on restoring my 'real' SDK-85, when that has finished I can check the simulator against the real thing.
 
Here is another variant of the undoc opcodes information. A different nomenclature, and I think it should be checked for accuracy against other sources, especially that 8085 reverse engineering work that was posted online, to confirm the equations.
 

Attachments

  • UnDoc85.pdf
    274 KB · Views: 10
Also, I attach the following reference, produced by a Club100 member. I don't think they would mind if I share it. I use is regularly as quick reference.
 

Attachments

  • Op8085.pdf
    406.9 KB · Views: 15
The Op8085 is new to me, thanks, will come in handy :)
Already made some improvements, now at version 1.1, also added a changelog to the repository.
 
Back
Top