Are you looking for pinouts or other hardware stuff, or information for programming those? It's unclear whether the UM8673 ever existed as a discrete chip or only within the UM8886A by the way.

jakethompson1 wrote on 2023-02-15, 23:52:

Are you looking for pinouts or other hardware stuff, or information for programming those? It's unclear whether the UM8673 ever existed as a discrete chip or only within the UM8886A by the way.

Pinout, electrical specs, programming...as usual what is written in regular datasheet. The UM8673F existed as a discrete chip, I have it as a normal PCI HDD controller.

Comos wrote on 2023-02-16, 11:50:

jakethompson1 wrote on 2023-02-15, 23:52:

Are you looking for pinouts or other hardware stuff, or information for programming those? It's unclear whether the UM8673 ever existed as a discrete chip or only within the UM8886A by the way.

Pinout, electrical specs, programming...as usual what is written in regular datasheet. The UM8673F existed as a discrete chip, I have it as a normal PCI HDD controller.

Can't help with anything but programming and even that is just from looking at their drivers.

The UM8672 is a VLB IDE chip that doesn't appear to have any special acceleration features. The only thing you can control is tighter timings on its communication between the controller and IDE device. Linux 2.x had a umc8672 driver that someone wrote. I'm not sure whether they had a datasheet or looked at the DOS driver.

I hadn't seen the UM8673 as a discrete chip; have a picture? It would also be interesting to know its PCI vendor and device ID and its revision. I was familiar with the UM8886A and UM8886B which despite both using a driver called "UM8673.SYS" are completely different. The UM8886A is barely a PCI device; despite being one, it is programmed by writing special values to hardcoded i/o ports and not using PCI configuration space. My notes say that the driver for the UM8886A will probe the chip and decide whether to print out UM8673 or UM8886A depending on what values it gets. The UM8673/UM8886A/B never got a Linux driver; either no one figured them out, or no one cared because the Intel PIIX (Triton) had come out by then and is a far better product.

I have some notes but was last working with this a year or so ago and have all the applicable hardware accessible but packed away at the moment. Both the UM8886A and UM8886B have "FIFO mode" where the chip will go ahead and fill a buffer with data from the IDE device ahead of time, rather than having a direct coupling between the CPU's "rep insd" instruction and the IDE device. For the UM8886A the FIFO is 8 bytes and for the UM8886B the FIFO is 60 bytes. The IDE driver has to be specially written to switch the FIFO between filling, draining, and disabled states every time you read sectors from an IDE device, i.e. you can't just flip some bits at initialization and make it fast. As the FIFO just sits there dormant otherwise, I think this is why these controllers don't have the bad reputation that CMD640/RZ1000 ones have as any dangerous limitations/bugs (like the FIFO being shared between the primary and secondary interface) are never encountered accidentally.

On the UM8886B there is also a "bus mastering" mode but it's not like anything modern/UltraDMA that you would expect. It doesn't support scatter/gather IO and can only write to physically contiguous pages, and the driver has to deal with a possible unaligned head and tail, plus the FIFO draining issue mentioned above. IIRC UMC didn't attempt to implement this for anything but plain DOS.

Writes to the drive remain unaccelerated.

The FIFO is a big boost; according to my notes with a fast mechanical drive, I had 6 MB/sec with no driver, 11 MB/sec with FIFO mode, and 14 MB/sec with bus mastering mode on a UM8886B. Note that SSDs on these PIO-mode-only controllers may not actually be faster than a fast mechanical drive, because they do not support the Read Multiple Sectors command to cut down on the interrupts by a factor of eight or sixteen. If you enable the FIFO, you might have to back off on the speed rating you give to UM8673.SYS, as too-fast speeds apparently work with the FIFO disabled, but only because they are too bottlenecked by the CPU's rep insd instruction to overwhelm the drive.

I also picked up a GA586AM to mess with a later revision of the UM8886B and the UM8891 instead of UM8881, but I don't think I found anything conclusive. My notes suggest there might have been a write FIFO on a later revision, and possibly more DMA related stuff, but I didn't get anywhere.

