We were writing 32 bit DOS games in the early 90s. We handled graphics bank switching using what they call a bimodal interrupt where we would reflect the IRQ to/from protected and real mode. We treated the video memory as linear using this technique (we'd do the bank switching during the IRQ). In fact, VESA later used this technique, so did Windows Game SDK and DirectX..
this is one of two holy grails of DOS programming, one being this protected mode programming with DOS extenders, the other being SVGA-VESA-VDE graphics programming so that games can have 640x480 screen with more than 256 colors.. please tell more about the later
Computer Chronicles was an AMAZING show. Wish I lived near the Bay Area to see it growing up. Watched every archive which documents beautifully the infancy of technology age.
Well, with 16 million colours and 24-bit colour depth, resoulutions of 1600x1200, multi-media and such in the early 1990s, calling it the "infancy of technology age" is a bit of a stretch. If you talk about the earlier, 80s episodes, you are right, but people under-estimate the ability of e.g. Windows NT because most people used archaic DOS programs and, obviously, games.
@@Zedek To run Windows NT 3.1 in a usable form you need about 16 MiB of RAM. That was very expensive in 1993. For have a 24 bit color depth at a resolution of 1600x1200 you need a SVGA card with at least 6 MiB of RAM. In 1993 this cards had usually about 1 to 2 MiB VRAM, thus not enough for these resolutions. The rule was the same, memory was very expensive. And a computer monitor that could run at a resolution of 1600x1200 pixels and 70 Hz was also very expensive in the upper price range. For 70 Hz you also needed a video card with a very fast RAMDAC, most videocards were not able to supply at that time. In 1995 i upgraded my 486DX 33 MHz from 4 MiB of RAM to 8 MiB of RAM just to be able to run Star Wars Dark Forces. These 4 MiB additional RAM did cost about around 179.63 Dollars. Adjusted for inflation, that's $362.64 today. Thus a PC with 16 MiB of RAM would have a todays inflation adjusted price tag of 1450.56 Dollars just for the RAM and the VRAM would have cost about 543.96 Dollar. And these based on prices for 1995, in 1993 that would have looked worse. For this reason, computers that were suitable for Windows NT 3.1 were only used in large servers or by software developers, where the investment was really worthwhile. Hardly anyone had that at home. So you can still call it "infancy of technology age". Larger amounts of RAM only became affordable for ordinary users around 1997.
There is also a 16bit protected mode that was for 286s and above that were used by some applications, that allowed up to 16MB of physical memory (and a lot more vitual memory). I know because I had coded some applications using Borland Pascal that used the 286 protected mode (I had a 286 at the time) as I was working with data that would not fit in the 640K conventional ram. Also Windows 3.x Standard mode used this version of "protected mode" on 286 and above CPUs. It wasnt terribly usefull as you were still stuck with 64K per segment, but you could use as much memory as you had, but making dos/bios calls (disk access) was painfull as the 286 did not have an easy way of switching from protected to real mode for DOS/BIOS
To a 286 back to real mode a clever trick was used using the keyboard controller. All registers saved, instruct the keyboard controller to reset the cpu and back to real mode. Novell enhanced 286 uses this trick. Server os on top of dos.
For things you can't loadhigh and insist on being in that 640k in real mode, is there any way to trick software into thinking it's in conventional memory so one can use more then 640k? Like a emulator or something?
Yeah, unless you were a programmer, or ran the few programs designed for it, the 286 was basically just a fast 8088. The 386 on the other hand had a whole lot more programs designed for it.
The video gives a solid explanation of 16 vs. 32 bits and the use of DOS extenders. One small point I do not agree with relating to processor type (8 bit, 16 bit, 32 bits etc) and memory addressing. You state that a 16 bit CPU works with 16 bits integers and therefor can only address 64 KB memory. This logic is flawed, as this would mean that an 8 bit CPU like the Z80 of 6502 would only be able to address 256 bytes directly. This is obviously not the case, as many 8-bit CPUs has 64 KB address space. The CPU type (8 bit, 16 bit etc) is determined by the with of the internal *data bus*. The Z80 has an 8 bit wide data bus, so it is an 8 bit processor. The 8088/8086/80286 had an 16 bit wide data bus, to they are 16 bit CPUs. The 8088 had externally only an 8 bit data bus, but internally it was full 16 bit, so it is still a 16 bit CPU from a software point of view. The address space however is determined by the size of the *address bus*, which can be much wider that the data bus. The 8 bits CPUs generally had a 16 bit address bus, giving them 64 KB of memory space. The 8088/8086 had a 20 bits address bus, so it had a 1 MB address space.
To add to this, it is true that a single register in 8 Bit CPUs can only hold value from 0-255 bits, but there techniques to deal with higher bit addresses. The z80 for example could hold 16 bit addresses in register pairs. The 6502 has the famous zero page which you use with indirect addressing to generate an effective 16 bit address. And obviously the 80x86 has its weird memory segmentation model to address anything higher than 64k
A widely overlooked capability of 32bit processors is 32bit real mode. You can execute 32bit instructions in real mode, you don't need protected mode to run 32bit. The major difference of course is that you are still limited to the 16bit memory space.
Borland 32 bit DOS extender (here is called "TASM extender") provides very intresting functionality. It use Windows EXE format for a hosted application and supports subset (very limited) of Windows API functions. It means to have a possibility to create applications which act in DOS and Windows (with possible extended functionality).
Intel: Instruction prefixes can be used to override the default operand size and address size of a code segment. These prefixes can be used in real-address mode as well as in protected mode and virtual-8086 mode. An operand-size or address-size prefix only changes the size for the duration of the instruction. The following two instruction prefixes allow mixing of 32-bit and 16-bit operations within one segment: The operand-size prefix (66H) The address-size prefix (67H) These prefixes reverse the default size selected by the D flag in the code-segment descriptor. For example, the processor can interpret the (MOV mem, reg) instruction in any of four ways: In a 32-bit code segment: Moves 32 bits from a 32-bit register to memory using a 32-bit effective address. If preceded by an operand-size prefix, moves 16 bits from a 16-bit register to memory using a 32-bit effective address. If preceded by an address-size prefix, moves 32 bits from a 32-bit register to memory using a 16-bit effective address. If preceded by both an address-size prefix and an operand-size prefix, moves 16 bits from a 16-bit register to memory using a 16-bit effective address. In a 16-bit code segment: Moves 16 bits from a 16-bit register to memory using a 16-bit effective address. If preceded by an operand-size prefix, moves 32 bits from a 32-bit register to memory using a 16-bit effective address. If preceded by an address-size prefix, moves 16 bits from a 16-bit register to memory using a 32-bit effective address. If preceded by both an address-size prefix and an operand-size prefix, moves 32 bits from a 32-bit register to memory using a 32-bit effective address. The previous examples show that any instruction can generate any combination of operand size and address size regardless of whether the instruction is in a 16- or 32-bit segment. The choice of the 16- or 32-bit default for a code segment is normally based on the following criteria: Performance Always use 32-bit code segments when possible. They run much faster than 16-bit code segments on P6 family processors, and somewhat faster on earlier IA-32 processors. The operating system the code segment will be running on If the operating system is a 16-bit operating system, it may not support 32-bit program modules. Mode of operation If the code segment is being designed to run in real-address mode, virtual-8086 mode, or SMM, it must be a 16-bit code segment. Backward compatibility to earlier IA-32 processors If a code segment must be able to run on an Intel 8086 or Intel 286 processor, it must be a 16-bit code segment. The D flag in a code-segment descriptor determines the default operand-size and address-size for the instructions of a code segment. (In real-address mode and virtual-8086 mode, which do not use segment descriptors, the default is 16 bits.) A code segment with its D flag set is a 32-bit segment; a code segment with its D flag clear is a 16-bit segment. Executable code segment. The flag is called the D flag and it indicates the default length for effective addresses and operands referenced by instructions in the segment. If the flag is set, 32-bit addresses and 32-bit or 8-bit operands are assumed; if it is clear, 16-bit addresses and 16-bit or 8-bit operands are assumed. The instruction prefix 66H can be used to select an operand size other than the default, and the prefix 67H can be used select an address size other than the default. The 32-bit operand prefix can be used in real-address mode programs to execute the 32-bit forms of instructions. This prefix also allows real-address mode programs to use the processors 32-bit general-purpose registers. The 32-bit address prefix can be used in real-address mode programs, allowing 32-bit offsets. The IA-32 processors beginning with the Intel386 processor can generate 32-bit offsets using an address override prefix; however, in real-address mode, the value of a 32-bit offset may not exceed FFFFH without causing an exception. Assembler Usage: If a code segment that is going to run in real-address mode is defined, it must be set to a USE 16 attribute. If a 32-bit operand is used in an instruction in this code segment (for example, MOV EAX, EBX), the assembler automatically generates an operand prefix for the instruction that forces the processor to execute a 32-bit operation, even though its default code-segment attribute is 16-bit. The 32-bit operand prefix allows a real-address mode program to use the 32-bit general-purpose registers (EAX, EBX, ECX, EDX, ESP, EBP, ESI, and EDI). When moving data in 32-bit mode between a segment register and a 32-bit general-purpose register, the Pentium Pro processor does not require the use of a 16-bit operand size prefix; however, some assemblers do require this prefix. The processor assumes that the 16 least-significant bits of the general-purpose register are the destination or source operand. When moving a value from a segment selector to a 32-bit register, the processor fills the two high-order bytes of the register with zeros. -------------------------------------------------- AMD: 3.3.2. 32-Bit vs. 16-Bit Address and Operand Sizes The processor can be configured for 32-bit or 16-bit address and operand sizes. With 32-bit address and operand sizes, the maximum linear address or segment offset is FFFFFFFFH (232-1), and operand sizes are typically 8 bits or 32 bits. With 16-bit address and operand sizes, the maximum linear address or segment offset is FFFFH (216-1), and operand sizes are typically 8 bits or 16 bits. When using 32-bit addressing, a logical address (or far pointer) consists of a 16-bit segment selector and a 32-bit offset; when using 16-bit addressing, it consists of a 16-bit segment selector and a 16-bit offset. Instruction prefixes allow temporary overrides of the default address and/or operand sizes from within a program. When operating in protected mode, the segment descriptor for the currently executing code segment defines the default address and operand size. A segment descriptor is a system data structure not normally visible to application code. Assembler directives allow the default addressing and operand size to be chosen for a program. The assembler and other tools then set up the segment descriptor for the code segment appropriately. When operating in real-address mode, the default addressing and operand size is 16 bits. An address-size override can be used in real-address mode to enable 32-bit addressing; however, the maximum allowable 32-bit linear address is still 000FFFFFH (220-1). 3.6. OPERAND-SIZE AND ADDRESS-SIZE ATTRIBUTES When the processor is executing in protected mode, every code segment has a default operandsize attribute and address-size attribute. These attributes are selected with the D (default size) flag in the segment descriptor for the code segment (see Chapter 3, Protected-Mode Memory Management, in the Intel Architecture Software Developers Manual, Volume 3). When the D flag is set, the 32-bit operand-size and address-size attributes are selected; when the flag is clear, the 16-bit size attributes are selected. When the processor is executing in real-address mode, virtual-8086 mode, or SMM, the default operand-size and address-size attributes are always 16 bits. The operand-size attribute selects the sizes of operands that instructions operate on. When the 16-bit operand-size attribute is in force, operands can generally be either 8 bits or 16 bits, and when the 32-bit operand-size attribute is in force, operands can generally be 8 bits or 32 bits. The address-size attribute selects the sizes of addresses used to address memory: 16 bits or 32 bits. When the 16-bit address-size attribute is in force, segment offsets and displacements are 16 bits. This restriction limits the size of a segment that can be addressed to 64 KBytes. When the 32-bit address-size attribute is in force, segment offsets and displacements are 32 bits, allowing segments of up to 4 GBytes to be addressed. The default operand-size attribute and/or address-size attribute can be overridden for a particular instruction by adding an operand-size and/or address-size prefix to an instruction (see Instruction Prefixes in Chapter 2 of the Intel Architecture Software Developers Manual, Volume 3). The effect of this prefix applies only to the instruction it is attached to. Table 3-1 shows effective operand size and address size (when executing in protected mode) depending on the settings of the D flag and the operand-size and address-size prefixes.
@@r3v0lv3rz I like to use the 16 bit BIG REAL MODE with a segment size of 4 gb for DS,ES,FS and GS, but for CS and SS 64 kb segment size limit. It is usefull to write into the linear framebuffer for VBE video modes at the address of C0000000 svga-S3 emulation using 800x600x32 resolution in DosBox for example using instructions with an address size prefix. Address calculation: xor eax, eax mov ax,DATA Segment mov ds, ax mov edi, C0000000h shl eax, 4 sub edi, eax mov eax, color mov [edi], eax ; ds:edi = linear framebuffer ... Or with one special instructions to copy inside the linear framebuffer after ecx, esi and edi is filled with values: rep ; repeat + decrease ecx DB 67h ; address size prefix movsd ; copy from ds:esi to es:edi + increase esi and edi by 4 if direction flag is not set All instruction for the 16 bit mode with ems=false in config file.
Is that - at 8:20 - the reason why loading and saving was a bit slower? I remember saving games in DOS DOOM was making it "stop" for a brief moment - saving a few KBytes DSG file while the game itself ran fast and smooth 35fps. Is that "saving to disk" routine one of these wake-up CPU mode switches that are performance-heavy?
Technically the windows 3.11 386 enhanced mode (/w win32s) was preemptive multi tasking, so it came before win95. Windows 3.11 would then run a virtual machine in 16-bit mode, that would run a windows 3.11 kernel doing all the classical windows things while allowing 32 bit apps to run with preemptive semantics.
I'm pretty sure that Win32s applications ran within the same VM that was used with Win16 applications. In other words, Win32s couldn't do any preemptive multitasking under Windows 3.1x. I've read about this in a Microsoft article called "General limitations under Win32s" (Q131896), there are two points that states: "1. Thread creation is not supported." "2. Win32s uses the Windows version 3.1 nonpreemptive scheduling mechanism."
Under Windows 3.x the System VM (Win16) and every DOS VM under enhanced mode are preemptive multitasked. The Windows applications inside the System VM due to compability issues are only cooperative multitasked. A Windows program and a DOS program could be preemptive multitasked.
An excellent and well researched video! It's a bit lesser known fact but Wolfenstein 3D used self modifying code to make long divisions faster by using 32bit registers and without a DOS Extender and using XMS and EMS for accessing more ram (16bit i286 had a 24 bit address bus and had a protected mode so accessing more ram didn't need an i386)
@@theexplosionist2019 Self-Modifying code is slow NOW because it messes up with the Cache (specially the i-cache) and the translation from i32 and amd64 ISAs to µOps. But back in the 286 and 386 days, it was fast as hell (as well as compact)
The 286 doesn't have 32 Bit wide registers, it is still a 16 bit CPU with 16 bit wide registers. And Wolfenstein 3D's system requirement are a 286, not a 386. Are you sure that it is Wolf3d and not DOOM? The latter requires a 386 or better. Also Wolf 3d doesn't use DOS Extenders, it is using EMS memory.
Actually, there were also 16bit DOS-Extenders, that allowed 16bit programs to use up to 16MB of RAM. Those worked on 286 (or Higher) processors, but were not standarized. Par-Lap 286 DOS Extender is among them, there were others.
@@PJBonoVox He's probably talking about those late USB floppy drives for Windows computers that don't work at all without a driver for Windows. These drives were simply unusable for DOS without special drivers.
Thanks for this video. ‘Back in the Day’ I always assumed DOS Extenders added some additional ‘functions’ on top of more memory control, but didn’t realize how much it was doing to enable 32-bit code to execute.
IBM computers in the 90's allowed you to make the changes in the bios to run in 16 bit protected mode, 32 bit protected mode, and 16 bit real mode. Running in 32 bit protected mode forced all apps including dos games to run in 32 bit protected mode. No extender needed.
@@moeschizlac I think you do mess up OS/2 with the BIOS. OS/2 did make us of the VM86 which was part of the CPU since the 386 to make DOS applications run in a VM86 mode. Windows did the same.
@@OpenGL4ever I had no problem in windows 95 and dos using 32 bit protected mode on a bios level. When you have that setting on a bios level, it overrides vm86. It's a similar effect of you having a hardware raid card with it's own built in bios onboard; you are able to run large capacity HDD's in raid and override HDD capacity limitations set by an OS and/or motherboard's bios. You could be right about OS/2, I never messed with that.
@@moeschizlac You can't boot DOS from 32 bit protected mode. And the same applies to Win95. Point is, you were using OS/2 and this creates one or more VM86 machines for DOS applications. It can also run Windows 3.1. Your BIOS was never 32 Bit.
@@OpenGL4ever I never used OS/2. The PC I had set to 32 bit protected mode with was an IBM PS/1 2168 series with a 486 DX2 50mhz and a cl5428 onboard. It had a hard drive upgrade with a Seagate with dynamic drive overlay software due to the bios not seeing the large hard drive, even with LBA mode. It was probably able to boot win95 and dos up due to the Seagate software or simply because it had the advantages of being a true IBM PC(not a clone).
I remember when I was a kid many many years ago, seeing the Dos4gw thing when running a game, and... a .exe I think it was? over and over. I couldn't even figure out a meaning for it (granted, my non native English sucked big time back then). I always wondered what that was back in the day... eventually with the coming of Windows I ended forgetting about it. Now I saw this video, remembered about it, and finally got this doubt solved. Thank you.
And then you have the mess that is flat real mode aka unreal mode where the program sets up the segment descriptors in protected mode and then switches back to real mode allowing 16 bit programs access to the more than 1 mb. Famously used by ultima 7 (parts 1 and 2) and not much else and is completely incompatible with any dpmi host because it exploited a cpu bug that only sometimes works.
6:00 🥹 The Apogee intro music! Legendary. They made so many good games. Then they had a sub-division 3D Realms and they released even more epic games. And then they renamed to the name of that sub-division and totally messed up 😔
On 80386 we can use 32 bit instructions (including FS and GS segment register) in the 16 bit Real Address Mode with 64 kb segment size and additional in the (non official) 16 bit Big Real Mode/Unreal Mode with 4 gb segment size for DS,ES,FS,GS segment register in combination with 32 bit offset register. Example for copy a block of the linear framebuffer from the upper left corner to the center of the screen using resolution 800x600x32 and with using the 16 bit Big Real Mode/Unreal Mode: cld xor eax,eax mov ax,ds mov es,ax shl eax,4 mov esi,C0000000 ; linear framebuffer sub esi,eax mov edi,esi add edi,EAC40 mov ebx,AE8 mov edx,36 P1: mov ecx,66 rep DB 67 ; address size prefix movsd add esi,ebx add edi,ebx dec edx jnz P1
@@Lyricaldeamin Fun fact: floppy drives to this day, in windows machines are assigned as "A:". There's a video out there by theojoe i think that explains everything
@@karolwojtyla3047 it's not even that he didn't want to wait for 32 bit windows, he wanted Unix at home since he got to use it at university and he thought it was a good os
It's a marvel that Intel survived through all those years of having such a convoluted memory access model instead of just a straightforward 32 bit access model like other 32 bit processors of the time (such as the Motorola 68020). If the PC did not have such a huge market share that may not have been the case.
This made the x86 cheaper, it required less area on the silicon per chip and thus increased market share. With an increase in market share Intel got more money and this could be spend in better processing steps. The 386 already had the MMU already integrated in 1985, while Motorola needed 2 more years for that. Motorola had no chance.
I guess the question is, if the 386 had existed since 1985, why wasn't there a native 32-bit version of DOS? Why rely on stuff like Windows or DOS Extenders rather than just have a version of DOS that can run in protected mode? Were they just sort of trying to use 32-bit as the excuse to move people over to something new,, or is there some reason an OS like DOS wouldn't work as a 32-bit OS? Or was it a few edge cases with backwards compatibility with a couple of 16-bit applications that made DOS stick with 16-bit until the bitter end? It's just a little hard to believe that between 1981 and 1986, enough software was written for 16-bit DOS that it became impossible to move on...
There was a MS-DOS 4.0 with multitasking capabilties a year later. But the plan was to create a new operating system called OS/2. Later Microsoft and IBM went different paths. Microsoft created Windows NT and IBM OS/2 2.0. Also keep in mind, it needs some time to write a new OS for a new CPU with a completely new working mode. Also the 386 was very expensive when it was released, so market share was very small to get enough enough users for a new OS.
A more accurate title for this video would be 32bit Extender DOS applications, since MSDOS was only ever 16bit, and without a 32bit Extender its impossible for 32bit code to run under MSDOS... Details matter...
@igetakickoutofyou Oh it's not so bad. Today you see channels testing it under standard settings and declaring it "unplayable". But for one you had low res (double column) mode. For other you would reduce the window size. Third you pick lower difficulty and play it strategically rather than like a fast paced shooter. Careful stepping around corners. There's fun to be had there if you don't have something better. And you probably didn't.
@@SianaGearz I played DOOM on a 486DX at 33 MHz. And that was a suitable machine for this game. Although a 486DX2 at 66 MHz would of course have been a little better. But a 486DX2 was in the high end price range when my family got the 33 MHz version. But I can understand the thread starter. I had the problem with Wing Commander 3. The others played it on a Pentium 60 MHz and I had to play with a lot of stuttering on my 33 MHz fast 486 with only an ISA SVGA card.
@@OpenGL4ever Thing is 286 doesn't run DOOM at all as it's not compatible with DOS4G, does not have 32-bit protected mode. So it's not painfully slow, it literally won't start. Doom on a 386 is on the slow side, but it's not too bad. Heretic/Hexen is worse, missing low resolution mode. But i played it at 8 frames per second, i had fun!
Prefer technology from the eighties and nineties where there were one time payments and not worrying about user data being exploited by corporations harkening the olden days 😮
![[LIVE] นาทีนี้ต้องพี่ทนาย | ทนายแก้ว vs ทนายไพศาล | #คุยให้เด็กมันฟัง EP.47 (02/11/67)](http://i.ytimg.com/vi/HmquaO-PL_M/mqdefault.jpg)
We were writing 32 bit DOS games in the early 90s. We handled graphics bank switching using what they call a bimodal interrupt where we would reflect the IRQ to/from protected and real mode. We treated the video memory as linear using this technique (we'd do the bank switching during the IRQ). In fact, VESA later used this technique, so did Windows Game SDK and DirectX..
Growing Up, I always wondered that DOS/4GW message meant when starting games on my PC. Now I finally know!
this is one of two holy grails of DOS programming, one being this protected mode programming with DOS extenders, the other being SVGA-VESA-VDE graphics programming so that games can have 640x480 screen with more than 256 colors.. please tell more about the later
Can't wait for 64-bit DOS applications now
More efficient to have PAE? Or it'll just take one insane person to decide that the x86_64 instruction set is crucial for their program XD
Computer Chronicles was an AMAZING show. Wish I lived near the Bay Area to see it growing up. Watched every archive which documents beautifully the infancy of technology age.
I have very faint memories as a child watching the show on PBS either Saturday or Sunday mornings.
Well, with 16 million colours and 24-bit colour depth, resoulutions of 1600x1200, multi-media and such in the early 1990s, calling it the "infancy of technology age" is a bit of a stretch. If you talk about the earlier, 80s episodes, you are right, but people under-estimate the ability of e.g. Windows NT because most people used archaic DOS programs and, obviously, games.
@@Zedek To run Windows NT 3.1 in a usable form you need about 16 MiB of RAM. That was very expensive in 1993. For have a 24 bit color depth at a resolution of 1600x1200 you need a SVGA card with at least 6 MiB of RAM. In 1993 this cards had usually about 1 to 2 MiB VRAM, thus not enough for these resolutions. The rule was the same, memory was very expensive. And a computer monitor that could run at a resolution of 1600x1200 pixels and 70 Hz was also very expensive in the upper price range. For 70 Hz you also needed a video card with a very fast RAMDAC, most videocards were not able to supply at that time.
In 1995 i upgraded my 486DX 33 MHz from 4 MiB of RAM to 8 MiB of RAM just to be able to run Star Wars Dark Forces. These 4 MiB additional RAM did cost about around 179.63 Dollars. Adjusted for inflation, that's $362.64 today. Thus a PC with 16 MiB of RAM would have a todays inflation adjusted price tag of 1450.56 Dollars just for the RAM and the VRAM would have cost about 543.96 Dollar. And these based on prices for 1995, in 1993 that would have looked worse.
For this reason, computers that were suitable for Windows NT 3.1 were only used in large servers or by software developers, where the investment was really worthwhile. Hardly anyone had that at home.
So you can still call it "infancy of technology age".
Larger amounts of RAM only became affordable for ordinary users around 1997.
There is also a 16bit protected mode that was for 286s and above that were used by some applications, that allowed up to 16MB of physical memory (and a lot more vitual memory). I know because I had coded some applications using Borland Pascal that used the 286 protected mode (I had a 286 at the time) as I was working with data that would not fit in the 640K conventional ram. Also Windows 3.x Standard mode used this version of "protected mode" on 286 and above CPUs.
It wasnt terribly usefull as you were still stuck with 64K per segment, but you could use as much memory as you had, but making dos/bios calls (disk access) was painfull as the 286 did not have an easy way of switching from protected to real mode for DOS/BIOS
Switching back from Protected to Real Mode in the 80286 required a processor reset. Not a very elegant and rather cumbersome method to achieve this...
To a 286 back to real mode a clever trick was used using the keyboard controller. All registers saved, instruct the keyboard controller to reset the cpu and back to real mode. Novell enhanced 286 uses this trick. Server os on top of dos.
@@pcuser80explains why Novell servers always needed a keyboard!
For things you can't loadhigh and insist on being in that 640k in real mode, is there any way to trick software into thinking it's in conventional memory so one can use more then 640k? Like a emulator or something?
Yeah, unless you were a programmer, or ran the few programs designed for it, the 286 was basically just a fast 8088.
The 386 on the other hand had a whole lot more programs designed for it.
I maintained the DOS emulator for GameTap. This video is the best overview of the low level aspects DOS that I've seen so far.
Gametap... Wow
I remember Gametap. Subscribed to it back in the day. Good memories. Wish it took off it had a great interface.
The video gives a solid explanation of 16 vs. 32 bits and the use of DOS extenders.
One small point I do not agree with relating to processor type (8 bit, 16 bit, 32 bits etc) and memory addressing. You state that a 16 bit CPU works with 16 bits integers and therefor can only address 64 KB memory. This logic is flawed, as this would mean that an 8 bit CPU like the Z80 of 6502 would only be able to address 256 bytes directly. This is obviously not the case, as many 8-bit CPUs has 64 KB address space.
The CPU type (8 bit, 16 bit etc) is determined by the with of the internal *data bus*. The Z80 has an 8 bit wide data bus, so it is an 8 bit processor. The 8088/8086/80286 had an 16 bit wide data bus, to they are 16 bit CPUs. The 8088 had externally only an 8 bit data bus, but internally it was full 16 bit, so it is still a 16 bit CPU from a software point of view. The address space however is determined by the size of the *address bus*, which can be much wider that the data bus. The 8 bits CPUs generally had a 16 bit address bus, giving them 64 KB of memory space. The 8088/8086 had a 20 bits address bus, so it had a 1 MB address space.
To add to this, it is true that a single register in 8 Bit CPUs can only hold value from 0-255 bits, but there techniques to deal with higher bit addresses. The z80 for example could hold 16 bit addresses in register pairs. The 6502 has the famous zero page which you use with indirect addressing to generate an effective 16 bit address. And obviously the 80x86 has its weird memory segmentation model to address anything higher than 64k
Love the Quake shareware disc case you showed. Still have mine sitting on my desk. complete with game guide.
A widely overlooked capability of 32bit processors is 32bit real mode. You can execute 32bit instructions in real mode, you don't need protected mode to run 32bit. The major difference of course is that you are still limited to the 16bit memory space.
lol djgpp, that's a throwback... i used to mess around with djgpp and allegro waaaaay back in the day. fun times
Same lol
I wish I had these explanations as a kid, with no internet at the time
I've been looking for a video about this forever! Hope you do more videos like this, dos is fun.
Borland 32 bit DOS extender (here is called "TASM extender") provides very intresting functionality. It use Windows EXE format for a hosted application and supports subset (very limited) of Windows API functions. It means to have a possibility to create applications which act in DOS and Windows (with possible extended functionality).
QEMM386, oh the nostalgia!!!
Intel:
Instruction prefixes can be used to override the default operand size and address size of a code segment. These prefixes can be used in real-address mode as well as in protected mode and virtual-8086 mode. An operand-size or address-size prefix only changes the size for the duration of the instruction.
The following two instruction prefixes allow mixing of 32-bit and 16-bit operations within one segment:
The operand-size prefix (66H)
The address-size prefix (67H)
These prefixes reverse the default size selected by the D flag in the code-segment descriptor. For example, the processor can interpret the (MOV mem, reg) instruction in any of four ways:
In a 32-bit code segment:
Moves 32 bits from a 32-bit register to memory using a 32-bit effective address.
If preceded by an operand-size prefix, moves 16 bits from a 16-bit register to memory using a 32-bit effective address.
If preceded by an address-size prefix, moves 32 bits from a 32-bit register to memory using a 16-bit effective address.
If preceded by both an address-size prefix and an operand-size prefix, moves 16 bits from a 16-bit register to memory using a 16-bit effective address.
In a 16-bit code segment:
Moves 16 bits from a 16-bit register to memory using a 16-bit effective address.
If preceded by an operand-size prefix, moves 32 bits from a 32-bit register to memory using a 16-bit effective address.
If preceded by an address-size prefix, moves 16 bits from a 16-bit register to memory using a 32-bit effective address.
If preceded by both an address-size prefix and an operand-size prefix, moves 32 bits from a 32-bit register to memory using a 32-bit effective address.
The previous examples show that any instruction can generate any combination of operand size and address size regardless of whether the instruction is in a 16- or 32-bit segment. The choice of the 16- or 32-bit default for a code segment is normally based on the following criteria:
Performance Always use 32-bit code segments when possible. They run much faster than 16-bit code segments on P6 family processors, and somewhat faster on earlier IA-32 processors.
The operating system the code segment will be running on If the operating system is a 16-bit operating system, it may not support 32-bit program modules.
Mode of operation If the code segment is being designed to run in real-address mode, virtual-8086 mode, or SMM, it must be a 16-bit code segment.
Backward compatibility to earlier IA-32 processors If a code segment must be able to run on an Intel 8086 or Intel 286 processor, it must be a 16-bit code segment.
The D flag in a code-segment descriptor determines the default operand-size and address-size for the instructions of a code segment. (In real-address mode and virtual-8086 mode, which do not use segment descriptors, the default is 16 bits.) A code segment with its D flag set is a 32-bit segment; a code segment with its D flag clear is a 16-bit segment.
Executable code segment. The flag is called the D flag and it indicates the default length for effective addresses and operands referenced by instructions in the segment. If the flag is set, 32-bit addresses and 32-bit or 8-bit operands are assumed; if it is clear, 16-bit addresses and 16-bit or 8-bit operands are assumed.
The instruction prefix 66H can be used to select an operand size other than the default, and the prefix 67H can be used select an address size other than the default.
The 32-bit operand prefix can be used in real-address mode programs to execute the 32-bit forms of instructions. This prefix also allows real-address mode programs to use the processors 32-bit general-purpose registers.
The 32-bit address prefix can be used in real-address mode programs, allowing 32-bit offsets.
The IA-32 processors beginning with the Intel386 processor can generate 32-bit offsets using an address override prefix; however, in real-address mode, the value of a 32-bit offset may not exceed FFFFH without causing an exception.
Assembler Usage:
If a code segment that is going to run in real-address mode is defined, it must be set to a USE 16 attribute. If a 32-bit operand is used in an instruction in this code segment (for example, MOV EAX, EBX), the assembler automatically generates an operand prefix for the instruction that forces the processor to execute a 32-bit operation, even though its default code-segment attribute is 16-bit.
The 32-bit operand prefix allows a real-address mode program to use the 32-bit general-purpose registers (EAX, EBX, ECX, EDX, ESP, EBP, ESI, and EDI).
When moving data in 32-bit mode between a segment register and a 32-bit general-purpose
register, the Pentium Pro processor does not require the use of a 16-bit operand size prefix;
however, some assemblers do require this prefix. The processor assumes that the 16 least-significant
bits of the general-purpose register are the destination or source operand. When moving a
value from a segment selector to a 32-bit register, the processor fills the two high-order bytes of
the register with zeros.
--------------------------------------------------
AMD:
3.3.2. 32-Bit vs. 16-Bit Address and Operand Sizes
The processor can be configured for 32-bit or 16-bit address and operand sizes. With 32-bit
address and operand sizes, the maximum linear address or segment offset is FFFFFFFFH
(232-1), and operand sizes are typically 8 bits or 32 bits. With 16-bit address and operand sizes,
the maximum linear address or segment offset is FFFFH (216-1), and operand sizes are typically
8 bits or 16 bits.
When using 32-bit addressing, a logical address (or far pointer) consists of a 16-bit segment
selector and a 32-bit offset; when using 16-bit addressing, it consists of a 16-bit segment selector
and a 16-bit offset.
Instruction prefixes allow temporary overrides of the default address and/or operand sizes from
within a program.
When operating in protected mode, the segment descriptor for the currently executing code
segment defines the default address and operand size. A segment descriptor is a system data
structure not normally visible to application code. Assembler directives allow the default
addressing and operand size to be chosen for a program. The assembler and other tools then set
up the segment descriptor for the code segment appropriately.
When operating in real-address mode, the default addressing and operand size is 16 bits. An
address-size override can be used in real-address mode to enable 32-bit addressing; however, the
maximum allowable 32-bit linear address is still 000FFFFFH (220-1).
3.6. OPERAND-SIZE AND ADDRESS-SIZE ATTRIBUTES
When the processor is executing in protected mode, every code segment has a default operandsize
attribute and address-size attribute. These attributes are selected with the D (default size)
flag in the segment descriptor for the code segment (see Chapter 3, Protected-Mode Memory
Management, in the Intel Architecture Software Developers Manual, Volume 3). When the D
flag is set, the 32-bit operand-size and address-size attributes are selected; when the flag is clear,
the 16-bit size attributes are selected. When the processor is executing in real-address mode,
virtual-8086 mode, or SMM, the default operand-size and address-size attributes are always 16
bits.
The operand-size attribute selects the sizes of operands that instructions operate on. When the
16-bit operand-size attribute is in force, operands can generally be either 8 bits or 16 bits, and
when the 32-bit operand-size attribute is in force, operands can generally be 8 bits or 32 bits.
The address-size attribute selects the sizes of addresses used to address memory: 16 bits or 32
bits. When the 16-bit address-size attribute is in force, segment offsets and displacements are 16
bits. This restriction limits the size of a segment that can be addressed to 64 KBytes. When the
32-bit address-size attribute is in force, segment offsets and displacements are 32 bits, allowing
segments of up to 4 GBytes to be addressed.
The default operand-size attribute and/or address-size attribute can be overridden for a particular
instruction by adding an operand-size and/or address-size prefix to an instruction (see
Instruction Prefixes in Chapter 2 of the Intel Architecture Software Developers Manual,
Volume 3). The effect of this prefix applies only to the instruction it is attached to.
Table 3-1 shows effective operand size and address size (when executing in protected mode)
depending on the settings of the D flag and the operand-size and address-size prefixes.
Yes.
@@r3v0lv3rz I like to use the 16 bit BIG REAL MODE with a segment size of 4 gb for DS,ES,FS and GS, but for CS and SS 64 kb segment size limit. It is usefull to write into the linear framebuffer for VBE video modes at the address of C0000000 svga-S3 emulation using 800x600x32 resolution in DosBox for example using instructions with an address size prefix.
Address calculation:
xor eax, eax
mov ax,DATA Segment
mov ds, ax
mov edi, C0000000h
shl eax, 4
sub edi, eax
mov eax, color
mov [edi], eax ; ds:edi = linear framebuffer
...
Or with one special instructions to copy inside the linear framebuffer after ecx, esi and edi is filled with values:
rep ; repeat + decrease ecx
DB 67h ; address size prefix
movsd ; copy from ds:esi to es:edi + increase esi and edi by 4 if direction flag is not set
All instruction for the 16 bit mode with ems=false in config file.
Is that - at 8:20 - the reason why loading and saving was a bit slower? I remember saving games in DOS DOOM was making it "stop" for a brief moment - saving a few KBytes DSG file while the game itself ran fast and smooth 35fps. Is that "saving to disk" routine one of these wake-up CPU mode switches that are performance-heavy?
Technically the windows 3.11 386 enhanced mode (/w win32s) was preemptive multi tasking, so it came before win95.
Windows 3.11 would then run a virtual machine in 16-bit mode, that would run a windows 3.11 kernel doing all the classical windows things while allowing 32 bit apps to run with preemptive semantics.
I'm pretty sure that Win32s applications ran within the same VM that was used with Win16 applications. In other words, Win32s couldn't do any preemptive multitasking under Windows 3.1x. I've read about this in a Microsoft article called "General limitations under Win32s" (Q131896), there are two points that states:
"1. Thread creation is not supported."
"2. Win32s uses the Windows version 3.1 nonpreemptive scheduling mechanism."
Under Windows 3.x the System VM (Win16) and every DOS VM under enhanced mode are preemptive multitasked. The Windows applications inside the System VM due to compability issues are only cooperative multitasked. A Windows program and a DOS program could be preemptive multitasked.
An excellent and well researched video!
It's a bit lesser known fact but Wolfenstein 3D used self modifying code to make long divisions faster by using 32bit registers and without a DOS Extender and using XMS and EMS for accessing more ram (16bit i286 had a 24 bit address bus and had a protected mode so accessing more ram didn't need an i386)
You don't need a DOS extender to use 32 bit instructions such as those for division. You can use 32 bit registers in real mode no problem.
@@lordwiadro83 that is exactly what surprised me when I learned this for the first time.
That makes no sense to me. Self-modifying code is slow.
@@theexplosionist2019 Self-Modifying code is slow NOW because it messes up with the Cache (specially the i-cache) and the translation from i32 and amd64 ISAs to µOps. But back in the 286 and 386 days, it was fast as hell (as well as compact)
The 286 doesn't have 32 Bit wide registers, it is still a 16 bit CPU with 16 bit wide registers. And Wolfenstein 3D's system requirement are a 286, not a 386. Are you sure that it is Wolf3d and not DOOM? The latter requires a 386 or better.
Also Wolf 3d doesn't use DOS Extenders, it is using EMS memory.
Great explanation, thank you!
Actually, there were also 16bit DOS-Extenders, that allowed 16bit programs to use up to 16MB of RAM.
Those worked on 286 (or Higher) processors, but were not standarized.
Par-Lap 286 DOS Extender is among them, there were others.
A laptop with a working floppy driver. Can we appreciate this
Why?
@@madzen112 I've no idea what he's on about either.
i appreciated it
@@PJBonoVox He's probably talking about those late USB floppy drives for Windows computers that don't work at all without a driver for Windows. These drives were simply unusable for DOS without special drivers.
Thanks for this video. ‘Back in the Day’ I always assumed DOS Extenders added some additional ‘functions’ on top of more memory control, but didn’t realize how much it was doing to enable 32-bit code to execute.
IBM computers in the 90's allowed you to make the changes in the bios to run in 16 bit protected mode, 32 bit protected mode, and 16 bit real mode. Running in 32 bit protected mode forced all apps including dos games to run in 32 bit protected mode. No extender needed.
@@moeschizlac I think you do mess up OS/2 with the BIOS. OS/2 did make us of the VM86 which was part of the CPU since the 386 to make DOS applications run in a VM86 mode. Windows did the same.
@@OpenGL4ever I had no problem in windows 95 and dos using 32 bit protected mode on a bios level. When you have that setting on a bios level, it overrides vm86. It's a similar effect of you having a hardware raid card with it's own built in bios onboard; you are able to run large capacity HDD's in raid and override HDD capacity limitations set by an OS and/or motherboard's bios. You could be right about OS/2, I never messed with that.
@@moeschizlac You can't boot DOS from 32 bit protected mode. And the same applies to Win95.
Point is, you were using OS/2 and this creates one or more VM86 machines for DOS applications. It can also run Windows 3.1.
Your BIOS was never 32 Bit.
@@OpenGL4ever I never used OS/2. The PC I had set to 32 bit protected mode with was an IBM PS/1 2168 series with a 486 DX2 50mhz and a cl5428 onboard. It had a hard drive upgrade with a Seagate with dynamic drive overlay software due to the bios not seeing the large hard drive, even with LBA mode. It was probably able to boot win95 and dos up due to the Seagate software or simply because it had the advantages of being a true IBM PC(not a clone).
Excellent detail, I am very impressed! I also loved the side by side analysis!
I remember when I was a kid many many years ago, seeing the Dos4gw thing when running a game, and... a .exe I think it was? over and over. I couldn't even figure out a meaning for it (granted, my non native English sucked big time back then). I always wondered what that was back in the day... eventually with the coming of Windows I ended forgetting about it. Now I saw this video, remembered about it, and finally got this doubt solved. Thank you.
And then you have the mess that is flat real mode aka unreal mode where the program sets up the segment descriptors in protected mode and then switches back to real mode allowing 16 bit programs access to the more than 1 mb. Famously used by ultima 7 (parts 1 and 2) and not much else and is completely incompatible with any dpmi host because it exploited a cpu bug that only sometimes works.
Came scrolling through the comments to see who else remembered flat real mode hack!
_Zone66_ also used flat real mode with Tran’s pmode dos extender.
6:00 🥹 The Apogee intro music! Legendary. They made so many good games. Then they had a sub-division 3D Realms and they released even more epic games. And then they renamed to the name of that sub-division and totally messed up 😔
I love this diagram at 1:39 very nice work
I don't have any questions. Just saying this video was spot on (which I had seen it 20 years ago, had to learn all about it myself)
286.いやいや、内部構造8bit の86なので、OS 自体16bit だね。
私も未だに、MS-DOS 6.2 持っていますが、286から動くので16bit 。
痺れますよ、動いた瞬間は。
Nice video. Very informative and entertaining.
5:10 you have wrong informations about the 16 bit Real Address Mode on 32 bit x86 CPU.
This was a very good video. Thank you! :)
On 80386 we can use 32 bit instructions (including FS and GS segment register) in the 16 bit Real Address Mode with 64 kb segment size and additional in the (non official) 16 bit Big Real Mode/Unreal Mode with 4 gb segment size for DS,ES,FS,GS segment register in combination with 32 bit offset register.
Example for copy a block of the linear framebuffer from the upper left corner to the center of the screen using resolution 800x600x32 and with using the 16 bit Big Real Mode/Unreal Mode:
cld
xor eax,eax
mov ax,ds
mov es,ax
shl eax,4
mov esi,C0000000 ; linear framebuffer
sub esi,eax
mov edi,esi
add edi,EAC40
mov ebx,AE8
mov edx,36
P1:
mov ecx,66
rep
DB 67 ; address size prefix
movsd
add esi,ebx
add edi,ebx
dec edx
jnz P1
@echo off
REM UNREAL.BAT
REM For switching from the 16 bit Real Address mode into 16 bit Unreal-/Big real mode with
REM changing the segment size from 64 kb segment size to 4 gb segment size
REM for DS, ES, FS, GS segment register, but not CS and SS segment register
REM and at last open the 21 address line.
echo a>tmp.deb
REM -- disable interrupts and NMI --
echo CLI>>tmp.deb
echo IN AL,70>>tmp.deb
echo OR AL,80>>tmp.deb
echo OUT 70,AL>>tmp.deb
REM -- calculate addresses --
echo XOR EAX,EAX>>tmp.deb
echo MOV AX,CS>>tmp.deb
echo MOV [016D],AX>>tmp.deb
echo SHL EAX,04>>tmp.deb
echo MOV EBX,EAX>>tmp.deb
echo MOV [01B2],AX>>tmp.deb
echo MOV [01BA],AX>>tmp.deb
echo ROR EAX,10>>tmp.deb
echo MOV [01B4],AL>>tmp.deb
echo MOV [01BC],AL>>tmp.deb
echo XOR EAX,EAX>>tmp.deb
echo MOV AX,01A8>>tmp.deb
echo ADD EBX,EAX>>tmp.deb
echo MOV WORD PTR [01A0],27>>tmp.deb
echo MOV [01A2],EBX>>tmp.deb
echo PUSHF>>tmp.deb
echo LGDT [01A0]>>tmp.deb
echo MOV DX,SS>>tmp.deb
echo MOV EAX,CR0>>tmp.deb
echo OR AL,1>>tmp.deb
echo MOV CR0,EAX>>tmp.deb
echo JMP 0008:0150>>tmp.deb
REM -- start protect mode --
echo org 0150>>tmp.deb
echo MOV AX,10>>tmp.deb
echo MOV SS,AX>>tmp.deb
echo MOV AX,18>>tmp.deb
echo MOV DS,AX>>tmp.deb
echo MOV ES,AX>>tmp.deb
echo MOV FS,AX>>tmp.deb
echo MOV GS,AX>>tmp.deb
echo MOV EAX,CR0>>tmp.deb
echo AND EAX,-2>>tmp.deb
echo MOV CR0,EAX>>tmp.deb
echo JMP 0734:0170>>tmp.deb
REM -- switch back to Real mode --
echo org 0170>>tmp.deb
echo MOV SS,DX>>tmp.deb
echo POPF>>tmp.deb
REM -- open address line --
echo XOR CX,CX>>tmp.deb
echo IN AL,64>>tmp.deb
echo AND AL,2>>tmp.deb
echo LOOPNZW 0175>>tmp.deb
echo JNZ 0197>>tmp.deb
echo MOV AL,D1>>tmp.deb
echo OUT 64,AL>>tmp.deb
echo XOR CX,CX>>tmp.deb
echo IN AL,64>>tmp.deb
echo AND AL,2>>tmp.deb
echo LOOPNZW 0183>>tmp.deb
echo JNZ 0179>>tmp.deb
echo MOV AL,DF>>tmp.deb
echo OUT 60,AL>>tmp.deb
echo XOR CX,CX>>tmp.deb
echo IN AL,64>>tmp.deb
echo AND AL,2>>tmp.deb
echo LOOPNZW 0191>>tmp.deb
REM -- enable interrupts and NMI --
echo IN AL,70>>tmp.deb
echo AND AL,7F>>tmp.deb
echo OUT 70,AL>>tmp.deb
echo STI>>tmp.deb
echo RET>>tmp.deb
REM -- Global descriptor table --
echo org 01A0>>tmp.deb
echo DB 0,0,0,0,0,0,0,0>>tmp.deb
echo DB 0,0,0,0,0,0,0,0>>tmp.deb
REM 01B0
echo DB FF,FF,0,0,0,9A,0,0>>tmp.deb
REM 01B8
echo DB FF,FF,0,0,0,92,0,0>>tmp.deb
REM 01C0
echo DB FF,FF,0,0,0,92,FF,FF>>tmp.deb
echo.>>tmp.deb
echo n UNREAL.COM>>tmp.deb
echo rcx>>tmp.deb
echo C8>>tmp.deb
echo wcs:100>>tmp.deb
REM - unassemble routine -
echo ucs:100 l4F>>tmp.deb
echo ucs:150 l1F>>tmp.deb
echo ucs:170 l2F>>tmp.deb
REM -- Global descriptor table --
echo dcs:1A0 l8>>tmp.deb
echo dcs:1A8 l8>>tmp.deb
echo dcs:1B0 l8>>tmp.deb
echo dcs:1B8 l8>>tmp.deb
echo dcs:1C0 l8>>tmp.deb
echo q>>tmp.deb
debugDEB.INF
del tmp.deb
UNREAL.COM
del UNREAL.COM
HEY, a video where someone talks about DJGPP !
This is so cool! I didn't know about 32bit DOS games
I wish I could have a floppy disk reader
@@PelmeniDevourer it's never too late m-
WAIT A DAMN MINUTE.
@@KnockinOnYourDoor lol it’s cool I still have a pc with one but on modern ones it’s kinda pointless 😊
@@Lyricaldeamin Fun fact: floppy drives to this day, in windows machines are assigned as "A:". There's a video out there by theojoe i think that explains everything
I'll be your floppy disk reader
@@KnockinOnYourDoor lol I know u have an external floppy n it auto assigns to a:
Besides dos and windows there was also Linux released in 1991 which was fully 32 bit from the start
Linux was created especialy for this purpose, Linus Torvalds didn't want wait for 32bit Windows for his own 386.
@@karolwojtyla3047 it's not even that he didn't want to wait for 32 bit windows, he wanted Unix at home since he got to use it at university and he thought it was a good os
Thanks so much 4 this, so many years wondering what dos4gw is...
OMG I have the exact same laptop. I did my first linux kernel compile on one of those!
It's a marvel that Intel survived through all those years of having such a convoluted memory access model instead of just a straightforward 32 bit access model like other 32 bit processors of the time (such as the Motorola 68020). If the PC did not have such a huge market share that may not have been the case.
This made the x86 cheaper, it required less area on the silicon per chip and thus increased market share. With an increase in market share Intel got more money and this could be spend in better processing steps. The 386 already had the MMU already integrated in 1985, while Motorola needed 2 more years for that.
Motorola had no chance.
Great video!
Great video! Loved seeing Bio Menace too!
15:00 - that's cool that they took art from The Stone Prophet but I wonder if they actually had the rights for it?
Awesome video and research really good work
Odd that I saw no mention of "memmaker" supplied with DOS.? Or did it slip by?😜
Manually configuring your Autoexec bat and configuration system typically produced better results than Memmaker.
386 dos extender ? you mean 3D studio R4 (DOS)?
I guess the question is, if the 386 had existed since 1985, why wasn't there a native 32-bit version of DOS? Why rely on stuff like Windows or DOS Extenders rather than just have a version of DOS that can run in protected mode? Were they just sort of trying to use 32-bit as the excuse to move people over to something new,, or is there some reason an OS like DOS wouldn't work as a 32-bit OS? Or was it a few edge cases with backwards compatibility with a couple of 16-bit applications that made DOS stick with 16-bit until the bitter end? It's just a little hard to believe that between 1981 and 1986, enough software was written for 16-bit DOS that it became impossible to move on...
There was a MS-DOS 4.0 with multitasking capabilties a year later. But the plan was to create a new operating system called OS/2. Later Microsoft and IBM went different paths. Microsoft created Windows NT and IBM OS/2 2.0. Also keep in mind, it needs some time to write a new OS for a new CPU with a completely new working mode. Also the 386 was very expensive when it was released, so market share was very small to get enough enough users for a new OS.
Damn! I remember in the 90's i get all my savings to get the Toshiba Pentium 120 Mhz.....Amazing maintenance 💯👋👏
whats the song starting at 14:35? :D
Hold down the reset button, then press the power button. It will write: ready for bios update.
Wow, nice video..
A more accurate title for this video would be 32bit Extender DOS applications, since MSDOS was only ever 16bit, and without a 32bit Extender its impossible for 32bit code to run under MSDOS...
Details matter...
My first computer was 80286, as we couldn’t afford a 80386 back the. I was so mad because I am stuck with wolfstein when my friends could play doom.
@igetakickoutofyou Oh it's not so bad. Today you see channels testing it under standard settings and declaring it "unplayable".
But for one you had low res (double column) mode.
For other you would reduce the window size.
Third you pick lower difficulty and play it strategically rather than like a fast paced shooter. Careful stepping around corners.
There's fun to be had there if you don't have something better. And you probably didn't.
@@SianaGearz I played DOOM on a 486DX at 33 MHz. And that was a suitable machine for this game. Although a 486DX2 at 66 MHz would of course have been a little better. But a 486DX2 was in the high end price range when my family got the 33 MHz version.
But I can understand the thread starter. I had the problem with Wing Commander 3. The others played it on a Pentium 60 MHz and I had to play with a lot of stuttering on my 33 MHz fast 486 with only an ISA SVGA card.
@@OpenGL4ever Thing is 286 doesn't run DOOM at all as it's not compatible with DOS4G, does not have 32-bit protected mode. So it's not painfully slow, it literally won't start.
Doom on a 386 is on the slow side, but it's not too bad.
Heretic/Hexen is worse, missing low resolution mode. But i played it at 8 frames per second, i had fun!
@@SianaGearz We were talking about a 386, not a 286.
@@OpenGL4ever you say "I can understand the thread starter" who specifically had a 286 not 386, which excluded them from even trying DOOM.
Prefer technology from the eighties and nineties where there were one time payments and not worrying about user data being exploited by corporations harkening the olden days 😮
64k views?
also old school emulators are 32 bit apps
Mebibyte != Megabyte
It depends.
They are equal for memory, but, traditionally, isn't for storage manufacturers.
32-bit regs were accessible in real mode
8 MB, 16 MB recommended. now 8 GB, 16 GB... esit for 8 PB, 16 PB xD
Bro great content but I wish you were speaking more understandable
👏👏👏👏👍
👍👍👍👍👍👍
Chasm
Nice English
1:41
Wow! You only list Microsoft apps.
The world is a little bit bigger than all that crap.
How are you going to badmouth 90s era Microsoft yet resist the temptation to use the $ sign to spell their name?
@@Sashko_Dee “Microshaft” in 2023 … puts ads in Win 11. /s
Video is awfully incorrect in every second theory details.
I see, which are incorrect?
Tracy it’s me , Rufus
I am pretty sure that _go32_dpmi_lock_code(__mouse_handler,(long)sizeof(__mouse_handler)); would work instead of the weird NULL sizeprobe hack