mkarcher wrote on 2023-09-14, 16:04:

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

Ok the problem was the file itself. I just tried the version of ASPI7DOS uploaded by Disruptor and it works perfectly. I did a binary diff between that and the file I produced myself using omfpatch. There were a few bytes different...

I intended to make sure that the patches on GitHub work.

... and I have failed. The patch as published on GitHub in releases up to 1.3 is broken. I just uploaded a new release and edited the release notes of all older releases to point out that the ASPI7DOS.SYS patch object file is broken in all releases before 1.4. The version published by Disruptor was created using TASM (in its default MASM compatibility mode), and works fine, but contains unnecessary NOP padding in a conditional forward jump. This is the effect of running TASM in its default single-pass mode. The version published on GitHub now does not include this padding, so it compares different to the version published by Disruptor. This is an acceptatble difference. On the other hand, the difference between Disruptors version and the version obtained by applying the patch downloadable on GitHub at offsets 4998 to 499F are gone now, and they were the reason for the patched binary to fail.

Disruptor wrote on 2023-09-14, 19:19:

Perhaps the existing 2 GB partition has been created using an incompatible CHS translation on another controller?

As I said in the previous post, this partition was usable on this exact system before updating the BIOS on the SCSI card to 2.11E.

Disruptor wrote on 2023-09-14, 19:19:

Which FDISK did you try? As far as I remember Windows 9x FDISK have an overflow bug displaying the size of a disk > 64 GB.

You're right, I totally forgot about that. So we can disregard the part about FDISK. The salient part is the partition not being able to list a directory in DOS. It works fine if I boot all the way into win95.

Disruptor wrote on 2023-09-14, 19:19:

Do you get the same problem with and without loaded ASPI7DOS.SYS?

yes, as previously stated

Disruptor wrote on 2023-09-14, 19:19:

Do you use the WIDE version of this controller?

no, but it is the dual channel version

maxtherabbit wrote on 2023-09-14, 19:45:

Disruptor wrote on 2023-09-14, 19:19:

Perhaps the existing 2 GB partition has been created using an incompatible CHS translation on another controller?

Okay, we need to have look into this problem.
How do you currently boot (from another disk or the 73GB disk, and which operating system)?

Does the problem disapper when you use an unpatched ASPI7DOS.SYS?

maxtherabbit wrote on 2023-09-14, 19:45:

no, but it is the dual channel version

So you're limited to ~ 9 MB/s then.

Disruptor wrote on 2023-09-14, 20:01:

Okay, we need to have look into this problem.
How do you currently boot (from another disk or the 73GB disk, and which operating system)?

Does the problem disapper when you use an unpatched ASPI7DOS.SYS?

The external 73GB drive is connected as ID 1. The boot drive (ID0) is an 8GB internal. OS is windows 95B, booting into pure DOS mode (BootGUI=0).

The problem occurs with the patched ASPI7DOS, the unpatched ASPI7DOS, and with no ASPI7DOS at all. It only affects pure DOS. If I type WIN and boot the rest of the way into 95 it works fine.

maxtherabbit wrote on 2021-11-25, 20:18:

Impressive. I don't suppose you'd consider taking a look at ASPI4DOS.SYS as well?

The latest version of it does not work at all with the 1542B. The previous release, dated 1997, does support the 1542B but it has a bug. The latest BIOS for the 1542B supports extended translation, and indeed works with HDDs of all sizes in DOS (although only 8GB is accessible of course). However when you load the 1997 version of ASPI4DOS.SYS with a drive >8GB attached to the system, any subsequent accesses to that drive fail

Apparently this is a problem with a kind of "Genuine Adaptec card" check that was introduced in the latest version but fails on very old cards: https://www.os2museum.com/wp/learn-something- … d-aspi4dos-sys/

rkurbatov wrote on 2022-08-24, 22:39:

Patched BIOS + patched ASPI7DOS.sys - Partition Magic 6.0 hangs on start. Without EMM386 it just quits silently. I though there is not enough memory (I run it from FDD) so I added Jedex.exe - now it fails with small Jedex stacktrace.

There was a broken patch for ASPI7DOS.SYS on GitHub up to and including Release 1.3. I did not apply sufficient quality control when changing from the commercial TASM to the open-source JWASM assembler, and my approach of creating patches using assembler source code with a lot of ORG directives seems to trigger a bug in JWASM. I shuffled two blocks in the source file, now the patch file generated by the GitHub action should work fine.

