VOGONS


First post, by mkarcher

User metadata
Rank l33t
Rank
l33t

Acer sold a Graphics / SCSI combination card for their M11E system. The documentation for this SCSI/VGA combo card is available at manualslib. It is quite sparse, and interesting enough, it does not mention the name of the manufacturer anywhere in the document itself ("(C) 1998 by this company"). The card is not fully PCI compliant and specifically built for the M11E.

While PCI is a bus, some pins needs to be individual per device, so you can't just connect an AIC-7880P and an ATI Rage Pro to the same PCI edge connector. You need individual IDSEL#, REQ# and GNT# pins. The first one is needed on all devices, the latter two pins are required on master-capable devices only. Both the Rage and the AIC are master capable, though. The IDSEL# is the most delicate signal in this scenario: When the CPU lists the PCI devices to detect the required drivers assign resources to them, it needs a way to address devices individually. That's what IDSEL# is for. A card only responds to configuration attempts, when the slot-specific IDSEL# pin is active. To save pins on the Host/PCI bridge, the designers of that bridge used the fact that address signals A8 to A31 are not used during card configuration. Only A2 to A7 select a configuration register. So the Host/PCI bridge activates just one of the address signals A8 to A31 depending on the "slot" (aka "device") number of the device the processor currently tries to configure. The mainboard manufacturers just route a different single address line to IDSEL# at each slot, and the system works fine. There is no standard how "device numbers" and selected address lines are corellated.

This card has the Adaptec chip correctly wired to IDSEL# at the PCI slot, so the SCSI part works perfectly specification conforming. REQ#, GNT# and INTA# are also connected as required for standard operation of the Adaptec chip. On the other hand IDSEL# of the ATI Rage chip is connected to A21. On the SiS 496 board I tried this card in, this line is mapped to device ID 9. The shared PCI/ISA slot has its IDSEL# signal wired to A21, too. So the graphics chip appears to be on a card plugged into the shared slot. If that slot actually contains a PCI card, the chip on that card and the ATI chip cause a bus conflict during configuration. The REQ# and GNT# pins are not connected to the ATI chip at all (there are solder pads for 0-ohm resistors to add those connections, though), but you can't interrupt the connection of REQ# and GNT# to the adaptec chip by removing 0-ohm resistors. Without driver tricks or cutting traces, you can't get bus mastering of the ATI chip (even when adding the 0-ohm links) at the same time as the SCSI chip is active. This basically means any driver that relies on busmastering (either for texturing or for command transfer) will fail to work. The same is true about the interrupt: The interrupt output from the ATI chip is connected to a non-installed zero-ohm link that could connect it to INTA# at the slot.

Getting the interrupt to work would be require hacks, too: If you set JP4 to "enable VGA interrupts", the ATI chip claims to be connected to "INTA#". It's the job of the BIOS to find out what PCI interrupt line this corresponds to. The mapping of INTA# at the slot and the PCI/Host bridge interrupt pin is different per slot to distribute PCI interrupts from the card to differnt vectors. Unless the BIOS knows that the ATI chip is actually in the same slot as the Adaptec chip, although the ATI chip appears at a completely unexpected device ID, it can't properly inform the ATI chip about the IRQ routing. So this basically means: Leave JP4 in position 2-3, so the ATI chip doesn't claim an interrupt. Making the card interrupt-capable for the graphics part is way more complicated than just setting the jumper to 1-2 and installing the 0-ohm link to connect the ATI interrupt output to the PCI bus.

The other jumpers on that card make some more sense. JP2 can be used to disable the ATI chip completey. In that case, the card just behaves like an OEM edition of the Adaptec 2940UW. The OEM edition uses device ID 7880 instead of 7881, and doesn't support in-system flaching of the SCSI BIOS. More about that later. JP3 toggles the bootup mode of the ATI chip. In default position 2-3, the ATI chip enables it's VGA compatible interface on reset, and reports to be a VGA device. In the non-default position, the VGA-compatible interface is disabled, and the class changes from 03:00:00 to 03:80:00 (vendor-specifc graphics device). It will go back to 03:00:00 if the VGA part is enabled, though. The idea is that you can use the ATI card using an ATI driver that doesn't need the VGA resources as secondary card when you jumper it to "non-VGA mode". In case you jumper the card to non-VGA mode, the VGA BIOS gets treated as "non-VGA PCI option ROM", which is initialized later in the bootup sequence. Also, the ATI chip is activated and the ROM is invoked even if another graphics card (e.g. on the ISA bus) has already been found and initialized. The standard ATI ROM then activates the ATI chip in VGA compatible mode, which it will conflict with other VGA parts. One way to deal with it is to pull the VGA ROM from that card, but another way is to set jumper JP1 to 1-2 (again, 2-3 is default). When JP1 is set to 1-2, and the VGA compatibility is disabled, the last 8K of the BIOS ROM is mirrored across the whole ROM address space. This also makes the ROM unusable for the mainboard BIOS, so it doesn't call it. The original idea might have been that the last 8K of the ROM contains a kind of parameter table meant for an ATI driver.

