IK+ NTSC fixed version?

[ross]

Key here is your ACA500.

If in WinUAE you raise CPU speed (a Quickstart A1000 setup with 512KB chip RAM and CPU Frequency 4x will suffice) the game work properly even in NTSC.

[TjLaZer]

Oh is that a bug? Strange!

Just tried it on WinUAE and it didn't work. Set to 4x (A1200) speed. But with Fastest speed it works. Also with 68020, 68030 it works. Strange that is supports faster CPU. Most games of this era do not.

[Snoopy1234]

Tested IK+ WinUAE 5.0.0 A500 (1.2)(512k)(NTSC) doesn't work
A1000 (1.1(NTSC))(NTSC) doesn't work
A1000 (1.3) _ (NTSC) doesn't work.

[ross]

Originally Posted by TjLaZer

Oh is that a bug? Strange!

Just tried it on WinUAE and it didn't work. Set to 4x (A1200) speed. But with Fastest speed it works. Also with 68020, 68030 it works. Strange that is supports faster CPU. Most games of this era do not.

It is certainly a race condition, the fact that it only works for slightly higher frequencies or with 020/030 (therefore with execution of the same instructions in fewer cycles) is quite proving.
Maybe in NTSC it try to finish something with 000/7MHz in one frame and there isn't enough time.
The programmer simply reasoned for a 7MHZ PAL machine as the minimum specification, it's not that strange and a lot of code in NTSC world fails for that, but possibly without crashing .

I haven't checked the code but most likely it can be fixed by rearranging the semaphores between the 'tasks', or changing the 'trigger time' for the IRQs.

[Snoopy1234]

No expert but kickstart 1.2 included timer.device in rom that checked the Pal/Ntsc status of the amiga and updated timing and screens accordingly. 1.1,1.0 didn't have this and seperate PAL and NTSC versions were released.

On WinUAE, if IK+ is loaded in A500 PAL and then switched to NTSC while running the game goes into race-mode hyper fast. I guess WinUAE settings are already established.

[ross]

Originally Posted by Snoopy1234

No expert but kickstart 1.2 included timer.device in rom that checked the Pal/Ntsc status of the amiga and updated timing and screens accordingly. 1.1,1.0 didn't have this and seperate PAL and NTSC versions were released.

The game takes complete control of the system, so no matter which kickstart you use, the behavior is always identical.

But I checked the code: the IRQ3 handler is very dangerous (and in fact it crashes ).
So is this: "Maybe in NTSC it try to finish something with 000/7MHz in one frame and there isn't enough time."

Basically it lowers the priority during the management code to allow IRQs of the same priority (by Copper) to be executed anyway, as if they were of higher priority, interrupting the one being executed (VBI).

The problem is that the executed code requires more video lines than those available in NTSC and the new VBI is executed recursively within the previous one, generating a wonderful stack overflow (and since the SP is in low memory it quickly overwrites the exceptions vectors).

This explains perfectly why in NTSC you have to have a 68000 >7MHZ or a 020+

[TjLaZer]

Intersting. Any idea how the WHDLoad patch fixed this? It works in NTSC just fine. Is it just due to the fact the machine is upgraded from stock? Now I want to try a bone stock Amiga with the WHDLoad version lol

[ross]

Originally Posted by TjLaZer

Intersting. Any idea how the WHDLoad patch fixed this? It works in NTSC just fine. Is it just due to the fact the machine is upgraded from stock? Now I want to try a bone stock Amiga with the WHDLoad version lol

WHDLoad patch works thanks to Stingray nice idea to 'detach' the VBI with a trigger for a CIA IRQ6 that simulates PAL timing.

Unfortunately this does not eliminate the problem of missing time in the frame if the processor is slow.
So in NTSC it no longer crashes, but if the processor is not fast enough there are a significant amount of video glitches.
Probably for NTSC machines the IRQ manager should be completely rethought, also dropping the frames in case the processor cannot cope.