davidrg wrote on 2023-09-14, 21:01:

maxtherabbit wrote on 2021-11-25, 20:18:

Impressive. I don't suppose you'd consider taking a look at ASPI4DOS.SYS as well?

The latest version of it does not work at all with the 1542B. The previous release, dated 1997, does support the 1542B but it has a bug. The latest BIOS for the 1542B supports extended translation, and indeed works with HDDs of all sizes in DOS (although only 8GB is accessible of course). However when you load the 1997 version of ASPI4DOS.SYS with a drive >8GB attached to the system, any subsequent accesses to that drive fail

Apparently this is a problem with a kind of "Genuine Adaptec card" check that was introduced in the latest version but fails on very old cards: https://www.os2museum.com/wp/learn-something- … d-aspi4dos-sys/

Thanks for posting that. Here is an experimentally patched version of ASPI4DOS.SYS which removes those checks. There were actually two different ones, the one the blog author described which sums the 4 letters but also another that loops until it finds a 'D' then expects 'A' 'P' 'A'.

Credit to @jakethompson1 for finding the offsets for me (in record time).

Unfortunately it still won't init the driver on my 1542B, now instead of silently failing with no explanation it loudly beeps the PC speaker and says "Unable to read configuration from host adapter"

Before

After

maxtherabbit wrote on 2023-09-15, 01:45:

Unfortunately it still won't init the driver on my 1542B, now instead of silently failing with no explanation it loudly beeps the PC speaker and says "Unable to read configuration from host adapter"

So possibly this driver is not intended to work with the 1542B after all. The 1542C has a configuration EEPROM which can be configured using the built-in SCSISelect BIOS features, and the firmware of the 1542C controller exposes extended commands to read the configuration stored in that EEPROM. These command provide more detailed configuration data than the old configuration reporting commands supported by the 1542B which just report the jumper settings. The error message seems to indicate that the driver blindly tries to issue an extended configuration retrieval command without checking the controller version (now that the ADAP check is removed), and it fails because the 1542B firmware doesn't implement that command.

mkarcher wrote on 2023-09-15, 17:21:

maxtherabbit wrote on 2023-09-15, 01:45:

Unfortunately it still won't init the driver on my 1542B, now instead of silently failing with no explanation it loudly beeps the PC speaker and says "Unable to read configuration from host adapter"

So possibly this driver is not intended to work with the 1542B after all. The 1542C has a configuration EEPROM which can be configured using the built-in SCSISelect BIOS features, and the firmware of the 1542C controller exposes extended commands to read the configuration stored in that EEPROM. These command provide more detailed configuration data than the old configuration reporting commands supported by the 1542B which just report the jumper settings. The error message seems to indicate that the driver blindly tries to issue an extended configuration retrieval command without checking the controller version (now that the ADAP check is removed), and it fails because the 1542B firmware doesn't implement that command.

Yeah I think the blogger's assertion that adaptec intended to support the 1542B with this driver version but simply "forgot" it doesn't have the secret port is wrong. I think their failure was simply one of documentation.

The question remains, why does 3.35 hang the system when accessing very large drives? (when the BIOS has no such problem without an ASPI manager loaded)

And also: why does the 2.11 BIOS for the EISA card seem to have the same problem, or at least the same symptom?

Well I scored a 36.4GB SCSI drive on ebay for $10 shipped to use as a test to see (hopefully) where the size bug starts. Does anyone else in this thread other than @rkurbatov and myself have a 274x card to test?

maxtherabbit wrote on 2023-09-18, 00:27:

Well I scored a 36.4GB SCSI drive on ebay for $10 shipped to use as a test to see (hopefully) where the size bug starts. Does anyone else in this thread other than @rkurbatov and myself have a 274x card to test?

I just set up a system with an 2842VL, which uses a very similar BIOS to the 2742, and I connected two drives to it. The BIOS has my EDD patches applied.

• ID 0 is a 9GB drive. The only partition on it is a 1GB FAT32 partition (type 0B: CHS) at the start. This partition has been created with Win95B FDISK on that controller.
• ID 1 is a 36GB drive which already has some partitions on them, for example, the first partition is a 504MB DOS partition (type 06).

I can access all partitions on the ID1 drive without any crashes. Is it possible that the partition layout on your 72GB drive is "weird", which is exposed only when a LBA-capable BIOS is installed? Can you make a dump of the partition table of that drive? You can for example use DEBUG for it:

