JimDrew wrote:OK, I found the problem! I was able to make it pass the protection check within Steem once I figured out the issue.
The problem is in the code before checking the protection. The problem has to do with whatever actually puts the data in the buffer. The STX file has the right data, but for some reason that exact data is not getting copied to the buffer for tracks 2 and 4. I believe there is a shifting issue with the data due to the WD1772 emulation. Look at the capture below:
You will notice the track buffer has the wrong first 4 bytes. Those bytes should be 9210 90C2, which is in the STX file. If you replace those 4 bytes with 9210 90C2 for track 4 it passes the protection check. Track 3's info is correct. Track 2 also needs these poked in. Once you do that, the protection check passes and the game loads.
I still really want to test loading a real disk in a real machine with just the read track command and see what the ST returns. I believe there is an issue with the WD1772 emulation for consecutive 000's. If you look at the data and manually shift the bits (leaving bits cleared) it works out exactly as what the protection is looking for with the C2 00 and C2 0B. Maybe that is a fluke, but I don't think so.
This isn't the pasti section but this post accurately describes the problem: image data is correct yet pasti.dll thinks it must randomize the pre sector bytes.
Some of you may remember that long before Steem source was released, long before Steem "SSE", I offered a "no-nag" version of Pasti.dll.
Well, using the same hacker tools (IDA, OllyDbg...), I think I have patched pasti.dll for this problem as well! At least Jupiter's Masterdrive STX now loads. I'll include this new pasti.dll in next beta, maybe the patch breaks something else so some testing is needed.