[ppgrainbow]

I want to be able to triple boot between Windows NT 4.0, MS-DOS 6.22 and Memtest86+ via GRUB4DOS and here is what I have so far.

1. MS-DOS 6.22 is in a 128 MB hard disk image and it was created using QEMU. The filename is MSDOS.IMG and it is sitting in the root directory of drive C.
2. Memtest86+ is on a floppy diskette image on the root directory as well. The filename of Memtest86+ is MEMTEST.IMG.
3. The current version of GRUB4DOS that I'm using is version 0.4.4 with the build date of 2009-06-20.

Drive C is formatted as a NTFS partition.

I'm sorry if I'm not providing sufficient details, but I'm starting to feel tired.

How can I modify the menu.lst file in the root directory of drive C in order for MS-DOS 6.22 and Memtest86+ to be listed and how can I get it to work?

I'm new to using GRUB4DOS and multi-booting and I'm gonna need some help here.

This post has been edited by ppgrainbow: 11 October 2012 - 02:45 AM

[jaclaz]

Well, you should use a newer version of grub4dos.
What is recommended (by me) if you are going to use a 0.4.4, is version 2009-10-16 (which is latest 0.4.4 series):
http://reboot.pro/16641/

or (better) the newest "Featured" from the grub4dos homepage:
http://code.google.c.../downloads/list

HOW are you loading grub4dos?
I will presume like this:
http://diddy.boot-la...ws.htm#windows1

You NEVER (when experimenting) use a pre-made menu.lst entry, you use command line, pressing "C" to get to the prompt and entering commands one by one, this is because this way you get feedback from grub4dos related t the last command entered, thus, in case of issues you know WHAT exactly casuses it.

Usuallly (but of course in no way "compulsory") floppy images are given .ima extension, whilst hard disk or partition images are given .img ones.

Memtest is "easy".

find --set-root /memtest.ima
map /memtest.ima (fd0)
map --hook
chainloader (fd0)+1
rootnoverify (fd0)
boot

