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

[cjs]

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.

Thank you very much for this! That's great, and very interesting that it completed without errors. BTW can you tell me about how long it took to run on the 2 MHz 8080? I'm guessing about 2-4 minutes?

The issue I've been experiencing is related to this. (This is from the _Intel MCS 8080/8085 User's Manual,_ which I've found to be the most accurate of the Intel manuals covering the 8080, but the description has not actually changed since the original programmer's manual.)


You'll note that it's not entirely clear about how the AC should be set, but I assumed it should be set as per subtraction. That's not actually defined in any Intel documentation I can find, but I reckoned that if the low nybble of the result is $F, that would indicate that it had previously been 0 and thus a borrow would have been necessary. That fails the test for DCR that this program does on a certain value (it doesn't say what that value is) with the half-carry coming out as 0 when it is expected to be 1. I tried just hardcoding the DCR half-carry to 1, but while that doesn't print any failures, it also seems to put the program in an infinite loop.

I'm open to any thoughts on what might be going wrong here. Perhaps the half carry should be calculated as if an add had been done, rather than a subtract, since the 8080 only supports DAA for adds?

 

[smp]

I ran CPUTEST and timed it from when the sign-on message appeared until it indicated CPU TESTS OK:

Roughly 2 minutes and 7 seconds +/- a couple of seconds for my reaction times with the stopwatch.

Again, this is with my Altair 8800c with replica 8080 CPU board running at 2MHz with 64K RAM & CP/M.

I'm sorry that I cannot help you with the details of the 8080 that you are asking for.
Perhaps someone more knowledgeable will post their comments.

smp

 

[Chuck(G)]

I recollect that AC is always set as if the operation was an addition (Z80 may differ in this).

 

[cjs]

I recollect that AC is always set as if the operation was an addition (Z80 may differ in this).

Ok. A bit of time stepping my 8085 trainer (which surely bears some realtion to the 8080) through inc a and dec a instructions and looking at the result and flags gave me some insight: the half-carry after dec is not not a half-borrow, as the carry turns into a borrow with arithmetic adds vs. subtracts, but is instead a half-not-borrow. I.e., it's always 1 except when decrementing from $0 to $(n-1)F.

Your thought that the flag is set "as if the operation was an addition" makes sense: it no doubt is an addition of the two's complement ($FF) internally, and they just left out the logic that makes the carry a borrow bit.

This also, of course, provides insight into why the 6502 didn't use the standard carry/borrow that the 8080 and 6800 used, but instead used carry/not-borrow: it saves on circuitry. (And you know those 6502 guys: anything that can save a transistor will be done.)

Unfortunately, though changing my simulator to do the right thing here continues not to generate an error from the Supersoft diagnostics, it also continues to run forever. So I really need to start doing some traces and figuring out what the heck's going on there.

I also started another run of 8080EXER an hour or two ago, so tomorrow morning I guess we'll see if it agrees that I've fixed the inc/dec problems it identified.

 

[Svenska]

When writing an 8080 emulator, getting AC right was the most challenging part to me.

INR sets AC if the lower nibble of the result is zero.
DCR sets AC if the lower nibble of the result+1 (i.e. the input operand) is zero.
AND sets AC if (A OR input operand) has bit 3 set. That's a weird one.

ADD was easy. DAA was tricky. I gave up on SUB and just implemented it on top of ADD (flip second operand and carry, then flip result carry) to get the correct behaviour.