I've been down this road quite a bit as have feipoa and pshipkov. Anything you're particularly curious about?

jakethompson1 wrote on 2023-02-19, 04:04:

Can't help with anything but programming and even that is just from looking at their drivers. […]
Show full quote

Comos wrote on 2023-02-16, 11:50:

jakethompson1 wrote on 2023-02-15, 23:52:

Are you looking for pinouts or other hardware stuff, or information for programming those? It's unclear whether the UM8673 ever existed as a discrete chip or only within the UM8886A by the way.

Pinout, electrical specs, programming...as usual what is written in regular datasheet. The UM8673F existed as a discrete chip, I have it as a normal PCI HDD controller.

Can't help with anything but programming and even that is just from looking at their drivers.

The UM8672 is a VLB IDE chip that doesn't appear to have any special acceleration features. The only thing you can control is tighter timings on its communication between the controller and IDE device. Linux 2.x had a umc8672 driver that someone wrote. I'm not sure whether they had a datasheet or looked at the DOS driver.

I hadn't seen the UM8673 as a discrete chip; have a picture? It would also be interesting to know its PCI vendor and device ID and its revision. I was familiar with the UM8886A and UM8886B which despite both using a driver called "UM8673.SYS" are completely different. The UM8886A is barely a PCI device; despite being one, it is programmed by writing special values to hardcoded i/o ports and not using PCI configuration space. My notes say that the driver for the UM8886A will probe the chip and decide whether to print out UM8673 or UM8886A depending on what values it gets. The UM8673/UM8886A/B never got a Linux driver; either no one figured them out, or no one cared because the Intel PIIX (Triton) had come out by then and is a far better product.

I have some notes but was last working with this a year or so ago and have all the applicable hardware accessible but packed away at the moment. Both the UM8886A and UM8886B have "FIFO mode" where the chip will go ahead and fill a buffer with data from the IDE device ahead of time, rather than having a direct coupling between the CPU's "rep insd" instruction and the IDE device. For the UM8886A the FIFO is 8 bytes and for the UM8886B the FIFO is 60 bytes. The IDE driver has to be specially written to switch the FIFO between filling, draining, and disabled states every time you read sectors from an IDE device, i.e. you can't just flip some bits at initialization and make it fast. As the FIFO just sits there dormant otherwise, I think this is why these controllers don't have the bad reputation that CMD640/RZ1000 ones have as any dangerous limitations/bugs (like the FIFO being shared between the primary and secondary interface) are never encountered accidentally.

On the UM8886B there is also a "bus mastering" mode but it's not like anything modern/UltraDMA that you would expect. It doesn't support scatter/gather IO and can only write to physically contiguous pages, and the driver has to deal with a possible unaligned head and tail, plus the FIFO draining issue mentioned above. IIRC UMC didn't attempt to implement this for anything but plain DOS.

Writes to the drive remain unaccelerated.

The FIFO is a big boost; according to my notes with a fast mechanical drive, I had 6 MB/sec with no driver, 11 MB/sec with FIFO mode, and 14 MB/sec with bus mastering mode on a UM8886B. Note that SSDs on these PIO-mode-only controllers may not actually be faster than a fast mechanical drive, because they do not support the Read Multiple Sectors command to cut down on the interrupts by a factor of eight or sixteen. If you enable the FIFO, you might have to back off on the speed rating you give to UM8673.SYS, as too-fast speeds apparently work with the FIFO disabled, but only because they are too bottlenecked by the CPU's rep insd instruction to overwhelm the drive.

I also picked up a GA586AM to mess with a later revision of the UM8886B and the UM8891 instead of UM8881, but I don't think I found anything conclusive. My notes suggest there might have been a write FIFO on a later revision, and possibly more DMA related stuff, but I didn't get anywhere.

I've been down this road quite a bit as have feipoa and pshipkov. Anything you're particularly curious about?

Sry for late reply, I have attached a pic of the controller.The controller miss an extra ISA board for the IRQ14/15 like other controllers have.There is no eeprom onboard for the PCI vendor & device ID, so no PnP, but it's port I/O mapped.I did a testing in my P1 S4 TMC PCI/VLB board with a non PnP BIOS and HDD get's normally detected in BIOS and can be used. As for the chip itself, I was more interested on the pinout/ datasheet specs, but I think I can figure it out from the controller and MB where the chip is onboard.Thanks for the programming description, maybe this will come later or switch to another controller chip.

