Fortunately I stopped buying new computer hardware (espacially motherboards, CPUs and video cards) before (U)EFI hit the ground...

kind regards
soggi

Hang on I'll just go and check my care factor..
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Yip, it's still zero.

soggi wrote on 2021-06-10, 05:31:

Fortunately I stopped buying new computer hardware (espacially motherboards, CPUs and video cards) before (U)EFI hit the ground...

kind regards
soggi

Wise decision. 😎👍

From now on, x86 backwards-compatibility may go down hill.

Next step will be the removal of the 16-Bit instructions, I assume.

Most virtualizers do seem to emulate these,
at least partially, already.

V86 is already partially broken at the competition (AMD's Ryzen)..

Anyway, we still have emulators like 86Box, Bochs, QEMU..

It's.. It's just not exactly the same feel anymore. 😢

If you're working with the "real thing" it feels like your vintage knowledge and efforts are something worth still.

Coding in Assembler on a modern PC that's running DOS natively, is different from using an emulator.

Because you can do some useful, hacky things still.
You can bit-bang all the stuff in your real PC,
watch the registers, access PCIe cards and FPGA boards etc.
Or directly access attached hardware, like hard disks.

Long story short: Doing experiments with the "real thing" doesn't make you feel like a native living in the reservations (as opposed to developing for an imagination/emulation) ..

You don't actually need a "modern" PC to run Dos natively I think. I could be wrong though.

For instance I don't care one iota that this 64-bit system isn't running Dos. I have around ten systems that will run it without any problem at all. So not missing out on anything Dos related.

no dos means no win9x too

robertmo wrote on 2021-06-10, 06:54:

no dos means no win9x too

Is that a problem? 😀

That reminds me. I should get off my backside and get my old win98 box back up and running.

Jo22 wrote on 2021-06-10, 05:59:

soggi wrote on 2021-06-10, 05:31:

Fortunately I stopped buying new computer hardware (espacially motherboards, CPUs and video cards) before (U)EFI hit the ground...

kind regards
soggi

Wise decision. 😎👍

From now on, x86 backwards-compatibility may go down hill.

i cannot imagine a PC in 10-15 years from now being x86 compatible natively, sure it may be but at some point it will all shift away

So, the last, and "fastest" true DOS machine possible will be a 10th Gen i9 system? I wonder what the last (CSM) VBIOS version is or was officially relased by Intel. Is it the Kaby Lake / Skylake VBIOS 16-bit code (intel HD graphics 620 / 650), which I believe stopped at build 1062 back in 2018 / 19.

Surely there will be hacks forthcoming to overcome this limitation. BIOS hackers are some ingenious folks who put Intel to shame. Someone will find a way to get a VBIOS embedded somehow.

Inserting a VGA BIOS as such is easy, I think, because it's just another Option-ROM (well, almost).

It should be possible to use an ethernet card, just like how its done with XTIDE Universal BIOS.

However, writing a VGA BIOS for the Core-i..
Well, if the framebuffer is similar to that of its predecessors, it might be possible to hack an existing VGA BIOS, I assume.

That being said, I don't know much about modern UEFIs..
Not sure how they check for a VGA BIOS.

Personally, I'm more worried about the 16-Bit instruction code compatibility.
As long as the CPU itself supports them, things can be "fixed".
But if Intel decides to remove them eventually,
because they are "wasting precious space" in the CPU die and because "only DOS needed them", things get more complicated.

Some fiction :
On the other hand, a self-booting BIOS emulator would be a workaround.

Similar to these DDOs (Dynamic Drive Overlays) on old PCs, they would intercept/hook-in before the actual OS loads.

On modern PCs, that would be some some sort of payload that gets loaded by UEFI.
Maybe SeaBIOS could do that job?

Such a compatibility layer would use V86 or AMD-V/Intel VT type of hardware-based virtualization to set up a PC/AT+BIOS-like environment (a shim?).
That way, no real VGA BIOS would be needed.
Also, thinge like 8514/A, GLIDE etc could be provided without extra hardware.

This approach would have the benefit that certain ancient peripherals like ps/2 mouse and keyboard,
as well as the VGA card and the HDD interface could be emulated thoroughly.
An USB pen drive could appear as a super floppy/HDD etc.
And Bluetooth devices could appear as serial ports.

In essence, such a lightweight compatibility layer would behave like a VM in certain ways.
However, it would also allow direct access to certain devices still.
The IO-MMU feature, or how it's being called, could be used for this maybe.
Real PCIe cards, or serial/parallel ports could still be accessed.

Yeah, it's a bit sketchy. I like to think of it like a big, modern version of EMM386/QEMM.
It's a miniature OS in its own reign that can intercept/re-route hardware access,
if needed (SOFTMPU, TEMU etc) but also allows direct access.

But, speed (and compatibility) suffers greatly through emulation, which is always kludgy. Many think emulation is the cureall and the panacea, while of course it is NOT.

DOSBOX, for example is a far cry from running real DOS on bare metal. About 10x-50x slower and not perfect fullscreen, VESA write combining, or anywhere near the RAM performance. DOSBOX is a toy while DOS is the real thing.

zyzzle wrote on 2021-06-12, 09:31:

But, speed (and compatibility) suffers greatly through emulation, which is always kludgy. Many think emulation is the cureall and the panacea, while of course it is NOT.

DOSBOX, for example is a far cry from running real DOS on bare metal. About 10x-50x slower and not perfect fullscreen, VESA write combining, or anywhere near the RAM performance. DOSBOX is a toy while DOS is the real thing.

Thank you for posting that. My feelings exactly.

You just need to look in the DosBox section to see the issue folk have, then someone suggests to use another version of it. In saying that it does fill a gap for those without older Dos systems I guess.

DOSBox is great, IMHO. ❤️
By design, it's cleaner and more compatible than the real thing sometimes, IMHO.
Also, alternatively MS-DOS 5/6 can be booted inside just fine. AFAIK. 👍

PS: The DOS VM in IBM's own OS/2 was considered very good. It used a combination of emulation/virtualization.
Emulators were used since the earliest days of computing, also. They are common dev tools.

Can DosBox boot a different version of Dos, say DRDos, off a fdd in its own window like OS/2 can? Two different Dos variants at the same time.

Did any MS Windows version have the ability to do that without additional VM software.? On an Operating System that only takes up 60megs of hdd.

The Dos in OS/2 is based around MS Dos 5.

IMHO, this is both practically inevitable and a harbinger of things to come as even CSM itself was due to be sunset by 2020 (on the Intel side of things at least) according to some published roadmaps .

From a DOS gaming perspective, is there anyone actually running DOS bare-metal on modern hardware with no ISA slots and very limited ways (if any) of getting sound blaster emulation on PCI sound cards ? I mean, other than booting up DOS and firing up Quake or Duke Nukem 3D on my i9 9900K without sound and just because I can, is there a point ? And these last two games are probably among the best case scenarios as anything older and speed sensitive will be practically unusable .

As for DOS applications, losing the ability to boot DOS and run various utilities is not great for those who depend on it, and correct me if I am wrong, but is there anything that special on that Hiren CD that is still relevant to a modern machine and cannot be done either from a Linux live boot CD or the Windows Recovery console (bootable Windows install media) ?

While WIN32 and IA32 hardware support will likely go the way of the dodo as well at some point in the future, that seems relatively distant in comparison to the disappearance of CSM . Even if Microsoft deprecated WIN32 tomorrow morning, it would take years to get users to shed their dependence on legacy applications . Not to mention that Windows' secret weapon has always been backwards compatibility . Burning the bridge to 32-bit compatibility too early would just give a percentage of the user base an extra incentive to jump ship and rely on virtualization for their legacy needs . Also, even in 2021, 32-bit Windows 10 and its NTVDM and WIN16 support still exist for a reason : Microsoft still wants to cater to users of WIN32 and even WIN16 applications (even if it makes them jump through some hoops to get there). And by the time 32-bit x86 hits the end of the road, there will likely be even more options and better ways to run code dependent on it . Actually, IMHO, an impending EOL date would probably help kick development of those options into high gear .

zyzzle wrote on 2021-06-12, 09:31:

But, speed (and compatibility) suffers greatly through emulation, which is always kludgy. Many think emulation is the cureall and the panacea, while of course it is NOT.

DOSBOX, for example is a far cry from running real DOS on bare metal. About 10x-50x slower and not perfect fullscreen, VESA write combining, or anywhere near the RAM performance. DOSBOX is a toy while DOS is the real thing.

DOSBOX also has a ton of easy to fix bugs and also pretty easy to implement optimizations if you know what you are doing.

I need to finish going through the source files at some point and continue my list of bugs and possible optimizations.

I would imagine a well organize computer technician would take precautions and have a suitable. regularly tested, backup system/s ready swap in if things went tits up. Or even just for precautionary maintenance purposes after a certain amout of operating hours.. Which sould be put in the outfits IT procedures manual/documentation. And have a variety of spare components for a certain number of years to keep these systems operational.

So, the takehome message is to find a good, "modern" DOS system now with a recent i5 / i7 core CPU which still can run on bare metal with CSM support. For, in 5 years such systems will not doubt be priced at the 1000s of dollars if you judge by the recent scalper's haven which exists even now for legacy parts.

I'm thinking a good i5/i7 6th gen chip, with decently fast DDR4 performance will make do for the next 20 years for all our needs to run a DOS system on bare metal.

How to get sound in real DOS on such a system will be the project for the next 20 years. Converting and / or writing PCI sound wrappers for all of our favorite DOS games during that intreval.

Dosbox is just unsatisfactory because it's got a ton of problems, and, for me at least is slow, slow, slow --- even on a fast modern system. It seems wrong that DOS programs / games should run slowly with such beefy hardware as a decent i5 or i7 system with 8GB of RAM and a 3 Ghz+ clockspeed!

So, I stick with baremetal DOS as far as humanly possible, with excellent results, save for sound.

CSM sunsetting and lack of native 16/32 bit code execution on CPUs from here on out is a sad day for me.

Industrial mobo manufactures a still manufacturing mobos with great ISA support complete with. shhhhhh don't tell anyone., real serial ports.

I recall NASA scalping as many old x86 systems as they could a while back.

The latest and greatest iSPY cpu based mobos are not needed at all.

zyzzle wrote on 2021-06-13, 20:29:

Dosbox is just unsatisfactory because it's got a ton of problems, and, for me at least is slow, slow, slow --- even on a fast modern system. It seems wrong that DOS programs / games should run slowly with such beefy hardware as a decent i5 or i7 system with 8GB of RAM and a 3 Ghz+ clockspeed!

I would cordially challenge anyone to publish a list of **DOS games/apps** that DOSBox can be considered slow. So far, no one has yet to do that. If one looks at experience and usability point of view, DOSBox handsomely fulfilled such requirements. It is true that DOSBox can never be as fast as bare-metal, but the question really is if such bare-metal performance would even matter. For DOS games, when DOSBox runs them at 30fps while bare-metal at 200fps, there is really isn't any difference in experience and usability.

When x86 chipsets completely remove the logics that provide "Page Memory Attributes (PAM)" for memory regions 0xC0000-0xFFFFF, it will be the final nail in the coffin for DOS. UEFI class 3 does not need that. Thanks to the world we now live that "unused" codes and logics shall be purged to reduce potential security attack surface. DOS would remain alive & kicking in another dimension, in the VMs.