unfortunately I didn't manage to get it working, the device number was easy to find but,
I can only boot from the hard drive (dozens of floppy disks and the few drives I have are not working anymore), no support for boot from usb and so on...

so I had to load the autoexec from C:, the best I could get after failing to see any video and back to the voodoo was that it kept repeating this and the windows starting screen (same hard drive noise as with the 8400gs, so I'm sure it was doing the same).

Starting cmain () ... Will boot MS-DOS 7.x from drive=0x80, partition=0x0(hidden sectors=0x3f)

I tried a few different things, but I'm out of ideas for the moment

SPBHM, I think I totally messed up on my assumption that you have a floppy drive in your ASUS P2B system and booting to DOS from a boot floppy. I also assumed that you only have Win98 in your hard disk's primary partition. So I need to get somethings straight.
a) Since you don't have a floppy, I will make up a bootable ISO file (emulating floppy boot to DOS) which you can then burn to a CD and set your system to boot from CD.
b) Can you clarify on the number of hard disks, partitions and the OS details for your P2B system.
c) The commands in the AUTOEXEC.BAT are for your system with 8400GS only. It should never be used when Voodoo is inserted in your system.

Since IO.SYS is common for both Win98 and MS-DOS at the time of loading, the chainloader command i used in the AUTOEXEC.BAT was trying to load MS-DOS again and again from the primary partition instead of Win98(which was my intention and based on the assumption that Win98 is installed in the primary partition, i.e C drive).

I thought it might be the cause of the problem, booting from CD (emulating a floppy disk image) is definitely possible, floppy disks unfortunately not

it's pretty straight forward, I have a standard install of windows 98se on C:, the only other thing is another partition d: but nothing relevant, also I can run a CD drive.

to load "dos" I just basically run a different autoexec.bat, and for PCs with boot from usb support (like the Sempron) I have the usb drive formated for that with command.com, io.sys and msdos.sys I got from the 98 boot disk (downloaded from somewhere else, as I said, all my dozens of floppy disks and over 5 drives are all bad, pretty depressing actually 🤣),

I've downloaded an iso with the emulated boot disk in img format, I think it's just a question of replacing it with an edited img file with the files you provided (with x changed to 0B), I will give a go later and come back, just have to find the right tools for that,

edit: no success so far, I've created it using magiciso, also made a disk image with the files (based on a win98 boot disk) and it looks like it loaded, reading the CD, after that the hard drive, but it seems to stop at some point and there is no video.

SPBHM, It will be better if we take it step by step.
First let us check the chain loading part with proper display. So let us try this only with Voodoo card inserted. What we want to verify is,

1)Boot to DOS(not from hard disk, but from floppy by emulation) which will give 'A' prompt.
2)From 'A' prompt, we then load Win98 in the existing Hard disk by chain-loading as follows:
a)Run Grub.exe which will display a colorful menu list for search and load of various OS's, Live CD etc.
b)Select the 4th option on the list(load IO.SYS of Win9x/ME) which should boot to Win98 if everything goes well.

Once the above part is through, then we will concentrate on the 8400GS PCI resource allocation.

I have attached a 'DOS' ISO for the above requirement, if you need it.

yes it works, it loads windows 98 after choosing the option.

SPBHM, now that the chainloading part has been taken care of, let us concentrate on the 8400GS.

It will be better if we first try inserting the 8400GS in another PCI slot without disturbing the Voodoo card in its current slot that we can have the display to show the results of the commands that will be entered. There is a program named "PCI" along with "PCIDEVS.TXT"in my earlier attached ISO, which if run will display all the device details one by one. Can you run it and see whether the PLX PCI bridge and the 8400GS PCI are being listed? Since the PCI program is old it might not list the cards by its name, so you have to identify them by their vendor and device id's during the program's output. If they don't get listed, then we are in trouble as there might be hardware incompatibility.

it only detects the Intel devices and the Voodoo card, nothing related to the 8400GS.

That is weird, as in my case the onboard PCI bridge and GPU were getting listed but with no resources assigned and in a disabled state. I checked the Asus P2B manual, it was showing compliance to PCI 2.1 spec (mine is PCI 2.2 compliant). But I guess, it should not be a problem and I'm presuming you have the latest BIOS.
1) Does the heatsink on the graphics card even get warm indicating something is alive?
2) Does the Graphics card manufacturer's product specs mention anything about PCI version compliance?
3) Can you send a copy of the BIOS, i will try to dissect it and see if anything comes out of it.

well, it looks like your problem was not the same I'm facing with the P2B

the 8400GS will barely get any warm, but I would say it's a little bit over the temp with no power, the fan also spins as expected.
I'm using a bios from 1999, pre Coppermine I think!

but I also tried the bios from 2002 (the official, not the beta, which only adds Tualatin support I think) and it didn't change anything with the 8400GS (always invisible for tools like pcitool and the other you provided, and without the voodoo with the "no video" beeps from the MB)
yes this motherboard is PCI 2.1, as for the graphics card specifying a minimum requirement, it's very clear on the 8400GS box "PCI 2.1 Compliant slot",

