Does it actually work with sapucdex?

Try adding more logging like

case 0x0B :{/* Audio Track Info */ Bit8u attr; TMSF start; Bit8u track = mem_readb(buffer+1); mscdex->GetTrackInf […]
Show full quote

case 0x0B :{/* Audio Track Info */
Bit8u attr; TMSF start;
Bit8u track = mem_readb(buffer+1);
mscdex->GetTrackInfo(drive_unit,track,attr,start);
LOG_MSG("get audiotrack info, track %d, -> %d:%d:%d attr %x",track,start.fr,start.sec,start.min,attr);

and similar in the respective lowlevel cdrom parts.

wd wrote:

Does it actually work with sapucdex?

oh, no, no, sapucdex & its ioctl calls are completely useless in Vista.

and you know it can't switch to noioctl or sdl or anything, so sapucdex (and therefore dgVoodoo who relies on it) in Vista
amounts to
no caudio track music at all

like dosbox, I must say, when using -ioctl.

TR 1 dos. Mmm I do have it but it is still in it's original packing. (well it is some rerelease)

Qbix wrote:

TR 1 dos. Mmm I do have it but it is still in it's original packing. (well it is some rerelease)

Tomb raider 1 is a 1996 dos game which Dosbox 0.72 runs pretty well.

In this thread I'm talking about the "normal" (non 3dfx/glide) exe version, to keep it as simple as it can be.

One thing you must needs know :
talking about rereleases, at one time in the course of videogame wereldgeschiedenis, they had the bright idea of delivering a Sold Out version which... lacks cdaudio music 😵

see
http://www.tombraiderhub.com/faq/tr1.html#sound
http://www.tombraiderhub.com/faq/traudio.html

so if such is what you have I'm afraid it's not the right version to try out ioctl monkey businesses with 🙄

they use Glidos + KMO's gorgeous audiopack for that now
(see KMORelease110.zip which I attach as it's full of very interesting info on this),

or use a replacement cdrom,

or I could send you an image of my own original cdrom if necessary (TR1 as opposed to #2 and above was never localized so I have the English version anyway).

Just thought it fair to inform you before you start checking and find you're losing your time 😦

Um what about the additional logging?

I don't think Gidierre can compile dosbox himself.

I've attached shots of my version. (which includes a photocamera 😀 )

Qbix wrote:

I don't think Gidierre can compile dosbox himself.

I've attached shots of my version. (which includes a photocamera 😀 )

It seems to me it is NOT the defective thing.. only way to be sure is trying it though

well actually, Qbix, I can compile, I did it many times with MinGW/MSYS when I was struggling with glide.cpp and that nasty glide shadow issue..

the simple fact is, wd, I took note of your hint of course and I thank you for it, but..
I'm not sure what logging info would be really relevant to add, beside the GetTrackInfo() part, I mean.

Before entering a quagmire of sorts, could you please give me some more specific advice 😊 ?

Use the code i posted above, that is the LOG_MSG line added,
goes into dos_mscdex.cpp (function MSCDEX_IOCTL_Input).
Compare the different outputs when using the ioctl and sdl interfaces.

The returncode 0x0100 means "operation done", error would be 0x8000+.

wd wrote:

Use the code i posted above, that is the LOG_MSG line added,
goes into dos_mscdex.cpp (function MSCDEX_IOCTL_Input).
Compare the different outputs when using the ioctl and sdl interfaces.

thx, I'll try that
hey, somehow it's like when I was getting around to understanding the glide wrapper functions, I had begun by sneaking a whole bunch of LOG_MSG spotlights all around the place, it took ages just to guess the connections but it was fun 😀

wd wrote:

The returncode 0x0100 means "operation done", error would be 0x8000+.

oops 😊 you got me, bit #15
Give me this day my daily blunder 😒

btw if operation is done, then why doesn't the routine get over it ?

I guess that either the attribute field is incorrect (so it doesn't find the
audio tracks) or the track length/last track position is different from what TR
expects, both things might be results of a dummy-only or incomplete
implementation of the TOC ioctl function.

that's pretty exciting stuff !
It'll take me a couple of days or so until I can do this little debug test and hopefully I'll be coming up with something bright 🙄

---------------------------

I don't know how much/if that would be apropos, but I can't help reminiscing Paul Gardiner's problems & hacks thereof when he found a way to summon back msdcex failing support for the sake of Glidos v1.10 audio capability.
Will it interest you or anyone ? Be on topic here ? Only the Shadow knows!
What if I report here his attitude ?

Was that.. a yes 😜
Since you insist so, it wouldn't be polite of me not to attach a tiny digest of his (and Vladr's) proceedings 🤣

Or you could just post the log again with the additional output,
if it's the same for ioctl and sdl something different is going on,
but if there are difference i'll put up some code that might get
around the problematic ioctl calls.

wd...? (ouch)

before I go and compile it

hoping
it != "much TODO about nothing";

one question.
I know, me sux 😖

I had noticed you wrote :

"Try adding more logging like
...
LOG_MSG("get audiotrack info, track %d, -> %d:%d:%d attr %x",track,start.fr,start.sec,start.min,attr);
...
and similar in the respective lowlevel cdrom parts"

Now, I've been thumbing through cdrom.h, cdrom.cpp and cdrom_ioctl_win32.cpp a bit

buzzing over class CDROM_Interface_Ioctl & class CDROM_Interface_SDL

I say, is it worthwhile to add more LOG_MSG over there as you hinted ?

In cdrom_ioctl_win32.cpp e.g.

I spotted these

1bool CDROM_Interface_Ioctl::GetAudioTracks(int& stTrack, int& endTrack, TMSF& leadOut) 
2{
3//	Open();
4	CDROM_TOC toc;
5	DWORD	byteCount;
6	BOOL	bStat = DeviceIoControl(hIOCTL,IOCTL_CDROM_READ_TOC, NULL, 0, 
7									&toc, sizeof(toc), &byteCount,NULL);
8//	Close();
9	if (!bStat) return false;
10
11	stTrack		= toc.FirstTrack;
12	endTrack	= toc.LastTrack;
13	leadOut.min = toc.TrackData[endTrack].Address[1];
14	leadOut.sec	= toc.TrackData[endTrack].Address[2];
15	leadOut.fr	= toc.TrackData[endTrack].Address[3];
16	return true;
17};
18
19/////////////
20
21bool CDROM_Interface_Ioctl::GetAudioTrackInfo(int track, TMSF& start, unsigned char& attr)
22{
23//	Open();
24	CDROM_TOC toc;
25	DWORD	byteCount;
26	BOOL	bStat = DeviceIoControl(hIOCTL,IOCTL_CDROM_READ_TOC, NULL, 0, 
27									&toc, sizeof(toc), &byteCount,NULL);
28//	Close();
29	if (!bStat) return false;
30	
31	attr		= (toc.TrackData[track-1].Control << 4) & 0xEF;
32	start.min	= toc.TrackData[track-1].Address[1];
33	start.sec	= toc.TrackData[track-1].Address[2];
34	start.fr	= toc.TrackData[track-1].Address[3];
35	return true;
36};	

likewise, in cdrom.cpp

1bool CDROM_Interface_SDL::GetAudioTracks(int& stTrack, int& end, TMSF& leadOut)
2{
3
4	if (CD_INDRIVE(SDL_CDStatus(cd))) {
5		stTrack		= 1;
6		end			= cd->numtracks;
7		FRAMES_TO_MSF(cd->track[cd->numtracks].offset,&leadOut.min,&leadOut.sec,&leadOut.fr);
8	}
9	return CD_INDRIVE(SDL_CDStatus(cd));
10};
11
12///////////
13
14bool CDROM_Interface_SDL::GetAudioTrackInfo(int track, TMSF& start, unsigned char& attr)
15{
16	if (CD_INDRIVE(SDL_CDStatus(cd))) {
17		FRAMES_TO_MSF(cd->track[track-1].offset,&start.min,&start.sec,&start.fr);
18		attr	= cd->track[track-1].type<<4;//sdl uses 0 for audio and 4 for data. instead of 0x00 and 0x40
19	}
20	return CD_INDRIVE(SDL_CDStatus(cd));	
21};

What if append some LOG flares there too, before compiling, along the lines you pointed to ? Or something different (like what) ?

Or is this just what chez Qbix they'd be calling
onbegonnen werk
(a werk that no wise man ever bothers to handle) ?

------------------------------------

P.S.

but,
in dos_mscdex.cpp

though noone's ever gonna read it 😎
shouldn't
line #1094 :

MSCDEX_LOG("MSCDEX: INT 2F %04X BX= %04X CX=%04X",reg_ax,reg_bx,reg_cx);

read :

-> MSCDEX_LOG("MSCDEX: INT 2F AX= %04X BX= %04X CX=%04X",reg_ax,reg_bx,reg_cx);

instead ?

Just skip the lowlevel function logging for now, usually placing logging at
the upper levels AND lower levels around problematic code is rather
helpful though as you can track bugs in the parameter passing that way,
check what functions are really called etc.

shouldn't
line #1094 :
read ...

AX or AH usually specify the function of an interrupt, so somebody left out
annotating that explicitly.

wd wrote:

Just skip the lowlevel function logging for now

copy that.

Anyway, I understand the lowlevel functions I pinpointed were the right ones to search for 😁
(otherwise I guess you would have corrected me 😜 ).

I'm creeping, but, you know, I don't know if you know that I don't know if I know what I'm doing.

------------

Imagine!

hey,

I thought I was going to compile a debug version of dosbox, but I seem to only get the usual version as have always got before.

Yet this time I was sure to use
./configure --enable-debug
make
in msys as per instructions in the guide.

I don't get the debug window, only the console one. There ironically the LOG_MSG thingy will appear, but I wanted the debugger 😠

What did I do wrong ? Missed some other switch or trick ? A special source packet for the debugger ? I don't think such a separate thing exists.

The exe I compile is functional, except for no debugger.
Alt+Pause pauses the game, won't open any debug window, like no such feature opened on its own. Why is that ?

Help grrrrreatly appreciated 😳

do you have pdcurses installed ?
take a look in config.log to see why the debugger didn't activate (the switch is correct, but it will disable itself if you don't have curses)

Qbix wrote:

do you have pdcurses installed ?
take a look in config.log to see why the debugger didn't activate (the switch is correct, but it will disable itself if you don't have curses)

WARNING: Can't find curses, debug mode disabled

😢

better go get it

hope installation & use are not too much exotic

maybe we should give an error on it. It is easy to miss that warning