The DOS driver speeds up your disk speed a little bit (appr. 30%). In general the BIOS support of your Adaptec SCSI controller is sufficient. But there are some exceptions:

- The 1542B has no sufficient BIOS support and needs a DOS driver (beacause of conflicts with memory managern (EMM386), Windows 3.1 services and Virtual DMA Services - VDS) The later versions (C / CF /CP) have no need for DOS
- For more than 16MB RAM together with 1542x you have to load the ASPIBUF.SYS which depends a loaded ASPI4DOS.SYS
- the CD-ROM driver ASPICD.SYS depends a loaded ASPI driver of your controller
- the most other devices (ZIP, Scanner, etc.) except HDDs need the ASPI (Advanced SCSI Programming Interface) driver

Isn´t the BIOS support limited to 2 disks only? Running more than two disks will require the driver.

auron wrote on 2020-04-30, 02:54:

i've seen vague remarks on the internet that using a driver (for adaptec, presumably said aspidisk.sys) can actually improve HDD performance, but in what way would a driver operate differently?

Even if the driver would use exactly the same code, it is loaded in to RAM, whereas the ROM is, well, in ROM. Code from ROM runs slower, as access times are much worse. So a driver loaded into RAM can indeed improve performance. Unless the SCSI ROM is shadowed into RAM.

good points, hadn't considered SCSI ROM shadowing. some older boards can't do this. i think this is worth doing some benchmarking eventually, haven't seen the difference BIOS vs. driver tested yet.

The 1542 cause RAM issues and crashes with shadowing, which can result in corrupt data on your HDD

PC-Engineer wrote on 2020-04-30, 14:44:

The 1542 cause RAM issues and crashes with shadowing, which can result in corrupt data on your HDD

That only applies to the 1542Cx - and even then it works just fine if you set the shadow RAM to read/write instead of read only. The 1542B can be shadowed with regular read-only shadow RAM without any problems at all.

If shadowing is not an option for whatever reason, the same performance gain can be achieved by loading the ASPIxDOS.SYS driver only. ASPIDISK.SYS is only required if you have more than 2 HDDs or have the SCSI BIOS disabled.

maxtherabbit wrote on 2020-04-30, 15:51:

If shadowing is not an option for whatever reason, the same performance gain can be achieved by loading the ASPIxDOS.SYS driver only. ASPIDISK.SYS is only required if you have more than 2 HDDs or have the SCSI BIOS disabled.

interesting, i typically load aspi8dos.sys with the 2940 series anyway for use with a CD drive. but as it doesn't make any mention of the harddrive, and the harddrive is still just listed as an i13h device in speedsys, it didn't occur to me that the driver was already interacting with the HDD in some way. i guess the adaptec readme is a bit brief on this subject.

ASPIxDOS.SYS hooks the INT 13h handler and serves requests from RAM instead of ROM, so you get the same performance improvement as shadowing would for all SCSI devices.

Is there a good DOS disk I/O benchmark people would recommend other than speedsys? It hangs during memory identification on my machine for reasons unknown so I haven't been able to use it. Open to other options.

https://www.lo-tech.co.uk/wiki/DOS_Disk_Tester

i've now tested this on a batman's revenge socket 4 board, pentium 60, 2940uw and some 1999 68pin IBM drive and loading aspi8dos.sys did not result in a performance benefit in speedsys on this setup. scores were identical, except for buffered read speed, which in fact was very slightly, but repeatably lower with the driver loaded (~31800 KB/s vs. 31000 KB/s). i did however notice a message after the driver load saying that i13h is routed through the ASPI driver, so it's definitely doing something.

i assume that this board does SCSI ROM shadowing by default, which would explain the rather long boot time whenever a SCSI controller is present, and the ASPI driver comes with an ever so slight overhead, while not having any benefit when the ROM is already shadowed. needless to say though the bandwidth difference is totally irrelevant for actual use.

unrelated to this topic, but benching said SCSI setup on the same board vs. a slower IDE quantum fireball on the onboard RZ1000 with adaptec's threadmark in windows 95, i was surprised that CPU utilization was actually higher, 66.7% CPU and 6.21 MB/s with SCSI, vs. 58.7% CPU and 2.31 MB/s on IDE. i suppose the busmastering done on SCSI only help so much and these I/O operations still take significant CPU time, and the windows 95 implementation of multitasking is too limited to optimally take advantage of it as well.

All PCI card expansion ROMs are shadowed by necessity. No surprise in your results