Why do you think, that i440BX does not support graphics card with more than 64MB memory? You mean AGP aperture size in BIOS setup?

No not aperture size. Wikipedia indicates something to that effect and my FX5500 card produces video output and can boot into Windows 98 but can't work properly. Device manager indicates major resource conflicts and no Nvidia drivers will make it work. I bought a cheap GeForce 2 to get things running without the conflicts, it having less video memory and being older it works fine.

Hm, never hear about that and sadly I have none board with i440BX and AGP to test it out personally, but I think it is only some incompatibilty between board and concrete graphics/drivers.

Hang on, you said you needed to upgrade BIOS to get your Win98 install to boot? So you installed Win98 on a different system - with a different chipset and so drivers - and moved it here?

A Win98 install can survive that, but it's a recipe for instability and mess. With Win98 you really want to do a clean install with chipset drivers installed before VGA drivers. i440BX is supported out of the box on Win98SE, so not an issue with a clean install, but you particularly do not want to have *other* chipset drivers installed before Windows meets your hardware.

That - rather than hardware incompatiblity - is most likely cause of your issues. And if there is a hardware issue after all, it's more likely to be to do with current that your board can supply to the AGP slot than anything abstract around video memory sizes. 2002 cards can draw a lot more than 1999 motherboards were designed for. None of which makes i440BX an inferior solution for slot 1, you're just way outside the platform envelope with what you are plugging into it.

The issue is that old PCI BIOS implementations reserve a fixed amount 128MB of address space for video memory on secondary PCI busses. AGP cards generally run on a secondary bus behind the PCI-to-AGP bridge that is part of the north bridge. If an AGP card is installed that requires 256MB of address space for its vido memory, the resulting configuration of the AGP bridge is invalid. Some operating systems reconfigure PCI resources if the BIOS assigned invalid settings, but Windows 98 doesn't try to do that. Instead, in Windows 98 just refuses to access the video memory behind the AGP/PCI bridge in this invalid configuration, and shows the issue as "resource conflict".

The best solution would be a more modern BIOS that dynamically assigns address space sizes for secondary busses instead of the fixed amount of 128MB, and the second best solution would be a DOS tool that fixes the AGP bridge configuration, which is called from AUTOEXEC.BAT. I was able to successfully enable a 256MB video card on Windows 98 doing a hardcoded pci configuration patch, but as that tool was just a ten-line assembler program specifically crafted for one system, it is of no general use. Meanwhile, I made a simple DOS setpci-like utility, which is available at https://github.com/karcherm/dostools/releases/tag/v1.0 . If you can paste the output of PCI.EXE called without any parameters, I can take a look at it and suggest an invocation that fixes the AGP bridge configuration.

If we are talking about 100Mhz FSB the BX Chipset is definability your best choice, but it has limitations.
Early revisions of all motherboards max out at a P3 600, Which P3 CPU are to trying to use it may not be supported?
Just about all motherboards of this era only support hard drives upto 160GB. You'll need something like a PCI SATA card if you want larger drive support.

If your talking about 133FSB BX is still very good choice but requires overclocking the board, not really a problem but AGP slot is also overclocked so something to be wary of, Maybe this is what your reading about the FX550?

Other alternative something based off the ApolloPro133a chipset. This does have native 133FSB support and works well enough but drivers, stability, performance was never quite as good as the BX option.

mkarcher wrote on 2023-01-21, 10:43:

The issue is that old PCI BIOS implementations reserve a fixed amount 128MB of address space for video memory on secondary PCI busses. AGP cards generally run on a secondary bus behind the PCI-to-AGP bridge that is part of the north bridge. If an AGP card is installed that requires 256MB of address space for its vido memory, the resulting configuration of the AGP bridge is invalid. Some operating systems reconfigure PCI resources if the BIOS assigned invalid settings, but Windows 98 doesn't try to do that. Instead, in Windows 98 just refuses to access the video memory behind the AGP/PCI bridge in this invalid configuration, and shows the issue as "resource conflict".

