Try PLOP Bootloader or Sbootmanager

matze79 wrote:

Try PLOP Bootloader or Sbootmanager

So you have run into this problem before and PLOP and Sbootmanager were able to fix it?

Don't forget that it's not enough for the boot sector to be within whatever barrier you are up against. The BIOS needs to load the boot sector, but the first thing the boot sector does is ask the BIOS to load the next lot of data, e.g. IO.SYS, NTLDR, etc. If that's beyond the barrier then the BIOS won't be able to load that either. This is why the recommended advice is to ensure the entire boot partition is below any barrier, so an inadvertent defrag won't render your system unbootable by accidentally moving the bootloader files beyond the barrier point.

Is it a problem to use four partitions instead, with C: and D: being small boot partitions, and E: and F: being the respective data partitions?

I am guessing that the difference between the controllers is down to the maximum cylinder values they use during translation. Perhaps one has a max of 1023, and the other is 1022 or similar. The actual translation algorithm appears to be the same, otherwise the filesystem would appear corrupted on one of the controllers (at least until Windows loads, when it should use LBA access and the SCSI BIOS doesn't have to perform CHS translation anymore - this would be why you can see the whole disk fine once NT has loaded.)

Have you tried putting the VLB SCSI controller into your PCI system? That would at least confirm whether it's the controller's BIOS to blame. The error about the cylinder number being too large for the BIOS typically refers to the system BIOS, so you may find that either controller works fine in the PCI system, and it's a limitation in the VLB system's BIOS.

On booting the loader uses bios functions and thus the bios limits apply. So all the required files have to be on the disk below this limit. This is overcome as soon as the mass storage driver starts (e.g. for NT4 as soon as the kernal boots).

Following this behavior you can even install NT4 on a 120 GB partition as long as the relevant boot files stay within the first e.g. 8 GB.

Malvineous wrote:

Is it a problem to use four partitions instead, with C: and D: being small boot partitions, and E: and F: being the respective data partitions?

Why he should want 2 small boot partitions? That's only necessary if he wanted to dual boot Windows with any *nix flavor, but this isn't the case. With only 1 small boot partition you can dual boot NT and W9x/DOS, as soon as the small boot partition keeps formatted as FAT16. If you have Win95 OSR2 or WinNT SP6a, you can even send your OS partitions beyond the 32GB barrier, as soon as the boot files keep inside the BIOS barrier (Win95 IO.sys or WinNT NTLDR/NTDETECT.COM/BOOT.INI).

Btw, once the SCSI disk is connected to an specific HBA and formatted/partitioned with it,you can't move safely that disk to other HBA, unless you format it in the destination HBA again. In older days every SCSI manufacturer had their different way to do stuff, like HDD geometry translation and such, and unlike IDE, such ways weren't standarized at all. Many problems with booting SCSI stuff in these older days came from people misunderstanding SCSI ways, and thinking that preparation procedure steps were the same as with IDE disks.

Thank you for your responses everyone.

hyoenmadan wrote:

Btw, once the SCSI disk is connected to an specific HBA and formatted/partitioned with it,you can't move safely that disk to other HBA, unless you format it in the destination HBA again. In older days every SCSI manufacturer had their different way to do stuff, like HDD geometry translation and such, and unlike IDE, such ways weren't standarized at all. Many problems with booting SCSI stuff in these older days came from people misunderstanding SCSI ways, and thinking that preparation procedure steps were the same as with IDE disks.

So even if I had created two 4 GB partitions, one for NT4 and one for W95c, you're saying that the VLB might not boot W95 still, e.g. because the different host controllers format/treat the hard drive differently? However, considering that NT4 loaded fine on the VLB controller, is it fairly safe to assume that the two host controllers are compatible in this respect?

From the responses, it sounds like some of my Win95c boot files are passed the 8 GB barrier and this is causing the problems with booting. So if I use partition magic to shrink my NT4 partition down to 7000 MB, how do I stick just the W95c boot-required system files onto the next 1000 MB? I could create a 1000 MB boot partition, whereby partitioin 3 would be the Win95c partition with the rest of the files. While it is straight forward enough to install Win95c to that 1000 MB partition and all the program files onto the 3rd partition, I would ideally like to keep just the boot-required Win95c files on that 2nd partition.

i didnt try it, but it is worth, just write a floppy disk.
plop even allows usb boot on 486.

Responding to some of the comments posed above:

- PLOP did not allow the Win95c partition to boot.

- My Asus PVI-486SP3 (1 VLB + 3 PCI) does not recognise the HDD when using the Adaptec AHA-2842A VLB SCSI card. My PC Chips M919 (1 VLB + 3 PCI) also does not recognise the HDD when using the VLB SCSI card. So I can not determine if the issue is due to a motherboard BIOS limitation or strictly due to the VLB SCSI card's BIOS.

- It looks like I may need to setup this HDD another way. Does anyone know which files Win95c needs just to startup? I'd like to create a small Win95c boot partition, perhaps 100 MB if possible.

Since Win95 seems to be the problem, can you try putting that first (C:), and NT second (D:)? Maybe NT's boot sequence is smarter than Win95 and it's not as flummoxed by large disks.

I sorta recall WinNT4 needing to be installed on the first stretch of HDD real-estate because I am using FAT32 for Win95c. Maybe I am mistaken?

Not sure - I've never used NT. If it doesn't recognise FAT32 you'd think it would treat it as a non-DOS partition and leave it alone?

Something in the back of my mind is telling me that NT4 needs to put files on the first partition to boot properly and having FAT32 messes this up. Even though FAT32 for NT4 works in NT4, the driver only gets initialised later in the boot process.

Replace the bootloader with the one from Windows 2000 (NTLDR, etc.) in the root partition.

Well...you could get crafty, and set up your partition table such that the first partition starts at 7000MB, and the second partition starts at 1MB. Then NT would get the first partition, and Win95 would be within the 8GB boundary... Nobody ever said the order in the partition table had to match the order on the disk 😉

You'll of course need a non-Microsoft program to set up the partitions this way though.

alexanrs wrote:

Replace the bootloader with the one from Windows 2000 (NTLDR, etc.) in the root partition.

I think I tried that once and it didn't work (or my memory is false). Do you know for certain this configuration will allow NT4 to boot when the first partition if FAT32?

Malvineous wrote:

Well...you could get crafty, and set up your partition table such that the first partition starts at 7000MB, and the second partition starts at 1MB. Then NT would get the first partition, and Win95 would be within the 8GB boundary... Nobody ever said the order in the partition table had to match the order on the disk 😉

You'll of course need a non-Microsoft program to set up the partitions this way though.

This is an interesting idea. How do I tell the partitions who is #1 and #2? But maybe NT4's being fussy about having the boot files on the first partition is a cylinder # issue?

I remember doing that with NT 3.51, and it booted NT just fine. I don't recall experimenting with making the boot partition FAT32, though, but since Windows 2000 boots from FAT32 partitions just fine, it should work.

Exactly which boot loader files from W2K do I need to copy into NT4? If I recall correctly, I think I only copied NTLDR previously. Are there others I need to copy over?

I believe you need at least NTLDR and NTDETECT.COM. You might like reading this page.