Well that explains why I couldn't see it, it is not on the socket at all, but only on the silkscreen. I did not remove the ISA card. I guess I'll have to try again. Hopefully the option for boot ROM is not greyed out once the EEPROM is installed. If it doesn't work still, I'll have to order one of those isa rom boards.

I tested both the attached cards and there is no means to force the boot PROM to be enabled, at least not from within the configuration utility. I think the utility is looking for a particular type of EEPROM for it to auto enabled.

Has anyone confirmed if a 3Com 3C515-TX will work? I know those have an option to set the EEPROM size and to be set as enabled. I don't have a spare one in my bin, so I'll have to source one. I'd prefer the 3Com over the Lo-Tech ISA card, just to have less cards in the system. I can see how these $35 Lo-Tech ISA cards would come in handy though. Too bad they don't come with a metal mounting bracket.

Ha! Good luck with the 3C515! I tried to get one for myself, but wasn't prepared to pay more than a motherboard and cpu for one!

In relation to 3C515 setup, I'm not sure if it uses the same Dos .exe as for 3C509 cards, but the pictures in the manual show virtually identical screenshots in the tool to enable/disable boot rom, boot rom size, set transceiver, duplex, base address and boot rom memory location, so I would expect it to behave the same as it's 10mbit little brother.

Yeah, pretty much everything is a rip off right now. One will turn up.

Can this Lo-Tech ROM board be used for other adaptions, not just IDE support? Is there a listing of other ROMs that people have uploaded to add other features, like boot BIOS support for LS-120 drives?

feipoa wrote on 2021-06-11, 10:42:

I tested both the attached cards and there is no means to force the boot PROM to be enabled, at least not from within the configuration utility. I think the utility is looking for a particular type of EEPROM for it to auto enabled.

Did you try this with a known-good EPROM inserted into the socket?

The one you put in backwards is almost certainly destroyed now

I used a new eeprom, not the shorted one.

Anyone have any luck with the Intel or ibm using xtide bios?

In preparation for swapping out my Promise Ultra100 PCI controller for use of the onboard IDE port (to run Voodoo2 SLI), I wanted to do some benchmarking with various storage devices. In running my tests, I determined that PIO-4 mode is not stable in NT4 on this motherboard. I had to revert down to PIO-3.

I found no significant difference in benchmark results when the IDE port had a Maxtor ATA133 drive connected, or Sandisk Extreme Pro UDMA7, or a Samsung EVO 870 SSD. They all were incredibly slow at mass data throughput compared to the Promise Ultra100 controller.

I've never run PIO IDE controllers on PCI 486 boards, so these benchmarks results are new to me. Is it acceptable to have around 4 MB/s read and write speeds? By way of comparison, using the Promise Ultra100 controller on the same 3 devices (CF, SSD, Maxtor HDD), the throughput was 27 MB/s. The only benefit of using the SSD or CF compared to magnetic platters is the random access time, which is generally a magnitude better, e.g. from 10 ms to 0.6 ms. I noticed a lot of people are content with using the onboard IDE - is the benefit of reduced random access time so much more desirable for overall system performance compared to data throughput?

Maxtor Ultra133 IDE drive - PIO4 (not entirely stable)
Read Max = 4467 KB/s
Write Max = 5138 KB/s

Maxtor Ultra133 IDE drive - PIO3
Read Max = 4157 KB/s
Write Max = 4759 KB/s
PIO-2 results were the same as PIO-3

Samsung 870 EVO - PIO3
Read Max = quite variable and inconsistent, sometimes 700 KB/s, sometimes 3500 KB/s
Write max = 4409 KB/s

Sandisk Extreme Pro UDMA7 160MB/s - PIO3
Read Max = 3753 KB/s
Write Max = 4409 KB/s

I was a little disappointed that the CF card demonstrated slower throughput compared to the IDE HDD. Anyone know why?

On Wikipedia it looks like PIO mode 3 was only rated for 11 MB/s anyway, so there was no way it would match the UltraDMA card.
Programmed I/O ties up the CPU running a REP INSD instruction to read from the bus only 32 bits at a time. I don't know whether the fault for the slow times (vs. what PIO3/PIO4 should make possible) lies with the UMC chipset, the CPU, or both.
When the chipset was made, these boards were likely tied with low end drives. Mine came with an 850MB drive. Perhaps the implementation was sub-optimal but the drives were too slow to matter at the time.

That performance is consistent with the earlier UM8886A revision I have.