The best solution would be a more modern BIOS that dynamically assigns address space sizes for secondary busses instead of the fixed amount of 128MB, and the second best solution would be a DOS tool that fixes the AGP bridge configuration, which is called from AUTOEXEC.BAT. I was able to successfully enable a 256MB video card on Windows 98 doing a hardcoded pci configuration patch, but as that tool was just a ten-line assembler program specifically crafted for one system, it is of no general use. Meanwhile, I made a simple DOS setpci-like utility, which is available at https://github.com/karcherm/dostools/releases/tag/v1.0 . If you can paste the output of PCI.EXE called without any parameters, I can take a look at it and suggest an invocation that fixes the AGP bridge configuration.

AGP is a secondary bus behind PCI? I always thought it was independent of PCI.🤔

Doornkaat wrote on 2023-01-21, 14:36:

mkarcher wrote on 2023-01-21, 10:43:

The issue is that old PCI BIOS implementations reserve a fixed amount 128MB of address space for video memory on secondary PCI busses. AGP cards generally run on a secondary bus behind the PCI-to-AGP bridge that is part of the north bridge.

AGP is a secondary bus behind PCI? I always thought it was independent of PCI.🤔

Well, the matter is more complicated. You are right: Data from the processor to the AGP graphics card does not travel through the physical 32-bit 33MHz PCI bus on the motherboard. If data would physically travel through the PCI bus, you couldn't get higher performance from AGP than you can get from PCI. On the other hand, I am right, too: The configuration of the north bridge behaves as if the data would be passed through the the primary PCI bus to the Accelerated Graphics Port. The on-board PCI bus is configured as primary bus, with bus number 0. One of the devices that appear on the primary bus is the AGP bridge, which is configured as if it were a PCI to PCI bridge. The BIOS programs a range of MMIO space, a range of prefetchable memory space and a range of I/O ports that should be "forwarded" to AGP. The BIOS also assigns a non-zero bus number to the AGP, and programs the number of that bus into the AGP bridge. In a typical PC system, the AGP bridge is the only PCI-to-PCI bridge, so the AGP gets assigned bus number 1.

When the processor accesses memory, it communicates to the north bridge via the front side bus. The north bridge then looks up whether the address is inside the memory window(s) of the AGP bridge. If that is the case, the cycle is performed as AGP cycle. If the address is not inside the AGP window(s), the data is sent to the PCI bus instead. If the access is to an ISA card, it travels from the north bridge via PCI (on the 440BX) to the south bridge, and is then forwarded to ISA by the south bridge. Newer Intel chipsets, starting with the 800 series (i810, i815) use a special protocol between the north bridge ("memory controller hub") and the south bridge ("I/O controller hub"), called "hub link", which is twice as fast. Access to PCI devices are forwarded from the FSB to the hub link by the memory controller hub, and then from the hub link to the physical PCI bus by the "I/O controller hub". Yet, it looks to the operating system as if the north bridge, the south bridge and PCI cards are siblings on the same PCI bus.

440BX is hard to beat.

"440BX chipset doesn't support video cards with more than 64MB of VRAM"

This is bullshit btw.

I like my Asus P3B-F, and no problems with larger memoried AGP cards here either.

pete8475 wrote on 2023-01-21, 16:54:

This is bullshit btw.

Does it need such hard words?
His BIOS is the problem, not the 440BX.

Revolution wrote on 2023-01-21, 08:48:

[...] It's definitely good for being period appropriate to Slot 1 specifically, but I can't get a Pentium III CPU to work on this thing [...]

I'm guessing you are talking about a Coppermine CPU.
If that's the case, it will not work until you replace the voltage controller chip. All revisions of this board up to and including v1.9 come with the HIP6004ACB controller, which only supports voltages down to 1.8V.
You need to replace it with the HIP6004BCB, which will then support voltages down to 1.3V.

Another option would be to use a socket 370 CPU and a slotket adapter that supports custom voltage request signaling and forcing 1.8V (thus overclocking the CPU, but 1.8V should still be fine).
But, if you're comfortable with replacing the chip (or if you know someone who can do it), then this is definitely the recommended approach (especially because this is a very nice board, and you can even control the FSB in realtime from within DOS/Windows).

pete8475 wrote on 2023-01-21, 16:54:

440BX is hard to beat.

"440BX chipset doesn't support video cards with more than 64MB of VRAM"

This is bullshit btw.

+1

