hmm of some of the things I'm not certain.
interleaving ?
r-w subchannels ?
And is the audio really not playing ?
and locked ? perharps it's locked at request times.
Could you try to figure out where the value of this call is used ?
with "IV DS:DX result" you should be able to track it more easely.
Or even try setting it to 0xFFFF which is a nice value to track as well.

I explored what hapens with status. Program only inspects wheter the prefetch is enabled and stores it in approriate variable. Then of course it may use MSCDEX function 82. But no metter which is value of status program hangs in endles loop after:

int 2f 1510 function 80
int 2f 150b drive is OK (ABAB returned)
int 2f 150f get directory entry wich executes OK (i checked it)
Then about 80 executions of int 2f/1510 function 80 and 82 in row.
After this program hangs in endless loop around some condition.

Do you have any suggestions now?

Ognjen

well try disabling prefetch to see if that changes a thing.

futher the check directory entry is a very complex call.
you might want to see what it(game) does with the information it gets from it and where it searches for.

I tried without prefetch and same thing happens. (endles loops after
long read mscdex functions)

It is interesting that in all those reads same sector is being read.
Yes only one sector. I checked this trough MSCDEX driver header.
I'll try to figure out why this happens, because this shouldn't happend
because this is address of movie "intro.tgv", as I mentioned in earlier
message in int 2f/150f description. I think that this movie should be put in the memory and after this played, but for some reason it is always first
sector being read and some selfcheck prevents further reading of this file.

Ognjen Milic

you might want to see if it checks the date of the file.

Game is using internal memory manager.
Memory block headers are connected in circular list
with pointers to next and previous member. (Not binary tree I was tired )
All members of header except block name are dwords

This is how it looks like:
OFFSET

00 pointer to block
04 block name (12 bytes) this is file name for open files,
and internal name for other purposes (as CDSTREAM,fontbuffer etc)
10 number of bytes allocated (always dividable by 16)
14 number of bytes that block occupies
18 block type (bitfields)
1c ordinal number of block
20 pointer to next block header
24 pointer to previous block header

Firstly I thought that the problem is in allocation, but then I
saw that this bad allocation (0 bytes) comes because contents of block called SECCDSTREAM and/or block called CDSTREAM are not as they should be.

Then I thought that this comes from defectivity of the CD I am using.
I backed up old cd on the new one and of course used new one.
I put old cd (that has 10 years) and the game worked.
Only status trough 21/4402 was problem and I felt like jackass.
What stupid solution. I was debugging for days and have fully researched
about 70 procedures, tracked data structures etc.

Game started form old CD.
But described problems happens with ISO image of this disk made with BlindWrite.
Then I made a copy with nero to blank cd and game worked again,
but doesn't work with earlier copy (one I used during all this debugging)

Very odd isn't it

Ognjen Milic

Could be anything, but maybe it's related to some copyprotection
checking mechanism. Odd thing still.

Thanks for tracking this down 😀