I've been trying to debug using this core, but I was unable to make it boot from floppy. The only version that I got to boot is the official one, and in that one the keys get stuck, so I could not use it.
So I've started debugging on ao486 only, but I'm not quite there yet. PKUNZIP uses some anti-debugging tricks, easy to work around but I was not expecting them and that made me waste some time.
I strongly recommend
symdeb instead of
debug, for many reasons. It's basically compatible, but it has very interesting features. Among them: it allows expressions in the command line; e.g. you can do D (DS+1F42):2314 L 4, also multiple commands in the same line (e.g. to read register 4 of the 6845: o 3D4 4;i 3D5), it has a help command "?", and the main one: it allows you to write scripts. You redirect standard input from the script, and at the end of the file you add <CON to redirect standard input back to the console so you can continue typing. Or you add Q to quit, but debug supports that too.
PKUNZIP is compressed with PKLITE in a way that PKLITE can't revert, but there's a tool called UNP that can revert it (attached). I'm working with the uncompressed version.
With that uncompressed version, this is my current WIP script:
Code: Select all
g 10
t
* Go to start of main() (PKUNZIP is written in C)
g 1fbc
* Defeat anti-debug (writes to vectors 81 and 83 instead of 01 and 03)
e 116a 00 02
e 1168 00 02
* Pretend to detect 8086
g 21a4
p
rax 0
* This is where the processor is printed
*g 220a
* Enter the main routine that opens the file etc.
g 2237
t
* Prints "Searching ZIP: blahblah"
g 1d63
p
* Actually scans files
g 1d84
t
* Apparently scans one file
g 1c2b
* This may be doing the decompression, judging by the time it takes
g 1816
<con
Since I couldn't test with the PCXT core, I couldn't see that the failures depend on the preceding file. That's interesting, but since I isolated the BUBBOB.DAT file in a single zip to go directly to the meat, it doesn't seem like I would run into the issue, so my debugging would have been futile.
What I can think of, is to use a symdeb script to trace the decompression, dumping the output to a file, to compare the traces of the decompression when run in the core and when run in a "good" system. symdeb can also redirect output, so in the script you can put >FILENAME.TXT to redirect to a file, or >CON to redirect to the console, or even >NUL to suppress output temporarily.
