32-bit DOS Applications

Рет қаралды 77,212

2 жыл бұрын

In this video we will explore the marvel of 32-bit DOS applications. We will look at their history, and how exactly they work.
Official site of DJGPP: www.delorie.com/djgpp/
A very incomplete list of 32-bit DOS games: www.classicdosgames.com/forum/...
An article talking in more details about the rather chaotic history of DPMI: lists.gnu.org/archive/html/ly...

Пікірлер: 131

@WyMustIGo Жыл бұрын

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..

@NidonocuPoisonBunny Жыл бұрын

Growing Up, I always wondered that DOS/4GW message meant when starting games on my PC. Now I finally know!

@_lun4r_ Жыл бұрын

Can't wait for 64-bit DOS applications now

@imkow Жыл бұрын

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

@phqutub Жыл бұрын

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.

@0326Hambone Жыл бұрын

I have very faint memories as a child watching the show on PBS either Saturday or Sunday mornings.

@Zedek Жыл бұрын

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.

@OpenGL4ever 6 ай бұрын

@@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.

@matthouben4242 Жыл бұрын

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.

@klausschmidt982 Жыл бұрын

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

@JanoJ Жыл бұрын

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

@matthouben4242 Жыл бұрын

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...

@pcuser80 Жыл бұрын

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.

@stiansoiland-reyes2548 Жыл бұрын

@@pcuser80explains why Novell servers always needed a keyboard!

@petevenuti7355 Жыл бұрын

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?

@kargaroc386 Жыл бұрын

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.

@jaysistar2711 Жыл бұрын

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.

@gordy12gg Жыл бұрын

Gametap... Wow

@coreyoliver3182 Жыл бұрын

I remember Gametap. Subscribed to it back in the day. Good memories. Wish it took off it had a great interface.

@semenkovalev4988 Жыл бұрын

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).

@eformance Жыл бұрын

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.

@lboston4660 Жыл бұрын

lol djgpp, that's a throwback... i used to mess around with djgpp and allegro waaaaay back in the day. fun times

@derekpmoore Жыл бұрын

Same lol

@curtisnewton895 Жыл бұрын

I wish I had these explanations as a kid, with no internet at the time

@m.hosseinmahmoodi Жыл бұрын

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)

@lordwiadro83 Жыл бұрын

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.

@m.hosseinmahmoodi Жыл бұрын

@@lordwiadro83 that is exactly what surprised me when I learned this for the first time.

@theexplosionist2019 Жыл бұрын

That makes no sense to me. Self-modifying code is slow.

@williamyf Жыл бұрын

@@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)

@OpenGL4ever 6 ай бұрын

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.

@curious1706 Жыл бұрын

I've been looking for a video about this forever! Hope you do more videos like this, dos is fun.

@maxmuster7003 Жыл бұрын

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 Жыл бұрын

Yes.

@maxmuster7003 Жыл бұрын

@@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.

@prozacgodgamedev Жыл бұрын

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.

@Kernel32x86 Жыл бұрын

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."

@vascomanteigas9433 Жыл бұрын

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.

@williamyf Жыл бұрын

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.

@tayfuntuna Жыл бұрын

A laptop with a working floppy driver. Can we appreciate this

@madzen112 Жыл бұрын

Why?

@PJBonoVox Жыл бұрын

@@madzen112 I've no idea what he's on about either.

@KingLich451 Жыл бұрын

i appreciated it

@OpenGL4ever 6 ай бұрын

@@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.

@timhowland7103 Жыл бұрын

Love the Quake shareware disc case you showed. Still have mine sitting on my desk. complete with game guide.

@jrherita Жыл бұрын

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.

@moeschizlac 10 ай бұрын

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.

@OpenGL4ever 6 ай бұрын

@@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.

@moeschizlac 6 ай бұрын

@@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.

@OpenGL4ever 6 ай бұрын

@@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.

@moeschizlac 6 ай бұрын

@@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).

@CommodoreGreg Жыл бұрын

Excellent detail, I am very impressed! I also loved the side by side analysis!

@xcoder1122 Жыл бұрын

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 😔

@Shakeno Жыл бұрын

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.

@victorlgcarvalho Жыл бұрын

QEMM386, oh the nostalgia!!!

@saifal-badri 8 ай бұрын

I love this diagram at 1:39 very nice work

@blu3_enjoy Жыл бұрын

Awesome video and research really good work

@wizard-pirate Жыл бұрын

Nice video. Very informative and entertaining.

@intel386DX Жыл бұрын

This is so cool! I didn't know about 32bit DOS games

@pikuma Жыл бұрын

