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

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.

All I see on that page about 64 megs is this "AGP 2× Mode (max aperture size 32 or 64 MB)"

That line of text has NOTHING to do with the amount of VRAM on the card.

pete8475 wrote on 2023-01-22, 01:39:

All I see on that page about 64 megs is this "AGP 2× Mode (max aperture size 32 or 64 MB)"

That line of text has NOTHING to do with the amount of VRAM on the card.

It was literally just changed by another user here if you would read the thread.

Revolution wrote on 2023-01-22, 02:02:

It was literally just changed by another user here if you would read the thread.

Yes. mkarcher sat next to me and just has read before in the Intel 440 BX datasheet.

Revolution wrote on 2023-01-22, 01:22:

Tried version 1.1 of your tool and it actually kind of faceplanted on this. […]
Show full quote

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

Copy code to clipboard

1  forwarding MEM  d8000000..104ae7ffffff (notepad++ shows a bunch of SOH here)

weird

Revolution wrote on 2023-01-22, 01:22:

Tried version 1.1 of your tool and it actually kind of faceplanted on this. […]
Show full quote

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

Copy code to clipboard

1  forwarding MEM  d8000000..104ae7ffffff (notepad++ shows a bunch of SOH here)

OK, thank you for your report! You obviously found a bug I missed. I am going to fix that ASAP. The 1.0 output is enough to evaluate the situation.

EDIT: formatting fix

Revolution wrote on 2023-01-22, 01:14:

[…]
Show full quote

Copy code to clipboard

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

Copy code to clipboard

101:00.0: id 10de:0342, class 03/00/00
2  10: MMIO at ec000000..ed000000 (16M)
3  14: MEM  at d0000000..e0000000 (256M)

Exactly. That's the issue. See how the area d8000000.e7ffffff (forwarded range) doesn't fully contain d0000000..dfffffff (graphics memory)? Both areas are actually 256MB big, so my description that "the bridge is set up to forward a fixed 128MB area" was obviously wrong. Nevertheless, the core reason of the issue is that the BIOS code was written under the assumption that no secondary bus would ever need more than 128MB, and the BIOS assigns a start address of D8000000 to the AGP area, before even looking at the card installed in that port. A card that requires 256MB address space can only be set to D0000000..DFFFFFFF or E0000000..EFFFFFFF, so it can not be configured to start at D8000000 at all. IIRC the BIOS tries to assign D8000000..E8000000 to that card, but the card is just ignoring the "8" in the second digit (not because it is stupid or broken, but because that's how the bevaiour of cards requiring 256MB address space is specified by the PCI specification). I checked your dump, and it seems nothing is allocated to the D0000000..D7FFFFFF area. So adjusting the forwarding address start to D0000000 will fix that issue. I decided to also set the end address to DFFFFFFF, although also claiming the unused E0000000..E7FFFFFF range wouldn't hurt on your system.

Please invoke

1pci 06/04/00 24=dfffd000

from a "command prompt only" environment and try starting the Windows 98 GUI (using "win") afterwards. If that fixes your issue, put that line into autoexec.bat.

mkarcher wrote on 2023-01-22, 09:59:

Exactly. That's the issue. See how the area d8000000.e7ffffff (forwarded range) doesn't overlap d0000000..dfffffff (graphics memory)? Both areas are actually 256MB big, so my description that "the bridge is set up to forward a fixed 128MB area" was obviously wrong. Nevertheless, the core reason of the issue is that the BIOS code was written under the assumption that no secondary bus would ever need more than 128MB, and the BIOS assigns a start address of D8000000 to the AGP area, before even looking at the card installed in that port. A card that requires 256MB address space can only be set to D0000000..DFFFFFFF or E0000000..EFFFFFFF, so it can not be configured to start at D8000000 at all. IIRC the BIOS tries to assign D8000000..E8000000 to that card, but the card is just ignoring the "8" in the second digit (not because it is stupid or broken, but because that's how the bevaiour of cards requiring 256MB address space is specified by the PCI specification). I checked your dump, and it seems nothing is allocated to the D0000000..D7FFFFFF area. So adjusting the forwarding address start to D0000000 will fix that issue. I decided to also set the end address to DFFFFFFF, although also claiming the unused E0000000..E7FFFFFF range wouldn't hurt on your system.

I wonder if you could help us resolve Re: Not Another Ultimate Windows 98 Build . The issue is AGP aperture is not functional on Athlon 64 boards in Windows 98 on newer BIOSes. Windows XP is not affected. The issue was narrowed down to BIOS and affects multiple boards. It seems that this bug causes VIA AGP driver fail to initialize properly and AGP then behaves as PCI.

Revolution wrote on 2023-01-22, 01:22:

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

I released Version 1.1a, which should fix the output. I would appreciate feedback whether the fix works as intended.

mkarcher wrote on 2023-01-21, 16:53:

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.

That's pretty interesting. Thank you for the explaination!😃👍

Great work!
I remember that we had the same "memory allocation" problem a bunch of years ago with the GeForce 6800 ultra on Super Socket 7 Board. I can't find the thread right now but I guess it must be around somewhere.
I am curious if your tool can fix this and might set up a test rig to test it.

yeah i consider the 440bx to be the best chipset for slot1. although it doesn't official support for 133fsb, slot1 pentium3s @ 133fsb are not that common, so this requirement is unnecessary for me.
one can also try finding the abit sh6, which has 815e chipset. it is slightly slower than the 440bx and supports up to only 512mb of sdram, but it has proper 133fsb, agp4x and dma100 ide.

The most notable issue using 133 MHz FSB on a motherboard with the 440BX chipset is that the AGP bus gets overclocked to 89 MHz and a decent amount of video cards can't handle it. Also, most motherboards with the i815e chipset (including the Abit SH6) doesn't have ISA slots for the most ideal DOS compatibility.

mkarcher wrote on 2023-01-22, 09:59:

Please invoke […]
Show full quote

Please invoke

Copy code to clipboard

1pci 06/04/00 24=dfffd000

from a "command prompt only" environment and try starting the Windows 98 GUI (using "win") afterwards. If that fixes your issue, put that line into autoexec.bat.

Happy to report that command worked as intended! I was able to get into Windows 98 with no conflicts, set the desktop resolution, and open and run Arx Fatalis with only that game's usual graphical issues.

As well, version 1.1a of your tool seems to have fixed the bugs, here's its output.

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..e7ffffff (256M)
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

Revolution wrote on 2023-01-22, 19:08:

Happy to report that command worked as intended!
[...]

As well, version 1.1a of your tool seems to have fixed the bugs, here's its output.

Thanks for the positive report. The issue we worked around in this thread is likely very widespread on Socket 7 and Slot 1 boards with AGP slots. It doesn't apply to PCI graphics cards, as they are located on the primary bus, so there is no issue with bridge configuration.

noshutdown wrote on 2023-01-22, 18:46:

yeah i consider the 440bx to be the best chipset for slot1. although it doesn't official support for 133fsb, slot1 pentium3s @ 133fsb are not that common, so this requirement is unnecessary for me.
one can also try finding the abit sh6, which has 815e chipset. it is slightly slower than the 440bx and supports up to only 512mb of sdram, but it has proper 133fsb, agp4x and dma100 ide.

i840 is actually the best one if everything except availability is considered. It has superb RAM speed, AGP 4x, proper 133 MHz FSB support and is faster than BX (not by much to be fair) etc. But, motherboards with it are extremely rare.