• Hello, Guest! Welcome back, and be sure to check out this post for more info about the recent service interruption and migration.

The Great Gazelle PCI Hack Thread, Part 2

cheesestraws

Well-known member
As I was saying before we were so rudely interrupted... ;-)

@Daniël Oosterhuis, @Knez and I are digging into the feasibility of using unsupported combo PCI cards on Gazelle-based machines (TAM etc). The problem here is that there is a bug in the Open Firmware on those machines which prevent it seeing devices on the other side of a PCI bridge.

Sonnet did produce a patch for their early Tango 2.0 cards, which doesn't work with any other combination cards. The "patch", being for Open Firmware, is in Forth; and Forth is a bit of a write-once language, but given enough caffeine one can work out what is going on in it.

On looking at this (I can repost the commented analysis, if anyone's interested), it became obvious the reason it doesn't work with other cards is that it doesn't actually re-enable PCI enumeration at all: what it does instead is to "fake" the devices that PCI enumeration would find. It also became obvious that the patch wasn't really a patch at all but just an initialisation script (an "nvramrc").

This was bad news because it meant that we couldn't simply adapt the patch to work with all devices. But it was also good news, because it meant there wasn't any reason in theory why the approach couldn't work with other cards.

There was a parallel problem, which was how to install the patches. The Sonnet one was rather hardcoded to one specific patch, or rather a patch of that specific length. We do now have a more generic patcher that can install patches of varying length (https://github.com/cheesestraws/pitcherpatcher). We do still only have 2k to play with, though.

The next step will be to try to work out how to generate the patch source from the OF output of a "good" machine. I have a beige G3 arriving from @joshc next weekend, which will hopefully assist with this.

Further progress may occur...
 

jeremywork

Well-known member
Thanks for keeping this one alive.
I can re-post any of those OF .properties dumps I posted before if it would be helpful.
 

cheesestraws

Well-known member
Thankyou for the offer! Let me see what I can get out of the G3 before I bother you again for those :). I have actual cards now, sooooo
 

trag

Well-known member
If there is not room in the NVRAM for a general-solution patch, could the ROM itself be patched? Similar to what Doug3 and Bbraun (apologies if I have those names wrong) worked out for 68K Mac ROM hacking, which ultimately led to the ROMinator. This is probably looking out way ahead...

Anyway, the socket for the ROM module is Burndy ELF160HGC-3Z50 and is available here: https://www.connectorpeople.com/Connector/BURNDY/E/ELF160HGC-3Z50. Looks like they have more than 3500 in stock.

Oops. That's for Alchemy. Does Gazelle use the same arrangement?

Thinking in terms of a socket to go on a Programmer Unit for a programmable firmware (ROM) module.
 

cheesestraws

Well-known member
If there is not room in the NVRAM for a general-solution patch, could the ROM itself be patched?

This would be absolutely possible for someone who is better at this than I am :). It's certainly something worth doing the basic research for—the main reason I'm doing this like this is to start with is simply that I know enough Forth to attack the problem and I do not know enough about how to write low level PPC code.
 

trag

Well-known member
You're starting from a great place. I think it's a terrific approach. Try some experiments first and then work deeper later if one wishes.
 

pc297

Member
As I was saying before we were so rudely interrupted... ;-)

@Daniël Oosterhuis, @Knez and I are digging into the feasibility of using unsupported combo PCI cards on Gazelle-based machines (TAM etc). The problem here is that there is a bug in the Open Firmware on those machines which prevent it seeing devices on the other side of a PCI bridge.

Sonnet did produce a patch for their early Tango 2.0 cards, which doesn't work with any other combination cards. The "patch", being for Open Firmware, is in Forth; and Forth is a bit of a write-once language, but given enough caffeine one can work out what is going on in it.