I'm going to attach the bios I'm using for the P2B (1008A), it's a shame it didn't work so far, it would be very interesting to compare with the voodoo on Expendable for example, but many thanks for the effort you put into trying to make it work!

Nah, quite the reverse. I should thank you for all your efforts. I will update if I have something.

SPBHM wrote:

well, it looks like your problem was not the same I'm facing with the P2B

SPBHM, I found a probable reason why the 8400GS doesn't work with Asus P2B. As per PCI specifications(2.3 & above),

Revision 2.3 is an evolutionary change to the PCI Local Bus Specification. Revision 2.3 makes a significant step in migrating the PCI bus from the original 5.0 volt signaling to a 3.3 volt signaling bus.

Asus P2B motherboard, being PCI 2.1 compliant, does not need to provide 3.3V to the onboard PCI connector as it was probably optional under 2.1 spec, which is needed by the 8400GS PCI (compliant to 2.3/3.0 spec). I found two interesting references(one is japanese for which I got some translation) to substantiate it,
Reference 1:
http://log.shipweb.jp/?mode=datview&board_nam … hread_id=169724
Translation of entry '152':
EVGA 8400 GS PCI compatibility report:
Hardware prerequisites met with no (not receiving 3.3 V PCI)
Aopen AX6BC
Tekram P6B-A4X
Tekram P6B40D-A5
EPoX EP-6BXA-M
ASUS P2B-AE
ASUS P2B-F
ECS P6BX-MS

Reference 2:
http://www.tomshardware.com/forum/128405-28-card-motherboard

I intend to measure the availability of 3.3 V in any one of the pins (A21, B25, A27, B31, A33, B36, A39, B41, B43, A45, A53, and B54) on my motherboards's PCI slot later tonight. If it is available in mine and not in yours, then that might be it. One thing to be noted is the possibility of the BIOS disabling the PCI slots, if unused, in which case it will be slightly difficult to measure the voltage levels.

If the above is proved and if you are feeling adventurous, a hardware hack to extend the 3.3V (say from the unused AGP ver 1.0 slot ) might be a solution and surely you will know the usual risk factor. I once did a hack in the motherboard's power connector on my ECS mainboard and it was successful.

Edit: I couldn't measure the voltages properly as I was in a hurry leaving station for another 3 days and will not have access to the P3 system. From what little I observed, there was definitely some non-zero value in those 3.3V pins. Once I go back, I will measure them properly and also check the continuity of all the 3.3V pins.

Edit2: All the pins mentioned above except A53(0.6V) & B54(4.9V) indicate 3.3V and most of them seem to be in parallel.

I think this must have been discussed before a lot of times. Just wanted to share the youtube experience I had with my P3 system(specifically).

Result:

Smooth Flash video(Youtube) playback at Full HD in Full Screen with an average of 25 FPS (occassionally varying between 24 to 26) with negligible/few dropped frames courtesy of GPU acceleration (under laboratory conditions).

Frame Drops:

At best, they were almost nil and few times they were in single digits. At worst, there was a frame drop of 3.2%. I guess it all depended upon the other running processes, hard disk access, simultaneous streaming and rendering over the pci bus etc.

Test Conditions(Though some may not be relevant):

a) Clips used - 10 min clip - Big Buck Bunny; 2 min clip - BBB loves CC
b) Browser used - IE8 and Firefox 28.0
c) Flash version - 13.0.0.182(both ActiveX control & Plugin)
d) Internet connection speed - Relatively poor @ 3 to 4 Mbps on an average.
e) NO multitasking(as if it needs telling, didn't even touch the computer table)
f) No overclocking of CPU or GPU
g) VIA Chipset Hostbridge Tweaks - Maximum (AFAIK)
h) GPU and Internet connection(USB data card) both on the PCI bus
i) Northbridge to Southbridge link also over the PCI bus with no hub architecture or any dedicated link.

Method:

1) Immediately switched to full screen.
2) Paused(not necessarily required). I had to do this because of the poor internet speed.
3) Selected 240p resolution and let it buffer and then played it.
4) Waited till the 'video fps' stabilized at around 25 FPS and changed the resolution to 1080p
5) After a slight initial hiccup and some dropped frames probably due to switch to proper 'Full screen' (without any controls and mouse), I got the above result. The dropped frames were counted after the above initial hiccup which normally ran in many tens of frames.

It seemed that even the 'few' dropped frames (i.e without counting the initial hiccup) will not be there at the time of playback if the buffering had been full. If I change the resolution from Auto to 1080p in the window itself and then switched to Full screen, I get around 3 FPS on an average(720p=7 FPS; 480p=16 FPS; 360p=21 FPS).

Funny it seems that the system needs to warm up by getting to play low resolutions first to reach the optimum level before it can be stressed with Full HD resolutions. Or is it that the graphics subsystem (shaders and stuff) gets programmed properly if low resolutions are selected first before moving up the ladder.