I have used AGP cards with more than 64MB RAM without any problems on motherboards with 440BX and 440ZX chipsets.

Here's the wikipedia page that gave me the impression about the vram restriction if anyone feels like editing it: https://en.wikipedia.org/wiki/Slot_1

Otherwise, I'll look into resolving the video issues via what was suggested and maybe replace that voltage controller later on. No soldering kit for now but I can solve that issue a few paychecks from now.

Revolution wrote on 2023-01-21, 19:53:

Here's the wikipedia page that gave me the impression about the vram restriction if anyone feels like editing it: https://en.wikipedia.org/wiki/Slot_1

The Wikipedia page is referring to the AGP aperture size, not the size of video RAM on the card (note: I just edited it. It said "memory mapping" instead of "aperture size" up to now). One of the main features of AGP that is not present on PCI is that an AGP card can use parts of the system memory as "offboard video memory", usually called "AGP texturing" because this feature was intended to be used for textures. This is different to standard "busmaster DMA", because with AGP texturing, the operating system can control which parts of memory is visible to the card on a fine-grained basis. This "view" into the main memory that can be taken by the AGP card is called the "aperture". As bigger apertures require bigger management tables, there is a limit on the supported size of that aperture.

In practice, AGP texturing turned out to be too slow to be useful to high-performance graphics cards, so the size of the AGP aperture is not relevant to most users. The Intel i740 graphics chip is a notable exception, though, as this chip was designed to primarily use system memory for textures, and its general performance is low enough that the AGP texturing usually isn't the bottleneck. Even with that card, having access to 64MB of AGP aperture for textures is usually good enough, as the performance of the i740 doesn't call out for ultra high resolution textures. More than 64MB of texture memory might be interesting in specific Virtual Reality systems in which most of the system memory (which can be upgraded to 1 Gigabyte on the BX chipset) is used for textures, for example in flight simulators. It may not be very surprising that the i740 design is actually based on the requirements of military flight simulators, and it is from a time where putting that much memory on the graphics card seemed excessive.

mkarcher wrote on 2023-01-21, 10:43:

If you can paste the output of PCI.EXE called without any parameters, I can take a look at it and suggest an invocation that fixes the AGP bridge configuration.

Here's the output with the Geforce 2 installed. Let me know if you need me to swap out for the FX5500.

100:00.0: id 8086:7190, class 06/00/00
2  10: MEM  at e0000000..e4000000 (64M)
300:01.0: id 8086:7191, class 06/04/00
4  bus 0 -> 1
5  forwarding MMIO e4000000..e5ffffff
6  forwarding MEM  d8000000..dfffffff
700:07.0: id 8086:7110, class 06/01/00
800:07.1: id 8086:7111, class 01/01/80
9  20: PIO  at f000..f00f
1000:07.2: id 8086:7112, class 0c/03/00
11  20: PIO  at e000..e01f
12  INTD -> IRQ10
1300:07.3: id 8086:7113, class 06/80/00
1400:09.0: id 1102:0004, class 04/01/00
15  INTA -> IRQ9
1600:09.1: id 1102:7003, class 09/80/00
1700:09.2: id 1102:4001, class 0c/00/10
18  INTB -> IRQ9
1900:0b.0: id 100b:0020, class 02/00/00
20  10: PIO  at ec00..ecff
21  14: MMIO at e7004000..e7005000 (4K)
22  ROM (diabled), area size 00010000 (64K)
23  INTA -> IRQ10
2401:00.0: id 10de:0111, class 03/00/00
25  10: MMIO at e4000000..e5000000 (16M)
26  14: MEM  at d8000000..e0000000 (128M)
27  ROM (diabled), area size 00010000 (64K)
28  INTA -> IRQ11

Revolution wrote on 2023-01-21, 23:58:

mkarcher wrote on 2023-01-21, 10:43:

If you can paste the output of PCI.EXE called without any parameters, I can take a look at it and suggest an invocation that fixes the AGP bridge configuration.

Here's the output with the Geforce 2 installed. Let me know if you need me to swap out for the FX5500.

The configuration you posted is valid. That's not surprising, as the GeForce 2 just requests 128MB of address space for its video RAM. The address space that gets forwarded to the AGP is listed in the AGP bridge configuration

