The PT-626 is Pine Technology, I think they had 627, 628, 629 also, with the 629 being top dog with LBA BIOS, DMA mode 2, and possibly caching AFAICR. A lot of other near clones with UMC chipsets usually had Elpina on the board somewhere, the usual Hsing Tech / PC Chips /Amptron suspects.

BitWrangler wrote on 2023-04-17, 18:40:

The PT-626 is Pine Technology, I think they had 627, 628, 629 also, with the 629 being top dog with LBA BIOS, DMA mode 2

what controller would that use? and how was DMA handled, fifo, busmastering?

Promise PDC-20630 EIDE2300Plus PIO-4
Promise PDC-20630B P2630VL-1 PIO-4
those are pseudo DMA to the disk, but PIO to computer Re: Is there a VLB card that supports > Mode 3 or UDMA support?

Good post.

Holtek’s controller is PIO-4.

CompassLab CL3202 is rebranded GoldStar GM82C712 which is rebranded CHIPS 82C712.

There are 3-4 more early versions of the DTC series. They do PIO-3 only.

Have bunch of manuals. Many of them list PIO modes. Will respond tomorrow. Nudge me if i forget.

douglar wrote on 2023-04-17, 16:29:

Removed Acer M5105 because it is a board, not a chip

its very much a chip https://wiki.preterhuman.net/Acer_M5105 https://www.vogonswiki.com/index.php/Elitegroup_C190, but ISA one providing 2 Serials, LPT, FDC, and Gameport

Few more bits:
UM8672F can do PIO-4, but needs modded driver.
83C411 is PIO-3.
QD6500 is PIO-3 (without IORDY support).

pshipkov wrote on 2023-04-18, 18:47:

Few more bits: UM8672F can do PIO-4, but needs modded driver. 83C411 is PIO-3. QD6500 is PIO-3 (without IORDY support). […]
Show full quote

Few more bits:
UM8672F can do PIO-4, but needs modded driver.
83C411 is PIO-3.
QD6500 is PIO-3 (without IORDY support).

So when you say "Modded Driver", you are talking Windows driver or DOS driver?

I thought this comment was interesting:

https://xtideuniversalbios.org/browser/xtideu … _0.wiki?rev=448

VLB and PCI IDE controllers are more complex since they have an actual controller between bus and IDE drive. This controller can buffer the data so the CPU can read 32-bits at a time. Early VLB controllers are limited to PIO-2 but later VLB controllers and (all?) PCI controllers also support PIO modes 3 and 4. These later VLB multi I/O cards have two IDE connectors so you should use one of those even if you don't need the other IDE connector.

Unfortunately many of the controllers work only at PIO-0 by default. Some VLB multi I/O cards have jumpers to set transfer rates but most require controller specific programming to enable higher PIO modes. It is possible that your VLB multi I/O card don't offer any advantages over ISA multi I/O cards if your BIOS does not support the IDE controller on the VLB card. There are DOS drivers for many VLB IDE controllers so BIOS support isn't a necessity.

Looking through old threads, I spotted a Lion3+ Help id this VLB I/O controller

Don't have any info about it other than that the FCCID is for Atlantic Components Ltd AYCOMP-9401

https://fccid.io/LTNAYCOMP-9401

douglar wrote on 2023-04-18, 19:44:

https://xtideuniversalbios.org/browser/xtideu … _0.wiki?rev=448
VLB and PCI IDE controllers are more complex since they have an actual controller between bus and IDE drive. This controller can buffer the data so the CPU can read 32-bits at a time.

This got me thinking. While PCI bus mastering controller might buffer a double word to slam it over PCI into memory in one transaction, why would VLB disk controllers bother with 32bit transfers?

1) All came out in a short window between 1992 Windows 3.1 and 1994 WfW 3.11.
-Windows 3.1 introduced Protected Mode disk access, very fragile https://www.os2museum.com/wp/how-to-please-wdctrl/
-WfW 3.11 did Protected Mode file IO
32bit here means running 32bit code. Both speed up software side, have no influence on hardware access. Still no asynchronous IO. Even Win32s, the 32bit subsystem for Win3.1/11 didnt support async IO. This means that once Windows/DOS program calls disk IO it makes no sense to offload anything, do any busmastering DMA or play with fancy FIFOs buffering data inside controller, none of that makes sense. CPU has nothing else to do than poll IO in a tight loop until everything is slurped up or in case of Windows its time to cooperatively switch tasks. Disk itself will buffer sector/s in its own ram cache.
OS/2, NT, UNIX is different case where buffering/busmastering could be beneficial.

