LocalBus wrote on 2022-02-21, 22:51:

Sphere478 wrote on 2022-02-21, 22:31:

Try a promise tx4 sata II those seem to work in all my pentium boards

Thanks! I might just give it a try if I can get my hands on one.

How old Pentium systems are we talking about here? 430 chipset? I bet anything with PCI 2.1 compliance is somewhat more forgiving 😀

I’ve tried them on 430 hx and tx.

snufkin wrote on 2022-02-21, 22:58:

Have you tried testing combinations of JP32 and 34 in case they make a difference, since they seem to be connected to the VL/PCI bridge. Or the JP16/17/19 since I don't think we know what they do.

So far only tried with removing JP34, but no change. I will do some more trial and error with the others.

I read that some got fairly modern controllers to work even on 486 systems with PCI bus?

My SiS 496 based PCI 486 works great with a promise ultra133 card. The 496 is a PCI 2.1 chipset though

Some resources points at that only Slot-A on OPTi 82C822 PCI-to-VLB bridge based mainboards support bus mastering:

https://tldp.org/HOWTO/PCI-HOWTO-10.html

This is in fact the only slot I haven't tried since the PCI card interferes with the CMOS battery. All PCI boards I have come across protrudes here to give more support to the mounting bracket I guess.

In the name of science, maybe I will just remove the battery (again). And try with an external battery as suggested by @Snufkin.

I couldn't restrain myself so I did the dig and found a Tekram DC-290N (PCI IDE-2) controller on fleaBay (with a paddle board in all its glory).

It will probably not perform any better than the ISA IDE controller, but at least gives me more than one IDE channel 😄

Interesting reading:

https://www.bswd.com/pciide.pdf

3.1. Device Operation with Older BIOSes
PCI IDE controllers that follow this specification and are added into a system that has an older BIOS that is
not aware of this specification will behave as follows:
If the device defaults to 'compatibility' mode, it will hard decode the compatibility addresses and use the
compatibility IRQs. If the system already contains an IDE controller some unusual behavior will occur.
The end-user will have to deal with the problem.
If the device defaults to native-PCI mode, it will be configured like any other PCI device and will operate
(with the appropriate drivers) without end-user involvement.

4.0. Compatibility Interrupt Connection
This document does not define how a PCI IDE controller on an add-in card gets connected to the
'compatibility' IRQs (14 and 15) needed to operate in 'compatibility' mode. It is unlikely that these IRQs
will ever be made available on the standard PCI connector. However, it is the responsibility of the add-in
card to provide these connections in some manner.

Chapter 4.0 "Compatibility Interrupt Connection" - describe the use of a so called "paddle board" to connect to IRQs 14 and 15 - this is most likely what applies in my case.

I doubt the BIOS on this board have any knowledge about Native-PCI mode. Maybe something for the BIOS decompiling aficionados out there to investigate 😀

What I do know is that the 82C822 is wired for IRQ 14 and 15.

So my guess would be that, for example the Promise Ultra 133 TX2 PCI IDE controller can only operate in Native-PCI mode. Or this would maybe be irrelevant since it is carrying its own ROM? But it simply prompts that "no drives are detected and thus no BIOS routines will be loaded".

Edit:

This thread also covers the perils with early PCI revisions and the crappy PCI IDE controller support:

Re: What are the Early PCI implimentation issues.

Which have even further inspired me to try out the first / upper PCI slot-1 / slot-A (not to be confused the CPU board slots with the same name).

Just have to remove the battery since it is interfering. Fun fact is that the Tekram DC-290N PCI IDE controller (which is on the way) does not interfere with the CMOS battery - coincidence - or by design? 🤔

LocalBus wrote on 2022-02-11, 20:40:

Haha yes, you got it from the starters! Beers on me!! 🍺 […]
Show full quote

Doornkaat wrote on 2022-02-11, 19:01:

snufkin wrote on 2022-02-09, 18:29:

[forgot to say: Doornkaat wins the prize:

]

Really? Woohoo!😄
But it wasn't just the oscillator, was it? This thread is twelve pages long after all.😅

Haha yes, you got it from the starters! Beers on me!! 🍺

We somehow convinced ourselves that the chipset was sporting a 1/2 divider and that you could either use the Chrontel 9007E clock generator or an external oscillator as clock source. Hence I went and sourced a 66 MHz oscillator and yep, it "kind of worked" using either of them as clock source, which probably deviated us further from the goal 😀 I should have known better, since the jumper position it was in when I got it was indeed pointing at the non-populated oscillator (not even attempting to boot, no POST code). Then I changed the jumper using the CH9007E and started to see signs of life. Putting the 66 MHz oscillator in the socket and it "worked" with either clock source.

