You can install MSDOS in DOSBOX. It's just like a running computer. I'm not sure it will respond to special EMM386 settings though.

What do you mean "install"? Like to a directory on my real HD which is mounted as C: under DOSBox? And where will the boot sector will be written?

And even if it works, how will I mount the directory that contains TBRA afterwards?

You can't install DOS in DOSBox, but you can mount a bootable disk image of DOS in DOSBox and boot from it. It will lose access to any mounted folders from your physical disks when you do, though.

Sample usage of a harddisc image in DOSBOX

h-a-l-9000 wrote:

Sample usage of a harddisc image in DOSBOX

Thank you for this link. I believe it brings me closer to my cause.

Ok, I now have a bootable HD image that works under DOSBox. However, to run this game (and probably others) I need some DOS files on this HD. For starters, I'll need the HIMEM.SYS and EMM386.EXE.

So, I took the images of the three MS-DOS 6.22 installation disks that I happen to have and booted them under DOSBox so I can make a full installation of MS-DOS 6.22 on the HD image. However, I got this error:
"A disk error was detected while writing new boot record to your first hard disk".
Since that failed, I decided to manually copy the two files that I need. The problem is, they appear as EMM386.EX_ and HIMEM.SY_, so I renamed them. But when I had my CONFIG.SYS with the line DEVICE=HIMEM.SYS in it, the HDD image always froze on booting.

So I guess there are two possibilities - 1. Renaming HIMEM.SY_ to HIMEM.SYS is not a good solution, and I need the real file. If this is the case, can I install the files from my DOS 6.22 installation disks without it trying to overwrite the HDD boot? If not, is there somewhere that I can download these files?
2. DOSBox can't handle HIMEM.SYS at all. If this is the case, well... can I still make some extended memory available?

Thanks

By the way - it seems that even though no device drivers are loaded when I boot this HD, I still get SoundBlaster support! How can it be? There's no mouse support (unless I load a driver), after all.

Files that end in .??_ are compressed. You can use EXPAND.EXE (which should be included both on your DOS disks and with every verison of Windows) to decompress them.

Thanx, HunterZ. It worked. But now when the HD boots, I get:

ERROR: No available extended memory was found. XMS Driver not installed.

Is there something I can do? Like add parameters to the HIMEM.SYS line or to DOSBox? I already have xms=true in DOSBOX.CONF...

Hmm... I think you can add /v or /verbose or something similar to device=himem.sys in config.sys and then see if it's loading properly. You may want to also set xms=false in dosbox.conf so that it will let HIMEM.SYS provide the XMS instead of trying to do it itself.

I should mention that I haven't yet tried booting MS-DOS inside of DOSBox myself.

for hdd boot you HAVE to set xms and ems to false in dosbox.conf. And you have to add Device=himem.sys to config.sys. You can even write Device=himem.sys /testmem:off to speed things up (you need to pint eh line to the actual location of himem.sys though)

SirGraham wrote:

By the way - it seems that even though no device drivers are loaded when I boot this HD, I still get SoundBlaster support! How can it be? There's no mouse support (unless I load a driver), after all.

Real, physical SoundBlaster cards work without a driver in almost all DOS programs, only the physical card needs to be there; the games contain their own code for talking to it. Same in dosbox: only the emulated card needs to be there -- and it is, no matter whether you boot a DOS inside dosbox or you don't.

The mouse, on the other hand, is almost always used through a driver by DOS programs. Booting DOS seems to clobber the INT33 vector to this driver.

The reason, of course, is that not all mice talked to the computer in the same way, so a standard driver interface developed to solve the problem. This was especially helpful when PS/2 mice came along.

The same thing happened with CD-ROM drives and SVGA cards (via VESA drivers), although by the late DOS era most CD-ROM drives used the ATAPI standard and most SVGA cards had VESA support in the BIOS.