2) CPU<->VLB connection speed is not the bottleneck when talking to orders of magnitude slower disk. Cirrus Logic VLB VGA cards doing 16bit transfers while still being fast enough for video are a proof. But then I looked at a ton of VLB IDE cards and all wire full 32bit data bus.

Now off topic: so I looked at Cirrus Logic VLB cards and even the lowest CL-GD5424 also wires full 32bit bus?!?! and every single card has populated upper 16bit *245 data line buffers! What the hell is going on. Everyone and their dog knows those cards only do 16bit VLB transfers. I jumped into Cirrus Logic datasheet and discovered its hardwired for 16bit transfers:
- when accessing A0000-BFFFF
- if Linear Access (vesa LFB) is enabled
that covers all possible ways of writing to video ram 😮 so why did Cirrus Logic bother wiring all 32bits when datasheets says they always activate MSC16*? 😒

adaptec vl adavantage 2840A/2842a which is scsi and ide has a AIC-25VL onboard.

IDE interface is 16-bit.
The controller simply aggregates two 16-bit reads then transfers to CPU in a single 32-bit word and the opposite for writing, effectively cutting chatter through the bus in half.

pshipkov wrote on 2023-04-19, 03:42:

IDE interface is 16-bit.
The controller simply aggregates two 16-bit reads then transfers to CPU in a single 32-bit word and the opposite for writing, effectively cutting chatter through the bus in half.

but why? At the time everything did synchronous IO
- program was stopped while waiting for the data, CPU was in a kernel task reading IDE IO in a loop
- bus wasnt doing anything else between transfers
- VLB bus itself can do transaction every 30ns? 486 CPU can easily sustain ~15MB/s copy speed so ~120ns? fastest theoretical HDD timing was 120ns while real drives didnt cross 5MB/s so ~400ns
- even if something did asynchronous IO you couldnt really switch tasks between ~400ns cycles of a 5MB/s disk, you couldnt even do it if you buffered to 32bit to get to 1 microsecond between transfers. OSes switch between tasks up to hundred times per second so every ~10ms, but the biggest problem is cost of context switch on the order of microseconds. Controller would have to buffer something like 64 bytes at a time to make switching to another task give any benefit.

tldr: CPU is sitting doing nothing, bus is sitting doing nothing, everything is waiting for slow HDD. Sending data in bigger batches doesnt change anything. Neither data will show up faster nor you will be able to spend this time on other computations.

rasz_pl wrote on 2023-04-19, 06:06:

tldr: CPU is sitting doing nothing, bus is sitting doing nothing, everything is waiting for slow HDD. Sending data in bigger batches doesnt change anything. Neither data will show up faster nor you will be able to spend this time on other computations.

I thought that a good VLB IDE controller would have a small buffer that would allow it to take advantage of write combining, to push more data across the bus in each interrupt. In theory, a 486 should have enough bandwidth as you lay out, but when you have to spend cycles throwing everything on the stack for each interrupt, you start to collect significant CPU related resistance in the system.

In practice, most of the performance increase from windows 32bit protected mode drivers was because the processor didn't have to switch back to real mode BIOS calls and then switch back to protected mode. But that has a similar effect for 16 bit busses and 32bit busses and not anything particular about VLB.

Not sure how complete you want this list.
I own a "TK 8287 2J D01.1" with FCCID: HBQUMC8287D01
Quick google says this is a UMC product. Can't tell you much more though as it's back in oz.

douglar wrote on 2023-04-19, 11:50:

I thought that a good VLB IDE controller would have a small buffer that would allow it to take advantage of write combining, to push more data across the bus in each interrupt.

