GloriousCow wrote on 2024-08-15, 16:25:

aux carry flag is undefined after SHL and SHR. Behavior may differ between CPUs. An 8088 can set AF on a SHL, a V20 will alway […]
Show full quote

superfury wrote on 2024-08-15, 14:50:

OK. Somehow it seems to run the debugger now.

The 80186 shift tests keep setting the auxilliary carry flag (bit 4) for all results somehow? All other flags seem fine.

aux carry flag is undefined after SHL and SHR. Behavior may differ between CPUs. An 8088 can set AF on a SHL, a V20 will always clear AF.
There's also no guarantee that the tests you're looking at matched actual hardware behavior of a 186.

superfury wrote on 2024-08-15, 14:50:

With the MUL tests only 3 sets of flags are incorrect. I see auxilliary carry erroring(stack offset 8C), then overflow flag with auxilliary carry erroring out at stack offset 88h.

aux carry flag is undefined after MUL. An 8088 will clear it. I believe the overflow flag should be set to the same state as the carry flag.

if you're going to implement undefined flags, you have to first decide which CPU you are going to implement them for.

Hmmm... What about DAA/DAS auxilliary carry? niPCemu sets it, but then (in current versions) resets it when calculating sign/parity flags (probably should leave it unaffected at that point?)

superfury wrote on 2024-08-15, 17:09:

Hmmm... What about DAA/DAS auxilliary carry? UniPCemu sets it, but then (in current versions) resets it when calculating sign/parity flags (probably should leave it unaffected at that point?)

On 8088 and V20, I set AF for both as AF = AL & 0xF > 9 || AF

GloriousCow wrote on 2024-08-15, 17:22:

superfury wrote on 2024-08-15, 17:09:

Hmmm... What about DAA/DAS auxilliary carry? UniPCemu sets it, but then (in current versions) resets it when calculating sign/parity flags (probably should leave it unaffected at that point?)

On 8088 and V20, I set AF for both as AF = AL & 0xF > 9 || AF

And sign/zero/parity? At what point are they samples on 8088 and NEC V30?

superfury wrote on 2024-08-15, 18:12:

GloriousCow wrote on 2024-08-15, 17:22:

superfury wrote on 2024-08-15, 17:09:

Hmmm... What about DAA/DAS auxilliary carry? UniPCemu sets it, but then (in current versions) resets it when calculating sign/parity flags (probably should leave it unaffected at that point?)

On 8088 and V20, I set AF for both as AF = AL & 0xF > 9 || AF

And sign/zero/parity? At what point are they samples on 8088 and NEC V30?

Set according to the value of AL.

GloriousCow wrote on 2024-08-15, 18:17:

superfury wrote on 2024-08-15, 18:12:

GloriousCow wrote on 2024-08-15, 17:22:

On 8088 and V20, I set AF for both as AF = AL & 0xF > 9 || AF

And sign/zero/parity? At what point are they samples on 8088 and NEC V30?

Set according to the value of AL.

And DAS overflow flag?
Edit: managed to get it implemented I think (the testsuite succeeds on that).
Now on the MUL tests, there's an error in AAD?
It performs a normal MUL (unsigned, adjust timings), then adds the result to AL to generate flags (essentially AL= ADD AX,originalAL), with the flags becoming the add operation part of it?

superfury wrote on 2024-08-15, 18:38:

And DAS overflow flag?

It's undefined.

here's the source of an emulator in C++ that validated against the 8088 test suite, so this should be correct.
https://github.com/a-mcego/granite/blob/main/ … /main.cpp#L3445

GloriousCow wrote on 2024-08-15, 19:04:

It's undefined. […]
Show full quote

superfury wrote on 2024-08-15, 18:38:

And DAS overflow flag?

It's undefined.

here's the source of an emulator in C++ that validated against the 8088 test suite, so this should be correct.
https://github.com/a-mcego/granite/blob/main/ … /main.cpp#L3445

And the AAD issue? Right now it's:
8-bit MUL data,AH (8-bits version MUL) for getting the intermediateresult (8-bit)
ADD intermediateresult,AL (intermediateresult*AL->8-bit result)
AX = 8-bit result (AH cleared)

Rather than go through every instruction and flag one by one, perhaps you can look at the source code to that emulator or to MartyPC.

GloriousCow wrote on 2024-08-15, 19:51:

Rather than go through every instruction and flag one by one, perhaps you can look at the source code to that emulator or to MartyPC.

Just adjusted the 808x core BCD AAA/AAS instruction to match yours.
The test386 testsuite is still erroring out on the flags results (when configured to check undefined 80386 flags)?

