Although your concern is valid, it's a separate one. Being able to run FreeDOS on such newer system is useful, even if such a system would no longer have full IBM PC compatibility.
Even historically, MS-DOS was designed to run on 8088/8086 systems that were not necessarily fully compatible with the IBM PC at the hardware level. There were some machines that weren't IBM PC clones, but could still run DOS, even if that sometimes required a custom DOS version. The DEC Rainbow comes to mind, but there were other such machines too. And indeed, such machines wouldn't be able to run any applications that accessed IBM PC hardware directly. But "well-behaved" applications, which used the DOS API (INT 21h and such) ran just fine. In many ways, a modern UEFI PC would still be much more compatible with an IBM PC than those non-clone DOS machines were. For one thing, muefircate would offer the legacy BIOS API (INT 10h and such), which would already help with most things. And many modern systems still have some level of register-level legacy VGA compatibility, which muefircate would be able to expose, either by loading the legacy VGA BIOS from the upper memory area, or loading the SeaBIOS generic VGA BIOS. Heck, by installing another (older) graphics card with legacy VGA compatibility in a PCI Express slot, it could still be made to work. And this could also apply to the use case that you mentioned: getting network access to work. Even if no DOS drivers exist for any NICs with a PCI Express interface, there are still various conventional PCI NICs available that do have DOS drivers (Realtek RTL8139, 3COM, etc). You should still be able to get those to work in a modern motherboard, through use of a PCI to PCI Express adapter. But at the end of the day, even in what you could consider the worst case scenario, with no legacy VGA compatibility or any network support, being able to natively boot FreeDOS, and with that run at least some applications and do some retro or embedded software development on that, would be worth it, IMO. Some of the incompatibilities could also be solved by developing specific hardware emulators that run as DOS TSRs that trap I/O port access. Yes, that would be emulation, but it would be "targeted" emulation for specific peripherals, while the machine would otherwise still be running DOS natively. From a nostalgia perspective I'd still prefer that over running all of (Free)DOS inside a VM. And also, people are already relying on that to emulate old sound devices anyway. (SoftMPU, SBEMU, etc.) Taking a step back, I believe this also a matter of not wanting to solve too many problems at once. Let's focus on getting FreeDOS to run on these newer systems. What you describe is a larger and more general problem of hardware (and peripheral) incompatibility. On Mon, Dec 23, 2024 at 2:39 PM Danilo Pecher via Freedos-devel < freedos-devel@lists.sourceforge.net> wrote: > The trouble with new baremetal machines goes beyond just UEFI or lack > of CSM. You would perhaps be able to run freedos, but couldn't use > most of the hardware. The only real metal that I can haveTCP acces for > instance is a 17 year old laptop. I have yet to see any network or > sound drivers for recent hardware. > > On Mon, 23 Dec 2024 at 13:23, Volkert via Freedos-devel > <freedos-devel@lists.sourceforge.net> wrote: > > > > Thanks for bringing this project up in this mailing list, Liam. > > > > It's unfortunate that there haven't been any replies to your post so far. > > > > Also, muefircate (and its predecessor BiEFIrcate) have been mentioned in > threads in freedos-devel before, but there hasn't been much engagement on > it. > > > > That's really unfortunate, since this project seems to be exactly what > FreeDOS needs to remain natively usable on newer PCs. > > > > Muefircate (a.k.a. "μuᴇꜰɪrcate") is a UEFI boot loader that would allow > legacy OSes to boot from UEFI systems that lack a Compatibility Support > Module (CSM), which applies to most motherboards and laptops that entered > the market after 2020. > > > > The project accomplishes this by implementing the relevant legacy BIOS > routines, notably INT 10h for video output and INT 13h for disk access, and > by scanning the upper memory area for option ROMs and a video BIOS, and > loading them if detected. (Even on modern UEFI systems, the upper memory > area often still contains such loadable ROMs.) Even if no legacy video BIOS > is detected, it could then try either loading a generic VGA BIOS from the > SeaBIOS project, or failing that, implement INT 10h routines that output > video through whatever framebuffer interface UEFI would expose. Also, there > was some work in progress to emulate a PS/2 keyboard, since modern UEFI > systems only take USB keyboards these days. And then it would search for > MBRs to boot. > > > > And with those three (INT 10h, INT 13h, PS/2 keyboard emulation, MBR > chainloading), I believe you'd already have the bare minimum to be able to > boot DOS from a legacy-free x86-64 UEFI system, right? > > > > TKChia, who also maintains IA-16 (a 16-bit x86 fork of GCC), seems to > have been working on muefircate entirely by themself. > > > > This project could really do with some more contributors, and if > successful, would enable FreeDOS to remain bootable on newer bare-metal > hardware for the foreseeable future, especially now that Intel has > withdrawn their legacy-free 64-bit exclusive X86S specification proposal. > > > > I know that even without bare-metal compatibility, one would still be > able to run FreeDOS in a VM under an emulator or a hypervisor, but I can't > help but get the feeling that something would die in the project if new > hardware wouldn't be able to run FreeDOS natively anymore. I'm sure we'll > reach that point eventually, but as long as modern x86 CPUs still (at least > theoretically) have the ability to run (Free)DOS natively, isn't it worth > the effort to maintain that possibility? > > > > It would be wonderful if some knowledgeable people in the FreeDOS > Developers community could reach out to TKChia with an offer to assist in > completing muefircate to the point where it can actually boot FreeDOS, and > then possibly even including muefircate in a separate FreeDOS ISO image > "for newer legacy-free systems". > > > > Curious to read about other people's thoughts on this. > > > > Thanks, and happy holidays, everyone. > > > > On Sat, Nov 2, 2024 at 4:03 PM Liam Proven via Freedos-devel < > freedos-devel@lists.sourceforge.net> wrote: > >> > >> Since this is a FAQ, I was surprised to come across this today. > >> > >> https://gitlab.com/tkchia/muefircate > >> > >> It's a fork of the deleted BiEFIrcate > >> > >> There's another fork but it seems inactive: > >> > >> https://github.com/LoopZ/biefircate > >> > >> > >> -- > >> Liam Proven ~ Profile: https://about.me/liamproven > >> Email: lpro...@cix.co.uk ~ gMail/gTalk/FB: lpro...@gmail.com > >> Twitter/LinkedIn: lproven ~ Skype: liamproven > >> IoM: (+44) 7624 227612: UK: (+44) 7939-087884 > >> Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053 > >> > >> > >> _______________________________________________ > >> Freedos-devel mailing list > >> Freedos-devel@lists.sourceforge.net > >> https://lists.sourceforge.net/lists/listinfo/freedos-devel > > > > _______________________________________________ > > Freedos-devel mailing list > > Freedos-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/freedos-devel > > > _______________________________________________ > Freedos-devel mailing list > Freedos-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-devel >
_______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
