First off, it is I again. Yes, I felt flummoxed enough to ask for some help again despite my coding/understanding skills having improved somewhat since the last time I asked for assistance on something (and given that I went a long break without dealing with anything Amiga-related, that's saying something).
It concerns the 1991 Activision title
Hunter. Its trackloader seems to work okay under a standard A500 setup, but try to test/run it on anything more significant than that - say, a 68020 A1200 - and said trackloader promptly keels over and gets stuck in a cha-cha-cha loop before it can even load the title card. Yes, I tried it in Cycle Exact mode as well - no dice. (Funny how it's never an issue during the first opening seconds with the red and black display.)
And no, it's not copy-protection related. As well as the IPF (which I had to painstakingly step through the decryption routine via the WinUAE debugger to ensure it didn't unpack garbage after I had to change an "addq.l #6,a7" to "addq.l #8,a7" to get around a stack-related issue on 68020+ Amigas, just to confirm that yes, it wouldn't load anyway), I tried all of the existing scene cracks of the game. And they all exhibited the same problem. Yes, even the "AGA-fixed" edition by Nomad. Though that's probably because it falls over before it can even get to the part it had to change to make it work on AGA machines.
After some messing around, I can confirm that it's definitely related to the speed/frequency of the CPU. Selecting "68020" by itself can cause issues quite easily, and can only really be rectified by significantly lowering the CPU speed to fairly slow figures ("1x" in Cycle Exact mode, or -90 to -80% without CE). Lo and behold, it'll work as fine as it does on a bog-standard A500.
For the record, this seems to be where it gets stuck, starting from $10d86 in memory (A5 is pointing to $806, and A6 is pointing to $DFF000):
Code:
10d86 = bsr 10d4e 61 c6
10d88 = move.w #$c000,d0 30 3c c0 00
10d8c = mulu.w d4,d4 c8 c4 <- D4 is always empty during this part, so it's probably just a delay tactic. But alas, not a very good one.
10d8e = and.w #$2,1e(a6) 02 6e 00 02 00 1e
10d94 = dbne.w d0,10d8c 56 c8 ff f6 <- the possible problematic part - if it moves to $10d98 with a D0 result of either FFFF or anything above 8000, it's a bad outcome.
10d98 = move.w #$4000,24(a6) 3d 7c 40 00 00 24
10d9e = tst.w d0 4a 40
10da0 = rts 4e 75
10d4e = move.w #$4000,24(a6) 3d 7c 40 00 00 24
10d54 = move.l 160a(a5),20(a6) 2d 6d 16 0a 00 20
10d5a = move.w #$6a00,9e(a6) 3d 7c 6a 00 00 9e
10d60 = move.w #$9500,9e(a6) 3d 7c 95 00 00 9e
10d66 = move.w 160e(a5),7e(a6) 3d 6d 16 0e 00 7e
10d6c = move.w 1608(a5),d0 30 2d 16 08
10d70 = addq.w #$1,d0 52 40
10d72 = or.w #$8000,d0 00 40 80 00
10d76 = move.w #$2,9c(a6) 3d 7c 00 02 00 9c
10d7c = move.w d0,24(a6) 3d 40 00 24
10d80 = move.w d0,24(a6) 3d 40 00 24
10d84 = rts 4e 75
I've tried to come up with varying delay tricks in the code such as DBF loops and a VPOSR check without any success. I tend to get quite moody if I feel like I'm being defeated at every turn, and it's getting quite late where I am, so I'm willing to bite the bullet and ask one of the experts on here to point out to me where I'm going all wrong and what can be done to make the trackloader behave correctly on all Amigas of all shapes, sizes and, yes, speeds. Heck, it would be nice to confirm whether it's technically the fault of WinUAE, the game code, or something else altogether. (But if anyone does provide some code, try to showcase it in something I can understand straight away, like how I write things. I don't go by the MC68000 instruction manual for a living and don't use labels for everything.)
Obligatory "pretty please with a cherry on top", natch.