P2 Debugging - an actual experience...
Cluso99
Posts: 18,069
Thought I would share a little P2 debugging ahead of Chip's Zoom meeting on Wednesday.
When you start out writing fresh code, you build that code up over days/weeks/months, and you best test and debug it along the way if it's of any size.
However, when you're converting a largish P1 program to P2, you have a big "lump" of code that just has to be converted in one big execrise. Sure, you may have some object that can be done separately, but the bulk is going to be done in one big hit or miss. If it doesn't work, just where do you begin.
So here is a tale of converting/rewriting the ZiCog Z80 emulator (with CPM2.2) from P1 to P2. Almost 2 years ago I re-wrote the Z80 instruction set emulation. I did as much testing back then as possible, but at that stage there was no spin, so no SD FAT32 Driver. Spin2 turned out to be much delayed, and included a number of conversion hurdles when it finally arrived.
So I had the Z80 instruction emulation running some basic code, but it did not pass the zexall and other validation programs. But these validation program may not have run on the code I used as the basis for the decoding/emulation, and it was a pass all or fail - no nice errors of where it failed.
I have since converted Kye's FAT32 SD Driver, and I have written the PASM SD Driver, so time to bolt these on to my emulation, and add in the I/O handler code. This is where I was up to a month ago, when an untimely event caused a house move. Needless to say, the CPM2.2 didn't just boot up wonderfully.
So, how do you debug a big code "blob"? Where do you start?
Well, you just cannot trace every P2 instruction!!!
So, I set out to trace each Z80 instruction as it is emulated...
I output the PC, BC, DE, HL, A and F registers and flags, the opcode (4 bytes as the instructions may be 1-4 bytes), an instructions executed counter, all on a single line.
I also trap all I/O (serial and HDD) and output a further line.
Everything runs nicely, outputs the CPM startup message, and something goes wrong and CPM restarts all over again. Quite simple you think! Wrong answer! You see, $16xxx Z80 (about 100,000) instructions have executed. Looking for a needle in a haystack here!
I can see the CPM BOOT code executing nicely, then it reads the CBIOS of 88 x 128 byte sectors into RAM $0000+, then it moves $0A00($2300) up to $DC00+, and executes this. I get the nice CPM message. And then it starts all over again, loading CBIOS.
There is no nice way any debugger is going to help here. Something is wrong and I have no idea where to look.
Answer...
Modify the P1 ZiCog code. Now, while heater wrote the Z80 Emulator (ZiCog), I did have a hand in getting certain parts running so I have an advantage. I now set out to insert a similar debug output for each Z80 instruction emulated. It was a bit tight because the emulation uses almost every bit of COG for the main z80 instructions, and a small overlay area where the lesser used instructions get loaded in to emulate. I can patch in an overlay to save out the registers and detail I need to get at for the debug output.
So now I can record each z80 instruction as it is emulated. I can do this for both P1 and P2. With the terminal I am using, I am limited to saving about 1000 instructions at a time. But over the weekend I did just this. And then I ran a comparison program to sift out the errors.
In the first 16,000 instructions I find a few systematic errors resulting in two errors. Both are rep instruction errors where I incorrectly subtracted 1 from the repeat count. A trap! Some instructions like SETQ need count-1. rep does not.
Now I get further thru the boot process and receive a message "sector size must be 128". So, somewhere I am not setting (corrupting) the sector size in the HDD parameter block.
This will be my next exercise.
I hope this demonstrates that debugging is not necessarily a straight forward exercise, and requires some lateral thinking to find ways to debug in a timely manner.
When you start out writing fresh code, you build that code up over days/weeks/months, and you best test and debug it along the way if it's of any size.
However, when you're converting a largish P1 program to P2, you have a big "lump" of code that just has to be converted in one big execrise. Sure, you may have some object that can be done separately, but the bulk is going to be done in one big hit or miss. If it doesn't work, just where do you begin.
So here is a tale of converting/rewriting the ZiCog Z80 emulator (with CPM2.2) from P1 to P2. Almost 2 years ago I re-wrote the Z80 instruction set emulation. I did as much testing back then as possible, but at that stage there was no spin, so no SD FAT32 Driver. Spin2 turned out to be much delayed, and included a number of conversion hurdles when it finally arrived.
So I had the Z80 instruction emulation running some basic code, but it did not pass the zexall and other validation programs. But these validation program may not have run on the code I used as the basis for the decoding/emulation, and it was a pass all or fail - no nice errors of where it failed.
I have since converted Kye's FAT32 SD Driver, and I have written the PASM SD Driver, so time to bolt these on to my emulation, and add in the I/O handler code. This is where I was up to a month ago, when an untimely event caused a house move. Needless to say, the CPM2.2 didn't just boot up wonderfully.
So, how do you debug a big code "blob"? Where do you start?
Well, you just cannot trace every P2 instruction!!!
So, I set out to trace each Z80 instruction as it is emulated...
I output the PC, BC, DE, HL, A and F registers and flags, the opcode (4 bytes as the instructions may be 1-4 bytes), an instructions executed counter, all on a single line.
I also trap all I/O (serial and HDD) and output a further line.
Everything runs nicely, outputs the CPM startup message, and something goes wrong and CPM restarts all over again. Quite simple you think! Wrong answer! You see, $16xxx Z80 (about 100,000) instructions have executed. Looking for a needle in a haystack here!
I can see the CPM BOOT code executing nicely, then it reads the CBIOS of 88 x 128 byte sectors into RAM $0000+, then it moves $0A00($2300) up to $DC00+, and executes this. I get the nice CPM message. And then it starts all over again, loading CBIOS.
There is no nice way any debugger is going to help here. Something is wrong and I have no idea where to look.
Answer...
Modify the P1 ZiCog code. Now, while heater wrote the Z80 Emulator (ZiCog), I did have a hand in getting certain parts running so I have an advantage. I now set out to insert a similar debug output for each Z80 instruction emulated. It was a bit tight because the emulation uses almost every bit of COG for the main z80 instructions, and a small overlay area where the lesser used instructions get loaded in to emulate. I can patch in an overlay to save out the registers and detail I need to get at for the debug output.
So now I can record each z80 instruction as it is emulated. I can do this for both P1 and P2. With the terminal I am using, I am limited to saving about 1000 instructions at a time. But over the weekend I did just this. And then I ran a comparison program to sift out the errors.
In the first 16,000 instructions I find a few systematic errors resulting in two errors. Both are rep instruction errors where I incorrectly subtracted 1 from the repeat count. A trap! Some instructions like SETQ need count-1. rep does not.
Now I get further thru the boot process and receive a message "sector size must be 128". So, somewhere I am not setting (corrupting) the sector size in the HDD parameter block.
This will be my next exercise.
I hope this demonstrates that debugging is not necessarily a straight forward exercise, and requires some lateral thinking to find ways to debug in a timely manner.
Comments
A little story: I have been developing some HDL models of old HP calculators: 67, 41, 11, 71, 42, 48 and 75. There are some sw emulators, there are more or less comprehensive descriptions of inner workings of the machines and the processors. When developing them, I have been using the trace and compare method to find bugs/unimplemented features or just to understand how the machine is supposed to work. There are so many quirks in these designs, differences between similar hw models... and nobody seemed interested in writing a CPU exerciser. I also did not write one myself. At work we compare two models using random patterns... It is a method.