GL1zdA wrote:

Just acquired a BT-742A EISA SCSI controller (AFAIK the manufacturer is Mylex, now LSI). It also has a FDD controller. http://im […]
Show full quote

Just acquired a BT-742A EISA SCSI controller (AFAIK the manufacturer is Mylex, now LSI). It also has a FDD controller.

Although LSI does have lots drivers for it, they don't have the CFG files. But it seems here are some I could use.
For the VLB VGA i'll use a SPEA Mercury (S3 928).

Now a question (possibly stupid): should I use a normal ISA FDD controller, to run the ECU for the first time, or should it be somehow possible with the (not yet configured) SCSI controller?

The FDD part of the Eisa SCSI card should be operational so it should work but since I never used the SCSI controller you have I cannot guarantee it

OK, I managed to boot the floppy after disabling write back and external cache (odd?). There is one problem. The adapter is recognized as FUS5211 instead of the expected BUS4201 (can't even find what company used the FUS abbreviation). I forced the ECU to install BUS4201 for the slot in which this adapter sits, now it complains of course about ID mismatch. Is it still possible to run it? How should the controller manifest, that it works? (I expected something like the modern SCSI controllers do, which print something after the POST phase).

Try using a different slot. Usually on an EISA board there will be one or two slots that don't do bus mastering, and they produce annoying problems like this.

The cache problem likely is related to the fact that you are missing all three of your TAG RAMs. You will need these to use your cache.

OK. I'm finally a step further. It seems there was something with the connector. After several attempts to remove the card and put it back, it begun to recognize it as the BUS4201, installed the .cfg without any problems. Then there was apparently a problem with a broken SCSI CD-ROM, but now there is only a HDD on the SCSI bus (ID 0, with termination enabled, at the end of the SCSI ribbon). The controller sees it and displays it after the RAM test. The question is: should the BIOS somehow see the attached drives? I still get Disc C: and Disc D: as None on the screen right after the post, before booting, the BIOS also doesn't autodetect anything (My PCI SCSI cards usually install their own SCSI BIOS, and I can enter setup only after initializing the controller, but it doesn't work this way on the AMI EISA motherboard).

GL1zdA wrote on 2010-06-13, 18:38:

It seems there was something with the connector. After several attempts to remove the card and put it back, it begun to recognize it as the BUS4201, installed the .cfg without any problems. Then there was apparently a problem with a broken SCSI CD-ROM, but now there is only a HDD on the SCSI bus (ID 0, with termination enabled, at the end of the SCSI ribbon). The controller sees it and displays it after the RAM test. The question is: should the BIOS somehow see the attached drives? I still get Disc C: and Disc D: as None on the screen right after the post, before booting, the BIOS also doesn't autodetect anything (My PCI SCSI cards usually install their own SCSI BIOS, and I can enter setup only after initializing the controller, but it doesn't work this way on the AMI EISA motherboard).

O.k. new comer to the AMI Enterprise III mobo club. A few quick notes:

1. GL1zdA's missing chips are QS8888-15p cache chips. Data sheet here: https://www.datasheets360.com/pdf/-7013032174713305618.
2. This is the pickiest mobo I have ever seen regarding card insertion. Even if 1-2mm of gold fingers are showing the cards will not be properly recognized/activated. I had the same issue as GL1zdA until I pushed the card in ALL the way. I was almost ready to call it quits, as multiple EISA boards failed on this mobo, until I saw GL1zdA had the same issue as I did.
3. The EISA SCSI card works the same as any other. Once a HDD is detected on the SCSI bus the SCSI BIOS is enabled and you should be able to access the HDD. I would do the usual checks.
Is it a good drive?
Does it work in another system?
Has it been partitioned?
Does it have a file system?

Hope this helps anyone who finds the thread in future google searches.

Thanks, I will have to check if I can find these QS8888 or similar chips on my other motherboards. I hope to go back to this system, since it's the ultimate 486 I have (except for my IBM PS/2 MCA machines 😉 ).

QS8888 is a 16kx4 SRAM. I recommend installing 64kx4 if you plan on having a lot of RAM installed. These are probably relatively standard chips, so likely other brands would work too. Interestingly, these can be had as low as 8ns!!! I'd like to get my hands on some of those.

Anonymous Coward wrote on 2020-03-24, 11:36:

QS8888 is a 16kx4 SRAM. I recommend installing 64kx4 if you plan on having a lot of RAM installed. These are probably relatively standard chips, so likely other brands would work too. Interestingly, these can be had as low as 8ns!!! I'd like to get my hands on some of those.

Ah, I see, they have 14 adress lines, so indeed, 64kx4 is possible. Is there a datasheet for this chipset available? It's SiS, but I don't remember the exact parts.

I'm pretty sure the pdf manual for this motherboard is out there. AMI had it on their website until not too long ago.

*edit* I found the manual, but strangely there isn't much in there about the cache ram. It doesn't even mention the tags.

Anonymous Coward wrote on 2020-03-24, 12:52:

I'm pretty sure the pdf manual for this motherboard is out there. AMI had it on their website until not too long ago.

*edit* I found the manual, but strangely there isn't much in there about the cache ram. It doesn't even mention the tags.

I have the manual, I've backed up locally all AMI motherboard manuals 😉. Usually the chipset documentation is the best source for information about cache, that's why I asked for it.

GL1zdA wrote on 2020-03-24, 16:06:

Anonymous Coward wrote on 2020-03-24, 12:52:

I'm pretty sure the pdf manual for this motherboard is out there. AMI had it on their website until not too long ago.

*edit* I found the manual, but strangely there isn't much in there about the cache ram. It doesn't even mention the tags.

I have the manual, I've backed up locally all AMI motherboard manuals 😉. Usually the chipset documentation is the best source for information about cache, that's why I asked for it.

My 2 cents:
The cache should not be touched on that mainboard. It was 256kB, there is no option to downgrade or upgrade.
The question is: Why did some ***** remove the tag rams, when the board is still working, that's a mystery to me.

CoffeeOne wrote on 2020-03-24, 16:24:

My 2 cents:
The cache should not be touched on that mainboard. It was 256kB, there is no option to downgrade or upgrade.
The question is: Why did some ***** remove the tag rams, when the board is still working, that's a mystery to me.

I agree. This is one finicky board for a workstation/server class product. I don't think it is very hacker/power user/customization friendly. In fact most EISA boards were not. They were designed to run stably for ever as long as you followed the directions 😉

I have 256MB of RAM ready to go into my system. Once I do I can give an update as to any detrimental effect only 256K of cache has. As a reference my Systempro/XL has 512MB of RAM but only 256KB of cache and I haven't noticed any issues (yet).

Out of curiosity are you guys going EISA SCSI, VLB SCSI, or VLB IDE for the storage subsystem? I have a AMI Series 44 Cached controller but finding SCSI HDD is getting harder/more expensive so I am going with a cached VLB IDE controller with 4 matched IDE drives in RAID 0+1. Should be interesting. 😁

Just wondering if anyone has an update BIOS for this beasty? I fond one firmware dated 06/30/1993. This was about 3 months later then the one that came on my motherboard. Before I flash it does anyone have a later BIOS? TIA!

I think it's the last found, didn't find any newer one (it's from an archive called s68bios.zip).

GL1zdA wrote on 2020-03-30, 10:56:

I think it's the last found, didn't find any newer one (it's from an archive called s68bios.zip).

That is the one I have. Ok. I am going to have to do this the hard way.... The board is throwing Memory Parity errors for me when I try to boot to DOS and even sometime with going to the BIOS. This only happens when I put in 192MB of RAM and more frequently when I go all the way up to 256MB of RAM. At 64MB and 128MB the system seems solid. So basically when you have 12 or 16 sticks of RAM in there is when problems show up. Strangely I have ran MEM-TEST for over a day with 192M in and got one error in 5 passes and then again with the same 12 sticks with an additional four (total 256MB) with no error. Swapping memory around has not helped (I have a total of 20 sticks). I tried testing the memory in my SIM-CHECK II but it does not like the sticks. I am trying to get the firmware updated and see if that helps so I can test individual sticks. In the mean time I am thinking the following:

1. Bad Sticks (unlikely)
2. Bad memory slots (I hope not)
3. Bad motherboard (I really hope not and seems unlikely)

Of course 1 is the only thing I can fix. With 2 I could always limit myself to 128MB of RAM which is more then enough of course but not as cool! At 3 I am screwed but I have hope given the fact that board seems stable with only 8 sticks in use.

There is a fourth choice: power. The MB is using a 430W PSU (I forgot the brand but it actually was a decent one). However, this mobo uses THREE power connectors. It will work with two but I am wondering when you start loading it up with memory and a high powered VLB card if it isn't having little fluctuations causing parity errors. The third power is three ground and three 5V rails. I am wondering if I could use a second PSU to supply power on the third connector and see if it make a difference or take power from a FDD/HDD power output on the same PSU. Thoughts anyone?