The SCSI part has a PLCC-32 ROM socket which is shipped empty. The original M11E system has the SCSI ROM integrated in the mainboard BIOS. The PLCC-32 socket is compatible with 27C256 ROMs. It will also accept 27C512 ROMs, but the extra address pin is grounded, so only the first half is used. The PLCC-32 socket is incompatible with 29ee512 flash chips. The Winbond flash chips W27E256 / W27E512 (later renamed to W27C256/W27C512) use the 27C256 compatible pinout and work. The combo card does not support in-system flashing on the hardware level, so there is no point in trying to hack the Adaptec flashing tool accept that card as target device (i tried...). To use the SCSI part of the combo card in a non-Acer system, you thus need a 27C256-compatible PLCC32 ROM chip (in my case, I used a W27C512), a programmer (possibly using an adapter) to program that chip and an image that fits into 32K. You can find a BIOS image for the Asus AIC-7880 card (another Adaptec-based OEM card) on the internet, and its image is 64KB, but it is the same 32K repeated two times. This image will work out-of-the-box. A non-OEM BIOS would need to be patched for the different PCI device ID. Patching that BIOS is made more complex by the architecture of the Adaptec BIOS: Just like most PCI mainbaord BIOSes, the actual BIOS contents is LZH compressed, and the "Get the expected device ID" function that you need to patch is in the compressed runtime part.

I tried with the 40K image for an original 2940UW first, because I didn't know about the addressing limitation. Neither the mainbaord BIOS verified the option ROM checksum, nor the Adaptec decompressor verified the CRC of the extracted runtime BIOS. The result was a broken BIOS that worked fine until you tried to enter SCSI Select, because SCSI Select is the last part of the BIOS, and the only part that was contained in the unreachable 8KB that the 40K image exceeds the 32K addressable range. Interestingly, the AIC-7880P chip claims a 64KB range for the PCI option ROM, but seems to provide only 15 decoded address lines, which is only good for 32KB. The non-OEM 2940UW thus has a dedicated PAL chip that provides a latched A15 bit, and probably also helps to support write cycles to the flash ROM. The OEM cards are not designed to have PAL like this installed. No Adaptec card supports high voltage flashing, so flashing a 27c256-like chip is generally impossible. Flashable Adaptec cards always use 29C512-like chips that can be flashed with 5 volt supply. Those chips have a different pinout than the 27C256-like chips. For DIP chips, it's just four extra pins at the pin1 edge, so you can build a combination socket for a non-updateable 27c256-like chip or an updateable 29c256-like chip. The PLCC variant of those chips is in 32-pin packages in both cases, but there pinout is no easily adaptable. A flashable Adaptec-based controller with a PLCC-32 ROM thus needs to use the different pinout of the 29-series chips and is a different in this regared compared to this combo card.

A final pecularity about this card: It refused to negotiate Ultra speeds with a Seagate Cheetah hard drive until "Ultra Speed" had been disabled and re-enabled in SCSI select. After doing so, the card achived around 30MB/s in an Apollo Pro based Pentium 3 system, and around 25MB/s in a SiS-496 based 486 system (measured using SPEEDSYS). With Ultra SCSI disabled, I was stuck at 17MB/s, which is fine for non-ultra wide SCSI.

Reply 1 of 3, by rasz_pl

User metadata
Rank l33t
Rank
l33t
mkarcher wrote on 2022-12-21, 22:57:

To save pins on the Host/PCI bridge, the designers of that bridge used the fact that address signals A8 to A31 are not used during card configuration. Only A2 to A7 select a configuration register. So the Host/PCI bridge activates just one of the address signals A8 to A31 depending on the "slot" (aka "device") number of the device the processor currently tries to configure. The mainboard manufacturers just route a different single address line to IDSEL# at each slot, and the system works fine. There is no standard how "device numbers" and selected address lines are corellated.

I love learning new old things!

mkarcher wrote on 2022-12-21, 22:57:

ATI Rage Pro
you can't get bus mastering of the ATI chip (even when adding the 0-ohm links) at the same time as the SCSI chip is active. This basically means any driver that relies on busmastering (either for texturing or for command transfer) will fail to work.

Afaik a lot of graphic chips supported bus mastering in theory (another one is S3), but in practice it turned out to be too complicated (and probably slower) so nothing used it.

mkarcher wrote on 2022-12-21, 22:57:

The same is true about the interrupt: The interrupt output from the ATI chip is connected to a non-installed zero-ohm link that could connect it to INTA# at the slot.

While graphic interrupt was standard for EGA, VGA seems to have dropped the idea with most ISA VGA cards either not supporting it at all or having it optional behind a jumper. I dont know how the situation looks like for PCI graphic cards and if its used at all. Most were programmed using memory mapped registers anyway and software pooled busy/idle status this way.

https://www.os2museum.com/wp/fantasyland-on-vga/

Open Source AT&T Globalyst/NCR/FIC 486-GAC-2 proprietary Cache Module reproduction

Reply 2 of 3, by luckybob

User metadata
Rank l33t
Rank
l33t

I got one of these cards a while back for a pittance. I always knew they were acer specific. It's nice to know the eeprom socket was supposed to come unpopulated.

It is a mistake to think you can solve any major problems just with potatoes.

Reply 3 of 3, by mkarcher

User metadata
Rank l33t
Rank
l33t
luckybob wrote on 2022-12-22, 09:34:

I got one of these cards a while back for a pittance. I always knew they were acer specific. It's nice to know the eeprom socket was supposed to come unpopulated.

There are two (E)EPROM sockets on the card. The PLCC one is for the SCSI BIOS and is supposed to be unpopulated. The DIP one is for the VGA BIOS and is supposed to be populated.