Comos wrote on 2023-03-28, 09:06:

jakethompson1 wrote on 2023-02-19, 04:04:

Can't help with anything but programming and even that is just from looking at their drivers. […]
Show full quote

Comos wrote on 2023-02-16, 11:50:

Pinout, electrical specs, programming...as usual what is written in regular datasheet. The UM8673F existed as a discrete chip, I have it as a normal PCI HDD controller.

Can't help with anything but programming and even that is just from looking at their drivers.

The UM8672 is a VLB IDE chip that doesn't appear to have any special acceleration features. The only thing you can control is tighter timings on its communication between the controller and IDE device. Linux 2.x had a umc8672 driver that someone wrote. I'm not sure whether they had a datasheet or looked at the DOS driver.

I hadn't seen the UM8673 as a discrete chip; have a picture? It would also be interesting to know its PCI vendor and device ID and its revision. I was familiar with the UM8886A and UM8886B which despite both using a driver called "UM8673.SYS" are completely different. The UM8886A is barely a PCI device; despite being one, it is programmed by writing special values to hardcoded i/o ports and not using PCI configuration space. My notes say that the driver for the UM8886A will probe the chip and decide whether to print out UM8673 or UM8886A depending on what values it gets. The UM8673/UM8886A/B never got a Linux driver; either no one figured them out, or no one cared because the Intel PIIX (Triton) had come out by then and is a far better product.

I have some notes but was last working with this a year or so ago and have all the applicable hardware accessible but packed away at the moment. Both the UM8886A and UM8886B have "FIFO mode" where the chip will go ahead and fill a buffer with data from the IDE device ahead of time, rather than having a direct coupling between the CPU's "rep insd" instruction and the IDE device. For the UM8886A the FIFO is 8 bytes and for the UM8886B the FIFO is 60 bytes. The IDE driver has to be specially written to switch the FIFO between filling, draining, and disabled states every time you read sectors from an IDE device, i.e. you can't just flip some bits at initialization and make it fast. As the FIFO just sits there dormant otherwise, I think this is why these controllers don't have the bad reputation that CMD640/RZ1000 ones have as any dangerous limitations/bugs (like the FIFO being shared between the primary and secondary interface) are never encountered accidentally.

On the UM8886B there is also a "bus mastering" mode but it's not like anything modern/UltraDMA that you would expect. It doesn't support scatter/gather IO and can only write to physically contiguous pages, and the driver has to deal with a possible unaligned head and tail, plus the FIFO draining issue mentioned above. IIRC UMC didn't attempt to implement this for anything but plain DOS.

Writes to the drive remain unaccelerated.

The FIFO is a big boost; according to my notes with a fast mechanical drive, I had 6 MB/sec with no driver, 11 MB/sec with FIFO mode, and 14 MB/sec with bus mastering mode on a UM8886B. Note that SSDs on these PIO-mode-only controllers may not actually be faster than a fast mechanical drive, because they do not support the Read Multiple Sectors command to cut down on the interrupts by a factor of eight or sixteen. If you enable the FIFO, you might have to back off on the speed rating you give to UM8673.SYS, as too-fast speeds apparently work with the FIFO disabled, but only because they are too bottlenecked by the CPU's rep insd instruction to overwhelm the drive.

I also picked up a GA586AM to mess with a later revision of the UM8886B and the UM8891 instead of UM8881, but I don't think I found anything conclusive. My notes suggest there might have been a write FIFO on a later revision, and possibly more DMA related stuff, but I didn't get anywhere.

I've been down this road quite a bit as have feipoa and pshipkov. Anything you're particularly curious about?

