VOGONS


First post, by Miraculix

User metadata
Rank Newbie
Rank
Newbie

Over the last weeks I was browsing your forum and wiki a lot. Reading there was very helpful over choosing a sound card for my 2600k—A sound card which is able to emulate a Sound Blaster on DOS.

Long story short, I'm a Linux user. Whose familiar knows that starting Linux requires a bootloader. Though, it's also possible to start it from DOS, too. That's what I do for a quite a while now. In the beginning I just had my pleasure over starting Linux by typing LIN on a DOS prompt. It was basically sort of a retro joke. Over time I spent more and more time on DOS. Installing drivers, programs and games. The only thing missing was sound.

That's where the specs begin. On this 2011 PC the only cards able to emulate a Sound Blaster are Yamaha YMF7x4 (not tested) and Aureal Vortex (what I bought in 2019). An Audio PCI 5200 (ES1373) did not work with the H67/IT8892 PCI-PCIe-Bridge configuration.

Motherboard: Gigabyte GA-H67A-UD3H-B3 (rev. 1.1)
CPU: Intel i7 2600k
RAM: 16 GB
HDD: Hitachi HDS72101 (1 TB)
SSD: Crucial RealSSD C300 (64 GB)
Optical Drive: LG BH10LS30
Serial & Parallel Card: MosChip PCI 9865 Multi-I/O Controller
Sound Card: Aureal Vortex 1
Keyboard: Cherry G83
Mouse: Microsoft IntelliMouse Optical
Monitor: Samsung SyncMaster SA450

Now what works and what doesn't. Keyboard is connencted via USB and works just as supposed to. Onboard Intel HD3000 Graphics works quite fine. There's even a VESA Mode for my monitors native resolution of 1920x1200 pixel. Hard drive and SSD are both visible to DOS in AHCI mode, though the SSD is formated for Linux. DOS, FreeDOS 1.2 to be specific, lives in the first two gigabyte on the HDD, that's my boot partition. The rest of the HDD is also for Linux. This was what worked without the need of driver installation.

With HIMEMX.EXE 4 GB of RAM are addressable and MEM reports 3 GB to be free. In order to get the optical drive working I had to load AHCI.SYS from HP. It's working to read CDs and DVDs and propably BDs too, but I couldn't test them yet. Burning is not possible, because I couldn't find an ASPI driver. The I/O controller came with a DOS driver, GEMDOSIN.EXE its name. After installation MS-DOS' MSD could see the serial ports but not the parallel port, HWINFO then saw them all. However, I did not actually test the ports function yet. Mouse is connected with an USB to PS/2 adapter in order to get it working. Connection via USB, like the keyboard, wasn't successful. Now, three out of five buttons and the wheel are working with CTMOUSE.EXE. For the onboard network card, a RTL8111B, I found the driver RTGND. Combined with DIS_PKT and MSCLIENT I'm on the internet with DOS. Finally the sound card, the real mode driver ASP4DOS.COM provides Sound Blaster Pro 2.0 emulation. It seems to work better with newer games than older ones. Like Day of the Tentacle works fine and Maniac Mansion doesn't make a piep. DOOM, Settlers 2 and Wolfenstein 3D were also found working.

As mentioned, it's not exactly a retro PC. Yet I like this more or less 100% IBM compatible machine with it's old fashioned BIOS telling me about the good old times between 1984 and 2011 on every boot. If someone, then it's you who can understand my pleasure about compatibility for 35 years now.

PS: Actually I wonder why in all those years really no one ever published an open source Sound Blaster emulation for AC97 or HDA. Linux and BSDs all have free drivers for all those cards which look to be very generic. There's even MPXPLAY which supports the newer audio standards on DOS. Did I miss something or is this a task waiting for me?

PPS: A sidenote on the Audio PCI 5200 is that they didn't make use of electrolytic capacitors on it. Without the most likely thing to break in consumer electronics it's IMHO a very good design, unlikely to break. I found it especially noteworthy to mention, since in contrast to the ES137x sound cards I've seen all others had electrolytic capacitors mounted.

Reply 3 of 7, by chinny22

User metadata
Rank l33t++
Rank
l33t++

Welcome,
While no one will say that running dos on such a modern system is the best solution it does bring a certain type of joy and it still feels more um? authentic? then running dosbox

Reply 4 of 7, by Miraculix

User metadata
Rank Newbie
Rank
Newbie
chinny22 wrote:

Welcome,
While no one will say that running dos on such a modern system is the best solution it does bring a certain type of joy and it still feels more um? authentic? then running dosbox

Yeah, guess you can relate. I can't put it in words either. To me, running DOSBox in a window is like going into the garden with its fence and well. It's great to have and has lots of benefits over running DOS on real hardware. Yet I also like going into the wilds from time to time. Now I've got both worlds on the same PC.

