Updated prev reply. I am already running 2.11.

Any suggestions on settings to use or not use?

Sphere478 wrote on 2022-09-04, 18:05:

Any suggestions on settings to use or not use?

You need to have "Advanced Configuration Options" -> "BIOS Support for INT13h Extensions" enabled. I'm unsure whether I tested the internal utilities in the ROM, but I am quite confident that WIN 95 OSR2 was able to partition the whole 18 or 36 GB drive with this option set.

rkurbatov wrote on 2022-09-04, 17:58:

@mkarcher, wow, was it native BIOS from Adaptec or somebody did it just as you did? Strange they did that for old ISA adpaters and did not for more modern ones.

That's why I called the 2740 and 2840 "ugly ducklings". They obviously dropped out of support before the 1542CF. I suspect some big industrial customer paid them to release a modern BIOS for that controller.

Interesting. Can it be "reused" somehow?

mkarcher wrote on 2022-09-04, 18:21:

Sphere478 wrote on 2022-09-04, 18:05:

Any suggestions on settings to use or not use?

You need to have "Advanced Configuration Options" -> "BIOS Support for INT13h Extensions" enabled. I'm unsure whether I tested the internal utilities in the ROM, but I am quite confident that WIN 95 OSR2 was able to partition the whole 18 or 36 GB drive with this option set.

As you can see from the screenshot Sphere478 posted, he already has that setting enabled. Yet he claimed when I was talking to him on discord that he was still seeing only 8GB in DOS. So either:

1) he was not actually using DOS 7, and basing his claims on SCSISelect or some earlier version of DOS' FDISK
or
2) you were partitioning the full size of the drive in Windows 95 after the 32bit filesystem drivers were loaded.

Prior to this thread, I was under the same notion that rkurbatov was - no 154x card supports extended INT13h. Had he posted that screenshot on discord, I would have taken a quite different tack in the conversation.

No, I am seeing no drives in dos. (Me boot disk) I can not see any scsi in dos or redhat installer

I tried to post that pic but it sat there for an hour not uploading 🤣.

Anyway, in the scsi utility it is passing all tests.

I can try hirens boot cd next and putting it in another mobo next.

maxtherabbit wrote on 2022-09-05, 14:54:

As you can see from the screenshot Sphere478 posted, he already has that setting enabled. Yet he claimed when I was talking to h […]
Show full quote

mkarcher wrote on 2022-09-04, 18:21:

Sphere478 wrote on 2022-09-04, 18:05:

Any suggestions on settings to use or not use?

You need to have "Advanced Configuration Options" -> "BIOS Support for INT13h Extensions" enabled. I'm unsure whether I tested the internal utilities in the ROM, but I am quite confident that WIN 95 OSR2 was able to partition the whole 18 or 36 GB drive with this option set.

As you can see from the screenshot Sphere478 posted, he already has that setting enabled. Yet he claimed when I was talking to him on discord that he was still seeing only 8GB in DOS. So either:

1) he was not actually using DOS 7, and basing his claims on SCSISelect or some earlier version of DOS' FDISK
or
2) you were partitioning the full size of the drive in Windows 95 after the 32bit filesystem drivers were loaded.

I did not boot into the Windows GUI for sure. I don't actively remember how much I tested the 1542CF, but I did check the BIOS in a disassembler just recently: It does support INT13 extensions. Be aware, if you load ASPI4DOS.SYS, you will use the INT13 implementation of ASPI4DOS, not the one from the BIOS. If ASPI4DOS is old enough to not support the INT13 extensions, this means you lose access beyond 8GB.

mkarcher wrote on 2022-09-05, 20:38:

Be aware, if you load ASPI4DOS.SYS, you will use the INT13 implementation of ASPI4DOS, not the one from the BIOS. If ASPI4DOS is old enough to not support the INT13 extensions, this means you lose access beyond 8GB.

Confirm. That happened for me.

The check of ASPI7 is still on me 😀 I have new fresh old SCSI drive to test.

