Difficulties in DOS on real hardware
Re: Difficulties in DOS on real hardware
Generally, in the DOS protected mode programming one of the most problematic things are any routines using hardware interrupts or hardware callbacks. There are often problems when interrupt handler wants to use memory which is swapped out from memory pool.
So your application can be more stable if the computer does not use any memory manager with swapping.
In other words - does something change if you use plain DOS (not windows 9x) and "HDPMI32 -r" manager besides standard CWSDPMI ?
So your application can be more stable if the computer does not use any memory manager with swapping.
In other words - does something change if you use plain DOS (not windows 9x) and "HDPMI32 -r" manager besides standard CWSDPMI ?
Re: Difficulties in DOS on real hardware
VirtualBox works better than most (or KVM on Linux) if you have VT-X hardware extensions. I use that on my main desktop. My laptop is too old for that, though. VMware had some DOS extensions ("vmsmount", see FreeDOS -> Software -> Networking) that allowed sharing files. Same for older (2011?) VirtualPC, it has drivers somewhere on MS' site. On Windows (e.g. 7), you can natively mount a .VHD in Explorer (tested briefly by me). You can also unpack .VHD with "7z" (7-Zip). On Linux you can use "libguestfs-tools". See Ulrich Hansen's Mount the Image File for more info.keenmaster486 wrote:If you want a good emulator to test on, use 86Box or PCem, and emulate a 386DX with MS-DOS 6.22 or the like. Easy to copy files back and forth using ISO images and mounting them as CDs.
DOSBox is "only for games". It lacks lots of stuff. Yes, it's good for SVGA or SB16 or similar emulation. It uses its own fake DOS, so even that's not real. A true DOS (like FreeDOS or MS-DOS or PC-DOS or DR-DOS or ROM DOS or ...) is better overall. (Though DOSBox has several forks that improve upon "some" things, e.g. vDosPlus.) DOSBox only goes up to 64 MB of memory max anyways (but default 16 MB only), which is okay for most old games. (Please don't be naive and think that's enough. It's very easy to surpass that, e.g. DJGPP/G++ or RAM disk or almost anything, actually. XMSv2 was limited to 64 MB max, but XMSv3 wasn't. CWSDPMI can at least normally use almost 2 GB. Similarly, HX's HDPMI32. See what I mean?)keenmaster486 wrote: I have a feeling that if I was developing directly on such a machine instead of using DOSBox for primary testing, I might be able to get it to work, as DOSBox tries to provide an optimal environment for DOS programs to run in (i.e. lots of available memory, most compatible video card, etc.). You won't usually get this environment on a real machine. So maybe some things that I am doing are working in DOSBox because the emulation isn't perfect. But on the other hand, a lot of the problems will occur even before my program has done anything useful, which to me indicates that it is an issue with FBGFX.
FreePascal 3.x has i8086-msdos target support (usually cross-compiled atop modern Linux or Windows). Or you could use ancient Turbo Pascal itself (5.5 is roughly "freeware"). Even OpenWatcom requires 386+ host.keenmaster486 wrote: There are a lot of old Pentium-class systems still out there on the market for cheap. Less 486 and 386 but they can be found. I got myself a 286 the other day - obviously useless for FB stuff but it will be fun to play around developing in OpenWatcom.
XP was fairly good but not perfect. Of course, Vista disallowed booting atop FAT, didn't allow full-screen, and had the DPMI limit bug / quirk (undocumented registry fix in SP1), among other bugs. There were even some bugs in XP that were never fixed, so DJGPP had to workaround some of them. (They called them "Win2k fixes", e.g. patchlevel 2 of 2.03p2, which was "current" for many many years.) I forget the details (and never really understood, "LAR" ??), but it saved DJGPP from dying back then. So it worked okay on XP but less so on Vista. Some people imply that latest (32-bit) Win10 builds break DPMI entirely (since a few months), dunno, don't use it. A lot of people just run old Windows under VMs. I think that's what some DJGPP devs were still doing recently (Juan and Andris).keenmaster486 wrote: Just for your reference, the Windows XP NTVDM is not great for testing DOS stuff. It was always horrible for compatibility back in the day; I remember pulling my hair out trying to get things to work right in it. If you do have a Windows 98 VDM, that is much better. I do notice that a lot of the time running my game engine in Windows 95/98 will work better than in pure DOS... same problem as running it in DOSBox; Win9x will provide as good an environment as it can for DOS programs.
Re: Difficulties in DOS on real hardware
No, it's not preferred or supported by anyone, AFAIK. (There's basically no support for sound or networking or even power management on newer machines.) This old Dell laptop (2009/2010-ish?) has a diagnostics partition that uses DRMK ("Dell Real Mode Kernel", aka barely-modified DR-DOS). In other words, you can dual boot multiple OSes, obviously, and that can include DOS as long as you have a BIOS (or CSM or similar, which I've never used, and CSM will disappear by 2020 soon, hence the importance of VT-X and VMs like VBox). My Core i5 desktop (circa 2011? Nehalem Westmere, better VT-X, woot!) recently got a new hard drive. Before that, it was triple booting FreeDOS, Lucid Puppy Linux, and Win7. For now, it's Win7 only, but you can (since Vista) resize/shrink the NTFS partition in order to install other OSes (and use EasyBCD or similar to configure the native boot manager). But I can also just boot a DOS jump drive (made by RUFUS), so dual booting is not crucial. But I got a lot of use out of that machine over the years. (I think it saw 2.9 GB free memory in DOS whereas on my laptop it gets a little over 3 GB. But you have to call sbrk() twice, allegedly, in DJGPP, in order to allocate more than 2 GB overall. A lot of things just assume a 2 GB address space, if even that much. I never used that much RAM, honestly, but I do enjoy working atop a really big RAM disk! Probably why the old HDD lasted so long!) FAT32 is pretty universally supported by most OSes, so it's easy to download or exchange files. Easier would be a working packet driver for networking tools (Wget, Curl, Links2), but hardware drivers are quite rare these days. FreeDOS is still barely updated, but it's a very small team.coderJeff wrote:Continuing on an earlier thought...all my old hardware is broken, or rotted, or gone by now. So I just don't find any need to write something specific to DOS. Is any manufacturer specifically still making a 386(DX) micro where DOS is the preferred "OS"? I have trouble imagining that such a thing is happening.
-
- Posts: 7
- Joined: Feb 20, 2019 21:28
Re: Difficulties in DOS on real hardware
Hmm, interesting - I've tried HDPMI32, but not with the -r option. Why would installing as a TSR change anything from just running it as a one-time instance? (other than overriding programs which search in the current path for CWSDPMI)Laaca wrote:HDPMI32 -r
Yes - but it will emulate at least a 686 or something. Everything will "just work" in it. So it is not what I would recommend for testing DOS stuff - the reason being you have to develop for the lowest common denominator, which in this case is a 386SX/16 or something. The whole issue here is that FB programs will run great on 586+ machines, but tend to fail on 386 and 486.rugxulo wrote:VirtualBox works better than most
My goal is to fit my game into less than 8 MB of RAM. Currently in its highly un-optimized state it runs in under 16. I'm not too worried about meeting my requirement.rugxulo wrote:64 MB of memory max anyways (but default 16 MB only), which is okay for most old games. (Please don't be naive and think that's enough. It's very easy to surpass that, e.g. DJGPP/G++ or RAM disk or almost anything, actually. XMSv2 was limited to 64 MB max, but XMSv3 wasn't. CWSDPMI can at least normally use almost 2 GB. Similarly, HX's HDPMI32. See what I mean?)
Intel still produces DOS drivers for its (even gigabit) ethernet chips, believe it or not.rugxulo wrote:No, it's not preferred or supported by anyone, AFAIK. (There's basically no support for sound or networking or even power management on newer machines.)
You can still install and use DOS on any modern x86 PC. They are still compatible with the original IBM PC under the hood. But of course you will get no floppy drive access or sound card support, or DMA, or anything like that, unless you throw in some very old PCI expansion cards. But even the video cards are still CGA/EGA/VGA compatible, surprisingly.
Re: Difficulties in DOS on real hardware
(virtualbox)
(Nobody seems to have such real hardware anymore, so what does it really matter then?)keenmaster486 wrote: The whole issue here is that FB programs will run great on 586+ machines, but tend to fail on 386 and 486.
Re: Difficulties in DOS on real hardware
I was also wondering why one wants to make game in 2019 for a processor introduced in 1989 (i486) with a compiler from 2019?marcov wrote:(virtualbox)(Nobody seems to have such real hardware anymore, so what does it really matter then?)keenmaster486 wrote: The whole issue here is that FB programs will run great on 586+ machines, but tend to fail on 386 and 486.
Maybe 'just for fun', but does that require the latest compiler version?
-
- Posts: 7
- Joined: Feb 20, 2019 21:28
Re: Difficulties in DOS on real hardware
Why does a DOS version exist at all except to make programs for DOS computers?
Nobody's running solely pure MS-DOS on Pentium II+. Those machines almost always have Windows 9x. DOS is for 8088/286/386/486, and maybe early Pentium.
I'm developing for old machines. If you open your eyes and look around, then you will notice that there is a large community of people who like playing old DOS games on real hardware. This is why prices for DOS machines on eBay are so high...
To give you an idea of how much demand there is for this sort of thing, check out this project which is being released right now on floppy disk: https://www.kickstarter.com/projects/19 ... for-ms-dos
As for versions of the compiler... well, I am looking into developing for real mode 16-bit DOS using OpenWatcom. Of course this requires learning a lot about the 16 bit memory model, but that's OK.
Old versions of the FreeBasic compiler probably will not work, as I know the DOS graphics library was hopelessly broken until version 1.0 or something.
Nobody's running solely pure MS-DOS on Pentium II+. Those machines almost always have Windows 9x. DOS is for 8088/286/386/486, and maybe early Pentium.
I'm developing for old machines. If you open your eyes and look around, then you will notice that there is a large community of people who like playing old DOS games on real hardware. This is why prices for DOS machines on eBay are so high...
To give you an idea of how much demand there is for this sort of thing, check out this project which is being released right now on floppy disk: https://www.kickstarter.com/projects/19 ... for-ms-dos
As for versions of the compiler... well, I am looking into developing for real mode 16-bit DOS using OpenWatcom. Of course this requires learning a lot about the 16 bit memory model, but that's OK.
Old versions of the FreeBasic compiler probably will not work, as I know the DOS graphics library was hopelessly broken until version 1.0 or something.
Re: Difficulties in DOS on real hardware
I don't spend much time on the DOS version because the development cycle is truly tedious compared to win/linux.
Here's some areas for improvement:
- a really good emulator that faithfully respects the instruction set (386/486), and peripherals (video, etc). It's possible that over the years, that newer CPU instructions are used in the code generation, but no alternatives for older CPUs.
- something other than disk images (ISO/floppy) to transfer files, like serial comm link, or networking
- fbgfx on DOS is a hairy beast, using timer interrupts for screen updates. All data and code has to be carefully locked/protected. fbgfx patches over the years may not always respect this.
- in fbgfx, provide an alternate means to update screen using code statements instead of interrupts. When the dos gfx drivers work, it's great. When they don't, it's really tough to debug.
- careful attention to DJGPP environment, using tools built for the target CPU, if using fbc-dos on the DOS system
- cross-compile: even if fbc runs on some other host, use cross-compile to DOS tools to build the exe's for transfer to the DOS system, rather than the fbc-dos itself on the DOS system.
Here's some areas for improvement:
- a really good emulator that faithfully respects the instruction set (386/486), and peripherals (video, etc). It's possible that over the years, that newer CPU instructions are used in the code generation, but no alternatives for older CPUs.
- something other than disk images (ISO/floppy) to transfer files, like serial comm link, or networking
- fbgfx on DOS is a hairy beast, using timer interrupts for screen updates. All data and code has to be carefully locked/protected. fbgfx patches over the years may not always respect this.
- in fbgfx, provide an alternate means to update screen using code statements instead of interrupts. When the dos gfx drivers work, it's great. When they don't, it's really tough to debug.
- careful attention to DJGPP environment, using tools built for the target CPU, if using fbc-dos on the DOS system
- cross-compile: even if fbc runs on some other host, use cross-compile to DOS tools to build the exe's for transfer to the DOS system, rather than the fbc-dos itself on the DOS system.
Re: Difficulties in DOS on real hardware
What about this one?keenmaster486 wrote:As for versions of the compiler... well, I am looking into developing for real mode 16-bit DOS using OpenWatcom. Of course this requires learning a lot about the 16 bit memory model, but that's OK.
Old versions of the FreeBasic compiler probably will not work, as I know the DOS graphics library was hopelessly broken until version 1.0 or something.
But with Bob Zale dead, the website dead and the future unclear, maybe not the best choice.
Re: Difficulties in DOS on real hardware
What aspects of the graphics library do you need?Old versions of the FreeBasic compiler probably will not work, as I know the DOS graphics library was hopelessly broken until version 1.0 or something.
I have a few graphical programs that I've run in DOS on a 486. I compiled using FB 0.23. The main functionality that I use is SCREEN/SCREENRES and SCREENPTR. I just render straight to the memory buffer, with the occasional LINE or PRINT to add something on top.
The only problem I had in DOS with FB 0.23 related to gfx is that it's not very fast. I don't have direct access to video memory and when FB updates the screen it appears to only use banked VESA modes. Aside from that, I had a few mysterious GPFs (something related to resizing arrays I suspect)
Since it's DOS, you could always skip FB GFX functions and use inline asm to set the video mode and update the screen too.
Re: Difficulties in DOS on real hardware
Why limit to older processors when newer work fine?keenmaster486 wrote:Why does a DOS version exist at all except to make programs for DOS computers?
People have run dos (and win3.x and win9x) just fine on P-II. I had a P-II laptop (233MHz) for quite a while with originally 16MB. Sure the accent was a bit more win9x, but rebooting to dos for a game would work just fine. (in my case Colonizations)Nobody's running solely pure MS-DOS on Pentium II+. Those machines almost always have Windows 9x. DOS is for 8088/286/386/486, and maybe early Pentium.
Sure. The guy that is doing the 16-bit Freepascal port (with openwatcom compatible assembler and linker built in) also is involved with that kind of demo scene like vibe. People do all kinds of weird things to kill time. Some even just "run"!I'm developing for old machines. If you open your eyes and look around, then you will notice that there is a large community of people who like playing old DOS games on real hardware. This is why prices for DOS machines on eBay are so high...
Well, my only old machine is a Quadra 840AV and a C=64, but that is for a different kind of old machine nostalgia :_)
But will they be using all old processors, becuase that was the discussion here.To give you an idea of how much demand there is for this sort of thing, check out this project which is being released right now on floppy disk: https://www.kickstarter.com/projects/19 ... for-ms-dos
Plural. tiny, small,medium, compact, large, huge.As for versions of the compiler... well, I am looking into developing for real mode 16-bit DOS using OpenWatcom. Of course this requires learning a lot about the 16 bit memory model, but that's OK.
The meaning of large varies though, specially the size of global variables.
Some compilers only allow 64k of global vars (but more on the heap). A mix of small and large as it were, this keeps legacy code that uses a lot of local vars faster (more near accesses), but a 64kb limit. Such compilers often have an xlarge where this limit (or optimization, depending on how you view it) is lifted. (but e.g. Turbo Pascal didn't, it went straight to 286 pm )
Most compilers do hybrids where code access data in the same compilation unit near, and global data far. Some even allow you to group your data in optimal segments yourself, so that redundant segment loads could be optimized away more readily. I however mostly used older 16-bit, not very optimizing compilers, that didn't have that, so my experience with such things is low.
Besides this there are often overlay and sometimes "mthread" models. Mthread is often some form of concurrent access, e.g. pthreads emulation or cooperative multitasking based on a simple timeslicer. I did work with overlays sometimes, though usually I was more datasize limited than codesize limited.
Re: Difficulties in DOS on real hardware
QEMU at least has "-cpu pentium" (etc.) to limit instructions. DOSBox itself by default is a 486 DX2, but it can also (only?) emulate a "slow" Pentium.keenmaster486 wrote:Yes - but it will emulate at least a 686 or something. Everything will "just work" in it. So it is not what I would recommend for testing DOS stuff - the reason being you have to develop for the lowest common denominator, which in this case is a 386SX/16 or something. The whole issue here is that FB programs will run great on 586+ machines, but tend to fail on 386 and 486.rugxulo wrote:VirtualBox works better than most
If you have CSM for your UEFI, maybe. Also, you can get a USB floppy drive (works at least for vanilla 1.44 MB, 3.5"). But bootable USB makes it less pressing (once you already have the files on a suitable hard drive or similar medium).keenmaster486 wrote:You can still install and use DOS on any modern x86 PC. They are still compatible with the original IBM PC under the hood. But of course you will get no floppy drive access or sound card support, or DMA, or anything like that, unless you throw in some very old PCI expansion cards.rugxulo wrote:No, it's not preferred or supported by anyone, AFAIK. (There's basically no support for sound or networking or even power management on newer machines.)
Re: Difficulties in DOS on real hardware
You mean like mTCP's FTP server? Also, I think there's already programs for copying via null modem, e.g. File Maven (maybe even MODE itself, dunno, not super familiar with it).coderJeff wrote: Here's some areas for [DOS] improvement:
- something other than disk images (ISO/floppy) to transfer files, like serial comm link, or networking
Again, I mentioned that you can transfer files via .VHD (natively mounted, e.g. in Win7) with Windows Explorer.
Re: Difficulties in DOS on real hardware
(No, I'm not a registered user.) AFAIK, the website isn't dead, it's just under new ownership. According to BTTR's Forum recently, you can still buy it via email.badidea wrote: What about [PowerBasic]?
But with Bob Zale dead, the website dead and the future unclear, maybe not the best choice.
Last edited by rugxulo on Mar 26, 2019 23:02, edited 1 time in total.
Re: Difficulties in DOS on real hardware
Retro City Rampage DX / 486 was made available for purchase in 2015. It was a slight improvement over the original. But it was a labor of love, basically done on the guy (Brian Provinciano)'s vacation! (It was basically a bonus version to the Win32 and Linux ports. There was also a soundless Win16 demo version.) And he used that as an excuse to improve his optimizations, so I think he even backported some fixes from there to improve the 3DS port!badidea wrote: I was also wondering why one wants to make game in 2019 for a processor introduced in 1989 (i486) with a compiler from 2019?
Maybe 'just for fun', but does that require the latest compiler version?
Yes, it actually ran on a 486 (but slightly different / limited with less than 8 MB of RAM). He used C++ / OpenWatcom 1.9 (circa 2010). It only supported PC speaker (but pleasantly, IMHO). I haven't played it recently, so I don't remember if I ever bothered using a mouse (or if it supported one). IIRC, it fit (compressed installer) on one floppy. I don't remember exactly, but I think it was a 386 PMODEW (LE) .EXE. Actually, OpenWatcom won't optimize (only tune) for beyond 386 anyways. So it doesn't automatically enable newer (e.g. SIMD) instructions (although I'm sure you can use inline asm if desired).