Sry for late reply, I have attached a pic of the controller.The controller miss an extra ISA board for the IRQ14/15 like other controllers have.There is no eeprom onboard for the PCI vendor & device ID, so no PnP, but it's port I/O mapped.I did a testing in my P1 S4 TMC PCI/VLB board with a non PnP BIOS and HDD get's normally detected in BIOS and can be used. As for the chip itself, I was more interested on the pinout/ datasheet specs, but I think I can figure it out from the controller and MB where the chip is onboard.Thanks for the programming description, maybe this will come later or switch to another controller chip.

Interesting. It is weird to see a PCI card with all those jumpers. As you mention it seems this chip might be a VLB IDE chip that has had the bare minimum adaptation to work on a PCI bus instead, i.e., no use of PCI configuration space.

I wonder if the chip was intended to be paired with the UM8881+UM8886. The UM8886 lacked IDE and the UM8886A supported it, but the IDE portion of the UM8886A is also configured using I/O ports.

jakethompson1 wrote on 2023-02-19, 04:04:

The FIFO is a big boost; according to my notes with a fast mechanical drive, I had 6 MB/sec with no driver, 11 MB/sec with FIFO mode, and 14 MB/sec with bus mastering mode on a UM8886B. Note that SSDs on these PIO-mode-only controllers may not actually be faster than a fast mechanical drive, because they do not support the Read Multiple Sectors command to cut down on the interrupts by a factor of eight or sixteen. If you enable the FIFO, you might have to back off on the speed rating you give to UM8673.SYS, as too-fast speeds apparently work with the FIFO disabled, but only because they are too bottlenecked by the CPU's rep insd instruction to overwhelm the drive.

I also picked up a GA586AM to mess with a later revision of the UM8886B and the UM8891 instead of UM8881, but I don't think I found anything conclusive. My notes suggest there might have been a write FIFO on a later revision, and possibly more DMA related stuff, but I didn't get anywhere.

I've been down this road quite a bit as have feipoa and pshipkov. Anything you're particularly curious about?

Is there a specific driver revision or startup routine you can recommend to get to 14mb/sec? My HOT-433 motherboard revision has the UM8886B, and it forces me to use speed 16, which it then sets to 15 automatically. The BIOS isn't helpful in this regard, it only exposes up to PIO mode 3... In the ended up using a discrete modern PCI IDE controller for my SSD and the UM8886B for my CDROM drive. Also, was the driver stable for you or did it cause system instability?

mockingbird wrote on 2023-03-28, 22:48:

jakethompson1 wrote on 2023-02-19, 04:04:

The FIFO is a big boost; according to my notes with a fast mechanical drive, I had 6 MB/sec with no driver, 11 MB/sec with FIFO mode, and 14 MB/sec with bus mastering mode on a UM8886B. Note that SSDs on these PIO-mode-only controllers may not actually be faster than a fast mechanical drive, because they do not support the Read Multiple Sectors command to cut down on the interrupts by a factor of eight or sixteen. If you enable the FIFO, you might have to back off on the speed rating you give to UM8673.SYS, as too-fast speeds apparently work with the FIFO disabled, but only because they are too bottlenecked by the CPU's rep insd instruction to overwhelm the drive.

I also picked up a GA586AM to mess with a later revision of the UM8886B and the UM8891 instead of UM8881, but I don't think I found anything conclusive. My notes suggest there might have been a write FIFO on a later revision, and possibly more DMA related stuff, but I didn't get anywhere.

I've been down this road quite a bit as have feipoa and pshipkov. Anything you're particularly curious about?

Is there a specific driver revision or startup routine you can recommend to get to 14mb/sec? My HOT-433 motherboard revision has the UM8886B, and it forces me to use speed 16, which it then sets to 15 automatically. The BIOS isn't helpful in this regard, it only exposes up to PIO mode 3... In the ended up using a discrete modern PCI IDE controller for my SSD and the UM8886B for my CDROM drive. Also, was the driver stable for you or did it cause system instability?

I'll have to dig it out and try again at some point. Keep in mind that bus mastering only works under plain DOS mode though. The UMC Windows driver does support PIO+FIFO mode and I believe it has the 1-16 speeds hardcoded in it unlike the DOS one. It's been a while so I don't remember exactly.

jakethompson1 wrote on 2023-03-28, 23:53:

