This error appeared because I have just copied this game from one dirctory to another without reinstalling it.
But when I corrected this other error come out.
cdromcheck - CDROM STATUS NOT RETURNED
What this could be?
Maybe a returncode of int2f/ah=15 (mscdex) is wrong or the function
is not implemented.
How did you mount the cd?
I mounted it like cdrom with letter D and with ioctl on.
Ognjen
That should be enough, maybe there is some int2f/ah=15 right
before the game exits with that message?
There are several calls of int 2F AX= 1510, CX=3 which returns
MSCDEX status 100.
Last call of 2F/15 is AX=1501,
ES=87DF
BX=0000
ES:BX ->
A B C D
00 00 00 B6 D1 | 45 00 E8 FF BC | 00 9A 00 BD 00 | 9C 00 D1 00 A0 |
Please ignore those A B C D in row before last.
Ognjen Milic
> 00 00 00 B6 D1 | 45 00 E8 FF BC | 00 9A 00 BD 00 | 9C 00 D1 00 A0 |
Only the first 5 bytes are valid (1 cdrom mounted), but this
shouldn't matter here. After calling the function, maybe they
check some registers which might go wrong in dosbox (the
intlist states no registers should be changed).
> There are several calls of int 2F AX= 1510, CX=3
Those can be decoded further (1510 is a mscdex device driver
request call), but i doubt there's a problem with those
calls (see MSCDEX_Interrupt_Handler in dos_mscdex.cpp).
If there I find no problem where it could be?
One more question.
When code is executed within debugger with NBA95 lot's of times it happends that IP jumps to some non consecutive instruction from some point of the executing code(and of course
that instruction is not jum, call or return instruction). Here's example of instruction trace
05da:030f mov [0035], cl
.....
05da:2824 mov [0d66], gs
.....
cmp byte [11f0], 00
Is this wrong?
Ognjen Milic
The register Values does not change after int 2f/01. I'll look
what the game does after this call.
I noticed that debuger reports CX=0000 when it enters in interrupt routine
but CX=0003.
> that IP jumps to some non consecutive instruction
The dynamic core does that. Otherwise maybe the trace flag
is set (selftracing code), or something's severely messed up.
> I noticed that debuger reports CX=0000 when it enters in interrupt
> routine but CX=0003.
Did you put a LOG_MSG or so at the start of the interrupt routine?
Where exactly?
>> that IP jumps to some non consecutive instruction
>The dynamic core does that.
Yes I turned on dynamic core.
>Did you put a LOG_MSG or so at the start of the interrupt routine?
I don't have Heavy Debugger option on. I had difficulties with compiling the source
with miniGw, so c2woody sent me compiled debugger.
I trace interrupts by setting the breakpoint at the start of the routine.
>Where exactly?
In several places
for example
MISC:MSCDEX: INT 2F 150F BX=0000 CX=0000
and
MISC: MSCDEX: INT 2F 1510 BX=0000 CX=0000
MISC: MSCDEX: Driver Function 80
MISC: MSCDEX: Status : 0100
In both cases CX is 0003
Ognjen Milic
I looked to the interrupt 2f/1501 in details
and it says
ES:BX -> pointer to device header
first byte: device number (there is 00) which is ok
dword: address of device driver header
this dword is 45d1:b600 (of course in raw data 00 b6 d1 45)
When I look at 45d1:b600 there are all zeros.
Maybe this could be a problem.
Ognjen Milic
P.S. Please also look last message on previous page.
> MISC:MSCDEX: INT 2F 150F BX=0000 CX=0000
You can safely ignore that, it's a typo (the value of bx is displayed two times).
An what's about
ES:BX -> pointer to device header
first byte: device number (there is 00) which is ok
dword: address of device driver header
this dword is 45d1:b600 (of course in raw data 00 b6 d1 45)
When I look at 45d1:b600 there are all zeros.
Maybe this could be a problem.
Ognjen
The dword at es:bx+1 (after it is filled by int2f/1501) should point to
the dosbox dos data area (seg=0xd1??), at least if a cdrom is mounted.
Works fine here. That area (0xd1??:????) contains an almost-filled
device header, works correctly here, too.
I think I found the solution.
The file MSCD001 is corectly opened and gets
file handle AX=05 (with int 31 ax=0300
and on es:edi+1c=3d00)
But there is unhandled function
(report DOSMISC:DOS:IOCTL Call 2 unhandled),
This is int 21 AX=4402
(handle BX=05 wich is MSCD001's handle), also called
trough protected mode emulation int 31/0300
This is function: read from character device control
channel.
Ognjen Milic
Which subfunction(s) do they call? Maybe you can get around those
checks by faking success for those calls.
When int 21/4402 is called (which is reported as unsupported) CX is 5
so it tries to read 5 bytes.
I faked success by setting CF to 0, but
then program hopelesly runs in endless
loop calling mscdex driver functons 80 and 82.
When I remove condition wich is the cause of the
loop same program hangs in the new endless loop.
So I think that it needs those five bytes form
INT 21/4402
Ognjen Milic
> I faked success by setting CF to 0
A successfull call returns the number of processed bytes in ax,
but this shouldn't matter if there's no check for this.
I have looked at Ralf Brown's interrupt list and I finaly understood what
this interrupt call is for (I had reduced interrupt description).
It is subfunction 06 wich gets CD-ROM status
Status should be returned at DS:DX+1.
I faked the succes fully. Changed AX to 5, CF to 0, and
dword [DS:DX] to 00 00 13 B6 wich means
bit 0 = 0 door not open
bit 1 = 1 door unlocked
bit 2 = 1 supports raw reading in addition to cooked
bit 3 = 0 writable
bit 4 = 1 can play video/audio tracks
bit 5 = 1 supports interleaving
bit 6 = 0 reserved
bit 7 = 1 supports prefetch requests
bit 8 = 1 supports audio channel control
bit 9 = 1 supports Red Book addressing in addition to HSG
bit 10 = 0 audio is not playing
bit 11 = 0 disk is in drive
bit 12 = 1 supports R-W subchannels
other bits = 0
But again it hangs in same endless loops.
Is this faked status OK or not and if not what it should be?
Ognjen