One more thing to note - the 73GB drive does NOT work even when it's the only drive in the system (ID0), booting from the floppy

maxtherabbit wrote on 2023-09-24, 00:43:

One more thing to note - the 73GB drive does NOT work even when it's the only drive in the system (ID0), booting from the floppy

I found a bug in my code: It seems LBA calls for read, write, verify and seek are always sent to the drive with ID 0, no matter what drive is requested by the OS. This would be an explanation why IO.SYS gets the wrong partition table (trying to read it using the LBA call), whereas FDISK gets the correct partition table (trying to read it using the CHS call which I didn't break). When you formatted the partition that should have been 36GB, but got an 8GB format instead, and didn't corrupt drive C:, I guess the drive C: partition table had the 8GB partition of type 0B (FAT32 CHS), not 0C (FAT32 LBA), which caused DOS to format the D: drive using CHS calls, which indeed target drive D:.

When you did this final test: Did you use jumper the single 73GB drive as ID 0 or ID 1? If you used ID 1, this can be explained by the same bug.

It was jumpered as ID0, I even said so in the post you quoted 😀

Also you may remember from looking at the MBR sector that the only partition on the 73GB drive at the moment is type 6, CHS

I currently use an 82.4 G IDE drive using an ACARD adapter on the 2842VL (single, ID0).
SCSISelect 1.01 is currently verifying that disk and does a wraparound at 12997 MBytes.
FDISK from Windows 95 B is showing a disk capacity of 12993 MB.

We'll do some more examination soon.

maxtherabbit wrote on 2023-09-24, 07:56:

It was jumpered as ID0, I even said so in the post you quoted 😀

Also you may remember from looking at the MBR sector that the only partition on the 73GB drive at the moment is type 6, CHS

OK, it sounds like we are looking at two different issues then. I could reproduce the ID1 issues you had: I can access all partitions on a 36GB drive on my 2842VL when that drive is ID0. I can not access the LBA partition, but I can access (at least partly) the CHS partitions on that drive when it is ID1, and a second drive is installed. I can not access that drive at all if it is the single drive at ID1. This experience is slightly different then yours, because you get a mirror of the ID0 partition table as ID1, whereas I get the correct partition count when both ID0 and ID1 are connected. This might be due to differences in the partition schemes on the drive, and I don't consider that very important at the moment. Instead, I am going to fix the ID0-only bug first, and verify that this fix works as expected. Then I will use the 80GB drive prepared by Disruptor and try to reproduce the extra issues you encountered with your 72GB drive.

I consider the 64GB wraparound in the SCSISelect drive verification procedure, which is only a display problem not that important at the moment. IIRC the verification procedure verifies the disk in blocks of 1MB, so it looks like the block counter used to calculate the percentage is truncated to 16 bits (i.e. 65536MB). The verification procedure terminates after verifying 80GB, which is a strong indicator that a separate 32-bit LBA number is used to determine the loop termination, which is most likely also used as address to verify.

Perhaps that is only a display bug in this particular case, but it seems like too much of a coincidence. I'm guessing there is a similar truncation elsewhere in the code

maxtherabbit wrote on 2023-09-24, 15:20:

Perhaps that is only a display bug in this particular case, but it seems like too much of a coincidence. I'm guessing there is a similar truncation elsewhere in the code

I made an updated BIOS (patch not yet upload to GitHub) that fixes the ID0 bug. It fixed the issue in the 9GB / 36GB combination: It allowed me to access the FAT32/LBA partition on the 36GB drive jumpered as ID1, which was impossible before the bugfix. I also tried the 80GB IDE drive with the IDE-SCSI converter attached to it. I removed the 80GB partition on it (it had no data on it, so nothing got lost for this experiment), and created a 2GB partition, which I manually configured to type 6 (FAT 16 CHS), then I formatted it, and SYSed it with "Windows 95. [Version 4.00.1111]", and I could boot that partition. This is obviously not that much data as on your 2GB partition, which is actually filled with some data.

Can you suggest a specific test prodecure I can perform to reproduce your issue?

maxtherabbit wrote on 2023-09-24, 00:43:

One more thing to note - the 73GB drive does NOT work even when it's the only drive in the system (ID0), booting from the floppy

For example, what do you mean by "does NOT work"? Do you mean the system still crashes and/or displays garbage when listing directories?

EDIT/ADD: I copied the "Drivers" folder of my download directory, which currently has 800MB of mixed drivers, some big installers, some extracted drivers with lots of small files, and then ran "dir /s" using the 2840 controller, and it did not crash. It reported a sensible size and number of files.

The test I did with the 73GB drive was very simple yesterday. It was the sole drive connected to the system as ID0, booting from floppy. The system hung at the point in the DOS initialization (with the 73GB drive's access LED stuck on) where it reads the partition table of the hard disk(s) before even reaching the A prompt.

I'm starting to think now maybe I should wipe the MBR sector on it and repartition

maxtherabbit wrote on 2023-09-24, 19:37:

The test I did with the 73GB drive was very simple yesterday. It was the sole drive connected to the system as ID0, booting from floppy. The system hung at the point in the DOS initialization (with the 73GB drive's access LED stuck on) where it reads the partition table of the hard disk(s) before even reaching the A prompt.

I'm starting to think now maybe I should wipe the MBR sector on it and repartition

If there is an extended partition containing logical drives, corruption in the partitioning could cause this issue given the correct circumstances: The logical drives are a linked list in the extended partition. If that list goes circular instead of getting to an end, this might send IO.SYS into a loop scanning for partitions. Usually, this loops terminates after IO.SYS has seen 24 partitions, because the array of partitions in IO.SYS is limited to the number that can get drive letters assigned (it's independent of LASTDRIVE, though, for example because scanning of partitions happens before CONFIG.SYS is loaded and LASTDRIVE is seen). But if the loop in the logical drives only contains partitions that IO.SYS can not handle (like NTFS or ext2), it will not assign drive letters, and might spin forever. I'm not sure how likely it is to get into this loop without actively trying to get into this state by purposely writing evil partitioning info to the drive.

If you can reproduce a problem with that drive freshly partitioned as a single drive with ID0 (the ID0 bug is officially confirmed by me 😉 ), I will try to fix that problem, too. Otherwise, I will upload the BIOS patch with the ID0 bug removed without any further changes/fixes.

You've seen the MBR sector though, there was no extended partition.

I'll manually zero wipe the sector and try again regardless

Ok I used DEBUG to zero wipe the MBR sector on the 73GB drive. Configured it to be ID0 (no other HDD in the system) and booted from the floppy. Ran FDISK (large disk support: N) and created my 2GB primary FAT16 partition. So far so good. Reboot.

It appears to format just fine until the very end, after I enter the volume label it hangs with the drive LED stuck on. By the way, I found out when it does this it will eventually timeout (after like over a minute) and give this error. It's not a hard system lock, though the LED remains stuck on even after DOS prints the error.

maxtherabbit wrote on 2023-09-25, 00:17:

It appears to format just fine until the very end, after I enter the volume label it hangs with the drive LED stuck on. By the way, I found out when it does this it will eventually timeout (after like over a minute) and give this error. It's not a hard system lock, though the LED remains stuck on even after DOS prints the error.

Oh, I think I know what might go wrong if there is some other LBA call in-between. The ID0 bug in my LBA code might break SCSI disconnect/reconnect (but only for LBA calls). Please try disabling disconnect for ID0 in the EISA setup. If it helps, I hope that your issue is caused by this side-effect. If it doesn't help, I suspect the 2.11 BIOS has some general issues with the ATLAS drive, and I would ask you to try the unpatched 2.11 and test whether you can reproduce the issue.

I'm going to push the ID0 patch tonight anyway, as it will definitely make things better.

mkarcher wrote on 2023-09-25, 06:16:

maxtherabbit wrote on 2023-09-25, 00:17:

It appears to format just fine until the very end, after I enter the volume label it hangs with the drive LED stuck on. By the way, I found out when it does this it will eventually timeout (after like over a minute) and give this error. It's not a hard system lock, though the LED remains stuck on even after DOS prints the error.

I'm going to push the ID0 patch tonight anyway, as it will definitely make things better.

Posted.

mkarcher wrote on 2023-09-25, 06:16:

maxtherabbit wrote on 2023-09-25, 00:17:

It appears to format just fine until the very end, after I enter the volume label it hangs with the drive LED stuck on. By the way, I found out when it does this it will eventually timeout (after like over a minute) and give this error. It's not a hard system lock, though the LED remains stuck on even after DOS prints the error.

Oh, I think I know what might go wrong if there is some other LBA call in-between. The ID0 bug in my LBA code might break SCSI disconnect/reconnect (but only for LBA calls). Please try disabling disconnect for ID0 in the EISA setup. If it helps, I hope that your issue is caused by this side-effect. If it doesn't help, I suspect the 2.11 BIOS has some general issues with the ATLAS drive, and I would ask you to try the unpatched 2.11 and test whether you can reproduce the issue.

I'm going to push the ID0 patch tonight anyway, as it will definitely make things better.

This issue with the 73GB drive persists both with your latest release as well as stock 2.11 BIOS.

The EDD 1.1 ROM is working perfectly with the 32GB drive though 😀

I'm starting to wonder if the large drive issue only shows up with multi sector transfers

Remember how when listing the directory on the Atlas drive it would always successfully print the first half of the listing before bombing out? How much did you test the IDE drive + adapter, did you try copying a significant amount of data to the drive?

rkurbatov wrote on 2022-08-28, 12:16:

As for Aspi - my SCSI drive has died (like lots of others before). I ordered a party of newer ones and will try them instead. Then I can tell more about Aspi7DOS.sys problem.

Just a ping to you (by quoting you). The ASPI7DOS problem has been identified and fixed by now. Also, the BIOS patch before "Release 2.0" on my GitHub page for the AIC-7770 BIOS (274x and 284x) was broken for any configuration except a single hard drive at ID 0. Please update to use the newest patches if you want to go on with experimenting with big drives on your 2842A.

Perhaps another clue as to whats going on with the 73GB disk - for giggles I tried to repartition it again but this time using large disk support and making 1 full size partition. The format still failed, but did so slightly differently. Note the displayed size... perhaps indicating a wrap around somewhere

maxtherabbit wrote on 2023-09-26, 20:12:

Note the displayed size...

This looks like the standard FDISK display error.

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

maxtherabbit wrote on 2023-09-26, 20:12:

Note the displayed size...

This looks like the standard FDISK display error.

Except FORMAT doesn't have that display bug like FDISK does... right?

This is not FORMAT from 95 btw it's from 98SE or newer

This turned out to be untrue. I hooked up the same drive to a different system and booted from the same disk and ran FORMAT again, got the same displayed value.

Interestingly before I reformatted it, this system was able to read out the empty directory just fine, indicating that the 2742 system had indeed formatted the disk successfully, it just bombed out when trying to read back the FAT at the end.

Max, I've used your bootdisk to format my 82,4 GB IDE disk on an ACARD IDE-to-SCSI adapter on the Adaptec 2842VL with mkarcher's patched BIOS.
It passed without an error.

It is the same result to my Windows 95 B bootdisk, which I used before.

In both cases I have zeroed sectors 0 and 63 before and did reboots after zeroing and partitioning.