Hi Tom and Paul
> any EMM386 will redirect ANY interrupt because protected mode. > > while I didn't try this, I doubt you will be able to trace ANY > interrupt with debug. It COULD probably be debugged (by experts) with https://ulukai.org/ecm/web/#projects-ldebug or with 386SWAT http://www.sudleyplace.com/swat/ but the actual problem is that Paul runs into - apparently BIOS related - attempts to switch to protected mode in spite of EMM386 already using that. The problematic code - Paul writes it probably is int 13, BIOS disk I/O - does not check whether protected mode is in use, so EMM386 throws an error about the conflicting attempt. A work-around would be to never access BIOS disks while any EMM386, JEMMEX, JEMM386 or protected mode app (!) is in use. If you do not load EMM386, you have no EMS (no big problem for most apps) no UMB (unless you load UMBPCI or similar instead) and therefore less free RAM below 640k. Another possible work-around could be to load UHDD, probably before EMM386, if EMM386 has to be used at all: Because UHDD handles many aspects of disk I/O by directly talking to the hardware, the BIOS will be invoked less often. And if you are lucky, exactly those BIOS functions which trigger protected mode conflicts could get bypassed. This could be enough to let some protected mode apps work, although probably not very stable? I have no clear intuition about whether chances are better with or without EMM386. On the other hand, you say int 13 function 0 for drive 80 (first harddisk or SSD) is what fails in FDAPM WARMBOOT, which would be "reset disk system" and is probably NOT one of the functions which UHDD implements without BIOS help. Also, why do things only crash then? Do you not access the harddisk or SSD a lot anyway? Way before the reboot? So Paul: I do not think the problem is that something else redirects interrupts, but that the BIOS itself expects to be the only protected mode task on the whole system. A really interesting conflict! Keep me posted about testing. I still worry about the reserved 4 kB starting at 0x00058000, how would you make sure that DOS apps do not touch the area? You may have to do evil MCB edits to reserve it and I am not aware of an easy to use tool to help you with that... Regards, Eric PS: If REBOOT is an alias for FDAPM WARMBOOT, try whether rebooting works better with FDAPM COLDBOOT :-) _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
