DOS ain't dead

DOSBox-X 0.84.2 / 2022.08.0 has now been officially released! Designing to be a cross-platform DOS emulator, it is the goal of DOSBox-X to support different types of DOS software and implement accurate emulation, accurate enough to help make new DOS developments possible with confidence the program will run properly on actual DOS systems.

DOSBox-X provides official DOS versions in addition to other platforms. There are enhancements specific to the DOS version in this release as well such as network function support (a packet driver will be needed). You can download the DOS package of DOSBox-X 0.84.2 / 2022.08.0 package from the DOSBox-X project homepage:

https://dosbox-x.com/

There are a number of improvements in this latest version, and you can find the release notes for this version (containing the change history) here:

* https://dosbox-x.com/release-0.84.2.html

The DOS package is self-contained so that you can simply unzip the file and type DOSBOX-X to run in DOS. It is confirmed to work in DOS, and read the included README.TXT file for more information.

Wengier

> The DOS package is self-contained so that you can simply unzip the file and
> type DOSBOX-X to run in DOS. It is confirmed to work in DOS, and read the
> included README.TXT file for more information.

Thanks for the new release! Good work, AFAICS!

I have some comments:

1. It's not sufficiently pointed out that the keyboard issues in dosbox-x are more or less due to using sdl1 - they disappear if dosbox-x is compiled with sdl2 ( also, with sdl2, there's a much better fullscreen mode ).

2. Open Watcom's WD works fine with dosbox-x ( at least my slightly modified version, which is based on OW v1.9 ). Would be cool if dosbox-x supports an alternate video adapter ( monochrome ) like 86Box does ( or perhaps it does and I just have overlooked that info in the docs? ).

3. the ctrl-alt-del "emulation" does not work reliably - the system is not really in a clean state afterwards, and one might have to close and reopen dosbox-x ( not a big issue, just worth to mention ).

4. There are problems in dosbox-x if an exception occurs when the trace flag is set. This is also a problem with dosbox ( and 86Box, btw ). If you are interested, I can provide a test case.

---
MS-DOS forever!

Thanks for your support and feedback.

With the sole exception of HX-DOS target, both SDL1 and SDL2 builds are officially provided for all other platforms (Windows, Linux, macOS), and in the case of Linux the Flatpak package is only available in the SDL2 form. The Windows installer for example mentions that "DOSBox-X provides both SDL1 and SDL2 builds, and while SDL1 builds are preselected, you may prefer SDL2 builds if for example you encounter some issues with a non-U.S. keyboard layout in SDL1 builds". I am sure this is the issue you talked about with SDL1 builds. Be sure to try SDL2 builds in such cases. The HX-DOS target is not yet available in SDL2 since I was not able to make it run in MS-DOS when I tried to compile it with SDL2, since in such case the HX-DOS Extender would complain about missing imports (from the SDL2 library), which you may want to take a look at.

As for alternative video adapters, I think DOSBox-X (as with dosbox) does support this, and you can change the video adapter in use by modifying the "machine" config option in dosbox-x.conf. For example, try setting machine=mda or machine=hercules for monochrome mode.

I agree that "Reset virtual machine" or "Reboot guest system" (or just pressing Ctrl+Del+Alt) may not really return to a clean state, since there are many components involved when running the emulator. However, if you click the menu option "Restart DOSBox-X instance" (under "Main" menu), or type the command config -bc, then the system will be fully cleaned (since this automatically closes and reopens DOSBox-X).

Meanwhile, I am sure you are more familiar with the details of exceptions and trace flags than me. If you find a problem with them (or any other things indeed), you can surely consider sending bugfix (in the form of pull request) to solve the issue(s). DOSBox-X is an open-source project hosted on GitHub, and I am sure you are familiar with GitHub.

Thanks again for the support!

Wengier