Especially programming is a very different beast on DOS, too. There's just no memory protection in real mode. Which took me a while to realise that this is a hardware thing. Not even the administrator is going to read an applications memory from another one on Linux or modern Windows. That's kernel stuff overthere. Here on DOS I can access 4 GB of memory flat. Not actually with Turbo C++, though SmallerC is a more modern compiler, able to create unreal mode programs without any hassle. With this ability it's possible to access e.g. PCIe hardware, which is memory mapped, and then have a look into the datasheet to use it. DOSBox on the other hand is just a legacy emulation which probably doesn't even have PCI (for what anyway?). If you're interested in things like this, I'll report when I made my HDA beep for the first time.

The other thing is, that I feel like this x86 compatible era in computing is coming to an end. In hindsight of Spectre and Meltdown there's probably a new architecture coming soon. Guess my next PC won't even run DOS anymore. It makes me sad, when I think about such future PCs. They will be most likely the same way our smartphones are today.—Not even possible to open with an open source operating system we change happily but not install by any means. To me there's a really big difference in programming my hardware directly or against someone else's software to access my hardware. If the first is not possible, then I don't own the hardware. Comparable with going to the movies or buying a film. I'm silently hoping for something like the AMD64 coup on IA64 to happen, though direction is more towards owning less, e.g. streaming.

PS: A definition of unreal mode is still troublesome to me. Wikipedia says it's not a separate addressing mode, yet it enables the use of 4 GB main memory. How would you explain it to your grandma or a first grader? Would you talk about 32-bit real mode or 32-bit zombie/undead protected mode or 16/32-bit mixed real mode or would 16-bit real mode with some 32-bit registers be more accurate?

Reply 5 of 7, by Jo22

User metadata
Rank l33t++
Rank
l33t++

I think it would be even more confusing if we take AMD64 into account. Or should I say x64 or x86-64 ? 😀
What I think is most interesting -or most weird- is the fact that 16-Bit Protected Mode code can be executed in Longmode-Compatibility Mode.

Let's imagine a hacked version of WIndows 3.x that entirely runs in Longmode without any need for V86.. ^^
This kind of reminds me of Wabi, WINE's spritiual predecessor, that ran on Linux long long ago (-> my clips).
If my memory serves, it made use of one of the Linux kernal's 16-Bit features (yepp, still there).
Without any help of V86 or the MS-DOS code (WABI had no support for DOS or DOS apps, it relied on DOSemu for that).

That being said, Longmode and MS-DOS (or any DOS) are not friends. How about a new 64-Bit DOS ? 😉

It is possible to enter long mode under DOS without a DOS extender,[58] but the user must return to real mode in order to call B […]
Show full quote

It is possible to enter long mode under DOS without a DOS extender,[58] but the user must return to real mode in order to call BIOS or DOS interrupts.

It may also be possible to enter long mode with a DOS extender similar to DOS/4GW, but more complex since x86-64 lacks virtual 8086 mode.
DOS itself is not aware of that, and no benefits should be expected unless running DOS in an emulation with an adequate virtualization driver
backend, for example: the mass storage interface.

Source: https://en.wikipedia.org/wiki/X86-64#DOS

Edit: Since UEFI (or its successor. ModerFW) plans to drop the CSM (BIOS compatibility layer) somewhen around 2020,
there's a chance that we cannot any longer run any classic OS, like 32-Bit Windows (Win XP, 2k, Win9x) or DOS.
Well, at least not natively. Perhaps the FreeDOS project or the source code of PC-MOS/386 may help to overcome this.
The FreeDOS people are at least aware of this limitation, there's at least a hint on the official site ("some kind of UEFI bootstrap BIOS emulator")..
See http://www.freedos.org/contribute/ at the very bottom. In either case, direct hardware access is most important, IMHO.
That's one of the reasons why this hobby is so life and sound. Lots of new hardware was build in the last years. 😄

"Time, it seems, doesn't flow. For some it's fast, for some it's slow.
In what to one race is no time at all, another race can rise and fall..." - The Minstrel

//My video channel//

Reply 6 of 7, by Miraculix

User metadata
Rank Newbie
Rank
Newbie
Jo22 wrote:
I think it would be even more confusing if we take AMD64 into account. Or should I say x64 or x86-64 ? :) What I think is most […]
Show full quote

I think it would be even more confusing if we take AMD64 into account. Or should I say x64 or x86-64 ? 😀
What I think is most interesting -or most weird- is the fact that 16-Bit Protected Mode code can be executed in Longmode-Compatibility Mode.

Let's imagine a hacked version of WIndows 3.x that entirely runs in Longmode without any need for V86.. ^^
This kind of reminds me of Wabi, WINE's spritiual predecessor, that ran on Linux long long ago (-> my clips).
If my memory serves, it made use of one of the Linux kernal's 16-Bit features (yepp, still there).
Without any help of V86 or the MS-DOS code (WABI had no support for DOS or DOS apps, it relied on DOSemu for that).

That being said, Longmode and MS-DOS (or any DOS) are not friends. How about a new 64-Bit DOS ? 😉

