VOGONS


First post, by jheronimus

User metadata
Rank Oldbie
Rank
Oldbie

Hi, all

So I'm trying to resurrect this board, but it won't beep or produce any video. The POST card shows codes E0 and 05.

A bit of backstory here: the previous owner tried to test it but plugged the BIOS chip the wrong way and burnt it. When I got the board, I flashed a new chip and tried to turn it on which resulted in the U8 transistor burning as well. I can't remember the original part, but I replaced it with a TIP127 transistor because it's actually silkscreened as one of three options on the board. Another detail is that two of the cache chips on the board were replaced, so there must have been an issue there.

The board does start to beep when I remove the RAM, so I assume it is working, I'm just missing something (hopefully) obvious here.

The board revision is 1.22, I've tried flashing BIOS versions 3.06, 3.05 and 2.05 (supposedly 1.22 should be compatible with 3.06, but still). The chip used is Atmel AT29C010A, the board is setup for 5v flash chips.

I'm using an Ark Logic 1000VL videocard and 2x16MB of FPM RAM that I know to be working.

Here's what I've tried so far:

1) Three different CPUs: Intel DX4 (WT), AMD DX4100 (WT), Cyrix 5x86-100
2) Three different pairs of FPM RAM, both 2x16MB and 2x4MB
3) Replaced all cache chips. It's still 256KB, just 25ns instead of 15ns (didn't have 15ns chips handy)
4) Reflashed BIOS five times, three different versions

Nothing but CPU, RAM, videocard and POST card are plugged in.

Last edited by jheronimus on 2021-10-30, 03:29. Edited 1 time in total.

Reply 2 of 10, by Disruptor

User metadata
Rank Oldbie
Rank
Oldbie

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.

Reply 3 of 10, by jakethompson1

User metadata
Rank Oldbie
Rank
Oldbie

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.

Reply 4 of 10, by jheronimus

User metadata
Rank Oldbie
Rank
Oldbie

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 😀

Reply 5 of 10, by mkarcher

User metadata
Rank Oldbie
Rank
Oldbie
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.

Reply 7 of 10, by Jasin Natael

User metadata
Rank Member
Rank
Member

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.

Reply 8 of 10, by mkarcher

User metadata
Rank Oldbie
Rank
Oldbie
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.

Reply 9 of 10, by libby

User metadata
Rank Newbie
Rank
Newbie

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.

Reply 10 of 10, by mkarcher

User metadata
Rank Oldbie
Rank
Oldbie
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".