ZEXALL on a Z80 machine - CRC errors

[hlide]

I used the zexall from: https://github.com/anotherlin/z80emu/blob/master/testfiles/zexall.z80!

To do so, I tweaked the firmware so it can run on my SHARP MZ-80 K this way:

1. Mode 3 for RAM to speed up ZEXALL execution as it may be quite slow on a 2MHz machine,
2. Virtual RAM from $0000 to $CFFF since ZEXALL starts from $0100,
3. I/O memory from $D000 to $FFFF is kept but never used,
4. IN A,(n) is tweaked to output a string to Serial USB terminal,
5. OUT (n),A is tweaked to issue a HALT forever (interrupts are ignored),
6. $0000 and $0005 are also tweaked to issue OUT and IN.

So when booting the machine, here is what I get:

[MicroCoreLabs]

I ran ZEXALL while simulating the MCLZ8 and another Z80 core which passes ZEXALL in lock-step and looked for any difference in any register or flag. It took over 12 hours to complete - and many many hours and days fixing very small things in my code then restarting this long test!

I noticed that you got a failure on CPD but not CPI. That is very suspicious as they are the exact same code with the exception of incrementing or decrementing HL. Basically if one was incorrect and failed, you would think the other one would also.

Maybe you are getting failures due to the Mode=3 acceleration or some other setting which affects the addressing modes out to physical memory?

Or maybe you are modifying one of the flags by accident? ZEXALL will fail if even one bit in the flags is not what they expect - even in unused fields!

Thx -Ted

---

