Jump to content

Windows NT 4.0 and GRUB4DOS


ppgrainbow

Recommended Posts

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.

Edited by ppgrainbow
Link to comment
Share on other sites


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.com/p/grub4dos-chenall/downloads/list

HOW are you loading grub4dos?

I will presume like this:

http://diddy.boot-land.net/grub4dos/files/install_windows.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:

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

Link to comment
Share on other sites

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:

[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:

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:

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? :(

Edited by ppgrainbow
Link to comment
Share on other sites

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

http://diddy.boot-land.net/grub4dos/files/install_windows.htm#windows1

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:

  1. DO NOT want a line like C:\grldr.mbr="Grub4Dos" in BOOT.INI
  2. DO NOT want a file C:\grldr.mbr
  3. DO want a line like C:\grldr="Grub4Dos" in BOOT.INI
  4. 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 :unsure: ) 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

Link to comment
Share on other sites

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:

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?

Edited by ppgrainbow
Link to comment
Share on other sites

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.

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

jaclaz

Link to comment
Share on other sites

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! :thumbup

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

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:

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?

Edited by ppgrainbow
Link to comment
Share on other sites

I will try again (last time :angry: ):

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

Link to comment
Share on other sites

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. :(

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.

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? :whistle:

Edited by ppgrainbow
Link to comment
Share on other sites

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 :unsure:) was:

I tried "A" and it doesn't work (hanging at "A20 Debug: C806 done! ...")

I tried "C" and it does work.

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).

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.

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

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

Link to comment
Share on other sites

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.

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:

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.

Link to comment
Share on other sites

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.... :whistle:

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.org/pub/micro/pc-stuff/freedos/gnuish/

in gnufut21.zip:

http://www.ibiblio.org/pub/micro/pc-stuff/freedos/gnuish/gnufut21.zip

(there may be several other programs suitable)

jaclaz

Link to comment
Share on other sites

  • 3 weeks later...

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):

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:

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:

(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...

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.

:whistle:

Link to comment
Share on other sites

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 :unsure: :

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. :thumbup

The bolded commands are undocumented. :w00t:

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

Link to comment
Share on other sites

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.

:)

Edited by ppgrainbow
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...