superfury wrote:

If I disable the prefetch buffer (by setting the size of the current CPU to 0 bytes large, effectively disabling it) the game runs without problems.

Have you tried setting it to 4 bytes? What happens then?

It seems to go wrong as well. I've added support for setting the 8-bit bus in the BIOS settings (effectively changing the Prefetch Input Queue for 80(1)86 processors to their 80(1)88 equivalents: 4 bytes prefetched instead of 6 bytes).

When debugging the executed code using the emulator's own debugging utility, I notice that it's executing some kind of counter (I think it might be the IRQ0 handler) which decreases some counter and compares it to 0x18, finding it's not zero, signalling the PIC that it's done. After this it resets instead of executing an IRET. It gets back to the start of the interrupt handler (an STI instruction) infinitely looping (I notice that SP overflows infinitely while executing this way). Letting the CPU run doesn't seem to terminate the infinite loop.

Edit: Looking at the IRQ0 handler of the Turbo XT BIOS:

1;---------------------------------------------------------------------------------------------------
2; Interrupt 8h - Hardware Clock
3;---------------------------------------------------------------------------------------------------
4	entry	0FEA5h				; IBM entry, hardware clock
5proc	int_8	far
6
7	sti					; Routine services clock tick
8	push	ds
9	push	dx
10	push	ax
11	mov	ax, 40h
12	mov	ds, ax
13	dec	[byte ds:40h]			; Decrement motor count
14	jnz	@@increment			;   not time to shut off
15	and	[byte ds:3Fh], 11110000b	; Else show motor off
16	mov	al, 0Ch 			;   send motor off
17	mov	dx, 3F2h			;   to the floppy
18	out	dx, al				;   disk controller
19
20@@increment:
21	inc	[word ds:6Ch]			; Bump low order time of day
22	jnz	@@check_midnight		;   no carry
23	inc	[word ds:6Eh]			; Bump high order time of day
24
25@@check_midnight:
26	cmp	[word ds:6Eh], 18h		; Is it midnight yet?
27	jnz	@@user				;   no
28	cmp	[word ds:6Ch], 0B0h		; Possibly, check low order
29	jnz	@@user				;   not midnight
30	mov	[word ds:6Eh], 0		; Midnight, reset high order
31	mov	[word ds:6Ch], 0		;   low order ticks
32	mov	[byte ds:70h], 1		; Show new day since last read
33
34@@user:
35	int	1Ch				; Execute user clock service
36	mov	al, 20h 			;   send end_of_interrupt
37	out	20h, al 			;   to 8259 interrupt chip
38	pop	ax
39	pop	dx
40	pop	ds
41	iret

It seems that the emulator is retriggering the IRQ0 after the out 20h,al instruction is executed (clearing the flag, after which the interrupt is retriggered for some reason when reaching the "pop ax" instruction?

Edit: After adjusting the debugger to correctly clear/flush PIT timing passed when returning from the debugger (acting like no time has passed at all to prevent extreme amounts of interrupts being called because the debugger pauses the CPU) I notice it's executing a "LOOP 1275" at 3C6A:1275 (in the Castlevania executable?).

I also notice that the IRQ0 is nesting itself (executing itself after acnowledging the interrupt with "out 20h,al"). Is this a problem? It's probably caused by the STI at the start of the interrupt.