I'll have to dig it out and try again at some point. Keep in mind that bus mastering only works under plain DOS mode though. The UMC Windows driver does support PIO+FIFO mode and I believe it has the 1-16 speeds hardcoded in it unlike the DOS one. It's been a while so I don't remember exactly.

Yea, it was slow as molasses for me... I think like 3-4 MB/sec with the driver loaded. I'd really appreciate it if you would dig it up and post more details. There are two versions of UM8673.SYS, one for the UM8886A and one for the UM8886B. Interesting, I didn't know they were completely different, as you say.

@jakethompson1
About that utility of yours to force PIO-4.
Which motherboards you tried it and it worked fine ?

mockingbird wrote on 2023-03-29, 01:53:

jakethompson1 wrote on 2023-03-28, 23:53:

I'll have to dig it out and try again at some point. Keep in mind that bus mastering only works under plain DOS mode though. The UMC Windows driver does support PIO+FIFO mode and I believe it has the 1-16 speeds hardcoded in it unlike the DOS one. It's been a while so I don't remember exactly.

Yea, it was slow as molasses for me... I think like 3-4 MB/sec with the driver loaded. I'd really appreciate it if you would dig it up and post more details. There are two versions of UM8673.SYS, one for the UM8886A and one for the UM8886B. Interesting, I didn't know they were completely different, as you say.

I dug around my notes and found this. This was with the MB-8433UUD-A and a fast (40GB+) mechanical IDE drive. And I believe DOS 6.22.

5,753 KB/s using BIOS PIO mode 4 setting and no driver 6,607 KB/s using UM8673.SYS /D0:17 /NF0 /SM0 10,779 KB/s using UM8673.SYS […]
Show full quote

5,753 KB/s using BIOS PIO mode 4 setting and no driver
6,607 KB/s using UM8673.SYS /D0:17 /NF0 /SM0
10,779 KB/s using UM8673.SYS /D0:17 /F0 /SM0
13,900 KB/s using UM8673.SYS /D0:16 /F0 /MM0

/NF0 disables FIFO mode on drive 0 and /F0 enables it.
/SM0 disables bus mastering on drive 0 and /MM0 enables it.
The /D0:xx speed needs decreased if it turns out to be too aggressive for your machine. If it is, you will corrupt your HDD, so be forewarned.

Beware that the UM8673.SYS driver may not be compatible with Win95, even Win95 DOS mode. In my case, V3.20 would lock up the system even from a boot disk.

Beware that the UMC86B.MPD driver for Windows 95 may not always be compatible; feipoa has reported problems. I'm not sure if they are related to FAT32, the 8.4GB limit, the 32GB limit, and so on.
The UMC Win95 driver does not have this level of configurability. The FIFO is always enabled and bus mastering is always disabled. It also overrides the speed that was set by the BIOS, or um8673.sys. It asks the drive for the maximum supported PIO mode and uses speed 15 for PIO mode 4, speed 12 for PIO mode 3, speed 9 for PIO mode 2, speed 5 for PIO mode 1, and speed 2 for PIO mode 0.

You might also compare a speedsys HD run in plain DOS mode versus one inside a Win95 DOS box (even though it tells you not to run it that way). The test in Win95 gets intercepted by 32-bit disk access so it actually goes through the UMC driver, if you're using it.

Meanwhile I also got a Tekram DC-290N with the National PC87410 where it seems it's better documented. This IO card also have jumpers for INT# selection, here are not populated, but according to the datasheet has a PCI configuration space.Works also in IDE Legacy mode.

" As you mention it seems this chip might be a VLB IDE chip that has had the bare minimum adaptation to work on a PCI bus instead, i.e., no use of PCI configuration space."

I assume , that the UM8673F is pure PCI based, just like the PC87410.I can compare the pinouts, maybe the UM8673F is a ripoff copy based on other, who knows.

Update:
Have to test the DC-290N in another mobo, in my TMC P1 VLB/PCI does not detect any hdd,so have to investigate.

I wanted to point out that while the speed boost with UM8673.sys is nice in DOS, I have found this driver unreliable if using XT-IDE on a larger FAT32 partition, which is 60 GB in the case of my system. Users with smaller partitions (8 GB or less) have not run into my same problem.