BTW, none of my 36G drives, even Ultra160 worked on this 2842A (wasn't recognized) but that looks more like hardware problem. 9-18G is more than enough for 486 with VLB bus.

mkarcher wrote on 2022-09-04, 18:00:

rkurbatov wrote on 2022-09-04, 17:58:

@mkarcher, wow, was it native BIOS from Adaptec or somebody did it just as you did? Strange they did that for old ISA adpaters and did not for more modern ones.

It's the BIOS Sphere478 linked. Likely I got it from vogonsdrivers, too. I don't remember whether my card was shipped with it, or I upgraded it. Possibly I get around soon to look at the EPROMs on that card and check whether they have hand-written labels on them.

Te V2.11 EPROMs with EDD support on my AHA-1542CF are ceramic UV-erasable EPROMs with original Adaptec labels over the window that look like I never lifted them. In other words: my 1542CF was shipped with LBA support for Win95B/Win98 from the factory. The EPROMS are labelled like this:

1ADAPTEC INC
2553801-00 E
3MCODE 4B81
4(c) 1994

and

1ADAPTEC INC
2553801-00 E
3BIOS 7600
4(c) 1994

Anyone willing to help out with a 2.11 binary for the 274x cards? My only specimen is running version 1.something

Beautiful

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

Beautiful
20230913_154050.jpg

Please don't forget to use the patched ASPI7DOS.SYS too
INT13 Extensions to Adaptec 274x EISA & 284x VLB

Disruptor wrote on 2023-09-13, 22:33:

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

Beautiful
20230913_154050.jpg

Please don't forget to use the patched ASPI7DOS.SYS too
INT13 Extensions to Adaptec 274x EISA & 284x VLB

Naturally. Anyone happen to know offhand a DOS utility to expand an existing FAT32 partition?

maxtherabbit wrote on 2023-09-13, 22:42:

Naturally. Anyone happen to know offhand a DOS utility to expand an existing FAT32 partition?

You don't just edit the size of your FAT32 partition. You will probably alter file system type too. There is a difference between FAT32 (CHS) = type 0Bh and FAT32 (LBA) = type 0Ch.
In your place I'd do a backup with classic Norton Ghost and a restore (With this tool I prefer to not use high compression).

I'm sorry to report the patched version of ASPI7DOS doesn't work on my system. The patched driver will load just fine, but as soon as you try to load ASPICD.SYS or IFSHLP.SYS after it is loaded the system will crash. If EMM386 is loaded it traps the exception and resets the system, if it is not the system just hard locks. With the patched BIOS and no ASPI manager loaded everything works normally. With the patched BIOS and the unpatched ASPI7DOS.SYS everything also works normally (using my unmodified pre-patch partition table)

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...

Went back and retraced my steps and still getting bad output from omfpatch-win. Used the command line:

1omfpatch aspi7dos.sys a7-142.map a7-142.obj

Binary compared the source file to an original ASPI7DOS.SYS from adaptec archive (DOSDRVR.EXE) and it's good. Binary compared the MAP and OBJ file with the github release and they also match. But the output file is still bad. Uploaded it here for review.

Ok now I binary diffed my patched BIOS and it also doesn't match what Disruptor uploaded.... Something is very wrong here

I also checked the SHA-1 of my original 2.11 BIOS ROM and it matched what's specified in the github. omfpatch-win is producing bad output

At offset 0xBB8:
Disruptor's BIOS ROM has

105 01 00 

My output file from omfpatch-win has

183 C0 01

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

Ok now I binary diffed my patched BIOS and it also doesn't match what Disruptor uploaded.... Something is very wrong here

Nothing is wrong at this instance, except maybe the publishing process by Disruptor and me. The assembler source code of the patch is managed in GitHub, and will be automatically assembled using an Open-Source assembler on a cloud computer provided by GitHub. I am using JWASM here, which aims to be quite compatible to MASM (the classic Microsoft Macro Assembler).

On the other hand, I traditionally use a commercial non-free assembler TASM in my private development toolchain, which isn't legally available for free for use in GitHub workflows.

The patch is written in source form to be maintainable, so I don't specify what bytes needs to be in the target patched file when I write this patch, but I just specify what machine instructions need to be patched there. An assembler is supposed to generate an efficient encoding of the instructions specified in the source file, but in this instance, there are two different binary encodings of the same machine language instruction, and TASM (which was used during development, and used to generate the image uploaded by Disruptor) chose a different instruction encoding than JWASM (which is used in the cloud) uses. As both instructions encodings are 3 bytes, they are "equally efficient" if you just look at the code size. Decode performance might be different, though. As the instructions do the same thing and use the same amount of space, it doesn't matter which version of the patched ROM you use. Both work fine.

In this case, we are looking at Line 192 of aic7770.asm, which is

1ADD AX,1

Disruptor's BIOS ROM has […]
Show full quote

Disruptor's BIOS ROM has

Copy code to clipboard

105 01 00 

05 is the opcode for "add the following 16 bit constant to the fixed register AX". The two subsequent bytes are 01 00, which is the little-endian encoding of the 16-bit value 1. This encoding is generated by TASM

My output file from omfpatch-win has […]
Show full quote

My output file from omfpatch-win has

Copy code to clipboard

183 C0 01

• 83 is the opcode for "perform a arithmetic or logical operation specified by 3 bits in the subsequent byte on a 16-bit memory location or register specified on the other 5 bits of that byte. Sign-extend the 8-bit value in the byte after that to obtain the second operand for the instruction.
• C0 at that location (as ModR/M byte) means for 16-bit instructions: The operation is to be performed on the register AX. The operation to perform is "ADD".
• 01 is the constant 1

This encoding is generated by JWASM

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. I did know about the different encoding of the add instruction discussed in the BIOS patch, and I confirmed this is not a problem. Maybe there also is a difference in how JWASM handles the ASPI7DOS patch that does matter. I had some issues with JWASM not resolving references correctly in certain circumstance (maybe if there errorneously were labels that were defined multiple times), and I might have run into one of these issues in the ASPI7DOS patch. I will look into that issue, and likely uploaded a fixed patch source code soon.

mkarcher wrote on 2023-09-14, 15:59:

Nothing is wrong at this instance, except maybe the publishing process by Disruptor and me. The assembler source code of the pat […]
Show full quote

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

Ok now I binary diffed my patched BIOS and it also doesn't match what Disruptor uploaded.... Something is very wrong here

Nothing is wrong at this instance, except maybe the publishing process by Disruptor and me. The assembler source code of the patch is managed in GitHub, and will be automatically assembled using an Open-Source assembler on a cloud computer provided by GitHub. I am using JWASM here, which aims to be quite compatible to MASM (the classic Microsoft Macro Assembler).

On the other hand, I traditionally use a commercial non-free assembler TASM in my private development toolchain, which isn't legally available for free for use in GitHub workflows.

The patch is written in source form to be maintainable, so I don't specify what bytes needs to be in the target patched file when I write this patch, but I just specify what machine instructions need to be patched there. An assembler is supposed to generate an efficient encoding of the instructions specified in the source file, but in this instance, there are two different binary encodings of the same machine language instruction, and TASM (which was used during development, and used to generate the image uploaded by Disruptor) chose a different instruction encoding than JWASM (which is used in the cloud) uses. As both instructions encodings are 3 bytes, they are "equally efficient" if you just look at the code size. Decode performance might be different, though. As the instructions do the same thing and use the same amount of space, it doesn't matter which version of the patched ROM you use. Both work fine.

In this case, we are looking at Line 192 of aic7770.asm, which is

Copy code to clipboard

1ADD AX,1

Disruptor's BIOS ROM has […]
Show full quote

Disruptor's BIOS ROM has

Copy code to clipboard

105 01 00 

05 is the opcode for "add the following 16 bit constant to the fixed register AX". The two subsequent bytes are 01 00, which is the little-endian encoding of the 16-bit value 1. This encoding is generated by TASM

My output file from omfpatch-win has […]
Show full quote

My output file from omfpatch-win has

Copy code to clipboard

183 C0 01

• 83 is the opcode for "perform a arithmetic or logical operation specified by 3 bits in the subsequent byte on a 16-bit memory location or register specified on the other 5 bits of that byte. Sign-extend the 8-bit value in the byte after that to obtain the second operand for the instruction.
• C0 at that location (as ModR/M byte) means for 16-bit instructions: The operation is to be performed on the register AX. The operation to perform is "ADD".
• 01 is the constant 1

This encoding is generated by JWASM

That all makes good sense. I just panicked when I found out the patched version of ASPI7DOS did not work and out came the UV light to switch to Disruptor's binary. I didn't think to actually try to disassemble the bytes since the driver binary was clearly broken.

I can also report that there is still a limit somewhere, when I connect my 73GB SCSI external disk to the system it does not show the full capacity in FDISK, regardless if ASPI7DOS is loaded or not. This drive also had an existing 2GB partition at the beginning of the drive for compatibility sake with older systems, however trying to read a directory from this hangs the system. So it seems there is an overflow bug in the extended int13 handler or something. This first partition was usable on this system before the BIOS upgrade.

Perhaps the existing 2 GB partition has been created using an incompatible CHS translation on another controller?
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.
Do you get the same problem with and without loaded ASPI7DOS.SYS?

Do you use the WIDE version of this controller?