cheesestraws
Well-known member
Great, so it's finding the card. OK, I'll make a new iteration on the test patch in the next couple of days...
The Great Gazelle PCI Hack Thread, Part 2
- Thread starter cheesestraws
- Start date
Those numbers are indeed IDSEL. The PCI Bus Binding to Open Firmware says so.
The IDSEL is also the "Device Number" field of each entry in the "reg" and "assigned-addresses" properties.
cheesestraws
Well-known member
I suspected as much but I must have skipped that bit in the PCI bus binding. The fact I didn't really understand what I was reading probably didn't help 
. Either way, though, it's going to be easier to extract them from OF output than it is to trace them on the card, under nearly all circumstances
. Either way, though, it's going to be easier to extract them from OF output than it is to trace them on the card, under nearly all circumstancesOn a regular PCI card it would actually be easier/faster to check them with an ohmmeter, assuming you had one handy and didn't have to hunt for it, set it up, etc. You'd just put one probe on the IDSEL pin of the PCI card edge connector and strum the other probe down the address pins.
But, on these combo cards, you'd need the pinout for the PCI-PCI Bridge in front of you, and you'd be probing from the IDSEL pins on the PCI-PCI bridge to the address pins. And you'd need to figure which IDSEL goes with which downstream device on the card.
It actually wouldn't be that hard, once you were familiar with the pinouts, but I read some of your comments about you and hardware in another thread, so to each his own.
But, on these combo cards, you'd need the pinout for the PCI-PCI Bridge in front of you, and you'd be probing from the IDSEL pins on the PCI-PCI bridge to the address pins. And you'd need to figure which IDSEL goes with which downstream device on the card.
It actually wouldn't be that hard, once you were familiar with the pinouts, but I read some of your comments about you and hardware in another thread, so to each his own.
cheesestraws
Well-known member
Hardware certainly doesn't come naturally to me the way it does to some lucky souls . But in this case we want to get more information out of Open Firmware anyway—for these simple cards, just the vendor and device ID, sure, but for more complicated cards I suspect we're going to need more stuff from OF. We are, after all, trying to mimic the process that OF itself would use to set up the cards if it were working properly, so using the data OF on another machine gives us as ground truth is probably reasonable, I think. Plus it puts all the information one needs in the same place, so the information-gathering is only one process not several. But, as you say, each to their own—there are several ways to get this information, and I'm sure that there are people out there who could do the software side of this better than me too . But they're not doing it, so you all are stuck with me ;-)
. But in this case we want to get more information out of Open Firmware anyway—for these simple cards, just the vendor and device ID, sure, but for more complicated cards I suspect we're going to need more stuff from OF. We are, after all, trying to mimic the process that OF itself would use to set up the cards if it were working properly, so using the data OF on another machine gives us as ground truth is probably reasonable, I think. Plus it puts all the information one needs in the same place, so the information-gathering is only one process not several. But, as you say, each to their own—there are several ways to get this information, and I'm sure that there are people out there who could do the software side of this better than me too . But they're not doing it, so you all are stuck with me ;-)You could of course directly alter the process OF uses to probe PCI cards.
The PCI probe process usually happens after the NVRAM script is loaded. It's just that line at the front of your script that does the loading right then and there. All the code and data in Open Firmware is in ram and can be modified by the script.
If we knew where the bug(s) actually occured, a script could patch them out before they were run.
The PCI probe process usually happens after the NVRAM script is loaded. It's just that line at the front of your script that does the loading right then and there. All the code and data in Open Firmware is in ram and can be modified by the script.
Code:
probe-all install-console bannerIf we knew where the bug(s) actually occured, a script could patch them out before they were run.
cheesestraws
Well-known member
We discussed this upthread. It would be a fine way to do it, but I do not have the knowledge to do that. If you have the time and the knowledge, please feel free to do so: I cannot, so I am sticking with a simple approach that is known to more or less work.
And we are happy to have you. I've waiting close to 20 years for someone with software skills to take on the PCI issues.
cheesestraws
Well-known member
Oh, yup, I don't feel got at or anything, I just want to manage expectations that I am not a PCI guru, so you almost certainly won't end up with the "right" answer, though with luck we will end up with one that works...
@Knez I haven't forgotten you, I just haven't had time to knock up another patch yet (got a friend visiting)
@Knez I haven't forgotten you, I just haven't had time to knock up another patch yet (got a friend visiting)
Also, all the progress you make is information that can be built upon if someone decides to take the topic up again later.
Figuring out what it takes to make something work it almost always useful as an example.
Knez
Well-known member
@cheesestraws No stress!
LightBulbFun
Well-known member
one thing ill punt out there to keep in mind
is that if you install OS 9 on a mac without a USB card installed, then by default it wont install USB drivers, so installing a PCI USB card after install time wont work OOB on any old world Mac
I found this out the hard way back in the day when I had G3 beige but no ADB keyboard/mice!
so you either have to install the drivers manually, or at install time (ie while installing from the CD) make sure to manually check them as an option or have the USB card installed so it knows to install them
just something to keep in mind for those trying to test out the PCI patch etc
make sure you do have the USB drivers installed!
is that if you install OS 9 on a mac without a USB card installed, then by default it wont install USB drivers, so installing a PCI USB card after install time wont work OOB on any old world Mac
I found this out the hard way back in the day when I had G3 beige but no ADB keyboard/mice!
so you either have to install the drivers manually, or at install time (ie while installing from the CD) make sure to manually check them as an option or have the USB card installed so it knows to install them
just something to keep in mind for those trying to test out the PCI patch etc
make sure you do have the USB drivers installed!
mg.man
Well-known member
FWIW, someone selling a bunch of the 2.0 cards on eBay US...
- https://www.ebay.com/itm/Vintage-Ap...wire-400-USB-1-1-2-0-Combo-Card-/353446881123
cheesestraws
Well-known member
That's the person I got my testing one from. They even opened one up for me to check that the board in the box was the same one as pictured on the outside. Those are indeed the right ones.
cheesestraws
Well-known member
ried
Well-known member
I purchased one of the Tango 2.0 USB/FireWire cards from eBay last month and installed it in my TAM, which also has a Sonnet Crescendo G3 500 installed, running Mac OS 9.2.2. All of the relevant USB and FireWire drivers are installed.
I downloaded the patch, ran it (no invalid checksum error) and typed "y" + return twice. Rebooted and found that my TAM crashed during reboot with an interesting little bomb cursor. It was trying to load the first extension (Ethernet card) when the bomb appeared and the boot sequence stopped. Power button did not power it down, so I pulled the plug, zapped the PRAM and all is working again. Still no joy on the Tango 2.0's PCI-Bridge in System Profiler, of course.
Will keep an eye on this thread with great interest. Thanks for all your hard work on this!
cheesestraws
Well-known member
I have... never seen that bomb cursor before in my life. Anyone know what that's all about?
ried
Well-known member
I've never seen one before, either. It happened again, though. Even after zapping the PRAM, successfully booting and then shutting down the computer as normal. A bomb during the subsequent reboot. Strange!
I do have some good news to report, however. I once again zapped the PRAM, rebooted and then plugged a FAT32-formatted USB thumb drive into the Tango 2.0's USB port. To my surprise, it mounted on the desktop!
I expected it to be attached to the PCI-Bridge, but it's not. That's progress.
I do have some good news to report, however. I once again zapped the PRAM, rebooted and then plugged a FAT32-formatted USB thumb drive into the Tango 2.0's USB port. To my surprise, it mounted on the desktop!
I expected it to be attached to the PCI-Bridge, but it's not. That's progress.
cheesestraws
Well-known member
That's expected: With the "old" Tango 2.0 and Sonnet's official patch, it still happens. I don't know what metadata System Profiler is looking for but it isn't there. As far as I can see that's just cosmetic though...
So, am I right to sum up where you are as "card seems to be behaving but it took a couple of PRAM resets to get there"?
Similar threads
