douglar wrote on 2024-11-19, 13:31:

The Promise 20630 controller can do MWDMA2 transfers in DOS if you have a storage device that's agreeable to that mode, but I've had little luck getting that to work as DMA in Windows.

The Promise 20630 can indeed use the DMA transfer protocol between the drive and the Promise chip, but instead of doing DMA, the host has to wait until the device asserts /DRQ, then run a PIO block IN or OUT instruction to get the data from/to the PDC20630 chip. As you don't get an IRQ when DRQ is asserted by the drive, but only when the DMA transfer is done, the operation for read requests is like this: The host issues the command, then the drive locates the sector, reads the sector, verifies the CRC, possibly applies ECC correction and then asserts DRQ to get the data to the host. The host needs to run a busy polling loop on the DRQ status bit reported by the 20630, and then start the data transfer, which looks like a DMA transfer to the drive. Finally, when the transfer is done, the drives issues an interrupt for "DMA complete". This means that you don't only lose the advantage of DMA that the CPU can perform useful operations while the data is transferred from the drive to memory, but it is even worse than PIO in that the CPU already is busy with watching the DMA status bit while the drive is not yet ready to transfer. In "real" PIO modes, the drive will issue an IRQ before the transfer happens, so the CPU can do other tasks until the sector is ready. Bottom line: The Pseudo-DMA feature of the 20630 is even worse than PIO for multi-tasking operating systems. It only makes sense if you happen to have a drive that can achieve decent DMA speeds, but fails to do anything faster than PIO0 in PIO mode.

mkarcher wrote on 2025-01-22, 18:17:

douglar wrote on 2024-11-19, 13:31:

The Promise 20630 controller can do MWDMA2 transfers in DOS if you have a storage device that's agreeable to that mode, but I've had little luck getting that to work as DMA in Windows.

The Promise 20630 can indeed use the DMA transfer protocol between the drive and the Promise chip, but instead of doing DMA, the host has to wait until the device asserts /DRQ, then run a PIO block IN or OUT instruction to get the data from/to the PDC20630 chip. As you don't get an IRQ when DRQ is asserted by the drive, but only when the DMA transfer is done, the operation for read requests is like this: The host issues the command, then the drive locates the sector, reads the sector, verifies the CRC, possibly applies ECC correction and then asserts DRQ to get the data to the host. The host needs to run a busy polling loop on the DRQ status bit reported by the 20630, and then start the data transfer, which looks like a DMA transfer to the drive. Finally, when the transfer is done, the drives issues an interrupt for "DMA complete". This means that you don't only lose the advantage of DMA that the CPU can perform useful operations while the data is transferred from the drive to memory, but it is even worse than PIO in that the CPU already is busy with watching the DMA status bit while the drive is not yet ready to transfer. In "real" PIO modes, the drive will issue an IRQ before the transfer happens, so the CPU can do other tasks until the sector is ready. Bottom line: The Pseudo-DMA feature of the 20630 is even worse than PIO for multi-tasking operating systems. It only makes sense if you happen to have a drive that can achieve decent DMA speeds, but fails to do anything faster than PIO0 in PIO mode.

That sounds kind of like the UM8886B which we've talked about privately, but in reverse. The UM8886B can do bus mastering, but it still talks PIO to the drive. Because the IRQ comes in before the bus mastering happens instead of after, the host has to sit and spin waiting for the transfer to complete.

As we've also talked about, what is it about the Intel Triton design that didn't make it much more obvious to these VLB/early PCI IDE manufacturers to do it 'right' that way? The whole scatter/gather structure was too complicated for smaller chip companies without the clout to make it the standard?

mkarcher wrote on 2025-01-22, 18:17:

The Promise 20630 can indeed use the DMA transfer protocol between the drive and the Promise chip, but instead of doing DMA, the host has to wait until the device asserts /DRQ, then run a PIO block IN or OUT instruction to get the data from/to the PDC20630 chip.

Very very interesting. Many thanks for sharing. How did you learn this?

