feipoa wrote on 2024-01-15, 12:50:

I haven't been following this thread and didn't even know about it until now. So it sounds like mkarcher's BIOS fix would allow, for example, that w95 partition of mine to be 64 GB (in the above example), with the drawback being that the w95 read speeds would be reduced?

It would be nice if we had XT-IDE ROMs for SCSI VLB/EISA controllers.

Windows 9x has its own driver that has no problems with the 8 GB limit.
So mkarcher's BIOS patch will not influence transfer speed.

And his patch works on the EISA 2740 controller series too.

If you use Windows 95 B or C, I'd recommend to have DOS partitions within 1021 cylinders, and to have the LBA partitions to start at cylinder 1022.

DOS partition
NT partition
Extended: 2 GB FAT 16 partition
Cylinder 1022: W95 partition (60 GB?)

Disruptor wrote on 2024-01-15, 12:55:

Windows 9x has its own driver that has no problems with the 8 GB limit. So mkarcher's BIOS patch will not influence transfer spe […]
Show full quote

feipoa wrote on 2024-01-15, 12:50:

I haven't been following this thread and didn't even know about it until now. So it sounds like mkarcher's BIOS fix would allow, for example, that w95 partition of mine to be 64 GB (in the above example), with the drawback being that the w95 read speeds would be reduced?

It would be nice if we had XT-IDE ROMs for SCSI VLB/EISA controllers.

Windows 9x has its own driver that has no problems with the 8 GB limit.
So mkarcher's BIOS patch will not influence transfer speed.

And his patch works on the EISA 2740 controller series too.

If you use Windows 95 B or C, I'd recommend to have DOS partitions within 1021 cylinders, and to have the LBA partitions to start at cylinder 1022.

DOS partition
NT partition
Extended: 2 GB FAT 16 partition
Cylinder 1022: W95 partition (60 GB?)

OK, but I haven't had any problems with it the way it is. I've been running it like this for about 8 years.

feipoa wrote on 2024-01-15, 12:50:

with the drawback being that the w95 read speeds would be reduced?

I don't know why w95 is not enabling fast SCSI in my case and is in yours, but it's not the fault of the BIOS upgrade. I was stuck at 5MB/sec before I changed the ROM too

I'll have to do a binary compare on the miniport drivers included with B and C to see if something changed

As best I can tell there is a bug/drawback in the windows 95 miniport driver (ARROW.MPD) that does not enable FastSCSI on the EISA based 274x controllers. I have confirmed that the driver and associated INF information (stored in SCSI.INF) are 100% binary match between win95 B and C, and feipoa has confirmed FastSCSI works with the VLB version of the card. So the problem must be specific to the EISA adapter.

Does Win98SE exhibit the same symptoms?

feipoa wrote on 2024-01-21, 23:44:

Does Win98SE exhibit the same symptoms?

Yes

Wondering aloud if anyone tested the latest version of this code (2.0) and the driver on an Adaptec AHA-2842A. The last few pages of the thread called out some bugs and instability but it wasn't entirely clear to me what was and wasn't working.

I'm proactively necroposting this as I'm about to go down the path of trying it myself, and perhaps someone here can save me some time with a view on if it works or not.

Either way I'll circle back to this thread with my results, using the version 2.0 code that was posted to Github.

I don't own a VLB card so I can't help you but I've tested the firmware and modified driver on two different EISA systems with two cards and both performed perfectly

Awesome thanks! I'll report back with feedback after I try it. This is a bit further down my list after I get the 486 stable at 160MHz.

maxtherabbit wrote on 2026-07-06, 23:17:

I don't own a VLB card so I can't help you but I've tested the firmware and modified driver on two different EISA systems with two cards and both performed perfectly

Can you tell me more about it? I'd like to test your driver on my EISA 2740W and to look at the changes.
I've reportet about wide (non-fast) performance under Windows9x.
Win95 Performance of 2740W / 2742W
Please remember mkarcher's BIOS patch for enabling disks > 8 GB on that controllers (247X and 284X).

Disruptor wrote on 2026-08-06, 09:54:

Can you tell me more about it? I'd like to test your driver on my EISA 2740W and to look at the changes. I've reportet about wid […]
Show full quote

maxtherabbit wrote on 2026-07-06, 23:17:

I don't own a VLB card so I can't help you but I've tested the firmware and modified driver on two different EISA systems with two cards and both performed perfectly

Can you tell me more about it? I'd like to test your driver on my EISA 2740W and to look at the changes.
I've reportet about wide (non-fast) performance under Windows9x.
Win95 Performance of 2740W / 2742W
Please remember mkarcher's BIOS patch for enabling disks > 8 GB on that controllers (247X and 284X).

Huh? I got the copy of ASPI7DOS from you 🤣

Ah, so it's the BIOS and the ASPI7DOS driver and you also have no solution for Windows 9x?

I want to say the built in 9x driver could handle the larger disks already but I honestly don't remember clearly now

mkarcher wrote on 2021-11-25, 19:54:

The Adaptec 274x and 284x SCSI controller cards never got a BIOS update to support (booting from) drives bigger than 8GB. This i […]
Show full quote