100:01.0: id 8086:7191, class 06/04/00
2  bus 0 -> 1
3  forwarding MMIO e4000000..e5ffffff
4  forwarding MEM  d8000000..dfffffff

matches the address space configured in the card:

101:00.0: id 10de:0111, class 03/00/00
2  10: MMIO at e4000000..e5000000 (16M)
3  14: MEM  at d8000000..e0000000 (128M)
4  ROM (diabled), area size 00010000 (64K)
5  INTA -> IRQ11

Please don't worry about the difference in the end addres (dfffffff in the forwarding output and e0000000 in the MEM output), that's a quirk in PCI.EXE from release 1.0. I overhauled the tool today, and removing this quirk is one of the results. In Release 1.1, the end address for the memory range of the graphics card is also printed as dfffffff, and the sizes of the ranges configured in the AGP bridge are printed in readable form (like "128M") just as it already is for devices.

Please swap the graphics cards. I want to see the mess (as I assume) that is generated by the BIOS to provide a minimalistic way to clean it up. There is no immediate need to upgrade PCI.EXE right now. The changes are just improving the output of the configuration dump, and don't change the core functionality.

Here's with the GeForce FX 5500 installed.

100:00.0: id 8086:7190, class 06/00/00
2  10: MEM  at e8000000..ec000000 (64M)
300:01.0: id 8086:7191, class 06/04/00
4  bus 0 -> 1
5  forwarding MMIO ec000000..edffffff
6  forwarding MEM  d8000000..e7ffffff
700:07.0: id 8086:7110, class 06/01/00
800:07.1: id 8086:7111, class 01/01/80
9  20: PIO  at f000..f00f
1000:07.2: id 8086:7112, class 0c/03/00
11  20: PIO  at e000..e01f
12  INTD -> IRQ10
1300:07.3: id 8086:7113, class 06/80/00
1400:09.0: id 1102:0004, class 04/01/00
15  INTA -> IRQ9
1600:09.1: id 1102:7003, class 09/80/00
1700:09.2: id 1102:4001, class 0c/00/10
18  INTB -> IRQ9
1900:0b.0: id 100b:0020, class 02/00/00
20  10: PIO  at ec00..ecff
21  14: MMIO at ef004000..ef005000 (4K)
22  ROM (diabled), area size 00010000 (64K)
23  INTA -> IRQ10
2401:00.0: id 10de:0342, class 03/00/00
25  10: MMIO at ec000000..ed000000 (16M)
26  14: MEM  at d0000000..e0000000 (256M)
27  ROM (diabled), area size 00020000 (128K)
28  INTA -> IRQ11

Tried version 1.1 of your tool and it actually kind of faceplanted on this.

100:00.0: id 8086:7190, class 06/00/00
2  10: MEM  at e8000000..ebffffff (64M)
300:01.0: id 8086:7191, class 06/04/00
4  bus 0 -> 1
5  forwarding MMIO ec000000..edffffff (32M)
6  forwarding MEM  d8000000..104ae7ffffff (notepad++ shows a bunch of SOH here)
700:07.0: id 8086:7110, class 06/01/00
800:07.1: id 8086:7111, class 01/01/80
9  20: PIO  at f000..f00f
1000:07.2: id 8086:7112, class 0c/03/00
11  20: PIO  at e000..e01f
12  INTD -> IRQ10
1300:07.3: id 8086:7113, class 06/80/00
1400:09.0: id 1102:0004, class 04/01/00
15  INTA -> IRQ9
1600:09.1: id 1102:7003, class 09/80/00
1700:09.2: id 1102:4001, class 0c/00/10
18  INTB -> IRQ9
1900:0b.0: id 100b:0020, class 02/00/00
20  10: PIO  at ec00..ecff
21  14: MMIO at ef004000..ef004fff (4K)
22  ROM (disabled), area size 00010000 (64K)
23  INTA -> IRQ10
2401:00.0: id 10de:0342, class 03/00/00
25  10: MMIO at ec000000..ecffffff (16M)
26  14: MEM  at d0000000..dfffffff (256M)
27  ROM (disabled), area size 00020000 (128K)
28  INTA -> IRQ11