45 Year Old DOS on a New Intel CPU Without Emulation
Вставка
- Опубліковано 7 вер 2024
- DOS can still run on Intel and AMD CPUs! How? It's the power of backwards compatibility with the x86 architecture. Since the days of Intel's original 8086 microprocessor, the x86 instruction set has certainly grown, but those old 16-bit instructions from the 80s are still supported by even the latest CPUs released by Intel and AMD. So what does it take to get DOS running a brand-new CPU? Merely a boot disk and a BIOS that has legacy support. Even the first version of PC-DOS for the IBM PC (1981) still works fine, just no BASIC available.
I'm looking forward to ARM and RISC-V competition, but the x86 architecture is still the king today, and it doesn't seem like there is any real competition, at least in the desktop PC space.
Special thanks to IceWhale Tech for sending over their ZimaBlade single board computer. You can check their board out below:
ZimaBlade Official Shop: bit.ly/4cKwZ4y
ZimaBlade on Amazon: amzn.to/3LzV4Pw
ZimaBlade Personal NAS: bit.ly/4dbg6Qa
Sources:
1980s PC sales: en.wikipedia.o...
x86 Operating Modes: en.wikipedia.o...
Rufus boot disk maker: rufus.ie/en/
UNebootin boot disk maker (used to create the PC-DOS boot disk): unetbootin.git...
PC-DOS disk: www.pcjs.org/s...
x86-S: hackaday.com/2...
Interesting article about FreeDOS: arstechnica.co...
You may think you chose the 'No sound' option for Doom, but I could still hear every sound effect perfectly....
I can hear the Doom sounds even while I'm reading your comment. :-)
I heard it to, I forgot he had no sound and I swore there was Dooms original sound in it till I saw your comment. Replayed and sure enough no Doom sounds just some other background noise.
@@chrism3784 me too, same thing.
I once managed to run FreeDOS on a Xeon E-2224 machine just for fun. So yeah, it’s totally possible
idk what's surprising about it
all these CPUs are compatible with their instruction sets
most x86-64 CPUs should work just fine as long as they only use the common instructions and avoid newer specialized instructions
And a lot of laptops that are sold without a windows license come with a functional freedos installed
@agladkyi FreeDOS does have more modern extended memory drivers too?
FreeDOS does not share any code with MS-DOS or older DOS systems. FreeDOS was fully made to support both newer and older hardware, which kinda makes it less impressive. It's still cool though
FreeDOS is not an old OS, and of course it is not MS-DOS
memes aside, the ability to run legacy software is key to a lot of infrastructure
Most have 0 clue...😂
And let's not forget just how long a legacy software can have! There are grandparents around today who are younger than the software being used by big banks.
I'm finding Starglider a bit hard to play, though...
Beat me to it by several weeks. I've worked in places that run very expensive manufacturing equipment that, at its core, is running some old version of DOS, plus proprietary software to run the machine. If that old processor goes out, they will spend the money to put another processor in, not replace a piece of equipment with a six- or seven-digit price tag.
@TheRealScooterGuy the oilfield is that way also I've seen some pre pc stuff still run and state of the art right next to it...its kinda cool to see tbh
6:16 no, it doesn't waste space, this is a myth.
Because the chip runs microcode and the actual architecture is very different than an actual 8086. It only wastes a bit of ROM for a couple of instructions, that's almost nothing, most of the space goes to cache, but there are plenty of space for smaller things like a fixed ROM made out of simple diodes.
The old instructions can be perfectly emulated/interpreted on modern hardware by newer CPUs without wasting any extra space for any logic via the microcode mechanism. There's absolute no reason to remove them.
The source for this is Jim Keller, he said that.
And just as importantly, even if it wasn't, putting an entire 386 (275,000 transistors) on a modern CPU (with _billions_ of transistors) barely even qualifies as a rounding error.
I am on an Android tablet with an ARM CPU/no FPU and a DosBox app installed and the emulation of 80386/80387 CPU/FPU works good. But i miss a graphic emulation of a VBE 3 bios. The svga-S3 emulation have only a mixture of VBE1.?/VBE 2 bios and not many mode numbers for higher resolutions. On my last DOS PC i used a Radeon 7950 PCIe card with VBE 3 bios with mode number for wide screen 16: 10 aspect ratio 1920x1200x32 resolution on 28" LCD.
It is wasted space, but not in terms of silicon space. Many modern x86 instructions rely on VEX or REX prefixes to be recognized, while many of the original 1-byte 8086 instructions are all but completely deprecated (looking at you, x87). Simple coding theory would tell you that this is a wasteful encoding scheme. It wastes the abstract 'code space' for the instructions, which in turn makes the instructions longer, which wastes the precious L1 instruction cache. CISC instruction sets are often credited as having better encoding efficiency, but this waste is so significant that RISC-V with C extension would often beat x86-64 in code density.
Agreed. The x64 registers are mostly 64-bit versions of the 32-bit registers, which are 32-bit version of 16-bit registers. This also means the operations on 16-bit will often have a 64-bit version. For the most part (there's always edge cases in computing), you can just use 16 bits or 32 bits of the 64-bit register very similarly. The operation of something like ADD is going to be very similar whether it's done in 16-bit vs 64-bit
Jim Keller also mentioned that they don't need to optimize every single part of the CPU, just the parts that people mostly use. A Ryzen CPU will already be ridiculous for decades-old 16-bit DOS programs.
@@throwaway6478 _Barely even qualifies_ as a rounding error? I'd say proportionally, it's so small the appropriate phrase would be "doesn't even qualify". If you're dealing with several billion in total, anything less than several million might as well be free. You'd probably have to get up to the Pentium before you hit "rounding error" territory.
RIP OS/2 compatibility in x86-64 processors
This is news to me. I knew early Ryzens had trouble running it, but it was errata that was fixed in the AF revisions.
@@throwaway6478 64-bit long mode only has two of the four rings needed to run OS/2, which makes even emulation/virtualization difficult
@@AmaroqStarwindGood thing OS/2 doesn't run in 64-bit long mode then. It's a 32-bit protected mode (retroactively named "legacy mode" in the AMD64 docs) OS, with all 4 rings at your disposal. I suspect you're mixing this up with Intel's monstrous x64-S proposal, which _won't_ have IOPLs 1 and 2 at the hardware level, by "virtue" of not having a legacy mode - but nothing will stop you emulating it with a sufficiently-intelligent hypervisor if you _must_ run it on one of these unnecessarily-crippled CPUs.
@@throwaway6478 It also makes some of OS/2’s functionality harder to replicate for future operating systems.
@@AmaroqStarwindThat I can agree with - but as I said, nothing that a sufficiently-advanced hypervisor won't fix.
Dos is fully usable on new hardware, but when you start getting into drivers, you run into problems. Same with old windows versions. In most cases you wont have drivers at all, unless random people online chose to write new ones for the more commonly used parts. AC97 for example. Every computer I've built within the past 30 years has internal AC97 sound. If there isn't a driver for DOS yet, someone should have worked on it at some point.
There is SBEMU which allows you to emulate sound blaster on AC97. I've tested it on my own PC running FreeDOS and it works great!
Only if your BIOS/uEFI firmware still have legacy mode or the BIOS interrupts needed by DOS.
2 of my laptops cant run anything before protected mode. (and even then, it causes issues)
@@parad0xheart FreeDOS is the way to go. It doesnt rely on the old calls from BIOS and there are plenty of soft/emu solutions for almost anything.
Still, to play around i prefer using PCEmu emulating hardware i had long ago. Its kinda weird 🙃
@@parad0xheart My newest motherboard I bought last year came with AC97
Some BIOSES have native AC97 support
You don't need a ROM BASIC chip to run BASIC programs, you just need a local BASIC interpreter like Q-Basic or GW-Basic.
for IBM DOS 1.0 it needed the ROM BASIC.
Backward compatibility just pays for itself in so many ways. Old software has tremendous value.
As someone born in 1981and grew up playing games on a friends 386 and later 486, this is SO cool!
Thank you for the trip down memory lane
In 80s, I have handled equipment that were programmed in CP/M but it was fun. Once a REAL kid, on a freeDOS forum, told me that he finds it interesting that an old man wants to know internals of DOS
The backwards compatibility makes x86 processors always definitive. x86 users aren't missing out on MMX, SSE, and SSE2, even when they get the latest processor.
Except when they are (AVX512), but yeah.
@@lordofhyphens There's always ways to detect whether it's supported. And a compatibility hierarchy is maintained, with processors supporting SSE2 implicitly supporting SSE, which in turn is implicitly supporting MMX as well, which implicitly is supporting x87.
It definitely helps that all x64 CPUs are required to implement SSE2.
Don’t forget about x87 floating-point math.
@@MaddTheSane Can you use x87 in Long Mode? Or only in 32-bit processes?
I love that we've come full circle and gotten doom to run on a computer
Brilliant. This kind of stuff shows how we walk on the shoulders of giants whenever we do anything with computing.
What's cool: you can easily get MS-DOS to boot into any other program by creating an Autoexec.bat file. You can even make a simple menu, to let the user select what program they'd like to use.
Setting programs to load on boot with autoexec.bat was fun as an 8 year old kid.
Intel will never be able to rid the older x86 instructions simply because the commercial/industrial scape wont allow it for at least another 20 years or so.
Perhaps to rid completely.. But they can create a series of chips without the older instruction set for datacenter/scientific use. And then keep a gaming/consumer chip with all compatibility.
In 20 years i hope to see RiscV as the main architecture.
I don't know, they went UEFI-only (that is, removed CSM support) with a bit of wailing and gnashing of teeth, but no actual impact to their bottom line (which is what really matters - revealed preference and all that).
not quite how it works, nor is there any particular reason to want to get rid of x86 instructions. There have been many sort of "replace PC with THIS!" type projects that have come and gone through the years, and they do not fall on anything relating to industrial anything or what I think you mean by commercial.
They have no software, hardware or users. Boom. They offer nothing that the x86 PC's don't already do well enough for it to be a non-issue. There are plenty of single use type computers out there though, but the fun bit is even they are mostly x86 because standards and IDE's, plus of course support base, name recognition and so on forth, but primarily device add-on standards and IDE's and to a large degree code portability.
We humans make everything to fit hands. Hands are the standard. There are alternatives that might be better suited for some purposes, but we won't genetically select for them. Think about it---
@@IvnSoft They did. It was called Itanium. Note my use of "was" past tense. Look it up 😉
going UEFI-only is on the system manufacturers and the firmwares they use, not on the CPU manufacturers
the CPU couldn't give less of a damn about what firmware it runs on startup, be it a traditional BIOS or UEFI with CSM or without
2:22 saying this while intel CPUs are literally cooking themselves to death is wild!
intel cpus literally rebelling against the concept of existing in a functional state
AKA how to run classic Doom at 35,000 frames per second.
It's actually capped at 35.
Doom has FPS limit at 35 FPS.
But, Doom benchmark not! Doom benchmark is actually uncapped.
Once upon a time, editorials were published complaining that the latest x86 chips were "code museums" wasting much of their transistors to support backward compatibility.
Today, the _vast_ majority of the complexity is the logistics of dealing with superscalar and out-of-order execution, with a surprisingly small part of it being the Execution Ports that do the actual work, and a tiny sliver being the front-end that parses the instruction set. So today, supporting old instructions is not significant; the entire chip is abstracted away from the published instruction set anyway.
We need an i7-8086K running DOS!
I am not sure if it is possible to start with an UEFI bios in 64 bit mode and graphic mode to load an IBM compatible bios from a file into the memory and then switch into 16 bit mode and in text mode to boot MS DOS. I don’t know if an IBM compatible bios is compatible for the mainboard function of those mainboards without UEFI. The intel i7 architecture and the graphic cards can switch to 16 bit and text mode. But the problem is the missing IBM compatible bios.
Can someone get on this ASAP.
I recall fondly my first PC. A Philips 80286 with 1MB of RAM and 14" colour display. I used the keyboard of that computer until 2023 when the left shift key finally gave up.
If it is mechanical keyboard, switch can be replaced (separatelly).
In 286 times, most of keyboards were expensive and mechanical.
Just dont throw up mechanical keyboard, it can be almost always fixed to (almost) 100% state.
I consider myself fortunate to have seen, and worked on, computer technology from the 70s. 8in floppy disk, 9.6kbps data rate, punch cards, DEC/VAX minicomputers, PC DOS, CGA graphics, OS/2, IBM super mainframes and all the way to current state-of-the art gaming rigs. My home is connected to gigabit fiber which would have been unthinkable just a couple of decades ago. Such great memories!
It looks like at least two things are needed for a modern intel based or amd based computer to run old MSDOS. One thing is the computer needs to have a legacy bios mode available in its firmware and a legacy boot mode available in its firmware. Also the graphics card will need to have a legacy mode that it can be enabled. It is amazing that this backwards compatibility has been maintained for so long. Especially with planned obsolescence of so many items.
Planned obsolescence is a hoax. ¯\_(ツ)_/¯
There's no money in removing it.
@@demonmonsterdave
Removing it doesn't generate money. Correct. But.
Removing it will save a lot of money in design time and less rate of defective chips.
That being said, the reason they decided to keep it because backward compatibility was proven to be a big boost in sale. IBM became the top dog in the industry for several decades because of it.
@@gorilladisco9108 That being said, it is what it is, having said that, to be honest.
It's how Microsoft enforced it's monopoly. Intel's not a monopoly, but still can be "anticompetitive". As long as there's a substantial segment that demands backward compatibility, it pays to cater to them. When they don't, it gives purchasers more incentive to go to another vendor. For example, if you don't need Win32, you might as well get ARM, and maybe get an ARM Chromebook. They would rather you not do that!
"Quite literally everyone and his dog had an IBM PC" Um...most people from 1982-1992 did not have a home computer and had little reason to spend the money on one. In 1990 for instance, only 15% of households had a computer.
Yeah, and most people who did have home computers during that time had 8-bit machines from companies like Commodore, Tandy, Atari, or Apple. Or TI if they were unlucky.
That said, if you had a computer at work during that time period, it was probably a PC.
@@jeffspaulding9834 28.1% of the adult population, reported they
use a computer either at home, at work, or at school in 1989. As I remember, a lot of people at the time, who had PCs at work, bought a "clone" and pirated a lot of the software, particularly word processors and spreadsheets. I'm pretty sure Microsoft made this pat of their marketing plan. There was a lot less hassle about copying apps back then, and I think it was on purpose, to achieve monopoly power.
@@squirlmy An IBM PC back in those days would set you back at least a couple grand (in 80s money) for a minimal system. A "complete" system would cost you closer to $4-6k. Clones were usually cheaper, but the price point was still way above what you'd see on an 8-bit model like the Commodore.
Back in the 80s I knew several people with 8-bit machines, but only two with PCs (my family had one for my step father's work). Software was readily available at your nearest mall, and the PC section was fairly small (and mostly focused on business apps). Magazines like BYTE catered mostly to the 8-bit user. It didn't help that the graphics on the PC were horrible - tiny, expensive, usually monochrome monitors. Many of the 8-bit machines had color and could use a TV for a monitor. Because of this, you saw a ton of games for the 8-bit machines, which also appealed to the home user.
It really wasn't until the 486 era that the PC really took off for home users. By that time the prices had come down, graphics had improved, more games were available, and more people were using them at work with programs that required more than 64k.
(Edit: typo)
You bought a NAS to play Doom..... I approve 😆
Side note: Meanwhile Mac users have been forced into emulation to enjoy anything made before 2007. Kind of a shame, all my favorite games growing up rely on PowerPC architecture ☹️
Edit: Antonyms are fun! 😀
don't you mean made BEFORE 2007?
You might be able to shoehorn macOS into running on the IBM power series of servers that use a ppc architecture to this day, but the driver situation will likely be a nightmare
Before 2007 and also before 2021, Apple changed from x86 to ARM since then.
@@Pwnz0rServer2009 Welp, teach me not to comment on 6 hours of sleep 😆
@@oggilein1also the wii u is ppc!....then again i dont think its worth the hassle to make it run actual pc software seen as its pretty much just wii but more wii😭
My PC might still be able to run DOS, but it also sadly fails at Windows 95, as it's way too fast, which makes the (unpatched) security code fail horribly. 😉
And even if you can technically get it to run, it's unlikely you'll find drivers for most of your hardware
@@CaptainSouthbird pcie to pci adapter, modern motherboards with isa slots:
@@randomgamingin144p It'd be a waste of money and kind of silly to do that, but it sounds like exactly the kind of thing I would do just for the fun of it. I once forced a 2006-ish laptop to run Windows 98 including adding a compatible soundcard on a breakout board from its ExpressCard slot and wired in a voltage regulator to pump the otherwise missing 12V into the bus. It did work! And it was completely stupid, but that's beside the point.
Realistically though, if you really want to run Windows 95, there's practically unlimited choice of various Pentium clone machines on eBay. And even at the price levels, it might be cheaper to just buy period-correct hardware than one of these specialized adapters plus requisite hardware. Whereas you could spend somewhere around $75-$200 and just get a whole period system suited for the task directly. And be way less "messy."
Or, of course, just run a VM and be done with it.
It's fine to install patch. I wonder why UA-cam deletes comments with its name however.
VMWare Workstation must inject delays to make Windows 95 work.
I'm impressed you didn't have any speed problems with these old games. I don't know when they started programming the games to use timers rather than just clock cycles, but I remember a few times in the 90s when I used a pentium to play286 games and they were crazy fast. Cool Vid
I love your vid! Gives me real old school vibes. This is also quite fascinating to me, I remember running Windows 98 SE on a 2012 Ivy Lake Laptop, but I would never thought that something as recent as a 2016 Intel CPU would be able to run an Operating System as old as DOS!
I would love to see compilers do more work than CPU.
Stuff like branch prediction should be coded, tested, load registers based on results, and then executed. You can put other commands between these.
Also, the very time-consuming load indirect should be multiple commands.
These would decrease the complexity of the pipeline. There will still be latencies on cache misses, but the proper set of commands would reduce wait cycles.
Compilers attempt a lot of stuff like that.
When they're not trying to make rival cpu bench worse anyway
I think they tried that with Itanium, didn't went well. The compiler had to calculate precisely the latencies and put nops in the proper places, and even do the branch prediction.
@5:30 You're correct that the built-in BASIC is not available like it was back on those machines, but don't forget that you can (almost) always grab BASICA and BASICB and run those old basic programs by dropping those onto the system and using them to run 'em. On that note, QBASIC won't work with those much older basic applications, but BASICA and BASICB usually do the job when run with an OS that can run said BASICA and BASICB.
Nice video! If my own memory isn't faulty, BASIC was in the DOS directory, which should've been in the path, so not in ROM. I'm not sure if it came with PC-DOS, but I'm pretty sure it came with most versions of MS-DOS. Heck, even the C=64 came with a version of Microsoft BASIC. You forgot Cyrix as a competitor, but I suppose that's a subject for another video.
Intel is planning to make x86 64bit only architecture through x86-S specification
x86-S supports 32-bit apps but not 32-bit kernels. It also removes stuff like ring 1 and 2 (which almost nobody used)
@@sundhaug92 The should have done it years ago... there is a ton of legacy stuff that can be removed, also it would simplify the boot process and the operating systems (basically because the OS doesn't have to start from a 16bit real mode and setup all the stuff to get to 64 bit mode).
@@alerighiyeah, removing that tiny bit of code that is already written and working will save so much. I also bet that removing the old instructions will save hundreds of transistors.
@@alerighi You'd be surprised how many niche things still depend on 32-bit kernels. Also, modern kernels don't have to start in 16-bit, either because the bootloader gets them up to that point or because of UEFI
@@harrkev removing old instructions won't save transistors because they're just microcode in the ROM, it'll save a couple of diodes, no reason to do that.
they could remove the real mode because that can be emulated in user-mode by the operating system.
EPIC
love how much youve grown since ive been subbed for a long time
Of course ARM CPUs have a long and storied heritage of their own, and if you get the right arm single board computer you can even run the original RISCOS -originally designed by acorn computers for use in their first generation ARM workstations.
A lot of new laptops don't have any CSM mode so you can't run DOS at all...Soon desktops won't have it either.
I'm at an impass on your comment:
1) I like it because you are correct.
2) I absolutely hate it because you are correct.
This a bit of a pick, but;
Love how the mic quality has gotten progressively worse
soon it'll be period correct
It's running dos.
oh, hey koutsie. fancy seeing you again
0:31 may i have the movie in the background please thx
USB floppy drives are bootable so long as the device can boot from that USB port, and WAAAAAY faster than the floppy interface.
DOOM is what I still use a DOS P4-3GHz for. With ISA slots.
haven't you run into incompatibilities with the usb floppy drives? And more specifically modern ones, not the few IBM and other big makers put out back in the day. I was really shocked at the poor construction and lack of support. Maybe if all you do is boot FreeDOS it's all right. Actually moving data and updating firmware is a nightmare.
There are LGA1700 platform boards that take Alder Lake or Raptor Lake cpus that have a PCI slot. And it's possible on some motherboards to break out a fully functional ISA bus over the TPM connector. So you know what that means right?
PCI-e can easily use PCI cards via adapters too
@@AshBashVids motherboard still has to support DDMA if you want PCM sound over the PCI bus under dos, alot of boards with PCI slots don't, but then you find one that does and its golden, usually industrial boards today.
i think it's done through the lpc header, if the board is old enough, not the tpm. but even so, on one point in time and later, the way dma and irqs are handled by these ports (a.k.a the chipset), has fundamentaly changed, so dos sound etc. cannot work even if you managed to breakout an isa slot. you cannot use pci because it works completely different.
@@giornikitop5373 TheRasteri got it working, but I don't think every board may still have the full ISA protocol intact.
@@tek_lynx4225 More thinking if you want to use a Voodoo card. You can get sound working via ISA if you have a TPM/LPC header.
You don’t need basic in rom. You need a program to load the files into. Gwbasic. Qbasic etc
He was talking about BASIC which was originally present in PC DOS.
Of course, it is possible to use versions, which don't rely on ROM code.
Hi. Great video! Another use for single board computers like this is to run lightweight Linux distributions such as DietPi. You could even use Batocera as well!
I still use DOS regularly for data recovery and other low level stuff. DOS is still used in niche applications to this very day.
This is a big reason why I'm a bit of an x86 fanboy. Yes, the syntax for x86 asm is bad, but it's rare to write x86 by hand anymore. The compatibility is beautiful. I often bring up embedded ARM systems(usually zynq or zynqmp) and specifying devices in device trees, configuring u-boot is tiresome. This is why for instance with OpenWRT you see one build for x86 and 50 others for variants of ARM/MIPS devices.
Yeah compatibility is truly it's superpower, and by the looks of it AMD is getting even more serious about power efficiency with Strix and Intel is with Lunar Lake. There's lots of doomsaying about x86 but if history as proven anything it is one of, if not the most, adaptable architecture in history and clever engineers always find a way to break the mold with it.
The x86 _does not_ have backwards compatibility with the 8080 and it's derivatives (the 8085 and z80). Instead, it has a sufficiently similar opcode set that relatively simple binary translation is _almost_ the entirety of what's needed to move from 8080 to x86.
standardization is the only key to success on everything . this is the only reason why we still have pcs that work and make the world go round
How did you solve the problem of old games running too fast?
modern processors are optimized for 64bit instructions
@@yuan.pingchen3056 🤦♀️
Did you even watch the video?!
@@yuan.pingchen3056 BOT detected, opinion rejected!
Turbo button.
The underclocking of a lifetime.
It's good that Intel has such backwards compatibility. And with increasingly faster and more powerful processors, there really shouldn't be *that* much wasted space for such compatibility. And it's better than Microsoft's lack of backwards compatibility for DOS and 16-bit Windows programs.
Corncob 3D was my favorite shareware game before I discovered Descent.
Thanks for the fun video. I actually used to use dos 1 and over time about 12 versions on those old chips.
the backwards compatibility is not just for the sake of running DOS the 16 bit real mode is also when the CPU and bios communicate with each other and the BIOS then builds the tables and charts that windows will read to grab all the details of all attached devices pci cards etc. Hardware we really only understand in 16bit real mode or at least its best to talk to it in that way because of simplicity during commands the 2 wire serial interface near cmos can be used to issue commands to the BIOS during 16bit real mode on bootup meaning you can adjust registers and modify read/writable bits while in the 16 bit real mode. You can also do it in 64 bit mode but the bitness changes and so do alot of the addresses. I like to poke around with hardware probing tools like R/W everything and etc. Also why most drivers are written in low level languages to maximize speed effeciency when polling hardware devices along the PCI/USB/sata bus. You essentially could run 16 bit programs by pointing to them or by switching hardware registers to correlate to the required cpu execution model meaning you can run programs directly from bios theoretically ive never tried it but interesting to experiment with. Can also probe the clock generator on alot of motherboards and get back pure hexadecimal data giving you details of the Clock gen allowing you to overclock and change usually non accessible settings sometimes chips are internally write protected and theres no way to modify the signals without messing with the continuity of the wire leading to write protection pin on the chip.
There is a big difference. In old days, DOS PC's allways ask date and time setting when device power on. There was no RTC batarie and memory.
I use DosBox on android and it have no date and no time command.😂
@@maxmuster7003 It was 1980s 8088, 8086 HW, when i were at Unv. Not later . ;)
@@aligokcen5908 For an 80286 mainboard i used a floppy disk with a bios setup programm to enable the devices like hdd, because the mainboard have no setup on a bios chip.
Some instructions have been removed, for example intel removed some AVX-support over time (because they couldn't fit it in their efficiency-cores) while AMD made their equivalent cores more efficient by removing cache etc
The earliest versions of Intels processors supported AVX on the Performance cores but not the E-cores. I think it had to be disabled/removed due to complications with the OS level scheduler lacking the softistication to run threads which require AVX on P-cores only.
In 16 bit mode of MS DOS we can use 64 bit MMX instructions and 64 bit SSE instructions, but not AVX.
Intel microprocessor started with "real mode" at boot up. In Windows, it then followed by switching to "protected mode". The "protected mode" is the working environment for Windows. In DOS, it stayed at "real mode" (DOS was made before Intel had any idea about "protected mode").
In essence, DOS can still run in i9 computers, but it's confined to the 1 MB memory. Additional drivers can be used to reach the rest of the memory space, but it will always use in a swap mechanism.
Intel is quietly working to drop 16-bit and 32-bit compatibility from future processors, which will let them squeeze out more performance in future chips. So, this is a feature that probably won't last another decade.
We will see which DosBox emulation works faster on ARM or newest 64 bit intel. 😂
Some TPM ports can be used to effectively get a legacy ISA socket. Saw a legacy sound card attached to a semi-modern machine by this method.
That's exactly why I believe that DOS is the innate operating system of the x86 architecture
The Last Ninja was a Commodore 64 game and it looks better with the original colors than EGA colors.
Actually I was mostly running ARM in the 1990s after running mostly 6502 in the 1980s. The ARM back then was mostly backwards compatible with the 6502 in a number of ways mostly because of how it came about though the RISC structure of the ARM did eventually make this somewhat harder to do. Of course ARM has come a long way since those days...
So NO, not all of us went overboard for 8086 back then.
ARM chips are still almost compatible with the Acorn Risc Machines (ARM) 1 processor that was shipped with the Acord Archimedes home computer which shipped in 1987. Any Raspberry Pi can boot its own port RiscOS which shipped with the Acorn Archimedes. This includes an ARM version of BBC Basic.
My school bought a Heathkit H8 (8080). kit. No one would assemble it so i did over a few weeks. Still in tech pushing 70. That BIOS.
Running WordStar or WordPerfect should be able to keep up with typing speed. No virus checking or dozens of background processes causing little pauses, important for music production. Software back then was usually sold outright with a key, not annual licences.
... which was then pirated 😅
I have a fractal generator program I wrote myself back in the day that should run entirely from L1 cache (at like 1,000 times faster than it did back in the day).
If you program (or just even look at assembly after using a high-level language) it’s pretty clear with the instructions about what it runs in.
I use Quick-Basic and x86 assembly, but nothing else.
I used to play The Last Ninja on the Wii as a kid, thanks for bringing up a good memory!
going by the few guys who talk about how the CPU is physically put together there is no reason to get rid of the older instructions. The part of a picosecond you would save by doing so will not matter when compared to the other picoseconds taken by the rest of the chip. Yes picoseconds as it is all inside a very fast part of the chip.
Maybe when 20MHz was considered "fast" removing an instruction would be a thing that will show some benefit. Now that base speeds on the lower end chips are over 3000MHz removing instructions will just break backwards compatibility for no speed up as the possible speed up will be taken away when you get to the memory controller as CPU cache misses are common with multi tasking.
Being able to run DOS 1.0 or even older software written for x86 is just a forgotten or unknown benefit of staying on the same instruction set for so long. It also helps or helped with the compilers used for devlopment of the newer software now that everything is and has been basically the same for the past 7 to 10 years in CPUs. Nothing really added that you can bank on the majority of consumers having and both AMD and Intel supporting the same instructions. So the binaries are made for a 2009 CPU even for windows software made in 2024 as unless it is a console the programmer will not know what CPU the end user will have. Windows 11 is kind of forcing everyone to get a new machine so setting the profile for a 2018 CPU would be a good bet on what most end users will have or a newer one. At least in 2025 yes people upgrade that slowly that it will take 14 years for developers to feel safe changing the settings in their programs to one that is still older than current year.
The timer chip for PC Speaker sound is probably implemented as part of the chipset. Whether the output of channel 2 is connected to the audio output is another matter.
The cool kids got PCs with 8086, rather than the bottlenecked 8088. I had an Amstrad[!] with an 8086 and the full 640K of RAM. The good old days.
And any game that relies on the intrinsic CPU speed for timing (lazy programmers!) will be quite interesting to run.
It wasn't lazy programmers...well, it kind of wasy; but there is a very good reason programmers chose to use loops rather than the 8253 was the 8253 wasn't guarnteed to be on there. In fact, they couldn't count on any hardware being the same on any of the systems back then. Standards? There were none. No APIs. Don't forget this is an era where your verison of DOS had to be customized by the OEM because the standards for what a motherboard were didn't exist.
It was necessity. Using the 8253 would have limited the software to just IBM PCs and anyone who directly cloned it. By using "lowest common" methods, they ensured it worked on more hardware.
@@dewdude IBM didn't even name their ISA bus. It was later Compaq and a group of clone makers retroactively named it, along with their future plans for E-ISA (which soon gave way to PCI)
Yay! Guess time to mod my PC now!
The Surprising part to me was the speed it was running at. I have seen DOS games go absolutely BONKERS speed wise on even 20 year old CPUs. That looked stable and NOT running at warp 9.9999!
To be fair, he probaby used a slowdown TSR. They're pretty common (and pretty reliable) these days.
Luckily it just worked for me, probably more BIOS magic
Some games just seem to have been written in mind with limiting the runtime speed based on fps.
Slight tangent: on a different platform (Sega Mega Drive), the game Sonic the Hedgehog ran slightly slower in regions using 50Hz AC mains current, compared to 60Hz regions such as USA. The game's code was designed to sync with this frequency.
This meant that for some of us, we experienced Sonic at about 5/6 as fast as it was meant to be, and at the time we had no idea.
Very last line *chefs kiss*
🤣
That Doom install screen was nostalgia
You never needed to emulate anything to run Doom, they distributed the source code, which is why it can run on anything
Great stuff. Funny bit about the missing floppy. 🤣 Strictly speaking, saying DOS provides a HAL isn't correct. A HAL is an internal OS layer meant to support porting it across more than one processor architecture. DOS, of course, is a one-trick pony. Windows NT was the first MS OS with a HAL.
IA-64 x86 compatibility was only 32-bit and never was a huge priority and it wasn't providing full compatibility. Intel at the time thought native IA-64 code would quickly obsolete x86 so putting a lot of engineering and die area on x86-compatibility would be wrong. Meanwhile AMD did their x86-64 thing and the markted decided. One of the early adopers of x86-64 was the Linux community which at the time did support several other 64-bit architectures including Alpha, SPARC64, MIPS, PPC64 so x86-64 was really just a formality. IA-64 has some niche success with supercomputing or highly available systems (IA-64 did support master-checker afair) - not enough to tip the scale in favor of Intel.
don't forget Itanium was created by Hewlett-Packard. Intel only joined in development later. And HP took a pretty big hit financially from the failure. I don't think the Linux community was even a factor, because they ported to everything, they would adapt to any 64-bit tech as you note yourself. A big factor was costs. It cost the market (as a whole) a lot less to hold on to Win32 and be discretionary about what to software to port(and/or buy) to 64-bit. Yes the market decided, but it was short term (maybe even quarterly) budgets vs upfront costs for moving to an entirely new architecture.
@@squirlmy The Linux community in that case was a whole bunch of companies including HP, Intel, SGI and others plus various Linux vendors, the usual suspects including smaller ones such as Turbolinux and contractors. SGI was among those early adapters because they wanted to get rid of their inhouse processor development. Which arguably is what IA-64 did best - it resulted in the end of the Alpha, HPPA aka PA-RISC and the high-end variants of MIPS. SGI's traditional customerbase controls their own software which was already running on 64-bit. So the 32-bit compatibility was never much of interest. In In fact due to memory size 32-bit was no practical option even back then. Afair the first SGI Itanium system had 64-bit processors. HP's customer base was probably to a large degree identical so I don't think they had much interest in 32-bit either. Intel was making a bunch of IA-64 systems such as the Big Sur but I'm not sure if they were ever planning to become a big mainboard or system vendor. Microsoft and IA-64 was an entirely different matter.
Yes, the market did decide. Itanic took Intel a lot longer to finish development than they were planning for. At the same time Itanium 2 aka McKinley's was looking like it was going to be a faster processor than promised and arriving earlier. SGI eventually decided to cancel their Merced product in favor of the McKinley. Which however meant their first IA-64 product was being delayed yet again. Meanwhile AMD's x86-64 was looking much more promising and became available on the mass market at interesting prices.
This left a few niche markets for McKinley-based systems. Floating-point-heavy applications did tremendously gain. Also initially systems with massive I/O and memory were better off with McKinley than x86-64 since the heavy hitters HP and SGI had been working on them. Another niche was HP's Tandem division. Tandem was building fault tolerant systems. The sorts that doesn't crash only because you yank out a few parts or is hit by the death star. Tandem was using MIPS; an attempted migration to Alpha had failed so eventually they migrated to Itanium. Meanwhile there was no support in x86-32 / x86-64 for that sort of fault tolerance, so they were stuck with Itanium for a long time.
These were niches. x86-64 was meanwhile selling like fresh rolls. By the time Windows Vista, the first version of Windows with 64-bit support out of the box hit the market, x86-64 was already widespread.
What also helped selling x86-64 was that it was a better architecture design than the i386 aka IA-32 architecture. For every other architecture 64-bit code was running slower than 32-bit because it was bigger resulting in a lower cache hit rate. Not in case of x86-64.
Meanwhile Intel themselves appeared to have lost interest in IA-64 a bit. I think one reason was also that IA-64's EPIC (remember EPIC is the new VLIW ...) was hard to efficiently generate code for. That issue held compilers back; the actually achieved performance of compiled code was well less than what the hardware actually was capable of. And some features of the IA-64 such a giant register sets and register windows made for inherently large dies and complicated designs without achieving the original design goals. Then the unimaginable happened, Intel took an x86-64 license, had to catch up with AMD's x86-64 implementation and at the same time had that boat anchor IA-64 tied around their neck which they couldn't drop because they already had a customers.
Many believed Z80 production would never end, but it did.
x86 production will also end some day.
i don’t remember subscribing but i sure am glad i did, this is so interesting
The newest PC have an UEFI-Bios and starts in 64 bit mode. Only a few not so new mainboard have in IBM compatible bios and starts in 16 bit mode. Like asus striker mainboard for intel core2 CPU.
Apple gave up backward compatibility in hardware when they switched from 68000 to PPC, from PPC to x86_64, and from x86_64 to ARM. They gave up software backward compatibility when they switched from macOS classic to MacOS X and partially when they gave up on supporting 32 bit software in macOS altogether. That's one of the things I truly love about Apple. They step forwards, cut off old tails, get rid of legacy crap. There's always a smooth transition (macOS classic could run on MacOS X for quite a while, PPC code could run on x86_64 CPUs, and x86_64 code can currently run on ARM CPUs) but after a while they just move on.
If you truly want to run 45 year old software, just use an emulator. Not only can it emulate any hardware you like and hardware you cannot even buy anymore for ages, it can also fix issues that hardware had, it can make software even run better than on the original hardware. Some games today are way better playable in an emulator as they had ever been on true hardware.
Some people may think cutting off backward compatibility is a bad thing, but they would probably not think that way if they knew that x86 CPUs could be faster, more efficient, and cheaper today and Windows would be a lot smaller, more stable and less resource hungry if they only dropped a bit of backward compatibility at least once every decade. You are paying a high price for compatibility that 99.999% of all users will never ever have any use for. Quite often the answer to "Can we do that?" is "Sure we could do that and it would be awesome but it would also break backward compatibility, so unfortunately no, we cannot do that". That happen in software dev, that happens in hardware design and it happens all the time.
"That's one of the things I truly love about Apple. They step forwards, cut off old tails, get rid of legacy crap. "
... and their market share showed the result of such decision 😏
@@gorilladisco9108 Their market share has been constantly raising in the last 20 years and the main reason why not more people buy Apple products is the price and the fact that they cannot run their Windows programs on it but that has nothing to do with backward compatibility, as even if Apple was backward compatible to their systems 30 years ago, people could still not run their Windows software on it.
Nice idea to run DOS on a ZimaBlade. You got a new subscriber. I review ARM SBCs. Cheers.
As far as I know, the backwards comparability isn't that much of a deal. the x86 and x86_64 instructions are translated into even tinier micro instructions before they are send to the pipelines for out of order execution. So the 16 bit instructions aren't much more than a few additional entries in this translation table that is there anyway.
the problem lies more in the way the bit patterns form instructions, that make this translation less efficient. but to make it more efficient basically the whole ISA has to be reorganized... which would break a lot not just 16 bit mode
"Nothing says rebellion like x86." You a funny guy, says Charlie Chan.
Actually somewhere around the Nehalem Generation and with the availability of EFI1.0 (I have a Xeon Workstation from 2008 with EFI1.0, the predecessor to UEFI2.0 which we all use today) PC-CPUs did no longer start in 16Bit-mode but always in full 64Bit mode. You could force them to switch to 16Bit but that was about it. Besides that, all that old stuff, 16, 32, protected, real mode etcpp, uses around 100.000 bits of Microcode inside a current CPU. As modern CPUs have transistors in then 10ths of billions this is less 0,01% of the die-space.
And btw, around the Intel 10000 generation support for CSM/16Bit was dropped from pretty much any BIOS/UEFI. Finding Boards still supporting that is... hard.
"new" is questionable since you're running a 2016 chip. that said Skylake (which I think the N3450's Goldmont was based on) was the first CPU to begin trashing backwards compatibility. maybe Goldmont kept more of what Skylake dumped.
I ran dos on my laptop on bare metal back in 2014. I very very quickly discovered that I liked having USB drivers. Frankly dosbox on top of something modern will give you a better experience. Like, I can use my USB midi keyboard (which DOS would have no drivers for) as an audio output device for doom. Or a virtual synth like fluidsynth. If you want the games of yesteryear to survive, pin your hopes on emulation. It will give you a much better experience I swear…
You could probably flash the bios to use some empty space to store basic. As for USB support there are floppy emulators that register to the OS as a floppy drive. Lots of ways to make new things pretend to be old things.
well, that's one to describe that i'm old. 45 year old DOS
I love The Last Ninja but I prefer it on Commodore 64. You can't beat that SID chip soundtrack!
I'm still mourning the demise of the Motorola 68K architecture
I made some open source project using batch files as a container to create a new executable file with a little help from a special version of the debug command that provide 16 bit and 32 bit instructions. (Since 80386 we can use 32 bit instruction in DOS 16 bit mode too.) But i never test the projects on a real DOS PC, I use DosBox and one project with 800x600x32 is only made for a graphic card with S3 GPU. So hardware needed 80386 with svga graphic.
Since I was 11 in 2001 I remember a little bit more than two 3rds those days 16 bit instructions, I don't know how much 32 bit that I know but I wrote my own little OS, and of course if you booted my school floppy there was going to be a fire or some kind of plasma effect loaded. I once had a kind of worms clone put on the boot sector. Just for fun. I also got a 64 bit processor quite early but I kind of didn't learn much about the assembler instructions for them.
Technically most CSM legacy support is emulation. API emulation that is. They use a combination of small stubs with Virtualization, IOMMU and/or ACPI functions to create a classic Interrupt BIOS that calls the newer UEFI/ACPI functions. Because UEFI functions must run in either 32bit or 64bit mode, they do need to use a minimum of Virtual 8086 mode for a portion of their CPU-Side function.
It doesn't fully hide itself. If a DOS program traces down the calls it will see how they execute. They honestly won't care and will consider it like any other 32bit mode extended BIOS.
This basically makes it more in the family of the Wine Win32/Win64 stack or or CP/M for DOS stacks, than native stacks like WinPR and MinGW.
He seems blissfully unaware that PC-DOS did not need BASIC on disk because it was built-in on IBM's (ONLY). Clones used MS-DOS, which was NOT in ROM and had GW-BASIC (Gee Whiz Basic) on disk. IBM did offer BASICA (advanced BASIC) on disk.
Any PC compatible that HAD put IBM's BASIC in ROM would have been sued instantly. You can still be considered 100% compatible without having BASIC in ROM (which was pretty useless anyway since you need a DOS to store programs!). 🤡🤡🤡
You can write BASIC programs just by using the one supplied by the ROM, but you cannot save it. To do that, you'll need BASICA from PC-DOS, which added the capability to save the program.
ps. IBM BASIC was the default mode for "operating system not found" in IBM PC.
What's about Sound Driver, Networking driver, UEFI, TPM & Secure boot ?
lol, secure boot on DOS .
but Sound and Network might be doable.
_Sound Driver, Networking driver_
Actually surprisingly hard: there are no DOS drivers for modern sound or ethernet chips, and methods that "hack" an ISA and/or PCI slot into the system (to fit a more contemporary card) demonstrate how (for example) LPC is a very incomplete simulacrum of ISA, missing out - most crucially - DMA.
_UEFI_
UEFI, if viewed as an "operating system", is considerably larger and more capable that DOS ever was, but works completely differently, with most implementations running in protected mode, for example. Rewriting DOS (which, by today's standards, is a _very_ thin wrapper around the BIOS) to call down to UEFI instead of the BIOS would result in an OS so different from DOS, it might as well not be DOS anymore.
_TPM_
Interestingly enough, this is actually the easiest: a TPM is a native LPC device (or at least presents as one), which can be accessed through real mode with very little effort.
_Secure boot_
Goes hand-in-hand with the UEFI issues. Frankly, the simplest way to make DOS secure boot "aware" or "compatible" would be to chainload IO.SYS from a UEFI-aware bootloader of some kind, rather than modifying DOS.
..and don't forget that modern computers only boot from GPT. MBR is no longer supported. DOS is no longer possible. I guess he used Dosbox for the fake game videos. Even if he managed to run DOS on that old SBC, games with sound and graphics can't work. It's fake.
@@TT-pi8ww wdym PCs don't support a different disk structure?!
@@TT-pi8wwIt's a very rare computer that can only boot UEFI (certain very late-model Intel machines). Further, every machine I have that can UEFI boot can do it - get on this - from a MBR drive.
Makes me want to buy an IBM PC Jr. from ebay and relive my childhood.
1:05
Making up over 80% of all new home computers sold by 1989, well maybe in the US, but in the UK, the ZX Spectrum basically had the most HOME* marketshare during the 80's, with the C64 coming 2nd, then Atari STe/Amiga 500 3rd, with the PC bringing up the rear, Apple really WAS NOT A THING in the UK until 1997.
*Schools tended to have BBC Micro's/Acorn Archimedes before changing to PC's in the early-mid 90's
Backward compatibility is paramount for some old critical software in the military and in business.
6:12, well many of these old instructions are still well used today.
I see CMP, JMP, MOV, RET to name a few.
The problem is not being able to run DOS, it is that most of the time when you need to run DOS you need a true hardware 9 pin serial port 16650
The DOS is part of the problem, but that hardware serial port that the BIOS has programmed in it, and the speed of the CPU
Usually when you get over 300 MHz the software will crash because it was never written to work at that speed
The other big issue is slowing down the data rate of the COM port
The old machines had 9600 or 14400 but the device and the software don't handle much faster.
I program old two-way radios and it is a nightmare unless I have an old laptop with the first USB ports, and a hardware serial port and slow enough
A nice 486 or Pentium 60 megahertz that has a USB port is great.
I remember in the 90s having motherboards with USB header pins and no USB cable to add ports to the back.
And on the laptops that had a USB port, the only device available that was USB was a mouse.
I remember even in the late 90s, around 99 it was still almost impossible to find USB devices.
XP was the first time we saw USB keyboard and mouse and no PS2 ports
DELL was the one I dealt with all the time and I remember having to get PS2 to USB adapters or USB keyboards and mice.
Sadly, I have 3 computers, from 2016 all the way up to 2024. Oldest can't boot DOS, the newest can boot it but keyboard is running super fast (impossible to type), and the last computer renders flickering lines over the entire screen of DOOM and no keyboard working during gameplay (USB keyboard). Your video was correct over 10 years ago, but modern computers emulate in legacy mode, so it is an emulation still.
I've got a ~2015 computer that can actually run Win98 (as long as I use the Win 3.1 mouse driver). I'm guessing it's emulating a lot of peripherals, because USB drives show up as hard drives.
You need to have PS/2 keyboard emulation in bios
Now you just need a PCIe to PCI to ISA adapter to plug in a Sound Blaster 16. IIFC the TPMI (?) also has been used to get to ISA.
I had an old Intel Atom minilaptop, pretty useless for Windows today, gathering dust in a corner. I trashed the Windows installation and put FreeDOS in it. It works fine as a DOS machine, even with some stuff for original IBM CGA graphics from 80's.
Sometimes I wonder what number of 86 we'd be on nowadays.
By my reckoning, a 14th gen Intel processor would be a "2586". Here's my logic:
The Pentium was the P5 during development, and was going to be the 80586 until mere months before release, so 586. The Pentium Pro was the P6, so 686 (and it's ISA is often called that in source code). Pentium II was merely a slightly respun P-Pro, but I have no doubt Intel would have called it a 786. Pentium III was merely a slightly respun P2, but again Intel marketing would have ensured it was called the 886.
The Pentium 4 was radically different to anything before it, and definitely would have been the 986 as a result. The Pentium M was an interesting case, being a mobile processor, and not related to the "real" 986, but that wouldn't have stopped Intel from calling it the 986-SX or something. After that, the original Cores (not Core i[n], they came later) showed up. Core would have been 1086, and Intel would have made the Core 2 the 1186.
Then finally, along came Core i[n]s, and the original Nehalem would have been a 1286 (as long as you had a Super Duper Wowser VGA monitor). The Sandy Bridge second-gen 1386, Ivy Bridge third-gen 1486, Haswell fourth-gen 1586, and Intel would have called Broadwell (the obscure, stalled "fifth gen") and friends the 1686.
At this point, you can see the pattern that Core i[n] is just 1186+G*100 - 6th gen is 1786, 7th gen is 1886, 8th gen is 1986. Add 600 to get to 14th gen, and you get 2586. For extra marketing giggles, they could have called Celerons [nn]86SXs, i3s [nn]86DXs, i5s [nn]86DX2s, i7s [nn]86DX3s, and i7s [nn]86DX4s. A Core i5 11600K, as such, would be a 2286DX2-3900.
I don't know what Intel would have numbered their embedded x86 processors, but Intel (and Motorola - everyone in fact) would add or subtract a random value, or suffix for their embedded/microcontroller versions' names. The early Atoms are a fairly cut-and-dry case though: it arrived via the Stealy microarchitecture, which in turn was a modified Pentium M. As such, the original Silverthorne Atoms (from before they evolved into cut-down Cores) would have probably been the 1096 (add 10), the 1076 (minus 10) or perhaps the 1086EX.
Anyway, thanks for reading my blog. Don't forget to like and unsubscribe, and berate me on Hatreon. 😁
@@throwaway6478 I love this! You did the math I was too lazy to figure out. Thanks!