Looking for a test run on Intel 8080 and Intel 8085 machines

[cjs]

I'm working on a CPU simulator for the Intel 8080 (and probably, soon enough, 8085) and I'm running into some issues with a test program that I'm using.

I'm wondering if someone out there who has a machine with an actual Intel 8080 CPU could run the Supersoft CPU Diagnostics program (the CP/M program CPUTEST.COM in that directory) and let me know what output you get from it. I'd also be interested in seeing the output from a run on an 8085.

Note that it's unchanged from the various other copies of this program that are floating about out there (such as those mentioned here), so you can compare the binary with those copies if you're worried about what it might do.

 

[Twospruces]

Here is the output from an 80C85. It is a 2.5 MHz CPU running at 5MHz.

Reran test at 2.5 MHz and no change.

 

[Twospruces]

Here is the output from an NSC800 for what it's worth.

 

[Twospruces]

Here is the output from an 80C85. It is a 2.5 MHz CPU running at 5MHz.

Reran test at 2.5 MHz and no change.

If I understand this test result, it says that Opcode 05 DCR B did not set the undocumented flag V correctly, when B had an initial value of 0x16.
V flag is the 2's complement overflow for both 8 and 16 bit arithmetic operations.
Decrementing B from 0x16 to 0x15 should not set this flag, so it seems the CPU did the right thing.

I find this interesting - did Supersoft fully understand how the undocumented opcodes and flags were supposed to work?

Or maybe this is just a bad test.

 

[Chuck(G)]

Honestly, that INX/DCX would set any flags on the 8085 surprises me, if true. The reason is that the 16-bit increment/decrement instructions are not executed in the ALU, as I understand it, but rather use the increment block used to advance the P-counter.
Perhaps I've been living under a delusion...

 

[cjs]

Here is the output from an 80C85. It is a 2.5 MHz CPU running at 5MHz.

Ok, this one is easy.

INSTRUCTION SEQUENCE WAS 040000H
REGISTER f CONTAINS 00H
BUT SHOULD CONTAIN 02H

It's running an `INR B` instruction ($04). The two $00 bytes following it are just NOPs; one or two of those would be filled with the operand later on if the test had progressed to the two- and three-byte instructions.

On the 8080, bit 1 ($02) is always set in the pseudo-"F register" value pushed on to the stack. That program doesn't understand that that's only on the 8080 and the 8085 (or at least your particular 80C85) is a bug in the test. I don't know off-hand if the 80C85 is different from the 8085 (obviously I need to haul out one of my Kyocera KC85 clones and test it), nor do I know if this perhaps justified because this program dates from 1981. (The original 8085, from 1976, was quite old by that time, but I don't know when the 80C85 came out.)

If I understand this test result, it says that Opcode 05 DCR B did not set the undocumented flag V correctly, when B had an initial value of 0x16.

I think you are talking about a different test run from the one you posted, which failed on opcode $04.

I do see an almost immediate (4 minutes on my Python simulator, so probably a half to a quarter that on a real CPU) failure of `DCR B` ($05) on my simulator when coded to match the documentation that says that `DCR` updates the half-carry (AC) flag. If instead I always set the half-carry to `1` it appears to get through those tests and move on to others. That's more or less what prompted my original post.

I find this interesting - did Supersoft fully understand how the undocumented opcodes and flags were supposed to work?

I suspect not. I think they may have just added "8085" to the banner without actually even worrying about whether they were actually testing an 8085 properly. The code seems to have conditionals only for 8080 vs. Z80.

 

[cjs]

Honestly, that INX/DCX would set any flags on the 8085 surprises me, if true. The reason is that the 16-bit increment/decrement instructions are not executed in the ALU, as I understand it, but rather use the increment block used to advance the P-counter.
Perhaps I've been living under a delusion...

Well, that was the 8080 and so on. And in the diagram that Twospruces posted, it does not affect any of the 8080 flags. The `UI` flag there looks to me like something they might reasonably have added to work around the annoyance that `INX`/`DCX` do not update the zero flag, which is a pain when you want to use a 16-bit register as a counter.

I am not sure what a "CA80C85B" is; it doesn't sound like an Intel chip. Perhaps it's from a vendor that added this rather desirable extra feature?

 

[Chuck(G)]

It/s a licensed Calmos/Tundra chip, hence the "CA" prefix. Datasheets are available online. Canadian IC house. https://en.wikipedia.org/wiki/Tundra_Semiconductor

That leads me to ask if the UI flag is set when a "wraparound" in the P-counter (or POP/PUSH instruction) between 0xffff and 0x0000 is executed. In other words, was the UI just something tacked onto the 16-bit increment block?

I haven't checked out the UI flag on my NMOS 8085s to see if it works. Given its obscurity, I doubt that it was ever used much.

 

[cjs]

It/s a licensed Calmos/Tundra chip, hence the "CA" prefix.

Ah, ok. I've heard of it, and have a datasheet for CA80C85B (which I clearly haven't read in detail, obviously not even the title at the top ); I just didn't know the prefix. (And, as a Canadian, "Yay Canada!" )