In regard to the CF being slower, I have a possibility but not an answer. PIO mode also has multi-sector transfers, rather than requiring one IRQ per 512 bytes. When I was messing with these VLB/PCI controllers, that actually had the biggest performance impact more than all the other optimizations. There was an old Linux IDE FAQ that seemed to agree. Perhaps your CF card doesn't support 16-sector multi-sector transfers and supports a fewer number or only 1.

It looks like it is transfering, at best, at PIO-1 speeds. I was hoping for at least 10 MB/s out of a high-end CF card on PIO IDE. Is there any way to improve upon this?

Although DMA is supposed to free up the processor, to the end user transferring at 27 MB/s on the UltraDMA 100 controller still shows up as 100% CPU usage. The same 100% is visible when using the CF card on the MB's IDE port, albeit at a slower rate. Interms of how much the CPU is being used, is there any performance difference between the UDMA100 at 100% and PIO at 100%, aside from the faster throughput?

I did try two different CF cards. I've no idea if either support 16-sector multi-sector transfers.

How much slower will games load using 4 MB/s PIO IDE vs. 27 MB/s PCI UDMA?

Yeah, back in late 1996, these M919 and Biostar systems typically came with an 850 MB Western Digital Caviar piece of junk. In my personal experience, they were awfully slow, clunky, unreliable.

I've also been struggling to find a CF card that can do better than PIO-1 on a system with no UDMA support. I'm not sure cards with faster PIO modes even exist

maxtherabbit wrote on 2021-06-16, 03:16:

I've also been struggling to find a CF card that can do better than PIO-1 on a system with no UDMA support. I'm not sure cards with faster PIO modes even exist

Do those SCSI2IDE adapters offer any advantage over CF2IDE in the context of PIO? I don't own one, but I did a comparison of SCSI2SD and SCSI2CF on the ISA bus (PGA-132 motherboard), which achieved 2020 KB/s. I'd have expected PIO on the UM8886 to achieve better than 3750 KB/s with CF.

SCSI2SD comparison thread here, SCSI2SD - Comparison of SCSI SD, CF, and HDD performance

It's not just DMA mode and transfer speed, they don't have dram cache so. Dram cache for SSDs would increase performance in PIO mode, Id think even a traditional HDD with a large cache would perform better than a CF card in PIO mode even if the cache isnt used the same way as it is on a SSD.

I guess the point is ATA/IDE/SATA/NMVe etc is just the communication with the drive. IDE2scsi , ide2sata, 2 whatever shouldn't change the transfer speed if anything extra translation on the interposes theoretically slows you down. Though the results may not show that when the drive you attach to it is much faster.

Id guess you might see a benefit from ide2scsi only becasue scsi drives have the potential to be much faster than ide drives. however i don't think your going to get CPU offload from the interposer in that I don't think it will add DMA. Your best bet is to just abandon the onboard controller and slot a controller that actually works.

Warlord wrote on 2021-06-16, 06:23:

It's not just DMA mode and transfer speed, they don't have dram cache so. Dram cache for SSDs would increase performance in PIO mode, I'd think even a traditional HDD with a large cache would perform better than a CF card in PIO mode even if the cache isn't used the same way as it is on a SSD.

Indeed, the results above demonstrated that to some degree.

1[b]Maxtor Ultra133 IDE drive - PIO3 - has 8 MB cache [/b]
2Read Max = 4157 KB/s
3Write Max = 4759 KB/s
4
5[b]Sandisk Extreme Pro UDMA7 160MB/s - PIO3[/b]
6Read Max = 3753 KB/s
7Write Max = 4409 KB/s

Why can't we get even close to the PIO theoretical speed? Perhaps there is something wrong with the implementation of the IDE controller on the UM8886 southbridge? Is the speed degradation really worth it for Voodoo2 SLI? Why are so many people running PCI 486's with the onboard IDE controller?

Further interesting is that [on a Tualatin board] I tested a SATA 3Gbps drive on a Promise 3 Gbps PCI controller card and compared it to a PATA133 drive connected thru a SATA-to-IDE adapter bridge adapter and the PATA drive benchmarked faster. This is a bit off-topic, but the results for curiosity were as follows:

Promise SATA II PCI controller (3 Gbps) on dual Tualatin 1.4 GHz system:

Maxtor Diamond Max 10 PATA133 (6L080P0) - connected via an ACARD 7923 with chip ARC772-B
Read/Write = 66 MByte/s

WD Caviar SE (WD800JD-23SA0), native 3 Gbps
Read/Write = 57 MB/s

Sandisk Extreme Pro UDMA7 CF card 1067X - connected via ACARD 7923
Read/Write = 63 MB/s