This was a very good video. Thank you! :)

@BrianJones-wk8cx 7 ай бұрын

Great explanation, thank you!

@Zedek Жыл бұрын

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?

@MonochromeWench Жыл бұрын

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.

@MichaelPohoreski Жыл бұрын

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.

@VintageModernRemixes Жыл бұрын

Great video! Loved seeing Bio Menace too!

@Tech2C Жыл бұрын

Great video!

@MissNorington Жыл бұрын

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)

@VoidloniXaarii Жыл бұрын

Thanks so much 4 this, so many years wondering what dos4gw is...

@heno02 6 ай бұрын

OMG I have the exact same laptop. I did my first linux kernel compile on one of those!

@maxmuster7003 Жыл бұрын

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

@maxmuster7003 Жыл бұрын

@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

@RETROMachines Жыл бұрын

Wow, nice video..

@maxmuster7003 Жыл бұрын

5:10 you have wrong informations about the 16 bit Real Address Mode on 32 bit x86 CPU.

@gabrielblanchard3081 Жыл бұрын

I wish I could have a floppy disk reader

@user-yx6cl5mi9l Жыл бұрын

I wish I could be a floppy disk reader

@KnockinOnYourDoor Жыл бұрын

@@user-yx6cl5mi9l it's never too late m- WAIT A DAMN MINUTE.

@Lyricaldeamin Жыл бұрын

@@KnockinOnYourDoor lol it’s cool I still have a pc with one but on modern ones it’s kinda pointless 😊

@KnockinOnYourDoor Жыл бұрын

@@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

@Breadloaf-kr4gi Жыл бұрын

I'll be your floppy disk reader

@StigDesign 11 ай бұрын

whats the song starting at 14:35? :D

@Kaltinril Жыл бұрын

HEY, a video where someone talks about DJGPP !

@JustWasted3HoursHere Жыл бұрын

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.

@OpenGL4ever 6 ай бұрын

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.

@golarac6433 Жыл бұрын

Besides dos and windows there was also Linux released in 1991 which was fully 32 bit from the start

@karolwojtyla3047 Жыл бұрын

Linux was created especialy for this purpose, Linus Torvalds didn't want wait for 32bit Windows for his own 386.

@golarac6433 Жыл бұрын

@@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

@jozsiolah1435 Жыл бұрын

Hold down the reset button, then press the power button. It will write: ready for bios update.

@yuan.pingchen3056 Жыл бұрын

386 dos extender ? you mean 3D studio R4 (DOS)?

@merleatmo Жыл бұрын

Damn! I remember in the 90's i get all my savings to get the Toshiba Pentium 120 Mhz.....Amazing maintenance 💯👋👏

@younan68000 Жыл бұрын

286.いやいや、内部構造8bit の86なので、OS 自体16bit だね。私も未だに、MS-DOS 6.2 持っていますが、286から動くので16bit 。痺れますよ、動いた瞬間は。

@mybachhertzbaud3074 7 ай бұрын

Odd that I saw no mention of "memmaker" supplied with DOS.? Or did it slip by?😜

@OpenGL4ever 6 ай бұрын

Manually configuring your Autoexec bat and configuration system typically produced better results than Memmaker.

@jeremyandrews3292 7 ай бұрын

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...

@OpenGL4ever 6 ай бұрын

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.

@sinephase Жыл бұрын

15:00 - that's cool that they took art from The Stone Prophet but I wonder if they actually had the rights for it?

@looneyburgmusic Жыл бұрын

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...

@rasimbot Жыл бұрын

32-bit regs were accessible in real mode

@matthewrease2376 Жыл бұрын

Mebibyte != Megabyte

@semibiotic Жыл бұрын

It depends. They are equal for memory, but, traditionally, isn't for storage manufacturers.

@user-kx7qy7sr7t Жыл бұрын

👍👍👍👍👍👍

@cloud_s_97 Жыл бұрын

also old school emulators are 32 bit apps

@Chiavaccio Жыл бұрын

👏👏👏👏👍

@reno6 Жыл бұрын

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.

@SianaGearz Жыл бұрын

@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.

@OpenGL4ever 6 ай бұрын

@@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.

@SianaGearz 6 ай бұрын

@@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!

@OpenGL4ever 6 ай бұрын

@@SianaGearz We were talking about a 386, not a 286.

@SianaGearz 6 ай бұрын

@@OpenGL4ever you say "I can understand the thread starter" who specifically had a 286 not 386, which excluded them from even trying DOOM.

@troyiusmaximus Жыл бұрын

64k views?

@8randomprettysecret8 Жыл бұрын

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 😮