I haven't checked out the UI flag on my NMOS 8085s to see if it works. Given its obscurity, I doubt that it was ever used much.

I just checked it on my NEC TK-85 trainer board, which has a NEC D8085AC, and that flag works there. Just to make sure I'm not misinterpreting anything (I can be a n00b at times), here are the details.

The program I'm using is as follows.

(1)    7/8200 :                                     org  $8200          ; suitable for TK-80
(1)    8/8200 :                        
(1)    9/8200 : 11 00 00                clearF      ld   de,$0000       ; "clear all flags" stack value
(1)   10/8203 : D5                                  push de
(1)   11/8204 : F1                                  pop  af
(1)   12/8205 :                        
(1)   13/8205 : 01 FE FF                inxF        ld   bc,$FFFE       ; check undoc V flag for INX
(1)   14/8208 : 03                                  inc  bc
(1)   15/8209 : 76                                  halt
(1)   16/820A : 03                                  inc  bc
(1)   17/820B : 76                                  halt

At the first halt, BC=$FFFF and AF=$0000. Continuing the program, at the second halt BC=$0000 and AF=$0020. Thus, bit 5 is set, and that's the UI bit, right?

Given that, according to the 8080EXER page, the NEC 8080A produces the exact same CRCs as the Intel 8080A, I am reasonably confident that the NEC 8085 is no different from the Intel 8085.

And it may not have been used much, but I have several 8085 and 80C85 machines, so I'm very happy to know that these work on all of them. I'll definitely be using this.

 

[Chuck(G)]

Should be identical, as the NEC (and other chips billing themselves as "8085") was done under license from Intel, who was quite generous with licensing back then. That is, until the Intel vs. NEC legal blowup over the V-series chips. https://jolt.law.harvard.edu/articles/pdf/v03/03HarvJLTech209.pdf
I'd like to see a sample of a PC using the NEC V53 MPU. Because it was hard-coded, not microprogrammed and had independent data and address paths, it was supposed to be many times faster than the 8086.

 

[cjs]

I'd like to see a sample of a PC using the NEC V53 MPU.

Which totally reminds me, I'd also like to see the results of this test on a NEC V20 or V30 in 8080 mode. (I may get around to it myself, one day, when I get around to building an SBC around one of the V20s that I have.)

 

[Chuck(G)]

IIRC (and it's been a long time), the V20 8080 emulation is pretty good with a couple of gotchas. The first is that it uses the same BIU that the 16-bit mode uses, so code modification in some cases won't work right. One other that comes to mind is that there was a bizarre bug where JRT Pascal 1.0 would just plain die, due to the way the JRT procedure calling sequence was set up; e.g., [private stack with return address][code entry...] In other words, the stack pointer was set just below the entry point before the call was made.
Don't expect to find the 8085-specific instructions. A couple of those opcodes were appropriated for managing the emulation; e.g. RETEM, CALLN...

 

[cjs]

Don't expect to find the 8085-specific instructions. A couple of those opcodes were appropriated for managing the emulation; e.g. RETEM.

Actually, it's that it's not an 8085 that interests me. The V20 is the closest thing I have to an 8080 and, at this point, it's not looking like that's going to change any time soon. I should have grabbed a TK-80 back when they were $100; now they're $400 when you can find one at all.

 

[Chuck(G)]

The V-series I find interesting not for the 8080 emulation or the 8086-compatible stuff, but rather the instructions that nobody uses; e.g. the packed BCD string instructions.

 

[cjs]

Here is the output from an 80C85. It is a 2.5 MHz CPU running at 5MHz.
Reran test at 2.5 MHz and no change.

How long did the test take to run at 5 and 2.5 MHz?

I can complete the 8080EXER test on my simulator at about 2 MHz 8080 speed on a fast machine, but I just now discovered that the Supersoft diagnostic I kicked off last night failed with a timeout after about 12 hours. I'm wondering if it really is a multi-hour thing, or if might be because I turned on debug mode.

 

[Twospruces]

The NSC 800 at 5MHz complete the test in about a minute or less.

 

[cjs]

Thanks. On my simulator, both debug and non-debug runs I started about 18 hours ago are still running, so obviously there's something wrong with my simulator there. (Sigh.)

And I've still had no luck finding someone, either here or on Retrocomputing SE, who has been able to run this on an 8080, so if anybody here knows someone, and you could give them a poke for me, I'd appreciate it.

 

[smp]

I sent a DM about my Altair 8800c with replica 8080 CPU board running at 2MHz with 64K RAM & CP/M.
All I need is the .COM file to be tested to be emailed to me.

I also have a Heathkit H8 with a Z-80 CPU that can run 2, 4, 8, & 16 MHz with 64K RAM and CP/M.
Again, all I need is the .COM file emailed to me.

smp

 

[smp]

OK!
I received the CPUTEST.COM file (thanks) and I ran the program on my Altair 8800c with replica 8080 CPU board running at 2MHz with 64K RAM & CP/M.
Here are the results:

 

[smp]

I ran CPUTEST.COM on my H8 with a Z-80 CPU running at 16 MHz with 64K RAM and CP/M.
The results were the same as above, aside from indicating a Z80 CPU, and much faster to complete.

smp