It is possible to enter long mode under DOS without a DOS extender,[58] but the user must return to real mode in order to call B […]
Show full quote

It is possible to enter long mode under DOS without a DOS extender,[58] but the user must return to real mode in order to call BIOS or DOS interrupts.

It may also be possible to enter long mode with a DOS extender similar to DOS/4GW, but more complex since x86-64 lacks virtual 8086 mode.
DOS itself is not aware of that, and no benefits should be expected unless running DOS in an emulation with an adequate virtualization driver
backend, for example: the mass storage interface.

Source: https://en.wikipedia.org/wiki/X86-64#DOS

Edit: Since UEFI (or its successor. ModerFW) plans to drop the CSM (BIOS compatibility layer) somewhen around 2020,
there's a chance that we cannot any longer run any classic OS, like 32-Bit Windows (Win XP, 2k, Win9x) or DOS.
Well, at least not natively. Perhaps the FreeDOS project or the source code of PC-MOS/386 may help to overcome this.
The FreeDOS people are at least aware of this limitation, there's at least a hint on the official site ("some kind of UEFI bootstrap BIOS emulator")..
See http://www.freedos.org/contribute/ at the very bottom. In either case, direct hardware access is most important, IMHO.
That's one of the reasons why this hobby is so life and sound. Lots of new hardware was build in the last years. 😄

Very interesting channel, already watched a view videos.

Is there also something like 64-Bit Unreal Mode?

This ModernFW sounds quite promising. It seems like it's only missing some sort of BIOS emulating OS to load before DOS to provide a legacy interface. If it's then going to be really that minimal as described, it could be possible without that much additional overhead. We'll see.

Another thing I'm wondering about is if it would be possible to run Real Mode software in Ring 0 of Protected Mode. Basically as a means to circumvent memory protection.

Reply 7 of 7, by Jo22

User metadata
Rank l33t++
Rank
l33t++
Miraculix wrote:

Very interesting channel, already watched a view videos.

Is there also something like 64-Bit Unreal Mode?

Hi, good question - I'm not sure, haven't thought about such a possibility yet. 😐

Miraculix wrote:

This ModernFW sounds quite promising. It seems like it's only missing some sort of BIOS emulating OS to load before DOS to provide a legacy interface.
If it's then going to be really that minimal as described, it could be possible without that much additional overhead. We'll see.

Hi, yes, I hope so. If it comes close to OpenFirmware, it's on a good way. 😉
Let's hope that some will create a BIOS payload. Maybe something like SeaBIOS or the BIOS from Bochs/Qemu. 😀

Miraculix wrote:

Another thing I'm wondering about is if it would be possible to run Real Mode software in Ring 0 of Protected Mode. Basically as a means to circumvent memory protection.

Hi, I think Windows 3.x in Standard Mode uses something like that, but I'm speaking under correction. 😅
In essence, well written Win16 software uses 64KB chunks, but doesn't use any kind of segment arithmetics (Enhanced Mode uses 4KB chunks normally).
Such programs are the same in Real-Mode as they are in Protected-Mode, so they may fall into that special case category that Wikipedia once mentioned..

The Intel iAPX 286 Programmer's Reference Manual states the protected mode is just an overlay over the 80186 instruction set, an […]
Show full quote

The Intel iAPX 286 Programmer's Reference Manual states the protected mode is just an overlay over the 80186 instruction set, and indeed the 80286 protected
mode, for application programmers, didn't add much beyond having access to up to 16 MB of physical memory and 1 GB of virtual memory (512 MB global, 512 MB local) and
was binary compatible with real-mode code, so in theory, 8086 and 80186 application code could run in protected mode if it followed these rules, although it will run slower
than in real mode because loading segment registers is slower:

no segment arithmetic
no use of privileged instructions
no direct hardware access
no writing to code segment (which means that self-modifying code is never allowed)
no executing data (that, together with segmentation did provide some buffer overflow protection then)
don't assume that segments overlap

In reality, almost all DOS application programs violated these rules, for lack of replacement DOS or BIOS calls or because of the insufficient level of performance of such calls.
The most common violations were segment arithmetic and direct hardware access. Also some of the BIOS interrupts use numbers that was reserved by Intel.
In other words, protected mode was less compatible with DOS applications than in theory real mode applications would be and so there was a need for virtual 8086 mode,
which came with the 386.

Source (old): https://en.wikipedia.org/w/index.php?title=Pr … &oldid=70173835

That being said, I believe that the article assumed that a normal copy of MS-DOS was used. A special flavour of DOS that supported/assisted Protected-Mode use,
might have been able to allow more of Protected-Mode's features to be used. Digital Researchs Concurrent DOS 286 tried to provide DOS "VMs" without V86, I believe.

https://en.wikipedia.org/wiki/Multiuser_DOS#C … _and_FlexOS_286

"Time, it seems, doesn't flow. For some it's fast, for some it's slow.
In what to one race is no time at all, another race can rise and fall..." - The Minstrel

//My video channel//