Generic 200X CF card - connected via ACARD 7923
Read = 23 MB/s
Write = 15 MB/s

Samsung 870 EVO, native 6 Gbps
Read = 112 MB/s
Write = 107 MB/s

Is the 8 MB cache on the ATA drive able to help that much?

The onboad IDE on my 486 is pretty fast. It has that ADI/2, , CL-PD7220, AIC-25VL01 I maybe wrong but its seemed pretty fast. So maybe your right its just the UMC chipset. While this isn't a exactly a good benchmark, I was getting over 8k reads with the Dx2 compared the the 7k reads the the IBM SLC with a CF card.
Re: Alaris Cougar Fastest 386

A few observations from using CF cards over the years:

- Most don't support multi sector transfers (maxmultsec is 1, on most of the cards I've got - most real IDE drives, unless they are ancient, can do 8, 16 or 32 sectors - so 4KB, 8KB or 16KB transfers with one command versus 512 bytes)
- DMA support is hit and miss
- Lack of on drive cache for CF/SD cards has a big impact on performance in Windows/Linux; that said, in Dos, this does not manifest particularly badly - it's only high IO jobs like unpacking big zip files or copying directory trees from one partition to another where it becomes apparent. In most other cases the near-zero access/seek times more than make up for it.

All that said, I still prefer CF cards for most older systems for their convenience, low power and lack of noise.

Warlord,
I tried to compare my 1066x Sandisk CF card to your results, but Speedsys doesn't see my CF card. Seems that even if I manually type in the cylinders and heads to the BIOS to set my 32 GB card to 8 GB, Speedsys doesn't see it. I had to use a slower 133x 8 GB CF card for Speedsys to see it, and in PIO-3 mode, buffered read and linear read were both about 4240 KB/s. PIO-4 was 4730 KB/s. And this is with an IBM 5x86c-133. If you are getting around 8K read on a 386-class system (IBM BL3), something doesn't seem quite right with the UM8886BF IDE controller. I suppose I need more data from users using their 486's onboard IDE ports.

While playing around with the CF HDD setup in the BIOS, I did notice that speedsys returned HDD test values quicker when the CF card was set to the "LARGE" mode rather than "LBA" mode, however the linear/buff read speed results were the same for both LARGE and LBA. The BIOS Companion did mention that on some boards LARGE will be faster than LBA. I also played around with numerous BIOS settings thinking I might have one amis which is causing the slow IDE performance, but this was not the case.

megatron-uk,
How were you able to determine what sector size your CF card is transferring per command?

Do you also use CF cards on socket 5/7 era systems, or are you referring to much older DOS-only type systems? The system in question, an IBM 5x86c-133/2x, is mostly used to load late 90's 3D accelerated games. Of my dozens of systems, this one sees the most use because I use the 3D games on this system as motivators to get my kids to do their homework. For the use case, would you still pick the CF over the Maxtor? It's not exactly loading up pong.

The switch-over is still contingent on XT-IDE being able to see up to 120 GB on this system on the onboard IDE port.

EDIT: I was doing a little reading on these Maxtor DiamondMax 9 plus and DiamondMax 10 hard drives I have been using. While both support 150 MBytes/sec, the DiamondMax 10 supports Native Command Queuing (NCQ), which was a SATA feature. I did a Google search and this is what came up,

1Native command queuing (NCQ) is a technology enabling SATA hard drives to accept more than one command at a time by optimizing the order in which read and write commands are executed. This increases the performance of the drive by limiting the number of drive head movements when multiple read/write requests are queued.

Hence I was wondering, is the HDD able to make use of this feature while in PIO mode on a 486? If not, what about while connected to the Promise Ultra100 ATA controller? Do compact flash drives support NCQ? It looks like A2 class SDXC cards support this.

In Dos itself, the capabilities of the drive can be examined in nssi:

That's an 8GB Transcend drive in my 286 (the one with DDO software, as I couldn't access the full capacity using XTIDE for some reason). You can see that it doesn't support multi sector transfers under the 'Sectors per interrupt' heading (well, it does, but a value of 1). You can see similar information in linux via the hdparm utility; you can often see the value the drive is set to, as well as the maximum supported.

Multiple sector transfer is also sometimes known as block mode transfer, and that tends to be what the option in BIOS to enable it is listed as.

feipoa wrote on 2021-06-16, 10:41:

Do you also use CF cards on socket 5/7 era systems, or are you referring to much older DOS-only type systems? The system in question, an IBM 5x86c-133/2x, is mostly used to load late 90's 3D accelerated games. Of my dozens of systems, this one sees the most use because I use the 3D games on this system as motivators to get my kids to do their homework. For the use case, would you still pick the CF over the Maxtor? It's not exactly loading up pong.

Unfortunately I don't have a system of the K5/K6/Pentium/Cyrix 6x86 generation (I have a GA586HX and a P166+, but those are just components in storage, haven't had it as a working system for 20+ years). Below that I have a 486DLC (Dos only, CF), then the next closest is my AMD X5 P75+ (Dos only, CF), then the next working system is a Pentium Pro 200. That had a 2.5" ATA notebook drive in, the last time I was actively using it.

I have to admit it would be a bit of a head scratching decision on something running Windows. I think I'd be tempted to go for a SATA (or mSATA) SSD connected to an PATA/SATA convertor, again for the power/noise benefits rather than anything else. I try to minimise the amount of spinning rust in use.

Native command queuing (NCQ) is a technology enabling SATA hard drives to accept more than one command at a time by optimizing the order in which read and write commands are executed. This increases the performance of the drive by limiting the number of drive head movements when multiple read/write requests are queued.[/code]
Hence I was wondering, is the HDD able to make use of this feature while in PIO mode on a 486? If not, what about while connected to the Promise Ultra100 ATA controller? Do compact flash drives support NCQ? It looks like A2 class SDXC cards support this.

No, I don't think your built in disk controller will understand NCQ (it's the equivalent of SCSI's command queue where a sequence of commands can be fired off to the drive, without waiting for each one to complete and return in sequence). Of course if you add a PCI SATA controller it will speak native SATA (and thus NCQ, if the drive supports it). A PATA controller on the other hand doesn't understand NCQ and will talk to the drive in old ATA commands (though I suspect you'll have a bridge chip converting your PATA interface card to the SATA interface of your drive?).

Thanks for the information. Unfortunately, NSSI hangs on load for me, however HWINFO worked fine. It also shows a data buffer size of 1 KB and 1 sector per interrupt.

For the NCQ, I was actually referring to an IDE hard drive that supports it, not a SATA drive. The Maxtor DiamondMax 10 series support NCQ and it got me wondering how NCQ would work since this feature wasn't around when [most/all?] PATA controllers were designed. Can it work independent of the IDE controller to some degree?

SATA SSD didn't perform well on the motherboard's IDE controller for read operations.

I've begun testing the XTIDE on my Biostar MB-8433UUD. I was able to write the EEPROM while in the motherboard, but when I went to make some changes and re-write the EEPROM, I would get:

1EEPROM did not return the same byte that was written.  EEPROM was not flashed properly!

after which the XTIDE BIOS stopped show up upon boot. I pulled the Lo-Tech ISA ROM card and re-programmed the EEFPROM in another computer, then put it back into the 8433UUD. Using my 120 GB Maxtor HDD, I was able to boot WIN NT4.0 using XTIDE, however when I went to boot Win95c on the same HDD, I would get to the login screen, login, then receive an error about the video card's setting. I went to reboot and it just sat there - no IDE LED activity. Rebooted again and kept getting:

1A fatal exception OE has occurred at 0028:C3342C04

I changed the address on the ROM card, but screen stayed blank. I changed it again and it booted, but HDD LED activity ceased half way through Win95 booting. Are some of these addresses conflicting with existing hardware? I haven't tried them all yet, but that is what I'll do next.

The shadow address ranges noted in the Biostar's BIOS to enable/disable, namely,

1C8000-CBFFF Shadow - Enabled/Disabled
2CC000-CFFFF Shadow - Enabled/Disabled
3D0000-D3FFF Shadow - Enabled/Disabled
4D4000-D7FFF Shadow - Enabled/Disabled
5D8000-DBFFF Shadow - Enabled/Disabled
6DC000-DFFFF Shadow - Enabled/Disabled

do not coincide with the address options on the ROM card, which are,

1A800h 	
2B000h 	
3B800h 	
4C000h 	
5C800h 	
6D000h
7D800h
8E000h
9E800h
10F000h
11F800h

So perhaps the MB shadows these regions automatically. Not sure. Anybody know why Win95c isn't booting properly with XTIDE? I have device type set to 32-bit, interrupt 14 enabled, base address set to 170h, control block address set to 370h, block mode: yes, CHS translation method: LBA, internal write cache: disabled, IDE controllers: 1 (primary). I left off the secondary controller because XTIDE takes forever to auto scan it (CD-ROM and LS-120 connected to secondary).