maxtherabbit wrote on 2023-09-19, 23:13:

My card came with BIOS version 1.1. There is no prompt to enter SCSISelect on the EISA card, perhaps it can be run from DEBUG but I dont know the offset (tried :6 and :9 neither did anything)

Well, obviously it's been too long since I tampered with that card. In an EISA system, the configuration is performed using the ECU, of course. But the old version number, "1.1", might be a clue. I already know that there are two incompatible hardware revision, for the 2840 card, called 2840VL (uses BIOS 1.x) and 2840A (uses BIOS 2.x). Possibly, there also are different hardware revisions of the 2740, and the 2.x BIOS is just incompatible with your card. I dumped the 2.11 BIOS from an Adaptec 2740W, but according to Adaptec/Microsemi their current BIOS update at https://adaptec.com/de-de/speed/eprom_bios/274xa_exe.php containing the 2.10 BIOS is supposed to be compatible with all 2740 series controller. Maybe something broke on the 2.11?

maxtherabbit wrote on 2023-09-19, 23:13:

ETA Here's a BIOS dump if anyone's interested to look at v1.1

If my theory is correct, I "just" need to port the patch from the 2.11 BIOS to the 1.1 BIOS to fix your issue. We might also try whether the 2.10 BIOS works on your controller.

Considering the 2.11 BIOS work flawlessly with everything except the 73GB drive, I'm not convinced there is a hardware incompatibility. If there were, I don't think it would be working perfectly with my 9 and 4GB drives.

NJRoadfan wrote on 2023-09-20, 02:42:

I have both the EISA 2740W and VLB 2842A (BIOS dated 1993). I don't recall either having flash ROMs, so I really don't have any way of testing these patches. Cool that there is an update. Now if only there was a Windows 2000/XP driver for these cards.

Which version of the BIOS is on your 2740W?

Do you have a >36.4GB SCSI drive you could hook up to it and test? I mean using the stock BIOS you will only see the first 8GB of the drive of course but that would still be helpful to know if you can make and use a partition within that 8GB in DOS

maxtherabbit wrote on 2023-09-20, 13:02:

Considering the 2.11 BIOS work flawlessly with everything except the 73GB drive, I'm not convinced there is a hardware incompatibility. If there were, I don't think it would be working perfectly with my 9 and 4GB drives.

Too bad we cannot debug your system remotely (by using a terminal and a RS232 zero modem cable)
Both mkarcher and me are excited what's going on on your system

If yall are on the east coast you're welcome to swing by 😁

But seriously I could probably rig something up with a kvm or serial terminal maybe

I don't have any large SCSI drives here. A 9.1GB is laying around...somewhere. I have to pull out the 486 this weekend, I'll check then.

My $10 36.4GB drive arrived today. I had hoped it would either work fine, or exhibit the same symptoms as the 73GB drive. However what it actually did is even stranger. I hoped this would shed light, but it seems to raise more questions than provide answers.

So to recap:
System booting into Win95B's DOS mode (BootGUI=0) from 8GB type 6 FAT32 partition on 9GB SCSI drive (ID 0). This has been a constant through all testing and remains constant today. This partition is labeled "ATLAS ALPHA"
2.11+EDD BIOS
ASPI7DOS + EDD loaded unless otherwise specified.

New drive came from the ebay seller with a minion sticker, so I decided to call it MINION-1A. This is a 36.4GB drive connected to the system as drive "D" (ID 1).

