Mail Archives: djgpp/1999/12/29/11:46:50
On Tue, 28 Dec 1999, JP Morris wrote:
> > Try this. Load CWSDPMI, then try to run the V1.x program (it will
> > use the GO32 DPMI support). This takes a pretty different path internally
> > and may be a workaround.
>
> No, It has the same result.
What Charles proposed will not be a meaningful test if your GO32
environment variable says "nodpmi". Please make sure this is not the
case.
> BTW, It reports the version as 1.12 maint 3, which seems to be the last
> version of Go32.
That is correct.
> I'm not quite sure what the driver does, but it is certainly hooking
> int13 into the UMB (where it is loaded) instead of pointing at the ROM.
> Does GO32 make any assumptions about this?
As far as I could see, go32 doesn't do anything special with Int 13h,
or else it would be in conflict with any disk driver out there.
Something else is at work here.
One special thing that go32 does is to use several subfunctions of
function FFh of Int 21h (they are used for an interface between the
protected-mode and real-mode parts of go32). Similarly, function FFh
of Int 10h is used.
Does the driver use function FFh of Int 21h or Int 10h?
Another special thing that go32 does is to reprogram the Interrupt
Controller so that IRQn generates interrupt n + BASE, where BASE is
something different from the usual 8. However, CWSDPMI does that as
well, and since you tell that v2.x programs do run, I don't think this
is the cause of the problem.
If none of the above helps, I think that more info about what the disk
drive does is necessary to suggest a work-around (if one exists).
Btw, is migrating to DJGPP v2 an option? If not, why not?
- Raw text -