Hi Paul,
> It may be the case with other drivers than hard disk too... Apparently at least keyboard and graphics work without problems, so I think it is more related to drivers with block I/O such as disk and maybe network or USB. Which leads to the question how your system behaves after you have booted from USB media? > Which make me think my system would probably be more happy if the FreeDOS > kernel was > booted in VM86 mode by a UEFI program, and extended and expanded memory were > implemented by UEFI services. ;-) Unfortunately, things are more complicated. It could be that your BIOS is some UEFI CSM which simulates the BIOS under the assumption that only ancient real mode software would need a BIOS. So you would want a more sensible CSM, not a more sensible kernel, for better sharing of protected mode, to be able to run protected mode DOS apps. The general idea has been mentioned here a while ago: DOSEMU2 has ported the FreeDOS kernel to be a protected mode job on the Linux side of DOSEMU2, called fdpp. You could indeed use that as part of an infrastructure which boots directly from UEFI. But you would still need a CSM-style way to provide BIOS services to DOS apps. For protected mode apps, you would need a DPMI implementation to let them share protected mode with your UEFI and the other protected mode components and for real mode apps, you will have to be at least as vm8086 compatible as EMM386 would be on a real mode system, which brings you back to the conflict with your E800:x driver thing, probably a type of AHCI or SATA BIOS? About UHDD: > Well... I doubt it will be able to speak to an AHCI only chip (no ide). It is meant for IDE and SATA with some compatibility, so some non-AHCI mode would be enough, no ancient IDE. As far as AHCI-only SATA controllers are concerned, please try the mentioned AHCICD driver for CD/DVD, I am curious whether that one works for you :-) It has to be used together with SHSUCDX or MSCDEX etc. >> I still worry about the reserved 4 kB starting at 0x00058000, >> how would you make sure that DOS apps do not touch the area? > I worry too. Not sure at all how to handle it. You could edit your MCB chain to reserve the area, but as it is sort of in the middle of your DOS RAM, it will limit the choice of real mode apps which you can load. Protected mode apps might be more lucky, as most of their RAM use can be elsewhere. Which leads to ANOTHER idea: How about installing a large RDISK RAMDISK (with HIMEMSX and the special modified RDISK for that, you can even use more than 4 GB of RAM for that) and running your apps there? In particular the protected mode apps, to avoid all BIOS disk I/O while the apps are active? You would copy your apps to the ramdisk with either FreeCOM command.com copy or with XCOPY, whichever is less likely to collide with the 5800:0 problem. Of course you must not use JEMMEX or JEMM386 here, as both collide with your protected mode disk BIOS. Eric PS: In which year have your computer and "BIOS" been introduced? Are those very new designs? _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