Turns out that the external oscillator had a very specific purpose for providing the clock for VL Chipset, VL Bus and PCI Bus. Not the FSB. And there is no such thing as a 1/2 divider in the chipset... now we know! 😉

Wow, thanks for the tl;dr! What a weird choice to use an extra oscillator just for PCI.

LocalBus wrote on 2022-02-21, 22:17:

Lessons learnt so far while getting acquainted with this board (up and running):

The BIOS allowed me detect up to 1807MB of my 4GB CF disk, not too bad, I was actually expecting less.

Hi LocalBus,

You ran into the infamous 2GB HDD display limit bug.

All Award BIOSes dated July 1994 or later correctly support the LBA assisted translation, up to the 8 GB limit of the traditional BIOS Int 13h interface.
There is however a bug in the BIOSes dated before January 1996 that limits the harddisk size display, on the BIOS Setup and boot screens, to 2015 MB.

Whenever a drive is 2016 MB or larger, the display starts to count from zero again. The same happens at 4032 and 6048 MB.
So when the BIOS says your 4GB CF disk is 1807MB, it means that 2016+1807=3823MB are detected!

This looks a lot like the an actual 2 GB limit but is only a cosmetic bug in the harddisk size display routine, and it doesn't affect the BIOS support for these larger drives.
For these Award v4.50(P)(G) BIOSes, just use the HDD AUTO DETECTION feature to Setup the drive, select the option with LBA at the end, and disregard the incorrect HD size display.

There is an easy fix however and I can patch this bug for you.
Or, you could read my fix at Re: Diy modding support for k6+And 120gb hard drives into bios roms and patch this bug yourself! 😉

Cheers, Jan

Chkcpu wrote on 2022-02-23, 19:36:

Hi LocalBus, […]
Show full quote

LocalBus wrote on 2022-02-21, 22:17:

Lessons learnt so far while getting acquainted with this board (up and running):

The BIOS allowed me detect up to 1807MB of my 4GB CF disk, not too bad, I was actually expecting less.

Hi LocalBus,

You ran into the infamous 2GB HDD display limit bug.

All Award BIOSes dated July 1994 or later correctly support the LBA assisted translation, up to the 8 GB limit of the traditional BIOS Int 13h interface.
There is however a bug in the BIOSes dated before January 1996 that limits the harddisk size display, on the BIOS Setup and boot screens, to 2015 MB.

Whenever a drive is 2016 MB or larger, the display starts to count from zero again. The same happens at 4032 and 6048 MB.
So when the BIOS says your 4GB CF disk is 1807MB, it means that 2016+1807=3823MB are detected!

This looks a lot like the an actual 2 GB limit but is only a cosmetic bug in the harddisk size display routine, and it doesn't affect the BIOS support for these larger drives.
For these Award v4.50(P)(G) BIOSes, just use the HDD AUTO DETECTION feature to Setup the drive, select the option with LBA at the end, and disregard the incorrect HD size display.

There is an easy fix however and I can patch this bug for you.
Or, you could read my fix at Re: Diy modding support for k6+And 120gb hard drives into bios roms and patch this bug yourself! 😉

Cheers, Jan

Brilliant! You are absolutely right!

fdisk shows the full capacity with no XT-IDE ROM loaded 😀

Ok I will indulge myself in the thread you posted above, thanks!

While we are at it, have you explored the dark corners of PCI IDE interoperability with these early PCI BIOSes?

Cheers,
Linus

LocalBus wrote on 2022-02-23, 20:09:

While we are at it, have you explored the dark corners of PCI IDE interoperability with these early PCI BIOSes?

Cheers,
Linus

Hi Linus,

No, I haven't explored the dark corners of PCI IDE interoperability, yet. 😉

But seeing the early July 1994 date of this PCI BIOS, I think your chances are slim of getting Native PCI support, and you’re stuck with Compatibility mode on PCI-bus IDE channels.
A quick search through the disassembly listing didn’t reveal any Native PCI support either. This BIOS doesn’t even have a BIOS option to disable the on-board IDE, so you may end up with a ports or IRQ conflict with a compatibility mode PCI IDE card.

On this motherboard, I would place my bet on a Native PCI supporting PCI IDE controller card with its own ROM.

Jan

Some updates to this long adventure!

33.333 MHz oscillator arrived and now it happily runs at 66 MHz FSB and 33 MHz VLB/PCI clock 😀

