oh noes!

Workaround:

1void PIC_ActivateIRQ(Bitu irq) {
2	if (GCC_UNLIKELY(CPU_Cycles)) {
3		// CPU_Cycles nonzero means the interrupt was triggered by an I/O
4		// register write rather than an event.
5		// Real hardware executes 0 to ~13 NOPs or comparable instructions
6		// before the processor picks up the interrupt. Let's try with 2
7		// cycles here.
8		// Required by Panic demo (irq0), It came from the desert (MPU401)
9		// Does it matter if CPU_CycleLeft becomes negative?
10		CPU_CycleLeft += (CPU_Cycles-5);
11		CPU_Cycles=5;
12	}

Havan't had a closer look yet (notable the joystick optinon seems to make it lock up even in 0.74)

It works for me with joystick, using the official release 😀
I'll try the workaround. Thanks 😀
Update: the workaround didn't work for me 😖

Ah, with normal core it needs 6 instead of 5.

6 does work indeed 😀 Thanks.
Another game broken (with 2 and 6) is Innocent Until Caught. That one's more interesting since it hangs dosbox and if I try enough times, it gives me a blue screen.
It works again if I comment these:
/*
if (GCC_UNLIKELY(CPU_Cycles)) {
CPU_CycleLeft += (CPU_Cycles-2);
CPU_Cycles=2;
}
*/

You can try higher numbers too

Hmm, hack-ish... but it makes sence that the MCU on the soundblaster needs some time to react. Possibly more than set here. Need to check.

1	case 0xf2:	/* Trigger 8bit IRQ */
2		PIC_AddEvent((PIC_EventHandler)SB_RaiseIRQ, 0.005, SB_IRQ_8);
3		//SB_RaiseIRQ(SB_IRQ_8);
4		break;

Tried it with that one, it still hangs.

Wow it bluescreened my PC too, even with 0.74 and letting it sit at the start of the game some time.

PAGE_FAULT_IN_NONPAGED_AREA

I thought a BSOD was generally due to faulty hardware or buggy drivers, and applications don't have enough privelege to cause one themselves except indirectly by interacting with the aformentioned things. Is a module/driver (*.SYS) identified as the cause of the crash?

Haven't seen a BSOD in a very long time <knock on wood>, and not eager to see one now, but I can't even reproduce the hang in Innocent Until Caught with a build of current source. Is it related to the SoundBlaster? If so, which version of CT-VOICE.DRV (i.e. for which model of SB)?

No, Windows (2000) is at loss about the exact source of the crash. And since I've reproduced it only once it could still be coincidence and i.e. my hardware is going bad instead.

Only kernel mode stuff can cause BSODs, that's the theory. There's one big buggy driver though that interacts with applications, it's Windows 😀

I.e. an application that eats up all memory (Foxit with pcjr technical manual) causes BSODs for me, and I've heard at the Reactos place that DirectX has/had loosened checks at the kernel side for performance reasons which could be a problem too.

IUC works for me too

The comment on the fast interrupt change in pic.cpp mentions It Came From The Desert. ICFTD is crashing at startup when using the Roland sound option, but it stops crashing if I use 6 cycles instead of 2 in pic.cpp; however, the MPU401 is not used. There is some fast interrupt code for the MPU401 reset, so I tried both with and without it, and it made no difference. So far, the only way I have got it to use the MPU without crashing is to leave the fast interrupt on the MPU reset and remove the fast interrupt in the PIC.

I think this fast interrupt issue will go away entirely for ICFTD if the MPU reset delay patch is accepted.

BTW, Champion of the Raj uses the same game engine as ICFTD, and as far as I've seen it shares the same issues.

The reset delay patch...
What's left is to implement the command-response delay too, and look at the delays and buffer size when sending i.e. sysex data.

I have IUC set for Roland/Blaster. It's a CT-VOICE.DRV for sb pro.
It's definitely not the one that came with the game though, but to be completely honest, I've switched it around so much trying to get the sound blaster working I no longer know which version it is. I just found one that worked and stuck with it. If I look at the file in a hex editor, I'm unable to find a version number, only the copyright years: 1989-1990.

What's left is to implement the command-response delay too, and look at the delays and buffer size when sending i.e. sysex data.

Example of a game or sequencer that needs any of that? If these are "quality of emulation" enhancements, rather than addressing specific issues, can the reset delay not stand on its own?

Missing delays just ask for trouble, as seen with the soundblaster thing above. Maybe we should comment the change in pic.cpp until somebody has the time to add proper delays. Finding more broken stuff would be good though.

The MPU reset delay patch:
You tested it thoroughly yet?

I did a lot of testing of the MPU reset delay some time ago, but not much since. I had hoped Srecko would evaluate it, especially with the problem cases, but hard to say if/when that will happen.