Ark1000vl is a picky card.
While it works on my pv3 1.22, it certainly does not like each and every board out there.
Try isa vga adapter instead.

The PVI-486SP3 is tricky too.
This board may need an extra wait state for VL.
Perhaps your graphics card does not care about the setting the mainboard tells, like on my S3 Virge VL.
However, the graphics card or the graphics card BIOS has to care about it.

Instead you can try a PCI graphics card too.

We talked a bit earlier out-of-band about this; it appeared E0 is a POST code that the BIOS generates in (possibly rare?) failure situations where it doesn't beep. The BIOS shuts off interrupts and goes into an infinite loop after generating E0. The POST code 05 points to a problem with the keyboard controller's self test. Possibly bad keyboard controller or corroded/broken connection between KBC and the rest of the board.

So, jakethompson1 was absolutely right. After my friend replaced the keyboard controller, I can now boot. For some reason it doesn't like most of my VLB cards though — it won't boot with the Ark, with a Tseng ET4000/W32P and a Cirrus Logic 5428. S3 805 and S3 Trio32 are fine though, so are ISA and PCI cards.

I've noticed that the boards thinks I have no cache (says so in the POST screen) and can't boot from either HDD or floppy, so I probably have a dead chip installed or a bent pin somewhere. Another option is that the manual specifically calls for 15ns chips and I have 20ns chips installed.

I'm waiting for a bunch of Chinese 1mbit 15ns chips to arrive in a couple of days — I got 30, so I hope there will be at least 4 working ones to get 512K working on this board 😀

jheronimus wrote on 2021-11-04, 11:25:

So, jakethompson1 was absolutely right. After my friend replaced the keyboard controller, I can now boot. For some reason it doesn't like most of my VLB cards though — it won't boot with the Ark, with a Tseng ET4000/W32P and a Cirrus Logic 5428. S3 805 and S3 Trio32 are fine though, so are ISA and PCI cards.

I've noticed that the boards thinks I have no cache (says so in the POST screen) and can't boot from either HDD or floppy, so I probably have a dead chip installed or a bent pin somewhere. Another option is that the manual specifically calls for 15ns chips and I have 20ns chips installed.

As disruptor already set, the SiS496 / SiS497 chipset doesn't like VL cards that respond too fast. As I am currently working with a S3 Trio64/V+ card and experimenting with settings, I can definitely tell you that it won't work in 0WS mode. This is not a jumper choice on this card, but it depends on the BIOS you use. Most card vendors use a BIOS that sets up 1WS mode, so it is not surprising that many S3 cards work in your board.
I don't know those details about the Ark and the Cirrus card, but at least a couple of ET4000/W32 cards have a jumper to enable/disable 0WS mode, which could make them boot in your board. On the other hand, I remember using a generic CL-5426 based card in a very similar board without issues, so it might also depend on the type of Cirrus card whether they respond "too fast" for the board or not.

20ns cache chips shouldn't prevent cache detection. I have a lot of experience with different 486 boards, and I never encountered non-detection of working cache chips by them being too slow. As far as I know, the cache size detection happens with "failsafe" settings, i.e. the slowest possible cache access speed. The usual symptom of too slow cache chips is that the system crashes after printing the configuration summary box, right before printing a message like "starting MS-DOS" or "starting Windows 95". If you use slower cache chips than recommended by the manual, you might need to turn off "auto-configuration" in the advanced chipset settings and manually choose slower settings to get the system run stable. In your case, you are most likely right about having a dead or wrongly inserted chip.

the sp3 board here happily takes all vlb cards i threw at it, including the ones you mentioned, at 0ws.
it is surprising you experience this kind of problem.

I have one of these boards and although I only have one VLB card, a (Trident 9440GUI I THINK) it will post with the card but rarely boots. I've played with wait states but no difference. Works fine with PCI cards.

pshipkov wrote on 2021-11-04, 15:14:

the sp3 board here happily takes all vlb cards i threw at it, including the ones you mentioned, at 0ws.
it is surprising you experience this kind of problem.

That's interesting. Possibly VL 0WS problems were fixed in later revisions of the board or the chipset. Can you post the label of your SiS496 and SiS497 chips? Maybe you got one of the latest revisions that is also able to handle EDO DRAM? On my board, the SiS496 chip is the B4 revision, spelled as SiS496NV. The B5 revision, which supports EDO DRAM is marked as SiS496PR.

I have three of these boards and all work at 0WS with a VLB trio64V+, though they're notably picky about PCI video cards. ATI rage II cards don't seem to work at all for me.

one works with EDO but seemed unable to detect memory capacity correctly.

IIRC there was no benefit to running EDO in the chipset and it was actually a tiny performance hit due to the base chipset not having any support for it, it only worked via some BIOS trickery. but if there's a last chipset revision that added support beyond merely being able to run the EDO memory in FPM mode, I'd be curious.

libby wrote on 2021-11-04, 17:21:

I have three of these boards and all work at 0WS with a VLB trio64V+, though they're notably picky about PCI video cards. ATI rage II cards don't seem to work at all for me.

one works with EDO but seemed unable to detect memory capacity correctly.

IIRC there was no benefit to running EDO in the chipset and it was actually a tiny performance hit due to the base chipset not having any support for it, it only worked via some BIOS trickery. but if there's a last chipset revision that added support beyond merely being able to run the EDO memory in FPM mode, I'd be curious.

Looking at the "Revision 3.0 preliminary" data sheet of the SiS 496/497 chipset, the chipset is specified to run read bursts from DRAM (so this is irrelevant for L2 hits) at 2 cycles per 32 bits, whereas FPM memory runs at 3 cycles / 32 bit for 25-40 MHz host clock (CMOS settings: fastest, faster, slower), and drops down to 4 cycles / 32 bit at 50 MHz host clock (CMOS setting: slowest). So there actually is a benefit when you use EDO DRAM - if you are one of the lucky bastards owning the B5 revision of the chipset that supports EDO DRAMs. The benefit thus is 3 cycles for a 4-dword burst read (16 bytes, one cache line), because the leadoff is not affected by EDO RAM. Possibly you lose one the three gained cycles when you run back-to-back cycles to RAM, because the "EDO workaround" that tells the EDO RAM to stop delivering data, even though the page is still open takes one processor clock cycle. This cycle happens "in the background" if the memory interface is idle after the burst, so you don't always notice this "workaround cycle".