Mail Archives: djgpp/2000/11/09/13:25:28
In article <Pine DOT SUN DOT 3 DOT 91 DOT 1001109084112 DOT 16891F-100000 AT is>,
djgpp AT delorie DOT com wrote:
>
> On Thu, 9 Nov 2000 dcasale AT my-deja DOT com wrote:
>
> > Okay, I'm back with a slightly different problem.
>
> Welcome back ;-)
Heh. I don't know whether to cheer or cry. ;-p :-)
> > I tried experimenting around with Nate Eldredge's YAMD (Yet Another
> > Malloc Debugger), but my program hung almost right at the beginning,
> > and didn't even get close to where the original crash occurs.
>
> Did you try this on plain DOS or on Windows? If the former, did you
> use CWSDPMI as your DPMI host? YAMD will not work except with CWSDPMI
> or DPMI 1.0 host.
Yes, I ran it in plain DOS. (It does direct disk access; it won't even
run in WinBlows.) Yes, I used CWSDPMI.
> > // Check to see if the INT 13 HD extensions are present...
> > if( ( (regs.x.flags & 1) == 0 ) && ( regs.x.bx == 0xAA55 ) )
> > {
> > regs.h.ah = 0x48;
> > regs.h.dl = PhysicalDriveNumber;
> > regs.x.si = __tb & 0x0f ;
> > regs.x.es = regs.x.ds = __tb >> 4 ;
> > pINT13DP->BufferSize = 0x1A;
> > dosmemput(pINT13DP,sizeof(*pINT13DP),__tb);
>
> What is sizeof(*pINT13DP)? How many bytes did you mean to copy to the
> transfer buffer?
// Used to retrieve the file system type (normal or extended FAT)
typedef struct _INT13DriveParams
{
WORD BufferSize;
WORD InfoFlags;
DWORD PhysicalCylinders;
DWORD PhysicalHeads;
DWORD PhysicalSectors;
QWORD TotalSectors;
WORD BytesPerSector;
} INT13DriveParams;
26 bytes (1A hex) total. Like I said, this works outside the debugger.
> > asm volatile ("pushf" : : );
> > __dpmi_int (0x13, ®s); /* call BIOS */ <--- hangs here
> > asm volatile ("popf" : : );
>
> Why did you insert PUSHF and POPF? They are not needed for
> __dpmi_int calls; I suggest to remove them.
Because another programmer who was working on this code before me found
that with _some_ __dpmi_int int 13h calls, interrupts were mysteriously
turned off after the call returned. That _may_ be the reason my system
clock is slowing down. I've just been adding pushf and popf around the
interrupt calls to forestall that problem.
> > I'm guessing that RHIDE's debugger might be using the transfer
> > buffer itself, thus overwriting what I just put there.
>
> No, this guess is wrong: the DJGPP debug support arranges for the
> debuggee to have a separate transfer buffer, to avoid problems with
> stepping through system calls. This is done in the function that
> loads the debugged program and prepares it for execution, effectively
> replacing the stub loader; see the source of the function v2loadimage
> in djlsr203.zip.
Hmm. Okay, then.
> > Any ideas?
>
> The Interrupt List says something about specific BIOSes which fail to
> handle this function correctly if the flag word at DS:[SI+2] is not
> 0000h on entry. Are you sure you zero that word?
You mean InfoFlags in the structure above? No, I don't zero that.
I'll check to see if that's the problem. Thanks.
Damon Casale, damon AT WRONG DOT redshift DOT com (remove the obvious)
PEEK and POKE is a game played by young programmers.
Sent via Deja.com http://www.deja.com/
Before you buy.
- Raw text -