MS-DOS 6.22 booting from the hard-disk image (the same image I've used for a long time already) can't properly boot anymore still (gets into a LDS/JNZ/JMP-based loop on some (corrupted) non-zero pointer it seems?). It can still load HIMEM, but directly after that (before loading OAKCDROM for example) it crashes into said loop as well? It's looking like some loop that's following some kind of segment:offset chain?

According to the test386.asm testsuite, AAA at least is broken?

This is the current code used:

1byte CPU8086_internal_AAA()
2{
3	byte applycycles;
4	byte old_AL;
5	CPUPROT1
6		applycycles = 0;
7		if (CPU_apply286cycles() == 0) //No 80286+ cycles instead?
8		{
9			getActiveCPU()->cycles_OP += 7; //Timings!
10			applycycles = 1;
11		}
12	//Adjusted from MartyPC's explanation.
13	old_AL = REG_AL; //Backup!
14	if (((REG_AL & 0xF) > 9) || FLAG_AF)
15	{
16		getActiveCPU()->oper1b = REG_AH; //Load AH!
17		getActiveCPU()->oper2b = 1; //Add 1!
18		op_add8(); //Add together!
19		REG_AH = getActiveCPU()->res8; //Result in AH!
20		getActiveCPU()->oper1b = REG_AL; //Load AL!
21		getActiveCPU()->oper2b = 6; //Add 6!
22		op_add8(); //Add together!
23		REG_AL = (getActiveCPU()->res8&0xF); //Result in AL!
24		FLAGW_AF(1);
25		FLAGW_CF(1);
26	}
27	else
28	{
29		FLAGW_AF(0);
30		FLAGW_CF(0);
31		REG_AL = (REG_AL & 0xF); //Simple mask!
32		getActiveCPU()->cycles_OP += applycycles; //Timings!
33	}
34	flag_szp8(REG_AL); //Normal behaviour!
35	FLAGW_OF(((old_AL>=0x7A) && (old_AL<=0x7F))?1:0); //Overflow flag (undefined behaviour)!
36	FLAGW_SF(((old_AL>=0x7A) && (old_AL<=0xF9))?1:0);
37	//z=s=p=o=?
38	CPUPROT2
39	return 0;
40}

The op_add8 function is just the basic ADD instruction's execution using 2 input values and 1 output value (and modifying flags like it automatically).

The op_add8 is in the 8086 module:

1OPTINLINE void op_add8()
2{
3	getActiveCPU()->res8 = getActiveCPU()->oper1b + getActiveCPU()->oper2b;
4	flag_add8 (getActiveCPU()->oper1b, getActiveCPU()->oper2b);
5}

The flags themselves being in the flags module:
https://bitbucket.org/superfury/unipcemu/src/ … emu/cpu/flags.c

It's a bit too many macro-logic to simply post here I think. It's based on Dosbox's (or was it Bochs') lazy flags, but un-lazied instead (because they need to be live for the debugger).

The only difference between this and the 80286+ AAA instruction is that the 286+ instruction uses AX instead (adding 6 to AX as a 16-bit operation (documented in Bochs) instead of as a 8-bit operation), flags being determined in the same way, but using flag_add16(oper1,oper2) instead of flag_add8(oper1b,oper2b).

Just ran The Troubleshooter. I ran a CPU core processor test, and it found a problem: String operations apparently, according to the testsuite. I don't know if it's an issue with the actual memory accesses (being skipped somehow or the like) or flags though.
So is one of the string instruction malfunctioning somehow? Or REP/REPZ/REPNZ prefixes somehow?
Edit: Found some issues with 80(1)8x REP instructions and their timings not being recounted properly in subsequent executions, but that isn't the main problem (it mainly affects 808x timings because of delays with string instructions).
Looking at the tests running I see pretty much a bunch of string instructions done in a loop?
Edit: PC Doctor verifies the string instructions to be working? So The Troubleshooter is somehow failing it? Perhaps some single-instruction odd issues? Or IRQ-based interruption issues?
Edit: Adjusted the REP prefix handling a bit, so that (E)CX decrementing to zero immediately finishes the instruction, instead of triggering another instruction for (E)CX being zero (which would of course block). That is correct functionality isn't it? Or is it supposed to execute a final (E)CX zero blocked REP(Z/NZ) instruction that does nothing? Though I doubt that's the case (it should only block the (E)CX zero case when the instruction loop is started and (E)CX is zeroed, doesn't it (so it will be checked after the instruction instead of before after starting (it's only checked before to block when the REP and instruction opcode is fetched, doesn't it))?
Edit: Running FDISK on MS-DOS 6.22's command prompt seems to cause some part of it (at 2xxx:0018) to throw a #GP fault (because of addressing offset 10000h using an ADD instruction), repeatedly ending up at said location with each fault (#GP fault handler)?