The above sets of commands (once tested working become a menu.lst entry as this:

Quote

title Memtest86+
find --set-root /memtest.ima
map /memtest.ima (fd0)
map --hook
chainloader (fd0)+1
rootnoverify (fd0)

(you never need a boot command on a menu.lst as it is implied, i.e. automatically issued if EOF is reached or another "title" entry is foun in the menu.lst)

The MS-DOS 6.22 in a hard disk image is more complex.
Is it a hard disk image or a partition image? (i.e. is it's first sector a MBR or a PBR)?
Assuming the first:

find --set-root /msdos.img
map (hd0) (hd1)
map --hook
map /msdos.img (hd0)
map --hook
chainloader (hd0)+1
boot

jaclaz

[ppgrainbow]

Thanks for the help. I appreciate it, but I am running into problems when attempting to load the GRUB4DOS menu now.

In the boot.ini file, I added the following lines:

Quote

[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS

[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows NT 4.0 Workstation"
C:\grldr.mbr="Start the GRUB4DOS Menu"

I added the following lines in the menu.lst file in the root directory of drive C as well:

Quote

color blue/green yellow/red white/magenta white/magenta
timeout 30
default /default

title Microsoft MS-DOS 6.22
fallback 1
find --set-root /msdos.img
map (hd0) (hd1)
map --hook
map /msdos.img (hd0)
map --hook
chainloader (hd0)+1
boot

title Memtest86+
fallback 2
find --set-root /memtest.ima
map /memtest.ima (fd0)
map --hook
chainloader (fd0)+1
rootnoverify (fd0)
boot

But when I attempt to enter the GRUB4DOS menu, I got this output instead:

Quote

Try (hd0,0): NTFS5: 2
Try (hd0,1): invalid or null
Try (hd0,2): invalid or null
Try (hd0,3): invalid or null
Try (fd0): FAT12: No GRLDR
Cannot find grldr in all drives. Press Ctrl+Alt+Del to restart.

What does the error code NTFS5: 2 mean?

I copied the default, grldr and grldr.mbr to the root directory of drive C and now GRUB4DOS is now complaining that it cannot even find GRLDR in all drives?

What did I do wrong here? Since installing GRUB4DOS on a Windows NT-based operating system is difficult, how can I correct this since getting GRUB4DOS to work on a NTFS partition?

This post has been edited by ppgrainbow: 11 October 2012 - 10:12 AM

[jaclaz]

What about reading the help AND the link I posted earlier?

http://diddy.boot-la...ws.htm#windows1

Quote

Copy C:\Grub4dos\grldr to the root directory of an existing windows install and add the following line to the [operating systems] section of the configuration file boot.ini -

C:\grldr="Grub4Dos"

You:

• DO NOT want a line like C:\grldr.mbr="Grub4Dos" in BOOT.INI
  
• DO NOT want a file C:\grldr.mbr
  
• DO want a line like C:\grldr="Grub4Dos" in BOOT.INI
  
• DO want a file C:\grldr

Then, you DO NOT want (when experimenting) a menu.lst file BUT you use command line instead.
WHEN you add the set of commands that you already tested on command line to a menu.lst entry you DO NOT need the final "boot" command.

WHICH exact version of grub4dos are you using?
(among the two I suggested you, NOT the one you had before)

Try again chainloading directly grldr (and NOT grldr.mbr), cannot say if it will change anything, but let's first start with the "proper" way, OK?

If 0.4.4 2009-16-10 doesn't work, try with 0.4.5c-2012-06-19, or viceversa.
There could be an incompatibility with the NT 4.00 NTLDR (but I cannot recall anything about it ) just for test you can replace it with *any* NTLDR from Windows 2K or XP, that are all tested.
It could be an issue with the (old) version of NTFS filesytem NT 4.00 uses, since you have a floppy, try putting a copy of the grldr on the floppy (still for experiment only).

jaclaz

[ppgrainbow]

Okay, the exact version of the GRUB4DOS bootloader that I'm using is version 0.4.5c-2012-10-02 as this is the latest release of GRUB4DOS for version 0.4.5.

Now, here's the deal.

I migrated the files, DEFAULT, GRLDR, MEMTEST.IMG, MENU and MSDOS.DSK to a Windows NT 4.0 VMware VM. In the VMware VM, I left the original NTOSKRNL.EXE and NTLDR files intact.

(Please note that these files are from Windows NT 4.0 SP6a.)

In the VMware VM, I see the following boot menu options:

"Microsoft Windows NT Workstation Version 4.0"
"Grub4Dos"

When I select Grub4Dos from the boot menu, I get these options:
"Microsoft MS-DOS 6.22"
"Memtest86+"
"Reboot"
"Halt"

When I booted in to Memtest86+ or Microsoft MS-DOS 6.22, the VM was capable of booting the MSDOS.DSK probing 259 cylinders, 16 heads and 16 sectors per track for a total of 261,072 sectors. This was done on a single-core 2.4 GHz Pentium 4 machine.


However, the situation is much different on the Toshiba Tecra 720CDT laptop.

On the real laptop, I see the same options from the boot menu:

"Microsoft Windows NT Workstation Version 4.0"
"Grub4Dos"

When I select Grub4DOS on the real laptop, I do NOT even get access to menu options from Grub4DOS that I'm familiar with.

I get this error message and the system will NOT, I repeat will NOT proceed any further:

Quote

A20 Debug: C806 done! ...

This is often the case even if I replaced the NTOSKRNL.EXE and NTLDR files with the ones from Windows XP SP1, but it was a no go...so I reverted back with the files from Windows NT 4.0 SP6a. So the issue here is NOT a problem with Windows NT 4.0 itself, it has to be a problem with the fact that it might be hardware related and the fact that is a 133 MHz Pentium laptop.

I mean is there anyways, to force Grub4DOS to disable A20 debugging in order to make it work on a 133 MHz Pentium laptop?

This post has been edited by ppgrainbow: 12 October 2012 - 02:43 PM

[jaclaz]

The kernel has nothing to do (it is never involved in this part of booting) only NTLDR or the actual NTFS filesystem may have to do with the issue, but sincce the same worked in the VM, you are right it is a "hardware" connected issue.

jaclaz, on 11 October 2012 - 12:36 PM, said:

If 0.4.4 2009-16-10 doesn't work, try with 0.4.5c-2012-06-19, or viceversa.

jaclaz

[ppgrainbow]

Yep, it is. It looks like that the newer versions of GRUB4DOS (GRUB4DOS 0.4.5 2012-10-02) is incompatible with this laptop.

So...what worked is GRUB 0.4.3 released on 14 October 2007.

I can now boot MS-DOS and run Memtest86+ without problems.

Now that I have booted MS-DOS successfully, I'm gonna be installing Windows 3.1!


Edit: jaclaz, I have a problem here when I try to run MS-DOS 6.22 from a hard disk image:

Quote

Booting 'Microsoft MS-DOS 6.22'

(hd0,0)
Filesystem type is ntfs, partition type 0x7

floppies_orig=1, harddrives_orig=1, floppies_curr=1, harddrives_curr=2
Warning: total_sectors calculated from partition table (263008) is greater than the number of sectors in the whole disk image (262144). The int13 handler will disable any read/write operations across the image boundary. That means you will not be able to read/write sectors (in absolute address, i.e., lba) 262144 - 263087, though they are logically inside your emulated virtual disk(according to the partition table).

probed C/H/S = 261/16/63, probed total sectors = 263088
Starting MS-DOS...

HIMEM is testing system memory...done.

Bad or Missing Command Interpreter
Enter correct name of Command Interpreter (eg, C:\COMMAND.COM)
C>

The emulated disk image is writable, but the Bad or Missing Command Interpreter error only occurs when when I insert the C:\DOS\EMM386.EXE NOEMS in line 4 of the CONFIG.SYS file.

And if I try to install Windows 3.1 in a emulated hard disk image, I will only be able to run Windows 3.1 in Standard Mode. Attempting to run Windows 3.1 by typing WIN throws this error message:

Quote

Cannot find or load required KRNL386.EXE.

I end up getting thrown back to the MS-DOS prompt inside the emulated hard disk image instead.

Is there any way to fix this?

This post has been edited by ppgrainbow: 12 October 2012 - 04:42 PM

[jaclaz]

I will try again (last time ):
does 0.4.4 2009-16-10 version work?
It is not difficult, a yes or no would be enough, though of course knowing (if no) if it behaves the same as the 0.4.5.c version would be nice.

The error about the hard disk image is "normal", it depends on the way you made the hard disk image.
*any* "real" hard disk image (in the sense of image of a"real" hard disk) and *most* hard disk images (if built without using some "special" care) will have some UNindexed space at the end.
What grub4dos is trying to tell you is that the data on the MBR and in the PBR(s) of the volumes "cover" only 263088 sectors while your image is larger than that.
You can "truncate" the image at the correct size.

The DOS errror with EMM386.EXE is likely to be UNresolvable if not by doing several different tests.

WHY do you need such a large DOS image (around 135 Mb)?

jaclaz

[ppgrainbow]

You know, if the comments that I make are still overwhelmingly irrelevant, then I don't know what else to tell you and I can't blame you for that.

Anyways, GRUB4DOS 0.4.4 2009-10-16 will NOT work at all on this laptop, period. If I try to install GRUB4DOS 0.4.4 2009-10-16, when I select GRUB4DOS from the boot menu, the computer will hang as I mentioned in my previous posts. It's that simple.

But I boot GRUB4DOS 0.4.3, I will get the boot menu and select either MS-DOS, Memtest86+, the ability to reboot or to halt the machine.

I have given up all hope to get GRUB4DOS 0.4.4 2009-10-16 (and later versions) to work on this old laptop. I'm sorry.

Quote

The error about the hard disk image is "normal", it depends on the way you made the hard disk image.
*any* "real" hard disk image (in the sense of image of a"real" hard disk) and *most* hard disk images (if built without using some "special" care) will have some UNindexed space at the end.
What grub4dos is trying to tell you is that the data on the MBR and in the PBR(s) of the volumes "cover" only 263088 sectors while your image is larger than that.
You can "truncate" the image at the correct size."

As for the error that you described, thank you so much for telling me. I didn't know that this error about the hard disk image is by design. The hard disk image was created using QEMU-IMG using this command line: qemu-img create -f raw MSDOS.DSK -size 131072K. The hard disk image was created on this computer and it was transferred to the laptop over a network drive. The hard disk on the laptop is mapped as drive T on this computer.

Quote

The DOS errror with EMM386.EXE is likely to be UNresolvable if not by doing several different tests.

WHY do you need such a large DOS image (around 135 Mb)?

Now, why do I need such a large hard disk image of 128 MB? I only created the large hard disk image for testing purposes...and this is to just to install some software that was designed for MS-DOS and 16-bit Windows 3.1. That is all.

As for the DOS error with EMM386.EXE, do you know what several different tests can I try to get around this error?

This post has been edited by ppgrainbow: 13 October 2012 - 11:19 AM

[jaclaz]

ppgrainbow, on 13 October 2012 - 10:59 AM, said:

You know, if the comments that I make are still overwhelmingly irrelevant, then I don't know what else to tell you and I can't blame you for that.

They are incomplete, which is another thing.
I suggested you to try "A" or "B", what you posted (unless I missed something ) was:
I tried "A" and it doesn't work (hanging at "A20 Debug: C806 done! ...")
I tried "C" and it does work.

ppgrainbow, on 13 October 2012 - 10:59 AM, said:

As for the error that you described, thank you so much for telling me. I didn't know that this error about the hard disk image is by design. The hard disk image was created using QEMU-IMG using this command line: qemu-img create -f raw MSDOS.DSK -size 131072K. The hard disk image was created on this computer and it was transferred to the laptop over a network drive. The hard disk on the laptop is mapped as drive T on this computer.

It is not "by design".
And it is not even an error, it is a "Warning".
If you calculate EXACTLY the size of the disk image, counting the "default" 1 head (63 sectors) of "hidden sectors" (comprising the MBR) + the EXACT size of the partition on it (respecting the head/cylinder boundaries that FDISK or more generally any MS partitioning software up to XP/2003 do respect when making the partitions) you won't have that warning.
Compare with:
http://reboot.pro/?showtopic=3191
http://reboot.pro/9033/
Additionally (and this somehow and very loosely "connects" to the question about the size of the image) the BIOS used by Qemu (BOCHS one) is very "picky" and will use - depending on the size of the hard disk image that you create - an "orthodox" geometry, which in your case is a n/16/63 one, unlike the one you will have on *any* common "real" hard disk, which will be a m/255/63 one (and this may create some issues).

ppgrainbow, on 13 October 2012 - 10:59 AM, said:

Now, why do I need such a large hard disk image of 128 MB? I only created the large hard disk image for testing purposes...and this is to just to install some software that was designed for MS-DOS and 16-bit Windows 3.1. That is all.

Yes, the question was aimed to understand if you could make it smaller and try mapping it to --mem and/or using memdisk for it.

ppgrainbow, on 13 October 2012 - 10:59 AM, said:

As for the DOS error with EMM386.EXE, do you know what several different tests can I try to get around this error?

You can try making the image with a different geometry, try loading it to --mem or with memdisk, try replacing EMM386 with another memory manager.

jaclaz

[ppgrainbow]

Option B doesn't work either as it throws a "Cannot find grldr in all drives. Press Ctrl+Alt+Del to restart.". Only Option C works.

Quote

It is not "by design".
And it is not even an error, it is a "Warning".
If you calculate EXACTLY the size of the disk image, counting the "default" 1 head (63 sectors) of "hidden sectors" (comprising the MBR) + the EXACT size of the partition on it (respecting the head/cylinder boundaries that FDISK or more generally any MS partitioning software up to XP/2003 do respect when making the partitions) you won't have that warning.
Compare with:
http://reboot.pro/?showtopic=3191
http://reboot.pro/9033/
Additionally (and this somehow and very loosely "connects" to the question about the size of the image) the BIOS used by Qemu (BOCHS one) is very "picky" and will use - depending on the size of the hard disk image that you create - an "orthodox" geometry, which in your case is a n/16/63 one, unlike the one you will have on *any* common "real" hard disk, which will be a m/255/63 one (and this may create some issues).

Thank you for explaining this. I didn't know that it was a warning message to begin with. I found some research regarding the issue and I'm gonna try to look into this issue more.


Anyways, looking at the MSDOS.DSK file, I modified the MENU.LST to include the following:

Quote

title Microsoft MS-DOS 6.22
find --set-root /msdos.dsk
map (hd0) (hd1)
map --mem /msdos.dsk (hd0)
map --a20-keep-on=0
map --hook
chainloader --disable-a20 (hd0)+1
rootnoverify (hd0)
boot

I added the --mem switch to /msdos.dsk on HD0 and MS-DOS would boot with EMM386.EXE enabled in CONFIG.SYS, however it took almost 40 seconds to boot from the hard disk image. As a consequence of using the --mem switch to map the hard drive, the amount of memory available was reduced from 144 MB to almost 16 MB.

Unfortunately, since I mapped MSDOS.DSK to RAM, any changes made to the operating system inside a emulated hard disk will be lost when the system is rebooted!


Without the --mem switch, EMM386.EXE would cause MS-DOS inside the VM to crash. I at point even tried a different DOS-based memory such as JEMM386 manager and it still wouldn't work.

Is there a way to save the contents of the emulated hard disk image when a reboot is made? This is getting really frustrating.

[jaclaz]

ppgrainbow, on 13 October 2012 - 04:41 PM, said:

I added the --mem switch to /msdos.dsk on HD0 and MS-DOS would boot with EMM386.EXE enabled in CONFIG.SYS, however it took almost 40 seconds to boot from the hard disk image. As a consequence of using the --mem switch to map the hard drive, the amount of memory available was reduced from 144 MB to almost 16 MB.

Unfortunately, since I mapped MSDOS.DSK to RAM, any changes made to the operating system inside a emulated hard disk will be lost when the system is rebooted!


Without the --mem switch, EMM386.EXE would cause MS-DOS inside the VM to crash. I at point even tried a different DOS-based memory such as EMM386 manager and it still wouldn't work.

Yep, so why don't you use a smaller disk image mapped to --mem (which will be loaded faster AND will live you more RAM free AND will give you no issues with EMM386)?
This was the idea of the questions about "size" of the image....
You can have a second image mapped "normally".
You can even try having the same image mapped another time (without --mem), in which case you can use copy or Xcopy from DOS to save to it
Or you can try using a dd port to dos to image the drive mapped in --mem before rebooting.
An oldish one should be here:
http://www.ibiblio.o...freedos/gnuish/
in gnufut21.zip:
http://www.ibiblio.o...sh/gnufut21.zip
(there may be several other programs suitable)


jaclaz

[ppgrainbow]

I'm awfully sorry for not focusing on this topic for days now, but I found a solution to the problem. Unfortunately, the solution is not 100% perfect...

I used a smaller hard disk image of 64 MB and I even found a way to fix the CHS problem creating the hard disk image. I had to use DOSBox 0.74 Megabuild 6 to create a 64 MB hard disk image IMGMAKE. The input to create a 64 MB hard disk image will use 936 cylinders, 4 heads and 35 sectors per track for a total of 131,040 sectors and this works out to almost 64 MB (at 512 bytes per sector):

Quote

Z:\IMGMAKE D:\MSDOS.IMG -t hd -chs 936,4,35
Creating an image file with 936 cylinders, 4 heads and 35 sectors
D:\MSDOS.IMG

However, when I attempted to access the hard disk image, I got this warning:

Quote

Unrecognized Partition Table for Drive 80. Please rebuild it using a Microsoft-compatible FDISK tool.

To fix this, I had to use the FDISK utility to delete the partition and recreate it only to find that I was greeted with the Missing Operating System error, so what I did was to mount the BOOT.IMG disk image as drive A via DOSBox and reformat the hard disk image.

I copied the hard disk image to the root directory on the hard disk of the Tecra 720CDT via a network and this is the result when I booted from the 64 MB hard disk image:

Quote

(hd0,0)
Filesystem type is ntfs, partition type 0x7

floppies_orig, harddrives_orig=1, floppies_curr=1, harddrives_curr=2

Autodetect number-of-heads failed. Use default value 255
Autodetect sectors-per-track failed. Use default value 1

probed C/H/S = 936/4/35, probed total sectors = 131048

Gate A20 is turned off successfully.

Now that the size of the hard disk image has been reduced, WinImage is reporting that the size of the drive is 65,502 KB with 33,072 KB available.


In the menu.lst file on the root directory of drive C, I added the following lines...

Quote

title Microsoft MS-DOS 6.22 (64 MB RAM disk)
find --set-root /msdos.img
map --ram-drive=0x9f
map --rd-base=0x5000000
map --rd-size=0x100000
map (hd0) (hd1) (rd)
map (rd) (hd1) (hd0)
map --mem --disable-lba-mode --heads=4 --sectors-per-track=35 /msdos.img (hd0)
map --floppies=1
map --a20-keep-on=0
map --hook
chainloader --disable-a20 (hd0)+1
rootnoverify (hd0)
boot

title Microsoft MS-DOS 6.22 (Maintenance)
find --set-root /msdos.img
map --ram-drive=0x9f
map --rd-base=0x400000
map --rd-size=0x100000
map (hd0) (hd1) (rd)
map (rd) (hd1) (hd0)
map --disable-lba-mode --heads=4 --sectors-per-track=35 /msdos.img (hd0)
map --floppies=1
map --a20-keep-on=0
map --hook
chainloader --disable-a20 (hd0)+1
rootnoverify (hd0)
boot

In the first menu, I had to added the ability to boot MS-DOS 6.22 on a 64 MB hard disk image with LBA mode disabled with 4 heads and 35 sectors per track. The hard disk image is mapped in memory effectively occupying 64 MB of system memory. I also used the --ram-drive=0x9 map parameter to map a hidden RAM disk, set the --rd-base=0x5000000 parameter below it to reduce the total memory to 80 MB. With 80 MB allocated for a RAM disk and 64 MB occupied for a hard disk mapped in memory, this reduced the size of the system memory to 16 MB.

In maintenance mode, the parameter --rd-base=0x400000 is used to reduce the system memory all the way down to just 4 MB of system memory. If I select "Microsoft MS-DOS 6.22 (Maintenance)" to work on the hard disk image, I had to press F8 and not load EMM386 or I will end up with a "Bad or Missing Command Interpreter" error.

I can still boot from the drive without problems, but if the hard disk image is mapped as a RAM disk, then all of the contents inside the emulated drive will be lost once the system reboots. So, in order to get around this, I had to get a parallel port Iomega ZIP disk, install Windows 3.1 inside the ZIP drive (on drive D:) along with all of the software, install the Iomega ZIP utilities to lock the ZIP drive and treat it as a hard disk. And then after I exit Windows, the ZIP drive gets treated as a floppy disk again.

In order to maintain the health of the ZIP disk, I had to disable the swap file. The end result is that with a lot of software installed on the ZIP disk along with Norton Desktop and the 1024x768 wallpaper, the total amount of memory was reduced to 11.6 MB. If I don't feel comfortable about that, I may have to increase the base of the RAM disk to 96 MB and leave 32 MB available.


Booting MS-DOS from a hard disk image via GRUB4DOS should be done only for testing purposes. Because GRUB4DOS has problems with loading expanded memory managers in the CONFIG.SYS upon booting from the hard disk image, it's just too hard to get it to work properly. I had to either do the following:

1. Use the --mem parameter to map the hard disk image into memory which effectively reduces the total amount of system memory.
2. Don't use expanded memory managers at all.


(I tested the 64 MB hard disk image when I booting successfully from the MSDOS.IMG hard disk image in a Windows for Workgroups 3.11 Virtual PC VM.)

If this information is still overwhelmingly irrelevant, I don't know what else to tell you. I tried my best to get it to work as planned, but it's not 100% perfect, ya know. I'll look into other solutions to get MS-DOS working more perfectly inside GRUB4DOS in the foreseeable future.

[jaclaz]

With all due respect you are using a "crazy" CHS and went into all kinds of complex ways to make that image (and to map it in grub4dos).

I really cannot make head or tail of your menu.lst entry :

Quote

title Microsoft MS-DOS 6.22 (64 MB RAM disk)
find --set-root /msdos.img
map --ram-drive=0x9f
map --rd-base=0x5000000
map --rd-size=0x100000
map (hd0) (hd1) (rd)
map (rd) (hd1) (hd0)
map --mem --disable-lba-mode --heads=4 --sectors-per-track=35 /msdos.img (hd0)
map --floppies=1
map --a20-keep-on=0
map --hook
chainloader --disable-a20 (hd0)+1
rootnoverify (hd0)
boot

but if you are happy with it, that's OK.

The bolded commands are undocumented.
You map FROM_DRIVE to TO_DRIVE, to the best of my knowledge.
The red one seems "random" (or a leftover), as you didn't modify any floppy mapping.
The settings for a20 doesn't "look" right, but really cannot say.

For the record, you DO NOT need a "boot" command in a menu.lst entry (it is implied and automatically executed when either a "title" or EOF is found) while you need it on command line.

jaclaz

[ppgrainbow]

Well...I'm happy with the results. Creating a hard disk image using the IMGMAKE command with the custom cylinder-head-sector fixed the issue. As for making heads or tails on the menu.lst enter, there is no need for heads or tails. I'm very pleased with the results. ;p

The undocumented commands mapped the first hard disk (hd0), the hard disk image (hd1) and the hidden RAM drive (rd) and swapped them completely. The floppy mapping remains unmodified as it is designed to map only one floppy.

Lastly, as for not needing the "boot" command, I think that I will deprecate it.

But along with that, everything is working now.

This post has been edited by ppgrainbow: 29 October 2012 - 07:21 PM

[jaclaz]

ppgrainbow, on 29 October 2012 - 07:19 PM, said:

The undocumented commands mapped the first hard disk (hd0), the hard disk image (hd1) and the hidden RAM drive (rd) and swapped them completely.

Well, IMHO, no, but again, if you are happy with them, that's good.
If you could provide some documentation/examples about using map with THREE driives it would be nice.
In your menu.lst (hd1) is never defined, does your PC have two "real" hard disks?

ppgrainbow, on 29 October 2012 - 07:19 PM, said:

The floppy mapping remains unmodified as it is designed to map only one floppy.

If no floppy mapping is changed, there is no need to explicitly set the number of floppies, the number will remain as it was before.

A 64 Mb image could normally be 129/16/63 or (a little larger) 130/16/63.

And this is a good occasion to inaugurate latest work by larryb123456:


jaclaz

This post has been edited by jaclaz: 30 October 2012 - 05:05 AM

[ppgrainbow]

If I get the chance to provide some documentation about mapping three (or more) drives), I'll let you know. The laptop has one removable hard disk. The hard disk image mounted on hd1 is mapped as hd0 when executing MS-DOS 6.22 at boot.

[quoteIf no floppy mapping is changed, there is no need to explicitly set the number of floppies, the number will remain as it was before.[/quote]

That's correct. The floppy mapping remains unchanged as it is not designed to detect drive B (second floppy drive).

When a 64 MB hard disk image is created using FSUTIL or Qemu-img commands, the cylinder/head/sector values are defaulted to 130/16/63 for a total of 131,040 sectors which equals almost 64 MB in size. That's not the case when creating a hard disk image from DOSBox Megabuild's IMGMAKE command.

[jaclaz]

ppgrainbow, on 30 October 2012 - 11:17 AM, said:

When a 64 MB hard disk image is created using FSUTIL or Qemu-img commands, the cylinder/head/sector values are defaulted to 130/16/63 for a total of 131,040 sectors which equals almost 64 MB in size. That's not the case when creating a hard disk image from DOSBox Megabuild's IMGMAKE command.

Sure , the whole point being that a 129/16/63 or 120/16/63 is "right" (in the sense of standard) and a 936/4/35 is UNstandard.

I still don't get from your reply if the laptop has one or two "real" hard disks and if two on which hard disk is the /msdos.img.

Let's say that on a single hard disk with a single partition a "normal" DOS 6.22 in a "standard" roughly 64 Mb image CHS 130/16/63 works allright here with this menu.lst (that it seems to me simpler than the one you posted):

title Microsoft MS-DOS 6.22 64 Mb
map (hd0) (hd1)
map --mem (hd0,0)/msdos.img (hd0)
map --hook
root (hd0,0)
chainloader +1

(the need for A20 settings may depend from your BIOS, though it sounds "stange" to me that you actually need both the settings you have posted )

jaclaz

[ppgrainbow]

Quote

Sure , the whole point being that a 129/16/63 or 120/16/63 is "right" (in the sense of standard) and a 936/4/35 is UNstandard.

A hard disk image that has 120 cylinders, 16 heads and 63 sectors per track would equal 59 MB. A hard disk image with the 936/4/35 CHS setting is custom and based on how the hard disk image was created using IMGMAKE. The internal physical hard disk image (hd0) is where Windows NT 4 boots at start up. The hard disk image (hd1 mapped as hd0), MSDOS.IMG is where it boots MS-DOS both as a RAM disk and for maintenance use.

Quote

Let's say that on a single hard disk with a single partition a "normal" DOS 6.22 in a "standard" roughly 64 Mb image CHS 130/16/63 works allright here with this menu.lst (that it seems to me simpler than the one you posted):

title Microsoft MS-DOS 6.22 64 Mb
map (hd0) (hd1)
map --mem (hd0,0)/msdos.img (hd0)
map --hook
root (hd0,0)
chainloader +1

(the need for A20 settings may depend from your BIOS, though it sounds "stange" to me that you actually need both the settings you have posted )

The portion of the setup code (found in lines 7 to 20 of menu.lst) that boots into MS-DOS 6.22 in RAM only consumes 64 MB of system memory and reducing the size of the total physical memory available to DOS from 144 MB to 80 MB.

The eXtended Memory Specification Application Programming Interface (XMS API) version 3.0 that is used in MS-DOS has a 4 GB memory limitation. However, the HIMEM.SYS XMS 3.x driver that was used in MS-DOS 6.0 to MS-DOS 6.22 uses a unsigned 16-bit value (up to 65,535 KB of physical memory) to store the amount of physical memory to MS-DOS in kilobytes. If more than 64 MB of system memory is reported to MS-DOS, then only 64 MB will be usable to the OS.

If the HIMEM.SYS XMS driver is version 2.x, then MS-DOS cannot even use the memory above the 16 MB limit. The HIMEM.SYS XMS 2.x drivers were shipped with MS-DOS 5.0 and Windows 3.0 respectively..

(Unfortunately, on a bit of a off-topic note, Windows 3.0 does not support system memory above this 16 MB limitation in both Standard Mode and 386 Enhanced Mode as the OS relies on the HIMEM.SYS XMS 2.x driver to enforce this limit. While Windows 3.0 will continue to work with more than 16 MB of memory in 386 Enhanced Mode, any attempts to run Windows 3.0 in Standard Mode with more than 16 MB of memory will cause the system to hang unless a RAM disk is installed to reduce the available memory to 16 MB of less.)

By adding the lines "map --ram-drive=0x9f", "map --rd-base=0x5000000", "map --rd-size=0x100000" and adding (rd) to the end of "map (hd0) (hd1)", this reduces the total amount of available for MS-DOS to 80 MB. And along with a 64 MB hard disk image, it further cuts down the size of the physical memory available to MS-DOS to just 16 MB which is reasonable enough for most MS-DOS and Win16-based software.

As for the need to re-enable A20 support, I can try to change the line that reads "map --a20-keep-on=0" to "map --a20-keep-on=1" to see if MS-DOS will boot with Gate A20 support enabled and remove the "--disable-a20" reference to the chainloader command.

This post has been edited by ppgrainbow: 31 October 2012 - 01:46 AM

[jaclaz]

ppgrainbow, on 31 October 2012 - 01:33 AM, said:

A hard disk image that has 120 cylinders, 16 heads and 63 sectors per track would equal 59 MB. A hard disk image with the 936/4/35 CHS setting is custom and based on how the hard disk image was created using IMGMAKE. The internal physical hard disk image (hd0) is where Windows NT 4 boots at start up. The hard disk image (hd1 mapped as hd0), MSDOS.IMG is where it boots MS-DOS both as a RAM disk and for maintenance use.
....

Evidently I cannot have a conversation with you , there must be something lost in translation that we seem not to be able to overcome.
The message is/was simple:
You are using mostly unneededly a set of unstandard, partly wrong, overly complex procedures, commands and settings that can IMHO be greatly simplified.
Some of these "unstandard" settings will most probably result in a number of applications having issues with the system.

Just for the record, you never talked of Windows 3.0, but only of Windows 3.1 or 3.11 until your last post.

As said, if you are happy with them, I am very happy too .

jaclaz

This post has been edited by jaclaz: 31 October 2012 - 04:14 AM