Also got myself a legacy Tekram DC-290N PCI IDE controller which happily works in either of the PCI slots, but I took the one at the top since this PCB does not interfere with the CMOS battery.

The BIOS happily detects one IDE channel via this PCI IDE controller and it is even possible to use the "IDE HDD auto-detection" tool. However, it simply refuses to go past the main / POST screen when having any HDD configured in BIOS using this controller. Also played around with the paddle board to override IRQ 14, 15, but no difference. To the rescue I inserted my XT-IDE card with an AT BIOS ROM, which happily auto-detects both IDE channels and allows me to boot.

Next up is to see if I can use a 3rd IDE channel via the ISA I/O controller card and use this one exclusively for CD-ROM.

Is this even possible with legacy AT systems or is the limit 2 IDE channels based on IRQ 14 and IRQ 15 respectively? I can only recall I had one extra IDE channel off my SoundBlaster 16 back in the days. However, that 486 system only had one IDE channel to begin with...

I guess the key is the port I/O address configuration. And I cannot see the 3rd channel listed by the XT IDE BIOS ROM. It's like the PCI IDE controller takes over the same I/O ports completely. Let's see what happens when I connect a CD-ROM on that IDE header and see if any driver might detect it. There is a jumper on the ISA I/O controller to set "HD controller exists - E/D". I should probably enable this one to not conflict. The next jumper is whether the IDE port should be Enabled/Disabled. This would probably mimic the behavior of say a soundcard with and IDE port.

Cheers,
Linus

Ok that was a big let down... with the Tekram DC-290N PCI IDE controller it is just impossible to detect any CD-ROM drive.

At least with the OTI-91X driver provided on the Win98SE boot floppy.

In fact just having the PCI card installed is also messing with my ISA IDE controller so it will not detect the CD-ROM either. As soon as I remove it, then it detects the CD-ROM just fine.

Kind of back at square zero then with just one IDE channel.

It was just not meant to be using IDE controllers on PCI 2.0 revision 😉

You can have more than 2 IDE channels, but the I/O address of each one must be properly configured to avoid conflicts. Not sure if you can do that on your Tekram or ISA controllers. The IDE in SB cards could usually be configured to tertiary or quaternary, so it would coexist happily with the primary/secondary channels of the motherboard or IDE controller.

If you use the PCI and ISA controllers at the same time without changing anything, you'll probably end up with a conflict on either the primary or secondary channel.

TheMobRules wrote on 2022-03-15, 19:43:

You can have more than 2 IDE channels, but the I/O address of each one must be properly configured to avoid conflicts. Not sure if you can do that on your Tekram or ISA controllers. The IDE in SB cards could usually be configured to tertiary or quaternary, so it would coexist happily with the primary/secondary channels of the motherboard or IDE controller.

If you use the PCI and ISA controllers at the same time without changing anything, you'll probably end up with a conflict on either the primary or secondary channel.

Understood. Hmm, I did try to disable the ISA IDE controller completely and the PCI IDE controller worked just happily alongside the ISA IDE controller in that configuration, with two hard-drives detected, each as a Master on the respective IDE channels. Problem is just that I could not detect any ATAPI device in this configuration, connected as Slave on either of these channels.

I will give it another go with the PCI IDE controller. Otherwise I do have an extra AWE64 card with IDE header on it... 😀

Could it have something to do with this legacy header on the DC-290N?
I have some early S5 board (from Epox?) and it mentions this in the manual. I have a matching PCI IDE card and you have to connect the cable to both the card and motherboard in order for it to work properly. Something with bus mastering if I remember correctly?

Doornkaat wrote on 2022-03-15, 20:34:

Could it have something to do with this legacy header on the DC-290N?
I have some early S5 board (from Epox?) and it mentions this in the manual. I have a matching PCI IDE card and you have to connect the cable to both the card and motherboard in order for it to work properly. Something with bus mastering if I remember correctly?

Yes I have been playing with the legacy header without any real results. Maybe the XT IDE was playing tricks with me as well.

What I now did was to completely disable the ISA IDE controller and IDE header on that card [ISA Multi I/O controller]. JP8 set to "HDC exists" and JP9 set to "IDE disabled". Then I installed the PCI IDE controller card with my CF card as Master and CD-ROM as Slave [Primary IDE channel]. It auto detected my HDD just fine in BIOS but refused to boot past the main BIOS screen.

Then I tried installing the legacy header / paddle board again - and what do you know - it booted happily without the XT IDE ROM installed and also found the CD-ROM drive 😀

So I call it success, I now have at least two working IDE channels!