The Adaptec 274x and 284x SCSI controller cards never got a BIOS update to support (booting from) drives bigger than 8GB. This is in contrast to the 1542CF (an ISA card!), which did receive a BIOS update implementing the Phoenix Enhanced Disk Drive (EDD) Specification (which is endorsed/supported by Microsoft). If the SCSI controller supports the EDD specification, the Windows editions that support FAT32 and LBA addressing can make use of the whole drive (i.e. some late Windows 95 versions, Windows 98 and later).

I set out to fix this problem and developed a patch to implement at least basic support for the Phoenix EDD on Adaptec controllers based on the AIC-7770 SCSI controller. It turns out that the BIOS contains sufficient amounts of dead code (in case of the 2742W, Version 2.11) or unused space (in case of the 2842VL) to add the extra functionality. The BIOSes are so similar to each other, that a common patch is possible, you just need to adjust a couple of offsets.

Furthermore, the ASPI driver contains a (faster) Int 13 implementation. In case of the EISA/VL controllers, you use ASPI7DOS.SYS, which also is too old to support the EDD specification. In case of the ASPI driver, a happy accident allowed to easily add the EDD implementation: Instead of space for 8 data structures about BIOS supported HDD drives, Adpatec reserved space of 88 data structures. This causes a hole of 880 Bytes in the driver for free use.

I patched the latest BIOS of the 2742W (Version 2.11, contained in a OTP chip on Disruptor's controller) and the 2842VL (Version 1.01, came with the card, also available for download at Microsemi). Furthermore I patched ASPI7DOS.SYS. Preliminary tests (basically booting the command prompt of Windows 98, and runnig a disk test in speedsys) show that implementations work. I offer my patches under the very permissive BSD license on GitHub, see https://github.com/karcherm/scsi_edd. I do not have patched binaries on that page, as distributing modified versions (derived works) of proprietary software is something I don't want to get into - especially as Adaptec's successor Microsemi is still an active company today. Instead, the releases on that repository contain ".OBJ" files, which can be applied as patches using my project omfpatch, see https://github.com/karcherm/omfpatch.

I did something similar to the mainboard SDMS BIOS some time ago, see https://github.com/karcherm/sdms_8g, which I am likely going to merge into the scsi_edd repository some day.

Hello,

I've tried to apply this patch to my 2842A card and I'm getting this:

Did I do something wrong or...?

I used this command line:

1C:\Users\oerg866\Downloads\scsi_edd>omfpatch.exe AHA-2842A.BIN bios1632.map 284x-200.obj
2patched AHA-2842A.BIN using 284x-200.obj - OK

Base BIOS is this one: https://theretroweb.com/expansioncards/s/adaptec-aha-2842a

The original 2.0 BIOS was able to run the configuration tool just fine...
Thanks!
Eric

Have you disabled shadowing of adaptor ROMS in your BIOS?

Unfortuneately we don't have a 2842A here, just a 2842VL.

Yes. The issue I'm trying to fix here is that windows 95 stops loading after 2 or 3 seconds with the system going idle and the loading screen keeps cycling colors. Since the drive is 10GB, I thought this could be the problem 😒

Can you send both BIOS and patched BIOS to mkarcher please?

Okay, I've DM'd him (I'm assuming you don't want me to attach them publicly here)

Even though SCSISelect refuses to run, the BIOS does detect the drives and install itself, and I can access them in DOS, with the full size, using the modded ASPI7DOS.SYS. I'm installing Win95 again to see if the booting issue is fixed 😀

A small update: It does appear that the controller works fine, I was able to install windows on a 128GB SCSI drive even, and RANISH partition manager showed the full size even. Very cool!

Oerg866 wrote on 2026-08-12, 15:16:

Okay, I've DM'd him (I'm assuming you don't want me to attach them publicly here)

I was busy the last week, I looked into the SCSISelect issue right now. The code is simple and works the same on the 2842A and 2842VL: The BIOS copies a small trampoline function into RAM, then switches the ROM bank to the second 32K in the ROM address range, copies the SCSISelect code into RAM, and switches back to the first 32K for the ROM address range. After that second switch, it compares a small sample of the copied SCSISelect code (Offset C000..C01F) with the corresponding sample of the BIOS code (Offset 4000..401F). The BIOS code (likely on purpose) contains only 0FFh bytes at that location, while the SCSISelect code does not. If you get that message, the bytes that were supposed to originate from the SCSISelect code turned out identical to the bytes from the BIOS ROM - essentially the bank switching failed.

If you can enter SCSISelect with the original ROM chip, your system and the 2842A should be working fine, so the issue is either with the ROM image (which I highly doubt, looking at the images), or with your ROM chip. What chip did you write the modified ROM contents into? Are you sure it is pin compatible (especially regarding address pin A15) with the original Adaptec mask ROM? On the 2842VL, the mask ROM is a standard 27C512 type chip.

Oerg866 wrote on 2026-08-12, 15:16:

Even though SCSISelect refuses to run, the BIOS does detect the drives and install itself, and I can access them in DOS, with the full size, using the modded ASPI7DOS.SYS. I'm installing Win95 again to see if the booting issue is fixed 😀

The BIOS mod (if it works as intended) should make the full size available even without ASPI7DOS.SYS loaded. Did you check whether that works, too? For optimal performance, loading ASPI7DOS.SYS is recommended, though.