Brand new 1992 32-bit Disk Access (FastDisk) Windows 3 IDE driver https://www.os2museum.com/wp/how-to-please-wdctrl/ didnt even support multi sector reads:
"WDCTRL was of course not without disadvantages. The basic problem with WDCTRL was that it was stuck in the early 1990s. That meant no support for large disks, but also no support for multi-sector reads/writes and no bus master DMA. Within a few years of the Windows 3.1 release, WDCTRL could easily have worse performance than the system’s BIOS."
Some controller bioses/drivers did do multi sector operations, saves you on setting up multiple transfers if conditions are right (linear data on disk). Afaik ATA didnt get Command Queuing support until past 2000 so you couldnt even tell the drive to prepare a couple non consecutive reads/writes.

douglar wrote on 2023-04-19, 11:50:

In theory, a 486 should have enough bandwidth as you lay out, but when you have to spend cycles throwing everything on the stack for each interrupt, you start to collect significant CPU related resistance in the system.

Interrupts are hundreds of cycles, thats why by then it was Interrupt per IDE command (sector/fancy multi sector):

1 setup what you want to read with couple of out_byte IO operations to the drive (this starts with checking Status Register BSY/DRQ/ERR flags)
2 https://wiki.osdev.org/ATA_PIO_Mode#Polling_t … Status_vs._IRQs
- in multitasking OS you can enable HDD interrupt and switch to another task. Seeks are slow and you might get some compute in the mean time
- in DOS you just sit there on your thumbs pooling Status Register BSY/DRQ/ERR flags
3 You can start transferring data in a tight machine code loop. The speed is throttled by HDD /IOREADY line. NO drive available till 1997-8 would be able to send data faster than 486 can read here over VLB bus in 16bit chunks. CPU is sitting in this loop for at least 512 bytes, it doesnt matter if it performs 256 word transfers or 128 dword ones. It cant do anything else if it wants that data fast. Tricks like trying to wait for the drive to read data into its buffer while you let another task compute in the mean time will result in slower effective transfer unless timed perfectly, so afaik nobody did that and just looped over IDE Data port as data came in until we moved to PCI bus mastering controllers. The only fancy trick I know of is Promise PDC-20630 supporting early UDMA to disk, but hiding it behind normal IO transfers between CPU and controller. I think this faster controller<->disk speed will mainly help with writes letting OS transfer data into disk buffer and get back to computing earlier.

douglar wrote on 2023-04-19, 11:50:

In practice, most of the performance increase from windows 32bit protected mode drivers was because the processor didn't have to switch back to real mode BIOS calls and then switch back to protected mode. But that has a similar effect for 16 bit busses and 32bit busses and not anything particular about VLB.

yes, Win3 32-bit Disk Access and Win3.11 32-bit File Access only save on CPU time wasted by OS itself switching execution context and dont help with actual data transfer. I mentioned them as those were the only storage IO enhancements available in Windows.

chinny22 wrote on 2023-04-19, 12:56:

Not sure how complete you want this list.
I own a "TK 8287 2J D01.1" with FCCID: HBQUMC8287D01
Quick google says this is a UMC product. Can't tell you much more though as it's back in oz.

Right now I'm mainly interested in the IDE controller chip.

Having trouble finding that FCCid.

Does yours look like the HBQUMC8287D1A ?

douglar wrote on 2023-04-19, 14:31:

Does yours look like the HBQUMC8287D1A ?
HBQUMC8287D1A.jpg

thats a graphic card 😜 Google found https://festima.ru/docs/116771657/moscow/fcc-id

rasz_pl wrote on 2023-04-19, 15:26:

douglar wrote on 2023-04-19, 14:31:

Does yours look like the HBQUMC8287D1A ?
HBQUMC8287D1A.jpg

thats a graphic card 😜 Google found https://festima.ru/docs/116771657/moscow/fcc-id

