BIOS: Fix losing of interrupt flag (IF) after int13

[humply]

Some programs expect the int 13h handler to return with interrupts enabled (IF).

Looking into a BIOS for ASUS A7A266 revealed int 13h enables interrupts and sets the IF on the stack.

Affected games:

• Blackthorne (MS-DOS 6.22) (will hang because of lost IF after int 13h).
• others...

[fysnet]

I think this should be for hard drive services only. DL >= 0x80

A small addition to allow this would be to modify the line at 9011:

push #int13_out
  jmp _int13_diskette_function

to

push #int13_out_end
  jmp _int13_diskette_function

and then where the original int13_out was, add int13_out_end.

If you make this change, does the game still function as expected?

The notes I have say hard drive services only, not floppy services.

[humply]

After trying out the suggested changes, so that the IF will not be touched for the int13_diskette_function case, the game would not start.

Unfortunately I couldn't find definitive information on what the proper behavior should be regarding int13 setting the IF, but the game does run on real hardware, so that's why I started looking into the BIOS of the hardware.

If it helps, the int13 entry point in the BIOS for the ASUS A7A266 starts with:

sti
pushf
cmp     dl, 1
ja      short loc_FAA79

popf
int     40h    ; Hard disk - Relocated Floppy Handler (original INT 13h)
retf    2

loc_FAA79:
popf
sti
push    bp
mov     bp, sp
sub     sp, 1Dh
push    bp
mov     bp, sp
add     bp, 2
push    ax
push    bx
push    cx
push    dx
push    ds
push    si
push    es
push    di
push    eax
or      word ptr [bp+23h], 200h   ; Set Interrupt Flag (IF) on stack
and     word ptr [bp+23h], 0FFFEh ; Clear Carry Flag (CF) on stack
mov     si, 0
mov     ds, si
cmp     ah, 0
jnz     short loc_FAAAB
call    sub_FAAD1
jb      short loc_FAAC0
jmp     short loc_FAAC4
...

[Vort]

Small observation:
Without fix, game hangs with himem.sys 3.95 + emm386.exe 4.49, but not with himemx.exe 3.36 + jemm386.exe 5.79.

[fysnet]

Okay, I guess leave it as is then. Thanks for checking.

[fysnet]

I added this fix to my BIOS as well.
As a favor, will you test the bios image at https://github.com/fysnet/i440fx (i440fx.bin) to see if it boots your game.
Or will you post a link to the image you boot the game so that I can test it.
Thank you.

[Vort]

@fysnet here are game files: Blackthorne (Black Hawk).English.zip. Add himem.sys, emm386.exe and bug should show up (with older versions I mean).

[humply]

I tested the game with Bochs-2.8 and the i440fx.bin BIOS and the game started!

Because you're developing a BIOS, it's probably best to be able to reliably reproduce the issue yourself for further testing purposes.

[fysnet]

I tested the game with Bochs-2.8 and the i440fx.bin BIOS and the game started!

Thank you.

here are game files

Thank you. I used the two older versions, the ones that come default with DOS 6.22, game works fine until a few minutes into it and Bochs simply quits. No report to Microsoft crash, nothing in the log indicating an error at the end of the log file, or anything like that. Bochs simply quits. It doesn't quit normal because the .lock file(s) are still there.

There were a lot, and I mean a lot, of the following line in the log file:
interrupt(): gate descriptor is not valid sys seg (vector=0x16)
The vector number varies.

Also, a lot, though not as many:
interrupt(): soft_int && (gate.dpl < CPL)

and then quite a few of:
waveOutPrepareHeader(): error = 5

I'm using the same bochsrc file as I did with VChess with an included sb16 line.

If I find anything I will let you know.

[Vort]

Bochs simply quits.

Looks like bug.

There were a lot, and I mean a lot, of the following line in the log file:

This is bug #107.
No one knows if it's a problem in emm386 or in Bochs.
I just switched to jemm386 because of this.

and then quite a few of:

This is bug #270.
It is hard to fix because it requires implementation of arbitrary resampling.