The SoundBlaster doesn't need drivers because it (and the Adlib) set the standard and everyone else cloned it closely. It did have drivers available (I remember sound.com, ctsomething.drv, and similar) but only a few games bothered to use them, since it was just as easy to talk to the hardware directly.

Dominus wrote:

for hdd boot you HAVE to set xms and ems to false in dosbox.conf. And you have to add Device=himem.sys to config.sys. You can even write Device=himem.sys /testmem:off to speed things up (you need to pint eh line to the actual location of himem.sys though)

Yeah, I finally set ems and xms to false, and then HIMEM.SYS and EMM386.EXE were loaded fine, and the game ran quite flawlessly (although some parts were way to slow unless I raised the CPU Cycles to ~20,000, and I have a P4 2.8GHz!)

However, EMM386.EXE didn't work perfectly, unless I added 'noems' to the line in CONFIG.SYS; if I didn't add 'noems' I got some errors, as seen in the attached picture, and the game crashed at a specific point. Not only did it cause the crash, it also corrupted the game's files, and even when I added 'noems' again, the game kept crashing in the same location until I re-copied its files to the HD image.
Is there a way to use ems with EMM386 under DOSBox? I already disabled DOSBOX.CONF's ems...

TeaRex wrote:

Real, physical SoundBlaster cards work without a driver in almost all DOS programs, only the physical card needs to be there; the games contain their own code for talking to it. Same in dosbox: only the emulated card needs to be there -- and it is, no matter whether you boot a DOS inside dosbox or you don't.

Well, maybe drivers are not required, but what about all that SET BLASTER stuff? I thought that was necessary.

The mouse, on the other hand, is almost always used through a driver by DOS programs. Booting DOS seems to clobber the INT33 vector to this driver.

This is interesting, I've tried using MS Mouse Driver v11, and it doesn't find a mouse under DOSBox. So I used something called TRMouse v9.01, and it did work. However, the mouse worked only in some games (Maniac, SQ3, Big Red Adventure (fortunately!)), but didn't work in others (QFG3, Countdown). Is there a better mouse driver I can use under DOSBox?

SirGraham wrote:

Yeah, I finally set ems and xms to false, and then HIMEM.SYS and EMM386.EXE were loaded fine, and the game ran quite flawlessly (although some parts were way to slow unless I raised the CPU Cycles to ~20,000, and I have a P4 2.8GHz!)

The CPU cycles are an absolute value, not relative to your processor speed. Even on a 280 GHz processor you'd need to raise CPU cycles.

SirGraham wrote:

Well, maybe drivers are not required, but what about all that SET BLASTER stuff? I thought that was necessary.

For a couple of programs it is. Many ask for the values in their installation routine though. Some can even find the values automatically by probing for the card; that can have negative side-effects though if there is something else at the probed address.

SirGraham wrote:

Is there a better mouse driver I can use under DOSBox?

Good question, I'm also looking for one.

1. mouse:
a) try the mouse driver from here:
Der Patrizier: Mouse Problems
b) or try ctmouse
http://cutemouse.sourceforge.net/

2. ems:
try adding this parameter FRAME=E000 in the emm386.exe line

and disable umb in dosbox.conf

The paramater D=64... what does it do actually ? it sounds like a dma buffer parameter or so.

From the EMM386.EXE help entry in DOS 6.22:

D=nnn
Specifies how many kilobytes of memory should be reserved for buffered direct memory access (DMA). Discounting floppy-disk DMA, this value should reflect the largest DMA transfer that will occur while EMM386 is active. Valid values for nnn are in the range 16 through 256. The default value is 32.

robertmo wrote:

ems:
try adding this parameter FRAME=E000 in the emm386.exe line

I wonder, why is that so? Given that D000 is by far the most common location for the page frame, shouldn't dosbox keep that area free for this purpose if you say ems=false and umb=false?

No, because it contains the callbacks and other stuff.
Seg e000 was used on my original lim-ems card as well, and iirc emm386
used this segment on my other PCs as well.

would it be possible to place callbacks and other stuff in E000 and leave D000 free?