My Bad. Trying to work and post at the same time. I copied the picture from an amazon vendor without thinking . Here's the HBQUMC controllers from that period:
HBQUMC8663D2A 1994-12-15 Multi I/O Card
HBQUMC8287D1A 1994-10-17 VL Bux Multi-I/O Card
HBQUMC8237D02 1994-08-18 VL Bus Multi-I/O Interface Card
HBQUMC8237D01 1994-08-01 I/O Card
HBQUMC8637D01A 1994-05-16 Multi I/O Card
HBQUMC8631D06 1993-11-04 VESA Local Bus IO Card
HBQUMC8631D08 1993-09-24 VL Bus I/O Interface Card
HBQUMC8631D07 1993-09-24 VL Bus I/o Interface Card
HBQUMC8635D01 1992-12-04 Multi I/O Card
https://fccid.io/HBQUMC

rasz_pl wrote on 2023-04-19, 13:44:

it doesnt matter if it performs 256 word transfers or 128 dword ones. It cant do anything else if it wants that data fast. Tricks like trying to wait for the drive to read data into its buffer while you let another task compute in the mean time will result in slower effective transfer unless timed perfectly, so afaik nobody did that and just looped over IDE Data port as data came in until we moved to PCI bus mastering controllers. The only fancy trick I know of is Promise PDC-20630 supporting early UDMA to disk, but hiding it behind normal IO transfers between CPU and controller. I think this faster controller<->disk speed will mainly help with writes letting OS transfer data into disk buffer and get back to computing earlier.

Thanks for the explanation. It's a very reasonable theory. Can you think of any benchmark that will show that 16bit VLB transfers perform the same as 32bit transfers?

Ultimately, my goal here is after documenting what VLB controllers are out there, is to:

1. Find a fast VLB controller and a slow VLB controller using synthetic benchmarks
2. Pair them with a fast storage device and a fast 486
3. Do a repeatable common real world "makes you wait" task that has a storage dimension (aka cold booting Windows 98 with 16MB RAM)
4. See which storage related factors make the most noticeable improvement, if any.

Here are the notable factors that I see for VLB storage benchmarking:

1. ATA Protocol
2. Controller (for VLB controllers)
3. Bus Speed
4. Driver ( BIOS / BIOS + Shadowing / Drive Overlay / DOS driver / Protected Mode Driver )

I suspect that for any reasonably fast CPU and Storage device, the importance ranking will go Bus Speed + ATA Protocol, and then Driver + VLB controller

Once there, it would be interesting to see where the cutoffs are for "reasonably fast" are.

If one configuration shows an improvement over another with a 133Mhz CPU, does it still show a similar improvement with a 33Mhz 486 or does it all fade into the background noise with the slower CPU?
And where is the cut off for storage? If the controller matters with a 16GB SSD, does it still mater with a 6GB Quantum Fireball ? With an ST3600A ? With a Caviar 280?

The PT-626, as seen on https://skylots.org/6568006432/PT-626-Hard-Di … ntroller---0557 , uses the UMC UM82C871F VL IDE chip. The UM82C863F listed in the original table is the ISA I/O chip for everything but IDE.

I have three VL I/O controllers at hand right now:

• A copy of the controller listed in Re: 3 (+3 more) retro battle stations as "UM82C863", with the UM8672F VL IDE chip, but in a higher-tier configuration: My copy has the UM8663 instead of the older 82C863 ISA I/O chips, so it provides EPP and ECP options for the parallel port. I somtimes abuse that controller to add ECP/EPP capable parallel ports to ISA or PCI machines, just ignoring the IDE stuff 😀 The silkscreen on the back of that controller has the remark "(FOR 8663/8668 ONLY)" at the description of the jumper settings for the parallel port mode. The only thing on that PCB that looks like a controller model number is "TL-1203" in the back side copper layer.
• A copy of the UN 1082 (also in Re: 3 (+3 more) retro battle stations) labelled "PTI-255W V1.2". Looking at the FCC ID (which is identical to the one shown) looks like the PTI number is the original, and the UN 1082 is the clone. The PTI board also doesn't contain the silkscreen marking "MADE IN CHINA", but there is a "Made in China" marking on the Q/C sticker on the solder side.
• A EVLSIO-V3-HJ2, as shown in https://www.flickr.com/photos/181652282@N07/49368874853/ (also take a look at the other photos in that stream). My copy has standard black jumpers instead of the cool blue ones. It has the PDC20630, acompanied by the Goldstar Prime 2 ISA I/O chip.