First things first, open up FDISK (I'm now using the version with the size bug fixed from MS) and enable large disk support. Next up delete the existing NTFS partition on the minion drive and create a primary DOS partition using 100%.

Reboot
Next, FORMAT D: resulted in this:

Odd, that is the exact size of my boot partition on the C drive...
FDISK seems to think nothing is wrong though.

Ok for giggles, let's reboot without ASPI7DOS loaded. Totally clean boot, F8 -> safe mode command prompt.
checking the directory on D: now gives the exact contents of C:

And now, even FDISK is showing C as D.

Rebooting back with the ASPI manager loaded gets us right back to seeing a blank drive of MINION-1A with 8GB free. No data corruption on the C drive observed.
WTF, over

maxtherabbit wrote on 2023-09-21, 20:03:

Next up delete the existing NTFS partition on the minion drive and create a primary DOS partition using 100%.

For me, this is a bit confusing though.
I recommend to reboot the system between deleting the partition and creating a new one (cold boot ofc).
It is because Adaptec controllers are a bit pesky about translations.

Disruptor wrote on 2023-09-21, 21:59:

I recommend to reboot the system between deleting the partition and creating a new one (cold boot ofc).

I've literally never had to do that before on any DOS system ever in the 30+ years I've been doing this, including with almost every Adaptec ISA or PCI controller under the sun.

But regardless, that didn't change anything. The partition entry is fine, I can send the MBR sector if you don't believe me

My only suggestion is maybe try another DOS partitioning tool that doesn't act weird with large drives. FDISK isn't the greatest for testing. I'm also not a fan of those SCA adapters, although being on a wide bus, all they need is proper termination pigtails.

I have a veritable tool kit of SCSI adapters and terminators and am fully versed in their application. There is no physical communication fault, I guarantee it.

The patched win98 FDISK doesn't have any issues with large drives.

The problem is in the card's BIOS. Next step is to burn the unmodified 2.11 BIOS to a chip to verify the issue didn't come from the patch I guess. Based on the screenshots I've posted in the last two days I'm completely convinced some pointer(s) is/are getting corrupted due to some calculation overflow based on the drive's total LBA value.

maxtherabbit wrote on 2023-09-21, 20:03:

Next, FORMAT D: resulted in this: […]
Show full quote

Next, FORMAT D: resulted in this:

{formatting 8GB}

{8GB free}

Odd, that is the exact size of my boot partition on the C drive...
FDISK seems to think nothing is wrong though.

OK, this narrows the problem down to the partition scanning code when the IO.SYS reads the drive partition tables on boot. It looks like IO.SYS gets the partition table of drive C when trying to read the partition table of drive D. Later on, when FDISK reads the partition table, the correct partition table is returned. This doesn't seem to happen on my 2842VL, but as the BIOS is slightly different, it still might be an issue with my patch.

Can you test whether

• You can correctly access the 36GB / 72GB drive if it is the only hard disk drive installed in the system (preferably as ID0). Of course, this means you have to boot Win95B from floppy?
• If you connect a different drive as C: drive (and the 36GB/72GB drive again as ID1), you keep getting the size of the C: partition(s) as fake partitions of the D: drive?

This is to confirm or reject my theory that IO.SYS gets to read the wrong MBR during bootup.

Yep all that should be doable, I'll get back with results tomorrow

mkarcher wrote on 2023-09-22, 18:29:

[*]You can correctly access the 36GB / 72GB drive if it is the only hard disk drive installed in the system (preferably as ID0). Of course, this means you have to boot Win95B from floppy?

It appears to be formatting correctly. I can't stick around and wait for it at the moment so I'll check back later and make sure it can list directory and copy some files from the floppy.

maxtherabbit wrote on 2023-09-23, 15:56:

It appears to be formatting correctly.

OK, thanks for the tests. I'm going to re-review my patch whether I can find something that might mix up drive letters, or maybe I might even mess up some parts of the stack of the caller. There are two code-paths in the INT13 handler - one if EMM386 is loaded and one if EMM386 is not loaded. In the case EMM386 is loaded, the Adaptec code reserves more stack space to store some paging management structures in there. If I somehow run code that expects the extended stack frame to exist while EMM386 is not loaded, this could explain random crashes.

Just an update, my AHA-2740W has BIOS revision 2.11 on it. I forgot this card doesn't have the onboard SCSISelect ROM based setup. Everything is done in the EISA configuration utility.

mkarcher wrote on 2023-09-23, 17:37:

maxtherabbit wrote on 2023-09-23, 15:56:

It appears to be formatting correctly.

OK, thanks for the tests. I'm going to re-review my patch whether I can find something that might mix up drive letters, or maybe I might even mess up some parts of the stack of the caller. There are two code-paths in the INT13 handler - one if EMM386 is loaded and one if EMM386 is not loaded. In the case EMM386 is loaded, the Adaptec code reserves more stack space to store some paging management structures in there. If I somehow run code that expects the extended stack frame to exist while EMM386 is not loaded, this could explain random crashes.

The first problem I encountered with the 73GB drive as D occurred both with and without EMM386 loaded FWIW

maxtherabbit wrote on 2023-09-23, 15:56:

mkarcher wrote on 2023-09-22, 18:29:

[*]You can correctly access the 36GB / 72GB drive if it is the only hard disk drive installed in the system (preferably as ID0). Of course, this means you have to boot Win95B from floppy?

It appears to be formatting correctly. I can't stick around and wait for it at the moment so I'll check back later and make sure it can list directory and copy some files from the floppy.
20230923_115519.jpg

First attempt was a fail, but after freshly repartitioning the drive we have success. This is with the 32GB as the sole drive in the system (ID0) booting from floppy. All seems to be well with it. Was even able to SYS C: and boot from it.

mkarcher wrote on 2023-09-22, 18:29:

[*]If you connect a different drive as C: drive (and the 36GB/72GB drive again as ID1), you keep getting the size of the C: partition(s) as fake partitions of the D: drive?

The answer to this one is "yes"

Booting from the floppy, 4GB hard drive as ID0 (GORDONQUICK, 2GB primary FAT16 partition), 32GB hard drive as ID1 (MINION-1A). No EMM386 or ASPI7DOS.

If I reverse them, and make the 32GB drive ID0 and the 4GB drive ID1, everything seems to work correctly. Not extensively tested but I can read directories, etc.