> Thanks for the new release! Good work, AFAICS!
>
> I have some comments:
>
> 1. It's not sufficiently pointed out that the keyboard issues in dosbox-x
> are more or less due to using sdl1 - they disappear if dosbox-x is compiled
> with sdl2 ( also, with sdl2, there's a much better fullscreen mode ).
>
> 2. Open Watcom's WD works fine with dosbox-x ( at least my slightly
> modified version, which is based on OW v1.9 ). Would be cool if dosbox-x
> supports an alternate video adapter ( monochrome ) like 86Box does ( or
> perhaps it does and I just have overlooked that info in the docs? ).
>
> 3. the ctrl-alt-del "emulation" does not work reliably - the system is not
> really in a clean state afterwards, and one might have to close and reopen
> dosbox-x ( not a big issue, just worth to mention ).
>
> 4. There are problems in dosbox-x if an exception occurs when the trace
> flag is set. This is also a problem with dosbox ( and 86Box, btw ). If you
> are interested, I can provide a test case.

> As for alternative video adapters, I think DOSBox-X (as with dosbox) does
> support this, and you can change the video adapter in use by modifying the
> "machine" config option in dosbox-x.conf. For example, try setting
> machine=mda or machine=hercules for monochrome
> mode.

I'm sure dosbox-x emulates those (monochrome) adapters just fine.

However, with "alternate" I meant a SECOND adapter in the system, both being active. IIRC, the VGA adapter introduced this possibility ( see int 10h, ax=1A00h [ get display combination code ] ) and it was quite popular among developers in the early 90ties, since it allows to debug graphics applications without screen contents swapping ( the other option, using a serial/network connection, is by far not that comfortable ).

---
MS-DOS forever!

By the second adapter, do you mean the VGA & monochrome dual-screen setup? If so, it is supported via the -display2 option in command line (you can type dosbox-x -help for a list of command-line options). More information about this function can be found in this Wiki page:

https://dosbox-x.com/wiki/Guide%3AVideo-card-support-in-DOSBox%E2%80%90X#_dual_monitor

Wengier

> I'm sure dosbox-x emulates those (monochrome) adapters just fine.
>
> However, with "alternate" I meant a SECOND adapter in the system, both
> being active. IIRC, the VGA adapter introduced this possibility ( see int
> 10h, ax=1A00h [ get display combination code ] ) and it was quite popular
> among developers in the early 90ties, since it allows to debug graphics
> applications without screen contents swapping ( the other option, using a
> serial/network connection, is by far not that comfortable ).

> By the second adapter, do you mean the VGA & monochrome dual-screen setup?
> If so, it is supported via the -display2 option in command
> line

Yes, that's it.