Sorry for that, I'll throw in something from my own experience:
stock zotac gf430 pci, slot with 2 nothes, so it should support 3,3V & 5V slots, even 66MHz i think. No requirements about pci specs..
In subject of voltages of pci bus spec 2.3.
I tested this card in my stock hp xw8600, 1x legacy PCI 32b/33MHz, 1x PCI-X 64b/133MHz-this slot is auto adaptative: from legacy 32b/33MHz to pci-x 64b/133MHz:
32b/33Mhz legacy pci, only 5V - no boot - bios beeps indicates no vga adapter
pci-x with both 3,3V/5V ( 2 nothes) cards support - bios beeps indicates no vga adapter.
Also checked in compaq ap550 '98 workstation, as above, no boot, no screen, no beeps etc.
So i think, it is not a pci rev. issue, maybe (incompatible) vesa bios extensions?

Callahan wrote:

Sorry for that, I'll throw in something from my own experience: stock zotac gf430 pci, slot with 2 nothes, so it should support […]
Show full quote

Sorry for that, I'll throw in something from my own experience:
stock zotac gf430 pci, slot with 2 nothes, so it should support 3,3V & 5V slots, even 66MHz i think. No requirements about pci specs..
In subject of voltages of pci bus spec 2.3.
I tested this card in my stock hp xw8600, 1x legacy PCI 32b/33MHz, 1x PCI-X 64b/133MHz-this slot is auto adaptative: from legacy 32b/33MHz to pci-x 64b/133MHz:
32b/33Mhz legacy pci, only 5V - no boot - bios beeps indicates no vga adapter
pci-x with both 3,3V/5V ( 2 nothes) cards support - bios beeps indicates no vga adapter.
Also checked in compaq ap550 '98 workstation, as above, no boot, no screen, no beeps etc.
So i think, it is not a pci rev. issue, maybe (incompatible) vesa bios extensions?

Sorry for the delay. I lost my PC internet with the switch over from XP to Linux recently and on a learning curve(steep, hoperfully) and restricted to mobile internet only at pitiful speeds. So I will keep the reply short. I'm surprised that a modern card didn't get detected properly in a relatively modern system. Are you game for some troubleshooting in your HP workstation with the Zotac GPU? I would love to know the limits of a pinnacle PCI graphics setup 🤣 on a PCI-X 66 MHz bus supported by the GT 430 PCI.

Today i checked that card is completely dead, no not detected. Checked pci slots with old matrox millenium-runs fine.
Next I ran the card together with another pcie vga and under win xp64 no new device shows up. I will send this card back. Brand new.

I learned some interesting things about pci-e to pci bridge, zotac used a plx PEX 8112 bridge. This chip is from one side legacy pci 33MHz or 66MHz ( but not pci-x) and other side is pci-e x1.
So MAX throughput is when using with legacy pci at 66MHz - 266MB/s

Bridge is compatible with ALL 3,3V & 5V pci. Revisions of legacy pci:
http://en.wikipedia.org/wiki/Conventional_PCI
bridge:
http://www.plxtech.com/products/expresslane/pex8112

So not much help until the card returns operational.

A pity really then. Good luck in getting back a functional unit.

An update:

I went about installing Lubuntu 14.04 (dual boot with XP) to find out if anything works better (or as expected normally) in my system using nvidia binary driver(304 version). I chose this path thinking that I might be able to get some improvement by setting the framebuffer memory from 'uncachable' to 'write-combining' which is easily possible in Linux. Still working on this. Parallely, started some benching in increasing terms of complexity.

1. Installed mesa-utils and tried glxgears. Got approx. 2200 and 761 FPS in window and full screen mode respectively.
2. Then tried phoronix test suite (nexuiz & unigine-heaven) for some native benchmark. nexuiz at 800x600 (and everything off) gave some 16 FPS.
3. Then I installed wine and tried Quake 3,being an OpenGL game hoping for less overhead by means of less API calls translation. It gave some 40% less FPS in timedemo mode compared to XP.
4. Next one was Final reality (DirectX). None of the tests were running expect for the 2D & 3D bus transfers. The results I got was around 148 MB/s(unrealistic as theoretical PCI BW is 133MB/s) and 45 MB/s respectively against 15.34 & 19.28 MB/s I got from WinXP.

.
I tried to install steam client for Linux to try some native linux games which are also available in Windows for comparison. I hit a major roadblock in the form of SSE2(lack of) which is mandatory in Linux but not needed in WinXP. Considering these lightweight distros are there for low hardware spec. systems, it is a pity that there is no fallback for lack of SSE2. Recently released Opera 21 which boasts of complete hardware acceleration will also not install on mine probably due to the same reason. This need for SSE2 support is trying its best to drive me mad.

I always found that graphic stuff was faster in Windows compared to Linux.

feipoa wrote:

I always found that graphic stuff was faster in Windows compared to Linux.

That's probably because most games were designed for windows... and thus they run natively. In linux it all has to be emulated through emulation layers, before the games even run in the first place, thus slower.

When I wrote that sentance, I did not have games in mind. I was actually reflecting back to my experience with web browsers, like Firefox and Opera. To me, images, videos, and scrolling through text on a browser window is "graphic stuff".