1-a100
2xxxx:0100 mov ax,201
3xxxx:0103 mov bx,200
4xxxx:0106 mov cx,1
5xxxx:0109 mov dx,81
6xxxx:010C int 13
7xxxx:010E int 3
8xxxx:010F
9-g
10....
11-d 3b0L50
12xxxx:03B0 <some data>
13xxxx:03C0 <more data>
14xxxx:03D0 <even more data>
15xxxx:03E0 <another line of data>
16xxxx:03F0 <last line of data>
17-n partition.bin
18-rcx
19CX 0001
20:0200
21-rbx
22BX 0200
23:0000
24-w200
2500200 bytes written to partition.bin
26-q

The five lines of data (the last one should end with 55 AA) contain the raw partition table. You can redirect the output of debug to a file (but in that case, you have to type the commands blindly).
You also can use the the later commands to dump the complete sector to a file, and create a dump / analyze it yourself / attach it as a ZIP file.

maxtherabbit wrote on 2023-09-18, 00:27:

Well I scored a 36.4GB SCSI drive on ebay for $10 shipped to use as a test to see (hopefully) where the size bug starts.

At the moment, I would be surprised if the bug is related to the disk size. The EDD code I added does no calculations at all - it just passes a 32-bit sector number as given by the operating system to the SCSI hard drive.

Sure I can dump the partition table, I can also repartition it if necessary - I just backed up the data on that one.

FWIW I don't think the EDD code is the culprit. I suspect the issue was present in the stock adaptec 2.11 BIOS - I say this because it's still there with the unpatched ASPI7DOS loaded.

Here is the entire MBR sector for your review. The partition table looks perfectly sane to me.

maxtherabbit wrote on 2023-09-19, 02:05:

FWIW I don't think the EDD code is the culprit. I suspect the issue was present in the stock adaptec 2.11 BIOS - I say this because it's still there with the unpatched ASPI7DOS loaded.

maxtherabbit wrote on 2023-09-14, 18:58:

This first partition was usable on this system before the BIOS upgrade.

I initially assumed "before the BIOS upgrade" refered to the stock 2.11 compared to the 2.11+EDD, but now that I reconsider your quote, you likely refer to the BIOS you had before you got hold of an 2.11 BIOS. What version did you use before? 2.10 or even older?

maxtherabbit wrote on 2023-09-19, 21:29:

Here is the entire MBR sector for your review. The partition table looks perfectly sane to me.

Thanks. There is indeed just a single FAT16 partition using CHS adressing (type 6). Start CHS is 0/1/1, end CHS is 260/254/63. Start LBA is 63 (matches CHS @ 255/63), total size is 4192902 sectors (again consistent with CHS at 255 heads, 63 sectors per track). So this definitely is not a geometry issue - unless there is a bug in the CHS code of the 2.11 BIOS, which mishandles big drives... The BIOS is supposed to return a 1023/255/63 geometry on all drives exceeding 8GB, and Adaptec intends to return XXXX/255/63 for evereything exceeding 1GB.

I checked the 2.11 BIOS code, and it is supposed to work perfectly up to 2TB. Everything between 8GB and 2TB is handled the same way: Only 8GB is accessible using the classic functions.

Just to make sure that the BIOS upgrade didn't invalidate the SCSI configuration: Can you please verify whether the option to support drives above 1GB is enabled in SCSISelect?

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)

Extended translation is absolutely working though, my boot drive is 8GB and working flawlessly.

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

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.

Here are some more details about the actual problem when trying to read from the 73GB drive.

First screenshot is reading the drive from a cold boot into DOS only, gets part way through the directory listing and then hangs - notice the DRIVE activity LED stays stuck on until the SCSI bus is reset.

Next up is trying to read the same directory but not directly from boot, this is after using the system for a while before trying to hit the D drive. Hangs up in basically the same way but with the addition of garbage data being printed to the screen.

And here is the exact same drive on the exact same system, but from inside a windows 95 DOS shell prompt. Working 100%

And finally, running scandisk inside windows 95 on the same drive/system to demonstrate that the FAT is fine.

Windows 9x's driver likely supports Int 13h extensions without a problem.

NJRoadfan wrote on 2023-09-20, 03:10:

Windows 9x's driver likely supports Int 13h extensions without a problem.

Yes, I just wanted to underscore the fact that there is not a hardware fault or anything wrong with the contents of the drive.