From: hlide @.> Sent: Monday, May 1, 2023 8:34 AM To: MicroCoreLabs/Projects @.> Cc: Subscribed @.***> Subject: [MicroCoreLabs/Projects] ZEXALL on a Z80 machine - CRC errors (Issue #17)

I used the zexall from: https://github.com/anotherlin/z80emu/blob/master/testfiles/zexall.z80!

To do so, I tweaked the firmware so it can run on my SHARP MZ-80 K this way:

1. Mode 3 for RAM to speed up ZEXALL execution as it may be quite on a 2MHz machine,
2. Virtual RAM from $0000 to $CFFF since ZEXALL starts from $0100,
3. I/O memory from $D000 to $FFFF is kept but never used,
4. IN A,(n) is tweaked to output a string to Serial USB terminal,
5. OUT (n),A is tweaked to issue a HALT forever (interrupts are ignored),
6. $0000 and $0005 are also tweaked to issue OUT and IN.

So when booting the machine, here is what I get:

[image]https://user-images.githubusercontent.com/56785/235476884-f3ffbf83-a594-42ee-b104-dd7c2924b2a3.png

— Reply to this email directly, view it on GitHubhttps://github.com/MicroCoreLabs/Projects/issues/17, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AM4AVELHXYIBVPZSKMDNQVDXD7JXXANCNFSM6AAAAAAXR4H7TM. You are receiving this because you are subscribed to this thread.Message ID: @.***>

[hlide]

The CRC errors are totally reproductive and have the same values.

I also tried with a full 64KB RAM ($0000-$FFFF) but same result so far.

I have no reason to think mode 3 is a cause to those CRC errors. And having CPI and CPD to set the flags shows they both use temp8 = SUB_Bytes(register_a, Read_byte(REGISTER_HL));. And what differs is Writeback_Reg16(REG_HL, (REGISTER_HL -/+ 1)); which doesn't even assign the flags.

So I checked SUB_Bytes code against your source in GitHub and no difference.

The only thing I noticed is that you are not setting cp_opcode = 1; for CPD/CPI when calling temp8 = SUB_Bytes(register_a, Read_byte(REGISTER_HL)); so I'm adding it to check.

Nope, result is always the same.

[MicroCoreLabs]

I wonder if this could be a C compiler difference between my MacBook command-line C and the Teensy C. I definitely got ZEXALL to pass 100%, but this was running with the two Z80 cores running in lockstep on my MacBook. I did not run it on the Teensy. I have seen this before where sometimes math functions get different results between the MacBook and Teensy.

I also think the initial error is inside of the first BIT test that fails. Then the left-over flag/register results also corrupts the following CPD test.

---

From: hlide @.> Sent: Wednesday, May 3, 2023 12:06 PM To: MicroCoreLabs/Projects @.> Cc: MicroCore Labs @.>; Comment @.> Subject: Re: [MicroCoreLabs/Projects] ZEXALL on a Z80 machine - CRC errors (Issue #17)

The CRC errors are totally reproductive and have the same values.

I also tried with a full 64KB RAM ($0000-$FFFF) but same result so far.

I have no reason to think mode 3 is a cause to those CRC errors. And having CPI and CPD to set the flags shows they both use temp8 = SUB_Bytes(register_a, Read_byte(REGISTER_HL));. And what differs is Writeback_Reg16(REG_HL, (REGISTER_HL -/+ 1)); which doesn't even assign the flags.

So I checked SUB_Bytes code against your source in GitHub and no difference.

The only thing I noticed is that you are not setting cp_opcode = 1; for CPD/CPI when calling temp8 = SUB_Bytes(register_a, Read_byte(REGISTER_HL)); so I'm adding it to check.

Nope, result is always the same.

— Reply to this email directly, view it on GitHubhttps://github.com/MicroCoreLabs/Projects/issues/17#issuecomment-1533556392, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AM4AVEPAYJJSVVJJLFQDCQLXEKUCVANCNFSM6AAAAAAXR4H7TM. You are receiving this because you commented.Message ID: @.***>

[MicroCoreLabs]

As a quick test, could you try changing this variable to 32-bits?

uint16_t temp16=0;

change to:

uint32_t temp16=0;

---

From: MicroCore Labs @.> Sent: Wednesday, May 3, 2023 1:11 PM To: MicroCoreLabs/Projects @.>; MicroCoreLabs/Projects @.> Cc: Comment @.> Subject: Re: [MicroCoreLabs/Projects] ZEXALL on a Z80 machine - CRC errors (Issue #17)

I wonder if this could be a C compiler difference between my MacBook command-line C and the Teensy C. I definitely got ZEXALL to pass 100%, but this was running with the two Z80 cores running in lockstep on my MacBook. I did not run it on the Teensy. I have seen this before where sometimes math functions get different results between the MacBook and Teensy.

I also think the initial error is inside of the first BIT test that fails. Then the left-over flag/register results also corrupts the following CPD test.

---

From: hlide @.> Sent: Wednesday, May 3, 2023 12:06 PM To: MicroCoreLabs/Projects @.> Cc: MicroCore Labs @.>; Comment @.> Subject: Re: [MicroCoreLabs/Projects] ZEXALL on a Z80 machine - CRC errors (Issue #17)

The CRC errors are totally reproductive and have the same values.

I also tried with a full 64KB RAM ($0000-$FFFF) but same result so far.

I have no reason to think mode 3 is a cause to those CRC errors. And having CPI and CPD to set the flags shows they both use temp8 = SUB_Bytes(register_a, Read_byte(REGISTER_HL));. And what differs is Writeback_Reg16(REG_HL, (REGISTER_HL -/+ 1)); which doesn't even assign the flags.

So I checked SUB_Bytes code against your source in GitHub and no difference.

The only thing I noticed is that you are not setting cp_opcode = 1; for CPD/CPI when calling temp8 = SUB_Bytes(register_a, Read_byte(REGISTER_HL)); so I'm adding it to check.

Nope, result is always the same.

— Reply to this email directly, view it on GitHubhttps://github.com/MicroCoreLabs/Projects/issues/17#issuecomment-1533556392, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AM4AVEPAYJJSVVJJLFQDCQLXEKUCVANCNFSM6AAAAAAXR4H7TM. You are receiving this because you commented.Message ID: @.***>

[hlide]

So I tried:

[MicroCoreLabs]

This change should not have made rrd/rrld begin to fail. You are getting weird results.

---

From: hlide @.> Sent: Wednesday, May 3, 2023 5:13 PM To: MicroCoreLabs/Projects @.> Cc: MicroCore Labs @.>; Comment @.> Subject: Re: [MicroCoreLabs/Projects] ZEXALL on a Z80 machine - CRC errors (Issue #17)

So I tried: [image]https://user-images.githubusercontent.com/56785/236077319-831fcb45-829b-44c9-89bb-3504e1945c20.png

— Reply to this email directly, view it on GitHubhttps://github.com/MicroCoreLabs/Projects/issues/17#issuecomment-1533904347, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AM4AVENNOIJX2PCEMNGIU73XELYDFANCNFSM6AAAAAAXR4H7TM. You are receiving this because you commented.Message ID: @.***>

[MicroCoreLabs]

I ran the test on my Teensy 4.1 and it passed.

Hello

mclz8_setup

Z80all instruction exerciser

<adc,sbc> hl,<bc,de,hl,sp>.... OK

add hl,<bc,de,hl,sp>.......... OK

add ix,<bc,de,ix,sp>.......... OK

add iy,<bc,de,iy,sp>.......... OK

aluop a,nn.................... OK

aluop a,<b,c,d,e,h,l,(hl),a>.. OK

aluop a,<ixh,ixl,iyh,iyl>..... OK

aluop a,(<ix,iy>+1)........... OK

bit n,(<ix,iy>+1)............. OK

bit n,<b,c,d,e,h,l,(hl),a>.... OK

cpd........................ OK

cpi........................ OK

<daa,cpl,scf,ccf>............. OK

<inc,dec> a................... OK

<inc,dec> b................... OK

<inc,dec> bc.................. OK

<inc,dec> c................... OK

<inc,dec> d................... OK

<inc,dec> de.................. OK

<inc,dec> e................... OK

<inc,dec> h................... OK

<inc,dec> hl.................. OK

<inc,dec> ix.................. OK

<inc,dec> iy.................. OK

<inc,dec> l................... OK

<inc,dec> (hl)................ OK

<inc,dec> sp.................. OK

<inc,dec> (<ix,iy>+1)......... OK

<inc,dec> ixh................. OK

<inc,dec> ixl................. OK

<inc,dec> iyh................. OK

<inc,dec> iyl................. OK

ld <bc,de>,(nnnn)............. OK

ld hl,(nnnn).................. OK

ld sp,(nnnn).................. OK

ld <ix,iy>,(nnnn)............. OK

ld (nnnn),<bc,de>............. OK

ld (nnnn),hl.................. OK

ld (nnnn),sp.................. OK

ld (nnnn),<ix,iy>............. OK

ld <bc,de,hl,sp>,nnnn......... OK

ld <ix,iy>,nnnn............... OK

ld a,<(bc),(de)>.............. OK

ld <b,c,d,e,h,l,(hl),a>,nn.... OK

ld (<ix,iy>+1),nn............. OK

ld <b,c,d,e>,(<ix,iy>+1)...... OK

ld <h,l>,(<ix,iy>+1).......... OK

ld a,(<ix,iy>+1).............. OK

ld <ixh,ixl,iyh,iyl>,nn....... OK

ld ,........ OK

ld ,........ OK

ld a,(nnnn) / ld (nnnn),a..... OK

ldd (1).................... OK

ldd (2).................... OK

ldi (1).................... OK

ldi (2).................... OK

neg........................... OK

<rrd,rld>..................... OK

<rlca,rrca,rla,rra>........... OK

shf/rot (<ix,iy>+1)........... OK

shf/rot <b,c,d,e,h,l,(hl),a>.. OK

<set,res> n,<bcdehl(hl)a>..... OK

<set,res> n,(<ix,iy>+1)....... OK

ld (<ix,iy>+1),<b,c,d,e>...... OK

ld (<ix,iy>+1),<h,l>.......... OK

ld (<ix,iy>+1),a.............. OK

ld (<bc,de>),a................ OK

Tests complete

---

From: MicroCore Labs @.> Sent: Wednesday, May 3, 2023 5:46 PM To: MicroCoreLabs/Projects @.>; MicroCoreLabs/Projects @.> Cc: Comment @.> Subject: Re: [MicroCoreLabs/Projects] ZEXALL on a Z80 machine - CRC errors (Issue #17)

This change should not have made rrd/rrld begin to fail. You are getting weird results.

---

From: hlide @.> Sent: Wednesday, May 3, 2023 5:13 PM To: MicroCoreLabs/Projects @.> Cc: MicroCore Labs @.>; Comment @.> Subject: Re: [MicroCoreLabs/Projects] ZEXALL on a Z80 machine - CRC errors (Issue #17)

So I tried: [image]https://user-images.githubusercontent.com/56785/236077319-831fcb45-829b-44c9-89bb-3504e1945c20.png

— Reply to this email directly, view it on GitHubhttps://github.com/MicroCoreLabs/Projects/issues/17#issuecomment-1533904347, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AM4AVENNOIJX2PCEMNGIU73XELYDFANCNFSM6AAAAAAXR4H7TM. You are receiving this because you commented.Message ID: @.***>

[hlide]

Sorry, I was on holiday and a very bad news occurred so I was not inclined to come back here until a certain moment.

Might you add the change you did in the source for executing that ZEXALL test so everybody can check it? I just tweaked the original firmware to be running a virtual 64-bit RAM space and load ZEXALL code in RAM from a PROGMEM array. So I don't understand those weird behaviors.

Might you also explain how you compile the firmware (Single USB Serial? 600 Mhz? Faster mode? etc.)?

[hlide]

So getting back to your last source and just adding ZEXALL and make it running in mode 3 with full 64KB RAM and loading ZEXALL in RAM in setup, I'm getting that result:

bit n,<b,c,d,e,h,l,(hl),a>.... ERROR crc expected:5e020e98 found:b560ef65 cpd........................ ERROR crc expected:134b622d found:0241a81f

Everything else is OK.

Using another laptop, Arduino 2.1.0 et Teensy package 1.58.1

Note that you just need a Teensy 4.1, no need for MCLZ8 board and a Z80 machine.

The source is: https://gist.github.com/hlide/4a0d504a4c886cba6a87427f81f2a71c

[MicroCoreLabs]

When I change my BIU to your code I get lots of mismatches on the A register. I get no mismatches with my BIU where ZEXALL passes on both a Teensy 4.1 and on my MacBook command-line.

Despite the mismatches on register_A with your BIU, ZEXALL still fully passes on my MacBook, so there may be other changes in your code which account for this.

Thanks, -Ted

See below:

// ------------------------------------------------- // Initiate a Z80 Bus Cycle // ------------------------------------------------- uint8_t BIU_Bus_Cycle(uint8_t biu_operation, uint16_t local_address , uint8_t local_data) { /* register_r++;              if ( (biu_operation==MEM_WRITE_BYTE)&&(local_address==0x1d5d)) single_step=1;       if ( (biu_operation==IO_WRITE_BYTE)&&(local_address==0x1d5d)) single_step=1;       //if ( (biu_operation==MEM_WRITE_BYTE)&&(local_address<=0x10)) single_step=1;

if (biu_operation==OPCODE_READ_M1) return Internal_RAM[local_address];
if (biu_operation==MEM_READ_BYTE)  return Internal_RAM[local_address];
if (biu_operation==IO_READ_BYTE)   return 0xFF; //Internal_RAM[local_address];

if (biu_operation==MEM_WRITE_BYTE)  { Internal_RAM[local_address] = local_data;  return 0xEE; }
if (biu_operation==IO_WRITE_BYTE)   { Internal_RAM[local_address] = local_data;  return 0xEE; }

if (biu_operation==INTERRUPT_ACK)  return 0xC7; // RST0 Opcode

*/ switch (biu_operation) { case OPCODE_READ_M1: case MEM_READ_BYTE: return Internal_RAM[local_address]; case IO_READ_BYTE: return 0x00; case INTERRUPT_ACK: return 0x76; // HALT case MEM_WRITE_BYTE: Internal_RAM[local_address] = local_data; case IO_WRITE_BYTE: default: return 0xEE; }

return 0x00;

}

bit n,<b,c,d,e,h,l,(hl),a>.... NOMATCH their_register_a

NOMATCH their_register_a

NOMATCH their_register_a

NOMATCH their_register_a

NOMATCH their_register_a OK

NOMATCH their_register_a

NOMATCH their_register_a

NOMATCH their_register_a

NOMATCH their_register_a

NOMATCH their_register_a cpd........................ NOMATCH their_register_a

NOMATCH their_register_a

NOMATCH their_register_a

NOMATCH their_register_a

NOMATCH their_register_a OK

---

From: hlide @.> Sent: Thursday, May 25, 2023 12:27 PM To: MicroCoreLabs/Projects @.> Cc: MicroCore Labs @.>; Comment @.> Subject: Re: [MicroCoreLabs/Projects] ZEXALL on a Z80 machine - CRC errors (Issue #17)

So getting back to your last source and just adding ZEXALL and make it running in mode 3 with full 64KB RAM and loading ZEXALL in RAM in setup, I'm getting that result:

bit n,<b,c,d,e,h,l,(hl),a>.... ERROR crc expected:5e020e98 found:b560ef65 cpd........................ ERROR crc expected:134b622d found:0241a81f

Everything else is OK.

The source is:

— Reply to this email directly, view it on GitHubhttps://github.com/MicroCoreLabs/Projects/issues/17#issuecomment-1563403271, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AM4AVENDU3QQMNP6NWDILWTXH6XALANCNFSM6AAAAAAXR4H7TM. You are receiving this because you commented.Message ID: @.***>

[hlide]

Please do a DIFF between my MCLZ8_ZEXALL.ino and yours MCLZ8.ino in Projects/MCLZ8/Code/Standard_Z80. You will see no change in the Z80 instruction emulation side except for IN A,(n) and OUT A,(n) which should have no effect because they are not directly used by ZEXALL code but but when calling CALL 5 (BDOS) which is out of the scope of checking the instruction.

That's 99% your code. The changes are very minimal: full mode 3 use, full internal RAM use, no real BIU operations, and so on. But Z80 instructions are exactly yours without changes. I also changed the wait_CLK_edge routines to emulate Z80 CLK pulses using ARM cycles so I can run it on a standalone Teensy 4.1 (no need for a MCLZ8 PCB and a Z80 motherboard).

I don't have "NOMATCH their_register_a" but "OK" for the other instructions. That is an issue with your code by just changing BIU routine which is not enough in my opinion since I have no idea of your other changes compared to the original MCLZ8.ino.

I have no idea what I have this result but you should really use my code running on a teensy 4.1 and not just changing BIU code. That way, we will know if the issue is due to anything else the source (compiler issue?).

Since I have no access to your modified code running ZEXALL, I cannot compare and so I cannot accept your results because I cannot reproduce them. You have mine, just run it on a standalone Teensy 4.1 with an USB serial connected to your PC/Mac and tell me what you get. By the way, you should also specify what are your Arduino version, the Teensy package version and the compiling options (Speed option, CPU freq., Serial mode). Mine was: Faster, 600MHz, [Single] Serial.

[MicroCoreLabs]

I cut and pasted your code from GitHiub line 382 to 1992 and except for a few changes around opcode_0x76 and I get ZEXALL to pass.

Unfortunately, it seems that you have introduced some type of error due to your environment - either with printing or with the internal RAM, I am not sure which. I think a clue is where you are getting ZEXALL failures. There is nothing special about the MCLZ8 handling for the opcodes BIT or CPD, so there is no obvious reason for them to be failing - and in fact they do not fail under any scenario where I run them. Also, when I asked you to change a variable to uint16_t you got an additional failure...

I do get a lot of register and flag mismatches with your code which is probably the cause of your problem.

Please note that we get mismatches only when there is something to print- and I see mismatches for every ZEXALL test with your code. I believe that these mismatches do not cause ZEXALL to fail because the test is not checking CRC of the processor state in-between its tests.

I think what is happening for BIT and CPD is that the final state that you leave some critical flag or register gets calculated in to the subsequent test so that the CRC fails. It is not the actual opcode test that failed but instead the CPU state at which the test began, which is different with your code.

Anyway, I think the MCLZ8 core s not the issue here. Please let me know what you find.

Thanks, -Ted

Here is the tetst with your code from lines 382 to 1992:

*** TEST: zexall.cim Z80all instruction exerciser <adc,sbc> hl,<bc,de,hl,sp>.... OK add hl,<bc,de,hl,sp>.......... OK add ix,<bc,de,ix,sp>.......... OK add iy,<bc,de,iy,sp>.......... OK aluop a,nn.................... OK aluop a,<b,c,d,e,h,l,(hl),a>.. OK aluop a,<ixh,ixl,iyh,iyl>..... OK aluop a,(<ix,iy>+1)........... OK bit n,(<ix,iy>+1)............. OK bit n,<b,c,d,e,h,l,(hl),a>.... OK cpd........................ OK cpi........................ OK <daa,cpl,scf,ccf>............. OK <inc,dec> a................... OK <inc,dec> b................... OK <inc,dec> bc.................. OK <inc,dec> c................... OK ^C C02X54UQJG5J:Lockstep ted$

---

From: hlide @.> Sent: Thursday, May 25, 2023 3:27 PM To: MicroCoreLabs/Projects @.> Cc: MicroCore Labs @.>; Comment @.> Subject: Re: [MicroCoreLabs/Projects] ZEXALL on a Z80 machine - CRC errors (Issue #17)

Please do a DIFF between my MCLZ8_ZEXALL.ino and yours MCLZ8.ino in Projects/MCLZ8/Code/Standard_Z80. You will see no change in the Z80 instruction emulation side except for IN A,(n) and OUT A,(n) which should have no effect because they are not directly used by ZEXALL code but but when calling CALL 5 (BDOS) which is out of the scope of checking the instruction.

That's 99% your code. The changes are very minimal: full mode 3 use, full internal RAM use, no real BIU operations, and so on. But Z80 instructions are exactly yours without changes. I also changed the wait_CLK_edge routines to emulate Z80 CLK pulses using ARM cycles so I can run it on a standalone Teensy 4.1 (no need for a MCLZ8 PCB and a Z80 motherboard).

I don't have "NOMATCH their_register_a" but "OK" for the other instructions. That is an issue with your code by just changing BIU routine which is not enough in my opinion since I have no idea of your other changes compared to the original MCLZ8.ino.

I have no idea what I have this result but you should really use my code running on a teensy 4.1 and not just changing BIU code. That way, we will know if the issue is due to anything else the source (compiler issue?).

Since I have no access to your modified code running ZEXALL, I cannot compare and so I cannot accept your results because I cannot reproduce them. You have mine, just run it on a standalone Teensy 4.1 with an USB serial connected to your PC/Mac and tell me what you get. By the way, you should also specify what are your Arduino version, the Teensy package version and the compiling options (Speed option, CPU freq., Serial mode). Mine was: Faster, 600MHz, [Single] Serial.

— Reply to this email directly, view it on GitHubhttps://github.com/MicroCoreLabs/Projects/issues/17#issuecomment-1563586738, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AM4AVEP2LUOV5WHKEPL3KCTXH7MGHANCNFSM6AAAAAAXR4H7TM. You are receiving this because you commented.Message ID: @.***>

[MicroCoreLabs]

For example opcode_0xDB should update register_a but your code does not...

---

From: MicroCore Labs @.> Sent: Thursday, May 25, 2023 8:03 PM To: MicroCoreLabs/Projects @.>; MicroCoreLabs/Projects @.> Cc: Comment @.> Subject: Re: [MicroCoreLabs/Projects] ZEXALL on a Z80 machine - CRC errors (Issue #17)

I cut and pasted your code from GitHiub line 382 to 1992 and except for a few changes around opcode_0x76 and I get ZEXALL to pass.

Unfortunately, it seems that you have introduced some type of error due to your environment - either with printing or with the internal RAM, I am not sure which. I think a clue is where you are getting ZEXALL failures. There is nothing special about the MCLZ8 handling for the opcodes BIT or CPD, so there is no obvious reason for them to be failing - and in fact they do not fail under any scenario where I run them. Also, when I asked you to change a variable to uint16_t you got an additional failure...

I do get a lot of register and flag mismatches with your code which is probably the cause of your problem.

Please note that we get mismatches only when there is something to print- and I see mismatches for every ZEXALL test with your code. I believe that these mismatches do not cause ZEXALL to fail because the test is not checking CRC of the processor state in-between its tests.

I think what is happening for BIT and CPD is that the final state that you leave some critical flag or register gets calculated in to the subsequent test so that the CRC fails. It is not the actual opcode test that failed but instead the CPU state at which the test began, which is different with your code.

Anyway, I think the MCLZ8 core s not the issue here. Please let me know what you find.

Thanks, -Ted

Here is the tetst with your code from lines 382 to 1992:

*** TEST: zexall.cim Z80all instruction exerciser <adc,sbc> hl,<bc,de,hl,sp>.... OK add hl,<bc,de,hl,sp>.......... OK add ix,<bc,de,ix,sp>.......... OK add iy,<bc,de,iy,sp>.......... OK aluop a,nn.................... OK aluop a,<b,c,d,e,h,l,(hl),a>.. OK aluop a,<ixh,ixl,iyh,iyl>..... OK aluop a,(<ix,iy>+1)........... OK bit n,(<ix,iy>+1)............. OK bit n,<b,c,d,e,h,l,(hl),a>.... OK cpd........................ OK cpi........................ OK <daa,cpl,scf,ccf>............. OK <inc,dec> a................... OK <inc,dec> b................... OK <inc,dec> bc.................. OK <inc,dec> c................... OK ^C C02X54UQJG5J:Lockstep ted$

---

From: hlide @.> Sent: Thursday, May 25, 2023 3:27 PM To: MicroCoreLabs/Projects @.> Cc: MicroCore Labs @.>; Comment @.> Subject: Re: [MicroCoreLabs/Projects] ZEXALL on a Z80 machine - CRC errors (Issue #17)

Please do a DIFF between my MCLZ8_ZEXALL.ino and yours MCLZ8.ino in Projects/MCLZ8/Code/Standard_Z80. You will see no change in the Z80 instruction emulation side except for IN A,(n) and OUT A,(n) which should have no effect because they are not directly used by ZEXALL code but but when calling CALL 5 (BDOS) which is out of the scope of checking the instruction.

That's 99% your code. The changes are very minimal: full mode 3 use, full internal RAM use, no real BIU operations, and so on. But Z80 instructions are exactly yours without changes. I also changed the wait_CLK_edge routines to emulate Z80 CLK pulses using ARM cycles so I can run it on a standalone Teensy 4.1 (no need for a MCLZ8 PCB and a Z80 motherboard).

I don't have "NOMATCH their_register_a" but "OK" for the other instructions. That is an issue with your code by just changing BIU routine which is not enough in my opinion since I have no idea of your other changes compared to the original MCLZ8.ino.

I have no idea what I have this result but you should really use my code running on a teensy 4.1 and not just changing BIU code. That way, we will know if the issue is due to anything else the source (compiler issue?).

Since I have no access to your modified code running ZEXALL, I cannot compare and so I cannot accept your results because I cannot reproduce them. You have mine, just run it on a standalone Teensy 4.1 with an USB serial connected to your PC/Mac and tell me what you get. By the way, you should also specify what are your Arduino version, the Teensy package version and the compiling options (Speed option, CPU freq., Serial mode). Mine was: Faster, 600MHz, [Single] Serial.

— Reply to this email directly, view it on GitHubhttps://github.com/MicroCoreLabs/Projects/issues/17#issuecomment-1563586738, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AM4AVEP2LUOV5WHKEPL3KCTXH7MGHANCNFSM6AAAAAAXR4H7TM. You are receiving this because you commented.Message ID: @.***>

[hlide]

Wait! Are you telling me you're not using the same ZEXALL I used in the array?

Do you realize you're still trying to convince me with "facts" I cannot check myself because I cannot reproduce all you're doing? (how do you launch your ZEXALL? what is that ZEXALL you use? what is your code checking ZEXALL on a true Teensy? Inside a Z80 machine? etc.)

I was asking for you to check my code with your own development tools (that is, compile the source, upload it on a standalone Teensy 4.1 and run it and check the results on a USB terminal). That would be the first step to lead me in which direction I must go for the next step.

While I certainly understand BIT and CPD emulation code should NOT be the culprits and that it might come from the execution of instructions while checking or afterward, I see no reason for $DB being an issue because ZEXALL never use IN/OUT. BDOS call is an "OS operation" and the result of A should not enter in the CRC of the next instruction checking. It is quite irrational to think so and let me give you the evidence:

bdos push af push bc push de push hl call 5 pop hl pop de pop bc pop af ret

As you can see, bdos routine restores all the registers after the call to in al,(0) : ret at 0x0005.

ZEXALL doesn't use I/O operations and fully runs in RAM (so internal RAM is the right place) for its code, data and stack so the simplified BIU should not be an issue per se (if so, why the other instructions end OK?). Having mode = 3; gives us the insurance that there is no bus access which can introduce hazards in reading registers.

Right now, the results are irrational and MCLZ8 has no debug facility regarding Z80 emulation to help me to pinpoint the issue. I'll try to reduce the set of instructions to check to the failing one to see it is still an issue.

[hlide]

Another thing I don't understand is:

start: ld hl,(6) ld sp,hl ld de,msg1 ld c,9 call bdos

the sequence in a,(0) : ret is at 0x0005 and is 3 bytes (0x0005-0x0007) so I would expect ld hl,(6) to load 0xC900 in hl then in sp (still in RAM). BDOS is at 0x0005 so unless the CP/M has a RST n at this place, it looks quite hazardous to fetch the top stack here.

EDIT: I already replaced with LD HL,$8000 as seen in another version of ZEXALL.

[hlide]

Another ZEXALL I edited so it only checks the "failed" instructions (BIT and CPD):

MCLZ8 - ZEXALL Z80 instruction exerciser bit n,<b,c,d,e,h,l,(hl),a>.... ERROR crc expected:5e020e98 found:b560ef65 cpd........................ ERROR crc expected:134b622d found:0241a81f Tests complete

And if I reverse the order of them: MCLZ8 - ZEXALL Z80 instruction exerciser cpd........................ ERROR crc expected:134b622d found:0241a81f bit n,<b,c,d,e,h,l,(hl),a>.... ERROR crc expected:5e020e98 found:b560ef65 Tests complete

So the order of instruction checking doesn't count.

[MicroCoreLabs]

Wait! Are you telling me you're not using the same ZEXALL I used in the array?

Do you realize you're still trying to convince me with "facts" I cannot check myself because I cannot reproduce all you're doing? (how do you launch your ZEXALL? what is that ZEXALL you use? what is your code checking ZEXALL on a true Teensy? Inside a Z80 machine? etc.)

I am using the ZEXALL binary that was published on GitHub. I am not compiling it on my own. At this point you need to convince me that the core has a fault as every test passes for me on multiple platforms.

There are only ten lines of C code for the opcode CPD and you have isolated ZEXALL to just this test so it should be quick and easy for you to try a bunch of ideas to fix it. Then I can publish your fix back to GitHub giving you credit for finding it.

Thanks, -Ted

---

From: hlide @.> Sent: Friday, May 26, 2023 3:49 AM To: MicroCoreLabs/Projects @.> Cc: MicroCore Labs @.>; Comment @.> Subject: Re: [MicroCoreLabs/Projects] ZEXALL on a Z80 machine - CRC errors (Issue #17)

Another ZEXALL I edited so it only checks the "failed" instructions (BIT and CPD):

MCLZ8 - ZEXALL Z80 instruction exerciser bit n,<b,c,d,e,h,l,(hl),a>.... ERROR crc expected:5e020e98 found:b560ef65 cpd........................ ERROR crc expected:134b622d found:0241a81f Tests complete

And if I reverse the order of them: MCLZ8 - ZEXALL Z80 instruction exerciser cpd........................ ERROR crc expected:134b622d found:0241a81f bit n,<b,c,d,e,h,l,(hl),a>.... ERROR crc expected:5e020e98 found:b560ef65 Tests complete

So the order of instruction checking doesn't count.

— Reply to this email directly, view it on GitHubhttps://github.com/MicroCoreLabs/Projects/issues/17#issuecomment-1564203330, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AM4AVENQQCRVNO4FOV5WY2TXICDB5ANCNFSM6AAAAAAXR4H7TM. You are receiving this because you commented.Message ID: @.***>

[hlide]

Right now, I'm writing my own firmware with a cross emulation (probably what you call a lock-step?) using your emulator.

Basically, I first step an instruction with your emulator then I step an instruction with mine. I compare all the registers, including PC, IR, IFF1, IFF2, and so on. I also record any bus access done by those instructions (byte read/written and the same with your emulator) so I can compare them. That way, I can detect any divergence in registers and in memory whenever stepping an instruction. If no difference, it means same PC, same instruction, same IR and same contents for the registers. One note, I don't track F3 and F5 differences on F because I cannot trust them on both emulators on the actual stage.

So when I reach ZEXALL test bit n,<b,c,d,e,h,l,(hl),a>.... (the first one which is in ERROR when trying your emulator), I got that:

Register F appears to disaggree here (probably on F3 or/and F5 values) so I decided to disable the difference detection to see the final result of that ZEXALL test on bit n,<b,c,d,e,h,l,(hl),a>.... on my emulator. And I got bit n,<b,c,d,e,h,l,(hl),a>.... OK .

So it looks bit n,<b,c,d,e,h,l,(hl),a>.... is not correct on the way to compute F in your firmware (I mean the one you published here).

This is the code I use in my frimware to compute F on BIT (case 1:): Note that this->wz contains the effective address of (HL), (IX+d) or (IY+d) when F is computed with.

Yours is using register_pc for BIT n,(HL) which is extremely dubitative.

[MicroCoreLabs]

This also how I debugged my MCLZ8 emulator! I ran in lock-step with a known-good Z80 core which is how I was able pass all of the ZEXALL tests.

Good luck on your emulator, and I am happy that the MCLZ8 was useful for you!

Thx -Ted

---

From: hlide @.> Sent: Tuesday, July 18, 2023 1:53 AM To: MicroCoreLabs/Projects @.> Cc: MicroCore Labs @.>; Comment @.> Subject: Re: [MicroCoreLabs/Projects] ZEXALL on a Z80 machine - CRC errors (Issue #17)

Right now, I'm writing my own firmware with a cross emulation (probably what you call a lock-step?) using your emulator.

Basically, I first step an instruction with your emulator then I step an instruction with mine. I compare all the registers, including PC, IR, IFF1, IFF2, and so on. I also record any bus access done by those instructions (byte read/written and the same with your emulator) so I can compare them. That way, I can detect any divergence in registers and in memory whenever stepping an instruction. If no difference, it means same PC, same instruction, same IR and same contents for the registers. One note, I don't track F3 and F5 differences on F difference because I cannot trust them on both emulators on the actual stage.

So when I reach ZEXALL test bit n,<b,c,d,e,h,l,(hl),a>.... (the first one which is in ERROR when trying your emulator), I got that:

[image]https://user-images.githubusercontent.com/56785/254200268-240a1e4a-8338-419c-a1f4-c8de123eff56.png

Register F appears to disaggree here (probably on F3 or/and F5 values) so I decided to disable the difference detection to see the final result of that ZEXALL test on bit n,<b,c,d,e,h,l,(hl),a>.... on my emulator. And I got bit n,<b,c,d,e,h,l,(hl),a>.... OK .

So it looks bit n,<b,c,d,e,h,l,(hl),a>.... is not correct on the way to compute F in your firmware (I mean the one you published here).

This the code to compute F un BIT (case 1:): [image]https://user-images.githubusercontent.com/56785/254205842-f46faa64-6d93-4358-a06e-f9081ca76d62.png Note that this->wz contains the effective address of (HL), (IX+d) or (IY+d) when F is computed with.

— Reply to this email directly, view it on GitHubhttps://github.com/MicroCoreLabs/Projects/issues/17#issuecomment-1639809405, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AM4AVELN53WGSEL456MWA5DXQZFIDANCNFSM6AAAAAAXR4H7TM. You are receiving this because you commented.Message ID: @.***>