feipoa wrote on 2023-04-03, 09:51:

I wanted to point out that while the speed boost with UM8673.sys is nice in DOS, I have found this driver unreliable if using XT-IDE on a larger FAT32 partition, which is 60 GB in the case of my system. Users with smaller partitions (8 GB or less) have not run into my same problem.

Under DOS it was unreliable with that 60GB partition?

During my observation I managed to get another interesting PCI IDE card, the QD8580 with Vision QD-8580 chip.The chip looks like a clone of a existing one, could be National PC87410 from Tekram DC-290N or another unknown,no luck with the datasheet.Both have the legacy header conenctor for the needed IRQ14,15 signals.The diskette contains drivers for DOS,Win3.1/11, WinNT,OS/2.I have not tested it yet, probably during the winter time,when there will be more time.

QD8580 is a QDI part number, there's one on this board:
https://theretroweb.com/motherboards/s/qdi-mp4-p4u885g

More than likely this is a clone of the UM8673F chip.

That Vision chip look and feel reminds me of VDL, see on this board:
https://theretroweb.com/motherboards/s/juko-b0007

jakethompson1 wrote on 2023-03-29, 03:16:

5,753 KB/s using BIOS PIO mode 4 setting and no driver 6,607 KB/s using UM8673.SYS /D0:17 /NF0 /SM0 10,779 KB/s using UM8673.SYS […]
Show full quote

5,753 KB/s using BIOS PIO mode 4 setting and no driver
6,607 KB/s using UM8673.SYS /D0:17 /NF0 /SM0
10,779 KB/s using UM8673.SYS /D0:17 /F0 /SM0
13,900 KB/s using UM8673.SYS /D0:16 /F0 /MM0

Just wanted to update on this... My HOT-433 is a revision 3 I believe but it has the UM8886B... I did some experimenting... The Award 4.51 BIOS only exposes up to PIO3 as an option. Switching to the AMI BIOS, PIO4 is available and the block mode type becomes selectable (64 is the highest, IIRC). Still, the performance isn't good, maybe only slightly better than the Award BIOS.

With PIO3 selected and the driver loaded with "/D0:16 /F0 /MM0", it reaches something like 5-6MB... I think linear read may have been much higher in Speedsys, but probably not relevant (testing with a CF card). Either Shuttle disabled something with this board or it has something to do with the BIOS... I might try cross-flashing to the Biostar BIOS one day to see for certain. But I can live with the current speed if it means not having to go back to VESA 486.

mockingbird wrote on 2024-04-07, 22:40:

jakethompson1 wrote on 2023-03-29, 03:16:

5,753 KB/s using BIOS PIO mode 4 setting and no driver 6,607 KB/s using UM8673.SYS /D0:17 /NF0 /SM0 10,779 KB/s using UM8673.SYS […]
Show full quote

5,753 KB/s using BIOS PIO mode 4 setting and no driver
6,607 KB/s using UM8673.SYS /D0:17 /NF0 /SM0
10,779 KB/s using UM8673.SYS /D0:17 /F0 /SM0
13,900 KB/s using UM8673.SYS /D0:16 /F0 /MM0

Just wanted to update on this... My HOT-433 is a revision 3 I believe but it has the UM8886B... I did some experimenting... The Award 4.51 BIOS only exposes up to PIO3 as an option. Switching to the AMI BIOS, PIO4 is available and the block mode type becomes selectable (64 is the highest, IIRC). Still, the performance isn't good, maybe only slightly better than the Award BIOS.

With PIO3 selected and the driver loaded with "/D0:16 /F0 /MM0", it reaches something like 5-6MB... I think linear read may have been much higher in Speedsys, but probably not relevant (testing with a CF card). Either Shuttle disabled something with this board or it has something to do with the BIOS... I might try cross-flashing to the Biostar BIOS one day to see for certain. But I can live with the current speed if it means not having to go back to VESA 486.

If you're using a CF card, I suspect multi-sector (Block Mode) has no effect.
Also, the /D0: setting you pass to the driver overrides anything in the BIOS.