Yeah, don't quote me on this, but I think that paddle is used to pass the "legacy" IRQ 14 and 15 signals for the primary and secondary IDE channels from the ISA slot to the controller.

So after been playing around with the system and actually got MS-DOS 6.22 installed, I have reached the point where I started to do some benchmarking.

This will never be a speed demon, that I know - it was more intended to be something to relive some glorious 486 memories. I consider this system closer to a 486 than a Pentium really, especially with the VLB based chipset.

Nevertheless I simply cannot leave things in a non-optimal configuration (yes I probably have some undiagnosed letter combination) 😄

So I have been playing around with as aggressive chipset settings and memory settings possible in BIOS.

But the one setting I recon could really speed things up is "grayed out" in the BIOS settings , namely setting "External Cache Policy" to "Write-Back". It defaults to "Write-Through". I have been trying all kinds of jumpers settings but no change.

So my question to you, does this make any significant impact in terms of performance? And also, is this somehow related to the SRAM + TAG modules themselves? Sounds far fetched...

Posting a screenshot of my current settings:

"Addr. Delay For Page Hit" does not make any difference what so ever, just happened to be set to "Enabled" as part of trial and error when this picture was taken - now reverted to "Disabled".

Setting "DRAM Post Write" to "Enabled" renders the system unstable.

"Cache Write Burst Mode" and "Cache Read Burst Mode" are set at the most aggressive setting I can obtain and still have a stable running system.

Some bios editing utilities can enable hidden Settings.

Awdbedit I think is one, but I’m told it corrupts.

I think it would be really cool to make a socket 3 to socket 7 adapter.

We could be running dx4s in mvp3 and ali aladdin V boards :p

Sphere478 wrote on 2022-03-19, 02:01:

Some bios editing utilities can enable hidden Settings. […]
Show full quote

Some bios editing utilities can enable hidden Settings.

Awdbedit I think is one, but I’m told it corrupts.

I think it would be really cool to make a socket 3 to socket 7 adapter.

We could be running dx4s in mvp3 and ali aladdin V boards :p

Maybe @Chkcpu can help out with some BIOS modifications 😀

Judging by the brochure for OPTi 571/572 it should indeed support "up to 2 MB of Write-
back cache".

https://archive.org/stream/bitsavers_optibroc … e_1993_djvu.txt

I think the main thing holding this board back though, is the 32-bit DRAM bus.

The VLB-to-PCI might not help the cause either, but the main chipset design is just not keeping up.

When comparing benchmark results for # doom -timedemo demo3 (screen size maxed out), I get 2550 realtics. I bet a 430 chipset based P100 would have better results. Fun fact is that MBF204 runs significantly faster, where the same demo3 results in 1869 realtics = 40.0 frames per second.

Regarding 486 compatibility with this board (provided some kind of socket adapter) - I know @Snufkin looked into it. Might be some pins that would need to be hot-wired to the chipset since those are not present on Socket4, 5 or 7. Who knows, some day ...

LocalBus wrote on 2022-03-19, 08:49:

Maybe @Chkcpu can help out with some BIOS modifications 😀 […]
Show full quote

Sphere478 wrote on 2022-03-19, 02:01:

Some bios editing utilities can enable hidden Settings. […]
Show full quote

Some bios editing utilities can enable hidden Settings.

Awdbedit I think is one, but I’m told it corrupts.

I think it would be really cool to make a socket 3 to socket 7 adapter.

We could be running dx4s in mvp3 and ali aladdin V boards :p

Maybe @Chkcpu can help out with some BIOS modifications 😀

Judging by the brochure for OPTi 571/572 it should indeed support "up to 2 MB of Write-
back cache".

https://archive.org/stream/bitsavers_optibroc … e_1993_djvu.txt

I think the main thing holding this board back though, is the 32-bit DRAM bus.

The VLB-to-PCI might not help the cause either, but the main chipset design is just not keeping up.

When comparing benchmark results for # doom -timedemo demo3 (screen size maxed out), I get 2550 realtics. I bet a 430 chipset based P100 would have better results. Fun fact is that MBF204 runs significantly faster, where the same demo3 results in 1869 realtics = 40.0 frames per second.

Regarding 486 compatibility with this board (provided some kind of socket adapter) - I know @Snufkin looked into it. Might be some pins that would need to be hot-wired to the chipset since those are not present on Socket4, 5 or 7. Who knows, some day ...

See the p5a simple mod thread.

In that thread there is a way to toggle write back/write through with a hardware mod

K6-2/3+ Success on Asus P5A 1.06 - simple mod