Quik The Thunder Rabbit WHDLoad freezes with WinUAE

[hexaae]

Someone knows a correct config with WinUAE to make this WHDLoad work?

I tried a lot of cfgs changing CPU, cycle exact, cachesize 0 etc. but this is the first WHDLoad game I've found not working at all: when you 'Start Game' it hangs after loading level 1...

[Foebane]

Originally Posted by hexaae

Someone knows a correct config with WinUAE to make this WHDLoad work?

I tried a lot of cfgs changing CPU, cycle exact, cachesize 0 etc. but this is the first WHDLoad game I've found not working at all: when you 'Start Game' it hangs after loading level 1...

After a quick look on Retroplay, I see three versions, all v1.2a: OCS/ECS, AGA, and CD32. Did you try the first two versions? And the CD32, if possible for you?

[hexaae]

Yes, and can't make it work. It always freezes when Lev 1 starts… As far as I can read in the changelog the game did a lot of strange things to the chipset/CPU/mem (fixed)

[DamienD]

Ok, just tested the AGA version in my ClassicWB 3.1. Lite .HDF.

After trying to start the game I get a black screen and the level never loads...

Not sure how this is a WinUAE issue though, more a WHDLoad one... thread moved out of the support.WinUAE section

...also, obviously the floppy disk version works fine in WinUAE

[hexaae]

Good. Thanks for checking DamienD, it was also my suspect had nothing to do with WinUAE...

[DamienD]

Guess it would be good for someone with a real Amiga to also test

[hexaae]

The strange thing is that I remember I played this WHD game (AGA/CD32) long time ago... but I can't remember if was on my real A1200+Blizzard 1260 or very old WinUAE verison… However this game was a mess, reading CFou's slave changelog but had nice colorful gfx

[ Show youtube player ]

[DamienD]

The above video is probably someone using the CD32 CD / image and not WHDLoad I'd imagine...

...just quickly tested the original CD32 version in WinUAE and played part of level 1 without issue

[dlfrsilver]

this game works on my A1200 030. I have it installed from the original disk images.

[ross]

Hi buddies, can be fixed very fast but something strange here and maybe Toni can clear the question..

The stupid code is:

.up	move	#$2000,sr
	move	#$2700,sr
	cmpa.l	$(location),a5
	beq.b	.up
	
	CACR:	$00002000
	INTENA: $4010

So when INTREQ(bit 4)==1 an IRQ occour, change $(location) and you can exit from loop.
Problem is that IRQ do not trigger!
In theory it should do it between the two SR instructions and maybe in a real machine it does..
EDIT: ok, Denis confirmed it

Well, patch is simple (already tested and works) but a final word by Toni is required.

EDIT2: it's another case of MMU emulation that gives some problems/incompatibilities
try it yourself, real time enabling/disabling MMU from control panel

[Toni Wilen]

Usual requirement: exactly correct slave package required for testing.

[hexaae]

CFOU included sources with the installer http://whdload.de/games/Quik.html so ross fix could be applied?

[ross]

Hi Toni, see edit to my previous message.
There must be something in MMU emulation that changes some timing.
If you remember it happened other times to have small problems with the MMU, even if only enabled and not used.

(I normally use 030+MMU, try with "QuikTheThunderRabbit_v1.2a_AGA.lha")

[DamienD]

When I tested I used these settings with my ClassicWB 3.1 Lite .HDF:

... 68020 (no MMU or FPU)
... AGA (cycle-exact not ticked)
... KS 3.1 (A1200)
... 2MB Chip and 8MB Z2 Fast RAM

[Toni Wilen]

There are some config combinations where it works but most of them delay interrupt check after next instruction (after SR was set back to 0x2700) so nothing happened.

Fixed but not in JIT mode. I am not sure if it is safe because this interrupt handling difference is partially JIT related.

[ross]

Originally Posted by Toni Wilen

There are some config combinations where it works but most of them delay interrupt check after next instruction (after SR was set back to 0x2700) so nothing happened.

Thanks Toni.
Why this delay? In a real machine if you disable cache/superscalar I suppose there is not this situation (but my knowledge in real world stopped more than 20y ago at 030 and on 040/060 is only from manuals..).

Fixed but not in JIT mode. I am not sure if it is safe because this interrupt handling difference is partially JIT related.

Acceptable, who uses JIT knows what it's up to

[DamienD]

Ok, so I guess I need to move this back to the support.WinUAE section then?

Done

[hexaae]

Just found it did actually work but only in 020-030, no MMU, JIT off, cycle exact on, approximate A500/A1200 or cycle exact on. 040 or 060 with same config didn't make it work.

[hexaae]

Originally Posted by Toni Wilen

There are some config combinations where it works but most of them delay interrupt check after next instruction (after SR was set back to 0x2700) so nothing happened.

Fixed but not in JIT mode. I am not sure if it is safe because this interrupt handling difference is partially JIT related.

This game works fine now with latest WinUAE.z , even on 040-060 (JIT off).
I've just made a Coloricon for this game added to The Zone

[Toni Wilen]

Originally Posted by ross

Thanks Toni.
Why this delay? In a real machine if you disable cache/superscalar I suppose there is not this situation (but my knowledge in real world stopped more than 20y ago at 030 and on 040/060 is only from manuals..).


Acceptable, who uses JIT knows what it's up to

I only know that it has something to do with JIT and was also added when JIT was intoduced and was used for any JIT compatible mode. And something breaks strangely if it is removed.

Most likely MOVE to SR is a special case instruction that guarantees immediate interrupt check. Emulation does it too but delay broke it.