On looking at this (I can repost the commented analysis, if anyone's interested), it became obvious the reason it doesn't work with other cards is that it doesn't actually re-enable PCI enumeration at all: what it does instead is to "fake" the devices that PCI enumeration would find. It also became obvious that the patch wasn't really a patch at all but just an initialisation script (an "nvramrc").

This was bad news because it meant that we couldn't simply adapt the patch to work with all devices. But it was also good news, because it meant there wasn't any reason in theory why the approach couldn't work with other cards.

There was a parallel problem, which was how to install the patches. The Sonnet one was rather hardcoded to one specific patch, or rather a patch of that specific length. We do now have a more generic patcher that can install patches of varying length (https://github.com/cheesestraws/pitcherpatcher). We do still only have 2k to play with, though.

The next step will be to try to work out how to generate the patch source from the OF output of a "good" machine. I have a beige G3 arriving from @joshc next weekend, which will hopefully assist with this.

Further progress may occur...
I might be able to help you on this one, I have a 5500/6500-incompatible Tango 2.0 PCI card in a Beige G3. I tested it several times on the 5500 with all versions of the Sonnet PCI patch (up to 1.3) and it never, ever worked and was always recognised as a PCI bridge.

However, the card works like a charm in the Beige G3. I will post the vendor and device IDs tonight, and can assist for the OF output in the Beige with the 6500-incompatible Tango 2.0
 

trag

Well-known member
Anyway, the socket for the ROM module is Burndy ELF160HGC-3Z50 and is available here: https://www.connectorpeople.com/Connector/BURNDY/E/ELF160HGC-3Z50. Looks like they have more than 3500 in stock.

Oops. That's for Alchemy. Does Gazelle use the same arrangement?

For completeness sake, even though any such ROM modification would be a long way off...

I checked a 6500 board at home and it uses the same connector. On my 6500 board the ROM position was not populated. Only the cache socket was installed.
 

pc297

Member
Thankyou!

Hi @cheesestraws:

So these are the PCI IDs from the Gazelle-incompatible Tango 2.0 card in a Beige G3 (where it works fine)

There are 5 entries: 1 pci-bridge, 2 usb, 1 firewire, I am writing them down in the order that they show up in system profiler:

pci-bridge:
VID: 3388
DID: 0021
REV: 0011

usb:
VID: 1033
DID: 0035
Subsystem VID: 1033
Subsystem DID: 0035
REV: 0044

firewire:
VID: 1033
DID: 00F2
Subsystem VID: 1033
Subsystem DID: 00CE
REV: 0001

usb:
VID: 1033
DID: 00E0
Subsystem VID: 1033
Subsystem DID: 00E0
REV: 0005

Cheers,
 
Last edited:

chelseayr

Well-known member
btw I know theres probably low interest for it but just in case someone had a 6500 (which are gazelle-based boards after all) and wanted to 'kill two birds with one stone' then theres these pinnacle/adaptec cards which to my limited but strong opinion seem to have a pci bridge in use

I present you;
which has a bit of basic details on the card

and incidentally ebay has the best set of photos of them if you would mind;

unforunately someone would actually have to own such card as to be able to peel the barcode-containing sticker off as to be able to id the bridge chip used (that or just boot up with it and id it through software instead)

p.s by the way: I'm not certain if there was one or more versions of the 8945 in term of whether it was the one same bridge chip used all the times or not as there is another alike-model auction with seemingly same pcb layout but only one instead of both of the rightward big chips are covered by a 'full-footprint' sticker

the reason I finally decided to mention it here is because the way I see it is that it has ultrawide scsi for any very fast drives internally and/or externally (and media drives/etc can stay with the gazelle-onboard scsi just as well?) while also adding macos 8.6-9.2 compatible firewire for more modern external drives beside also being able to feed video from newer videocameras (in my opinion I'll trust the direct ilink port more than these cheap-looking ministereo-like composite-limited av cables often used with them, just saying!) .. and at the end you still have one more pci slot left for something else
 

jeremywork

Well-known member
Haven't seen one of these before... "486 Module" from Reply Corp in 1991 - could be another prototype to the DOS cards that Apple/Reply first built.
$200 BIN or offer.
If I knew more about how it works I might bite... ;)

 

jeremywork

Well-known member
Haven't seen one of these before... "486 Module" from Reply Corp in 1991 - could be another prototype to the DOS cards that Apple/Reply first built.
$200 BIN or offer.
If I knew more about how it works I might bite... ;)

Well I'm confused... could've sworn I hit 'post' over on the eBay finds thread tab I had open, but when I went checking that thread today I found the post was here instead. Sorry about that!
 

cheesestraws

Well-known member
Well I'm confused... could've sworn I hit 'post' over on the eBay finds thread tab I had open, but when I went checking that thread today I found the post was here instead. Sorry about that!

I did wonder about that, and meant to post to ask, but then the universe happened and I forgot :). No fret!

So these are the PCI IDs from the Gazelle-incompatible Tango 2.0 card in a Beige G3 (where it works fine)

Thankyou!

unforunately someone would actually have to own such card as to be able to peel the barcode-containing sticker off as to be able to id the bridge chip used (that or just boot up with it and id it through software instead)

We'd need a bit more than the PCI ID, unfortunately, but yeah—only way that's going to happen is if someone gets hold of one and dumps some information about it. I already have a handful of cards here, thanks to history and eBay and @trag 's generosity, so I'm going to start with the ones I've got and work from there, I think, for the moment...

(He said, having no results to show so far at all...)
 

pc297

Member
I did wonder about that, and meant to post to ask, but then the universe happened and I forgot :). No fret!



Thankyou!



We'd need a bit more than the PCI ID, unfortunately, but yeah—only way that's going to happen is if someone gets hold of one and dumps some information about it. I already have a handful of cards here, thanks to history and eBay and @trag 's generosity, so I'm going to start with the ones I've got and work from there, I think, for the moment...

(He said, having no results to show so far at all...)
What do I need to run in OF to dump the information about it? dev / ls? Do you need anything from ioreg?
 

cheesestraws

Well-known member
Not really in the last month or so—work has been a bit intense so I can't quite bring myself to do software for fun, unfortunately. I've gathered properties from various cards in working and non-working machines but haven't had the mental presence to try to translate those into Forth yet
 

trag

Well-known member
I present you;
which has a bit of basic details on the card


unforunately someone would actually have to own such card as to be able to peel the barcode-containing sticker off as to be able to id the bridge chip used (that or just boot up with it and id it through software instead)
Well, it doesn't get anyone the various IDs, but I would wager the bridge chip on that board is a later variant of the 21052. There's that big Intel 'I' not covered by the sticker.

Intel bought DEC's chip foundry. DEC's PCI-PCI bridge chip was the 21052 (IIRC) . I know Intel made those because I experimented with PPBs about 15 years ago, and I bought some of the Intel flavor. But Hint's 208 pin QFP (or was it 160?) was also pin compatible.

At the time, I swapped about four different variants of the PCI-PCI Bridge chip (later revs. of DEC's, Intel's and Hint's) into the Umax S900 logic board. They all worked fine, but none of them changed the behavior of the S900 -- leading the conclusion that its PCI issues are in firmware.
 
Top