It works, not perfectly ( at least on Linux, since the terminal is messed-up after you've left dosbox-x ), but it's quite sufficient.

---
MS-DOS forever!

Perfect again. On the other hand, this executable (and the last version too) doesn't contain the relocation information so I have to manually deal with it before running (I normally have at least one DPMI client loaded). Does it have any practical purposes or can you provide an executable with relocs in the future releases?

Thanks

---
DOS isn't about why. It's about why not.

Hi KormaX,

Thanks for the feedback. Meanwhile, I think most people have no idea about what the “relocation information” is, nor its purpose. The HX-DOS executable (as with the last version) is compressed by UPX to greatly save disk space and reduce load time, so you can try uncompress the binary with UPX if you want the uncompressed version.

Wengier

> Perfect again. On the other hand, this executable (and the last version
> too) doesn't contain the relocation information so I have to manually deal
> with it before running (I normally have at least one DPMI client loaded).
> Does it have any practical purposes or can you provide an executable with
> relocs in the future releases?
>
> Thanks

Thank you, but I think if you compress the executable with --strip-relocs=1, the relocation information can never be added back by -d, so that's not what I needed. Without .reloc the active HX can't load the new client by default as it would require relocation within the same address space (or a separate virtual address space), so that's why I have to run the last two versions with HDPMI32 -d and terminate it followed by HDPMI32 -e, otherwise I get the "Relocs stripped, cannot load" error message. It's not a big deal, so I just asked. I can use it this way as well.

Thanks

---
DOS isn't about why. It's about why not.

You can try the updated HX-DOS build below, which is now compressed with "--strip-relocs=0":

https://dosbox-x.com/devel-build.html

Hope this helps.

Wengier

> Thank you, but I think if you compress the executable with
> --strip-relocs=1, the relocation information can never be added back by -d,
> so that's not what I needed. Without .reloc the active HX can't load the
> new client by default as it would require relocation within the same
> address space (or a separate virtual address space), so that's why I have
> to run the last two versions with HDPMI32 -d and terminate it followed by
> HDPMI32 -e, otherwise I get the "Relocs stripped, cannot load" error
> message. It's not a big deal, so I just asked. I can use it this way as
> well.
>
> Thanks

> It works, not perfectly ( at least on Linux, since the terminal is
> messed-up after you've left dosbox-x ), but it's quite sufficient.

You can try the latest repository code, which hopefully fixes the said terminal mess-up issue with -display2 on non-Windows platforms (tested in Linux and macOS).

Wengier

> > By the second adapter, do you mean the VGA & monochrome dual-screen
> setup?
> > If so, it is supported via the -display2 option in command
> > line
>
> Yes, that's it.
>
> It works, not perfectly ( at least on Linux, since the terminal is
> messed-up after you've left dosbox-x ), but it's quite sufficient.

> You can try the latest repository code, which hopefully fixes the said
> terminal mess-up issue with -display2 on non-Windows platforms (tested in
> Linux and macOS).

I compiled it ( source taken from https://github.com/joncampbell123/dosbox-x/archive/refs/heads/master.zip ), but somehow the -display2 option is no longer known.

Maybe I did something wrong - I guess I'll wait until the next (monthly?) release.

---
MS-DOS forever!

The -display2 option is only supported in debug builds, so you can try run ./build-debug to compile the repository code (instead of running ./build). Then I think it should work. Hope this helps.

Wengier

> > You can try the latest repository code, which hopefully fixes the said
> > terminal mess-up issue with -display2 on non-Windows platforms (tested
> in
> > Linux and macOS).
>
> I compiled it ( source taken from
> https://github.com/joncampbell123/dosbox-x/archive/refs/heads/master.zip
> ), but somehow the -display2 option is no longer known.
>
> Maybe I did something wrong - I guess I'll wait until the next (monthly?)
> release.

> The -display2 option is only supported in debug builds, so you can try run
> ./build-debug to compile the repository code (instead of running ./build).
> Then I think it should work. Hope this helps.

Thanks! However, I used "./build-debug-sdl2", as described in https://github.com/joncampbell123/dosbox-x/blob/master/BUILD.md - shouldn't that also work?

---
MS-DOS forever!

Yes, ./build-debug-sdl2 is also supposed to work. You can check if there is “#define C_DEBUG 1” in ./config.h which is meant to enable debug functions.

Wengier

> > The -display2 option is only supported in debug builds, so you can try
> run
> > ./build-debug to compile the repository code (instead of running
> ./build).
> > Then I think it should work. Hope this helps.
>
> Thanks! However, I used "./build-debug-sdl2", as described in
> https://github.com/joncampbell123/dosbox-x/blob/master/BUILD.md
> - shouldn't that also work?

> You can try the latest repository code, which hopefully fixes the said
> terminal mess-up issue with -display2 on non-Windows platforms (tested in
> Linux and macOS).

Confirmed - the terminal is no longer dysfunctional after "dosbox-x -display2" has terminated.

---
MS-DOS forever!

Houston, we have a problem.

Attempting to build dosbox-x on slackware-64-current.

root@glennmcc-spare:~/build/dosbox-x-dosbox-x-v0.84.3# ./build-debug

hardware.cpp:63:4: error: #error Your libavcodec is too old. Update FFMPEG.
63 | # error Your libavcodec is too old. Update FFMPEG.
| ^~~~~
adlib.cpp: In function 'std::string getoplmode()':
adlib.cpp:1330:39: warning: NULL used in arithmetic [-Wpointer-arith]
1330 | if (Adlib::Module::oplmode == NULL || Adlib::Module::oplmode == OPL_none) return "None";
| ^~~~
hardware.cpp: In function 'void ffmpeg_audio_frame_send()':
hardware.cpp:163:33: error: 'av_packet_rescale_ts' was not declared in this scope
163 | av_packet_rescale_ts(&pkt,ffmpeg_aud_ctx->time_base,ffmpeg_aud_stream->time_base);
| ^~~~~~~~~~~~~~~~~~~~
hardware.cpp: In function 'void ffmpeg_flush_video()':
hardware.cpp:258:57: error: 'av_packet_rescale_ts' was not declared in this scope
258 | av_packet_rescale_ts(&pkt,ffmpeg_vid_ctx->time_base,ffmpeg_vid_stream->time_base);
| ^~~~~~~~~~~~~~~~~~~~
hardware.cpp: In function 'void ffmpeg_flushout()':
hardware.cpp:301:57: error: 'av_packet_rescale_ts' was not declared in this scope
301 | av_packet_rescale_ts(&pkt,ffmpeg_aud_ctx->time_base,ffmpeg_aud_stream->time_base);
| ^~~~~~~~~~~~~~~~~~~~
hardware.cpp: In function 'void ffmpeg_reopen_video(double, int)':
hardware.cpp:441:34: error: 'AV_CODEC_FLAG2_FAST' was not declared in this scope; did you mean 'CODEC_FLAG2_FAST'?
441 | ffmpeg_vid_ctx->flags2 = AV_CODEC_FLAG2_FAST;
| ^~~~~~~~~~~~~~~~~~~
| CODEC_FLAG2_FAST
hardware.cpp: In function 'void CAPTURE_AddImage(Bitu, Bitu, Bitu, Bitu, Bitu, float, uint8_t*, uint8_t*)':
hardware.cpp:1159:50: error: 'AV_CODEC_FLAG2_FAST' was not declared in this scope; did you mean 'CODEC_FLAG2_FAST'?
1159 | ffmpeg_vid_ctx->flags2 = AV_CODEC_FLAG2_FAST;
| ^~~~~~~~~~~~~~~~~~~
| CODEC_FLAG2_FAST
hardware.cpp:1451:49: error: 'av_packet_rescale_ts' was not declared in this scope
1451 | av_packet_rescale_ts(&pkt,ffmpeg_vid_ctx->time_base,ffmpeg_vid_stream->time_base);
| ^~~~~~~~~~~~~~~~~~~~
At global scope:
cc1plus: note: unrecognized command-line option '-Wno-int-to-void-pointer-cast' may have been intended to silence earlier diagnostics
cc1plus: note: unrecognized command-line option '-Wno-int-to-void-pointer-cast' may have been intended to silence earlier diagnostics
make[4]: *** [Makefile:798: hardware.o] Error 1
make[4]: *** Waiting for unfinished jobs....
At global scope:
cc1plus: note: unrecognized command-line option '-Wno-int-to-void-pointer-cast' may have been intended to silence earlier diagnostics
cc1plus: note: unrecognized command-line option '-Wno-int-to-void-pointer-cast' may have been intended to silence earlier diagnostics
make[4]: Leaving directory '/root/build/dosbox-x-dosbox-x-v0.84.3/src/hardware'
make[3]: *** [Makefile:820: all-recursive] Error 1
make[3]: Leaving directory '/root/build/dosbox-x-dosbox-x-v0.84.3/src/hardware'
make[2]: *** [Makefile:530: all-recursive] Error 1
make[2]: Leaving directory '/root/build/dosbox-x-dosbox-x-v0.84.3/src'
make[1]: *** [Makefile:399: all-recursive] Error 1
make[1]: Leaving directory '/root/build/dosbox-x-dosbox-x-v0.84.3'
make: *** [Makefile:332: all] Error 2

______________________

root@glennmcc-spare:~/build/dosbox-x-dosbox-x-v0.84.3# whereis ffmpeg
ffmpeg: /usr/bin/ffmpeg /usr/share/ffmpeg /usr/man/man1/ffmpeg.1.gz /var/man/cat1/ffmpeg.1.xz

root@glennmcc-spare:~/build/dosbox-x-dosbox-x-v0.84.3# ls -l /usr/bin/ffmpeg
-rwxr-xr-x 1 root root 271384 Oct 9 20:56 /usr/bin/ffmpeg*

root@glennmcc-spare:~/build/dosbox-x-dosbox-x-v0.84.3# ffmpeg
ffmpeg version 5.1.2 Copyright (c) 2000-2022 the FFmpeg developers
built with gcc 12.2.0 (GCC)
configuration: --prefix=/usr --libdir=/usr/lib64 --shlibdir=/usr/lib64 --docdir=/usr/doc/ffmpeg-5.1.2/html --mandir=/usr/man --disable-debug --enable-shared --disable-static --enable-gpl --enable-version3 --arch=x86_64 --disable-encoder=aac --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-gnutls --enable-libbluray --enable-libcaca --enable-libcdio --enable-frei0r --enable-openal --enable-libopus --enable-libspeex --enable-libssh --enable-libtheora --enable-libv4l2 --enable-libvidstab --enable-libvorbis --enable-libvpx --enable-libwebp --enable-libmp3lame --enable-opencl --enable-opengl --enable-libopenjpeg
--enable-libpulse --enable-libsmbclient --enable-libxml2 --enable-librsvg --enable-vulkan --enable-libglslang --enable-libdrm
libavutil 57. 28.100 / 57. 28.100
libavcodec 59. 37.100 / 59. 37.100
libavformat 59. 27.100 / 59. 27.100
libavdevice 59. 7.100 / 59. 7.100
libavfilter 8. 44.100 / 8. 44.100
libswscale 6. 7.100 / 6. 7.100
libswresample 4. 7.100 / 4. 7.100
libpostproc 56. 6.100 / 56. 6.100
Hyper fast Audio and Video encoder
usage: ffmpeg [options] [[infile options] -i infile]... {[outfile options] outfile}...
______________________________

root@glennmcc-spare:~/build/dosbox-x-dosbox-x-v0.84.3# whereis libavcodec
libavcodec: /usr/include/libavcodec /usr/man/man3/libavcodec.3.gz /usr/man/man3/libavcodec.3 /usr/man/man1/libavcodec.3

root@glennmcc-spare:~/build/dosbox-x-dosbox-x-v0.84.3# ls -l /usr/include/libavcodec
total 280
-rw-r--r-- 1 root root 1207 Oct 9 20:56 ac3_parser.h
-rw-r--r-- 1 root root 1354 Oct 9 20:56 adts_parser.h
-rw-r--r-- 1 root root 113770 Oct 9 20:56 avcodec.h
-rw-r--r-- 1 root root 2726 Oct 9 20:56 avdct.h
-rw-r--r-- 1 root root 3111 Oct 9 20:56 avfft.h
-rw-r--r-- 1 root root 11383 Oct 9 20:56 bsf.h
-rw-r--r-- 1 root root 13669 Oct 9 20:56 codec.h
-rw-r--r-- 1 root root 3847 Oct 9 20:56 codec_desc.h
-rw-r--r-- 1 root root 17112 Oct 9 20:56 codec_id.h
-rw-r--r-- 1 root root 7621 Oct 9 20:56 codec_par.h
-rw-r--r-- 1 root root 2853 Oct 9 20:56 d3d11va.h
-rw-r--r-- 1 root root 5349 Oct 9 20:56 defs.h
-rw-r--r-- 1 root root 4044 Oct 9 20:56 dirac.h
-rw-r--r-- 1 root root 3694 Oct 9 20:56 dv_profile.h
-rw-r--r-- 1 root root 2361 Oct 9 20:56 dxva2.h
-rw-r--r-- 1 root root 1650 Oct 9 20:56 jni.h
-rw-r--r-- 1 root root 3450 Oct 9 20:56 mediacodec.h
-rw-r--r-- 1 root root 23745 Oct 9 20:56 packet.h
-rw-r--r-- 1 root root 3763 Oct 9 20:56 qsv.h
-rw-r--r-- 1 root root 5102 Oct 9 20:56 vdpau.h
-rw-r--r-- 1 root root 1619 Oct 9 20:56 version.h
-rw-r--r-- 1 root root 2296 Oct 9 20:56 version_major.h
-rw-r--r-- 1 root root 4029 Oct 9 20:56 videotoolbox.h
-rw-r--r-- 1 root root 2285 Oct 9 20:56 vorbis_parser.h
-rw-r--r-- 1 root root 6136 Oct 9 20:56 xvmc.h
__________________________

---
--
http://glennmcc.org/

> Houston, we have a problem.
>
> Attempting to build dosbox-x on slackware-64-current.
>
> root@glennmcc-spare:~/build/dosbox-x-dosbox-x-v0.84.3# ./build-debug

Nevermind...

Built and installed the brand-new ffmpeg

dosbox-x now builds perfectly.

---
--
http://glennmcc.org/

Or will DOSBOX support 32-bit unreal mode in the future?

After switching to protected 32-bit mode (CS <- 32 segment) the program returns to real mode but does not reload the segment to 16-bit, it stays in this mode. This is 32-bit real mode and the only restriction is that you cannot run any procedure above an address greater than 64K.

> Or will DOSBOX support 32-bit unreal mode in the future?
>
> After switching to protected 32-bit mode (CS <- 32 segment) the program
> returns to real mode but does not reload the segment to 16-bit, it stays in
> this mode. This is 32-bit real mode and the only restriction is that you
> cannot run any procedure above an address greater than 64K.

Isn't that the mode that Fasm's DOS version uses?

IIRC it also has the "little" restriction that you have to intercept all interrupt vectors that may be used while in that 32-bit mode ( including the IRQs ), switch to 16-bit, call the interrupt routine, and finally switch back to 32-bit mode.

---
MS-DOS forever!

> Isn't that the mode that Fasm's DOS version uses?
>
> IIRC it also has the "little" restriction that you have to intercept all
> interrupt vectors that may be used while in that 32-bit mode ( including
> the IRQs ), switch to 16-bit, call the interrupt routine, and finally
> switch back to 32-bit mode.

Yes, this is the same mode that FASM uses.
I have several programs that run unreal 32-bit without any problems. QEMU or BOCHS support this mode, however, only one of them supports 32-bit stack greater than 64K.
I'm posting the test files (one with stack switching and one without).

https://megawrzuta.pl/download/e92992b7ecbb79ca6156b0f4ef6e9cf4.html
https://megawrzuta.pl/download/2316378c0e9263d43374732f733dafb7.html

> I'm posting the test files (one with stack switching and one without).
>
> https://megawrzuta.pl/download/e92992b7ecbb79ca6156b0f4ef6e9cf4.html
> https://megawrzuta.pl/download/2316378c0e9263d43374732f733dafb7.html

Ok, might be interesting. But generally, what benefit do you gain from that mode compared to "normal" unreal-mode? Did you some benchmarks? Is it faster? Or is the main advantage just that 32-bit code won't need 66h/67h prefixes and hence is a bit shorter?

---
MS-DOS forever!

> This is 32-bit real mode and the only restriction is that you
> cannot run any procedure above an address greater than 64K.

If the address must be less than 64k it sounds like you're only using 16 bits instead of 32?

I could be way off base here, but it sounds almost like you're using 16-bit protected mode and confusing it with 32-bit unreal mode. In 16-bit protected mode you can access ANY part of the 32-bit 4 GB memory space, but selectors (CS, DS, ES, FS, GS, SS) have a maximum 64k limit. I could be way off base, but that's kind of what it sounds like to me.

> > This is 32-bit real mode and the only restriction is that you
> > cannot run any procedure above an address greater than 64K.
>
> If the address must be less than 64k it sounds like you're only using 16
> bits instead of 32?

Think they meant CS has its D bit clear and EIP is not used, only IP. The "procedure" refers to code segment contents. So the data segments have higher limits but the CS cannot be used to access a code section larger than 64 KiB.

Side note: It appears both dosemu2 and qemu will not check segment limits in their interpreter or JIT modes (that is, no native DPMI, no KVM, no V86M).

---
l

> If the address must be less than 64k it sounds like you're only using 16
> bits instead of 32?
>
> I could be way off base here, but it sounds almost like you're using 16-bit
> protected mode and confusing it with 32-bit unreal mode.

No, Candyman is not confused. He talks about "32-bit real-mode", that is, the cpu is switched to protected-mode, CS is loaded with a "32-bit" selector ( D-bit = 1 ), and then the cpu is switched back to real-mode ( with the D bit in CS attr still set ).

This is an interesting variant of "unreal-mode", but has limitations. I never tried myself, but I guess that any INT that's executed will clear hiword of EIP.

---
MS-DOS forever!

Hello Japheth, hello ecm, hello bretjohn,

> No, Candyman is not confused. He talks about "32-bit real-mode", that is,
> the cpu is switched to protected-mode, CS is loaded with a "32-bit"
> selector ( D-bit = 1 ), and then the cpu is switched back to real-mode (
> with the D bit in CS attr still set ).

I see Michal Necasek has this to say about this mode (https://www.os2museum.com/wp/a-brief-history-of-unreal-mode/):

> It is also possible to set the D bit in CS [for unreal mode], changing the default operand size to 32-bit. This may reduce the size of unreal code if it is largely 32-bit (by obviating the need for overrides). Unfortunately, this again causes serious trouble with interrupts, because existing 16-bit code cannot run correctly with the D bit set. It is possible to switch to protected mode, clear the D bit, and execute the 16-bit handler every time an interrupt occurs, and in fact it’s exactly what fasm does (or at least did in some versions), but with so much mode switching and complexity, the advantages of unreal mode are rapidly lost. ...

> A larger problem is that the "advanced" aspects of unreal mode may not be implemented identically across CPU generations and vendors, precisely because they have never been documented. ... Protected mode, on the other hand, works consistently.

Thank you!

---
https://gitlab.com/tkchia · https://codeberg.org/tkchia · 😴 "MOV AX,0D500H+CMOS_REG_D+NMI"

> I see Michal Necasek has this to say about this mode
> (https://www.os2museum.com/wp/a-brief-history-of-unreal-mode/):

Thanks! ... and here's the fasm author's comments:
https://board.flatassembler.net/topic.php?t=11940

---
MS-DOS forever!

> > I see Michal Necasek has this to say about this mode
> >
> (https://www.os2museum.com/wp/a-brief-history-of-unreal-mode/):
>
> Thanks! ... and here's the fasm author's comments:
> https://board.flatassembler.net/topic.php?t=11940

thanks for both links; interesting!

however, I wonder: why would FASM run significant faster in unreal then inprotected mode? shouldn't this be mostly identical as there shouldn't be too much interrupt activity?

Some of the previous versions of the NDN file manager cause the computer to freeze on DosBox-X. This applies to NDNs that use the DOS32A dos extender. This takes place when saving the program configuration. I don't know if it's the emulator's fault or the program's. This situation never happened on DOSBox 0.74-3. Below is a link to one of the NDN versions to test.

http://www.ndn.muxe.com/download/file/ndn_2_31_5309_bin_d32.exe

See also AVI movie:
https://megawrzuta.pl/download/5b3d2edb6b73d3182779e062731e58c3.html