Marco wrote on 2025-10-07, 18:18:
I am not able to achieve more than 5,7MB setting with AHA 1542CP no matter what I tried.
My Mobo runs fine with 16MHz ISA max, DMA at 8 MHz but I think this is not the point.
Indeed, ISA clock and DMA clock do not matter for the 1542 series controllers, because despite what the term ISA clock might imply, ISA is basically an asynchronous bus. A memory read cycle starts when /MEMR gets asserted. Some time later, the value from memory is visible on the bus (or IOCHRDY is pulled low to ask for more delays), and after the reader latched the data from memory, it deasserters /MEMR. Obviously, most devices driving the ISA bus have an internal clock that sequences the ISA operation. In case of your mainboard, the chipset is obviously able to sequence ISA cycles from a base frequency of 16 MHz. The standard 0WS memory cycle will have /MEMR (or /MEMW) asserted for one clock, and deasserted for the other clock, for a total of two clocks.
In the case of the 1542, the 1542 asks the DMA controller to grant bus ownership to the 1542, and the 1542 starts issuing bus cycles derived from its internal 20MHz clock, not related to the ISA clock at all. In contrast to non-busmaster DMA, the DMA controller with its clock (of up to 8MHz) is not used for anything except bus arbitration. The 1542C series have quite freely programmable durations of the bus signal (/MEMR, /MEMW) being active and being negated. As the base clock is 20MHz, these durations are measured on a 50ns grid. The highest possible rate is achieved by having the signal two clocks asserted, two clocks desasserted, which results in 5 Mega-Transfers per second. The second-highest rate, 8MB/s can be achieved by 150ns asserted, 100ns de-asserted or the other way around. The 8MB/s setting in the BIOS maps to 100ns asserted ("active time"/"pulse width") and 150ns de-asserted ("recovery time"/"strobe off time"). I have a 386DX mainboard that works with the AHA1542CF at 8MB/s, but only using the other configuration, which can be set at the ASPI driver command line given a suitable speed code argument. (see page 46 of http://www.bitsavers.org/pdf/adaptec/pc/AHA-1 … nual_199304.pdf for the description of speed codes).
I just re-checked my reverse engineering of the 1542CF firmware, and it uses these mappings for classic speed codes:
- 5MB/s (code 0) maps to 250ns pulse / 150ns rest (400ns cycle time)
- 6.7MB/s (code 1) maps to 150ns pulse / 150ns rest (300ns cycle time)
- 8MB/s (code 2) maps to 100ns pulse / 150ns rest (250ns cycle time)
- 10MB/s (code 3) maps to 100ns pulse / 100ns rest (200ns cycle time)
- 5.7MB/s (code 4) maps to 200ns pulse / 150ns rest (350ns cycle time)
- 3.3MB/s (code 255) is actually a "custom rate" at maximum slowness of 450ns pulse / 150ns rest (600ns cycle time)
If your mainboard doesn't support speeds above 5.7MB/s, it requires an active time of at least one of MEMR or MEMW of 200ns at least, and it fails if the active time is reduced to 150ns (the next faster setting). You might want to experiment with speed setting 0xA2 (or 160 decimal), which will generate 6.7MB/s at 200ns active, 100ns rest.
Marco wrote on 2025-10-07, 18:18:
What’s the point then? Reaching max throughput for IDE at least is related to ISA Bus Speed. Seems to be different for scsi.
Let's not conflate the hard drive interface technology (IDE vs. SCSI) with the data transfer methode between the controller/interface card and the system memory (programmed I/O vs. busmaster DMA). Programmed I/O uses the ISA clock of the mainboard as reference clock for the cycle duration, so higher ISA bus clock means higher data rate. Busmaster DMA on the other hand lets the card control the timing entirely by itself. The card may use the bus clock signal on the ISA bus as basis for its cycle timing, but it doesn't have to - and the Adaptec controllers do not use the ISA bus clock to generate their busmaster timing. If, on the other hand, you would use an AHA-1522B in PIO mode, it would be as dependent on the ISA speed as an IDE interface card is.
Marco wrote on 2025-10-07, 18:18:
- why some (my) boards won’t go higher than std 5-5,7 MB? What’s the key to success?
To go higher than 5.7MB/s, the mainboard needs to be able to perform RAM reads within 150ns - either under all conditions, or it needs to use IOCHRDY to ask for extra delays. While 150ns might sound plenty for 70ns RAM, it actually is not, especially if the board is trying to use fast page mode. Note that 70ns is the time from starting a memory cycle to getting valid data. There is some extra delay after getting the data before the next cycle may start. If you are not using fast page page, this is the RAS cycle time, which is 130ns for a TC514400A-70 (a random 70ns chip I have a datasheet for at hand). To achieve that 130ns cycle time, you have a lot of timing constraints to hit: RAS needs to be low for 70ns (at least) and high for 50ns (at least). Given some ns for transitioning from low to high and vice versa, these two values are nearly fixed. Now, look at (for example) a 33MHz chipset clock, which has a period of 30ns. Unless the chipset uses half clocks, the fastest it would be able to drive the chip at is 90ns low + 60ns high (unless you violate specifications), which just hits the 150ns time given by the 1542. Not using page mode, this is no issue, because the 60ns high time can be in the 100ns "strobe off time" of the 1542 and the 90ns low time can be in the 150ns "pulse width" of the 1542. But if you want to use page mode, you keep /RAS low for some time after a memory cycle, hoping the next cycle hits the same page. If it does, you can perform a much faster "page hit" cycle (the page mode cycle time of that chip is 45ns), but if you miss the page, you need to raise /RAS at the time the next access is supposed to start, so the "RAS precharge time" of at least 50ns will start only after the address provided by the 1542 has been compared to the currently open page and a miss has been detected. The time required to detect the miss and close the current page will likely no longer fit the 150ns time frame required by the 1542.
If memory timing is generated off the FSB clock, using a higher FSB clock may help to reduce synchronization losses between the 1542 requests on the ISA bus and the memory controller. On the other hand, you also have to consider that higher FSB clocks might require more clock cycles for specific phases of the memory access cycle, so increasing the FSB clock might actually decrease memory performance if you need to add wait states.