Generally speaking, my results with the 20630 & the Promise DOS driver are that reasonably modern Solid State Storage devices do reads & writes @ 5500-6000 KB/s in Turbo PIO and IRDY modes and but get 6000 - 9200 KB/s in Turbo DMA mode, depending on the device and transfer direction.

Curiously, I got some outlier results on 20230 w/ XUB r625 instead of the promise driver that had transfer rates > 9400 KB/s. I'll have to go back and see if I can replicate with r630 and isolate what events lead to the high transfer rate & low latency results. I hope it wasn't a cut and paste error.

douglar wrote on 2025-01-22, 19:47:

mkarcher wrote on 2025-01-22, 18:17:

The Promise 20630 can indeed use the DMA transfer protocol between the drive and the Promise chip, but instead of doing DMA, the host has to wait until the device asserts /DRQ, then run a PIO block IN or OUT instruction to get the data from/to the PDC20630 chip.

Very very interesting. Many thanks for sharing. How did you learn this?

I reverse engineered the Promise DOS driver around 22 years ago.

mkarcher wrote on 2025-01-22, 18:17:

The Promise 20630 can indeed use the DMA transfer protocol between the drive and the Promise chip, but instead of doing DMA, the host has to wait until the device asserts /DRQ, then run a PIO block IN or OUT instruction to get the data from/to the PDC20630 chip.

I suppose that's why the 20630 never found its way onto a caching controller. There was probably no benefit to it since most of them can do memory mapped transfers.

p.s I finally found this thread that has a lot of info Is there a VLB card that supports > Mode 3 or UDMA support?

Found a new old one -- I completely forgot about this one, which is funny because I used to own it until about 5 years ago.

Although technically, it's on a card with a proprietary local bus, not VLB

Appian P928

https://theretroweb.com/chips/10619
https://theretroweb.com/expansioncards/s/tekr … ost-4000-3-plus

douglar wrote on 2025-04-24, 12:23:

Found a new old one -- I completely forgot about this one, which is funny because I used to own it until about 5 years ago. […]
Show full quote

Found a new old one -- I completely forgot about this one, which is funny because I used to own it until about 5 years ago.

Although technically, it's on a card with a proprietary local bus, not VLB

Appian P928

https://theretroweb.com/chips/10619
https://theretroweb.com/expansioncards/s/tekr … ost-4000-3-plus

I don't think the Appian P928 is a IDE controller.

Have a look at ISA cards with the Winbond W83787F. The pin headers on the Tekram card match those on the ISA Winbond W83787F cards. If the Appian chip provided IDE it would make sense to swap the IDE and floppy pin headers for easier routing.
Now have a look at VLB Tseng Labs ET4000AX cards. There are 74LS244 or 74LS245 buffers and 74LS373 latches where the Tekram card has the Appian P928 chip. Based on this I think the P928 is just the 74LS buffers and latches condensed in a single chip.

Also: https://www.techmonitor.ai/technology/appian_ … _local_bus_chip

Dorunkāku wrote on 2025-04-24, 15:49:

I don't think the Appian P928 is a IDE controller. […]
Show full quote

I don't think the Appian P928 is a IDE controller.

Have a look at ISA cards with the Winbond W83787F. The pin headers on the Tekram card match those on the ISA Winbond W83787F cards. If the Appian chip provided IDE it would make sense to swap the IDE and floppy pin headers for easier routing.
Now have a look at VLB Tseng Labs ET4000AX cards. There are 74LS244 or 74LS245 buffers and 74LS373 latches where the Tekram card has the Appian P928 chip. Based on this I think the P928 is just the 74LS buffers and latches condensed in a single chip.

Also: https://www.techmonitor.ai/technology/appian_ … _local_bus_chip

OK, nifty. Looks like perhaps provides a faster AT style bus over the 486 Local bus if I'm reading that correctly.

Appian Technology Inc is shipping its P928 FAST Local Bus Peripheral Interface chip: it links a local 80486 CPU bus to AT peripherals