• 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
OK, so in the interests of this project I just set my TAM to not auto-boot into MacOS but always to boot into the OF serial console.

When I inevitably forget I've done it and post a "My TAM is broken" thread, one of you folks will remind me, right?
 

cheesestraws

Well-known member
Big progress today! I have a "new" Tango 2.0, the incompatible one, working in my TAM at least for USB with a patched patch.

Anyone want to try it out? :D
 

cheesestraws

Well-known member
Here's the proposed patch for the new Tango 2.0. It seems to partially work with the Kalea cards that, IIRC, @Daniël and @Knez were most interested in, but only one of the three USB ports works (the middle one). Going to see if I can get the other ports on that working next...
 

Attachments

  • NewTango2.0.txt
    1.8 KB · Views: 6

cheesestraws

Well-known member
Here's my current draft patch for the Kalea "Serial Technologies Expander" card. This should allow all the USB ports and the firewire to work. SATA probably ain't happening, I'm afraid.

I'll try to test these both with firewire tomorrow and roll some patcher applications.
 

Attachments

  • kalea-crunched.txt
    1.8 KB · Views: 5

cheesestraws

Well-known member
I've written an application to apply them here: https://github.com/cheesestraws/pitcherpatcher/ which installs them out of a resource. I don't think I can send you a built version tonight, I'll have to get the G4 mini out to do that, and that's a tomorrow job at the earliest.

Apart from anything else, I don't want to make them too easy to install until I've at least tested them once more each, in case they do something terrible :D.
 

cheesestraws

Well-known member
Since @CircuitBored was interested in playing with OF in the S900 to try to get unsupported cards working there, I'm going to put here an expanded version of the commentary I posted in the crash-dead thread on what I think the Sonnet patch is up to, and (now) what I did to patch the patch.

Note, please, that I am not an OF guru, nor am I particularly good at Forth, so this is to an extent the opinions of a moderately educated onlooker, rather than an expert in the field.

Let's start. To begin with, this isn't really a "patch", it's an nvramrc, which is a script that's run early in the boot sequence. You can think of it as the Open Firmware equivalent of rc.local or AUTOEXEC.BAT. In this script you can do anything you can do at the OF command line. Now, this patch exists to work around PCI enumeration behind bridges not working; and the way it does this is to add "fake" device nodes to the tree that mirror what PCI enumeration would find. So, we can hack this by changing what card it is looking for, and what the fake devices it adds are.

Here's some code.

Code:
probe-all install-console banner

: config-l! " config-l!" $call-parent ;

: config-l@ " config-l@" $call-parent ;

We start off with some boilerplate. The colon defines a procedure, and the procedure is terminated with a semicolon. confg-l! and config-l@ are words which write and read, respectively, from the PCI configuration. I assume the shims we're putting on these here are so that our fake devices have them defined, but I'm not sure. (Not being sure will be a recurring theme).

Code:
: check-node
my-space " config-l@" $call-parent dup d# 16 >> swap h# 0000FFFF and 
my-space d# 8 + " config-l@" $call-parent d# 8 >> h# 60400 = 
swap h# 1668 = and swap h# 100 = and ;

check-node is the first routine in the patch proper. It checks whether the current device is one we care about. It does this by grabbing the vendor and device ID numbers out of the configuration space for that device (my-space returns the configuration address for the device; config-l@, as noted above, reads from it) and checking them. The two numeric constants in the last line are the ones you want to change here. For the "new" Tango2.0 and Kalea patches, I changed these to 3388 and 21, respectively.

Code:
: my-make-properties
make-properties 0 alloc-here 0 " pci" encode-cat
my-space h# 2c + config-l@ -rot 2 pick h# FFFF and (u.) encode-cat
" ," encode-cat rot d# 16 >> (u.) encode-cat
2dup swap 3 + swap bounds
do i c@ h# 40 > if i c@ h# 20 + i c! then loop
device-name 0 0 encode-2ints " power-consumption" property
0 0 my-space encode-3ints
0 0 encode-2ints encode+
0 0 my-space 2 d# 24 << or h# 10 + encode-3ints
1000 0 encode-2ints
encode+ encode+ " reg" property ;

my-make-properties sets up the properties for one of our fake PCI devices, especially its "reg" property. It does this based on its position in the PCI configuration space (note our friend my-space turning up again). I do not know enough deep PCI magic to understand totally what this is doing; fortunately, for the patches I've had to do so far, we don't need to poke it. So let's not.

Now we get onto the meat of the patch: make-nodes. make-nodes actually does three things, only one of which is making new nodes. First

Code:
: make-nodes
" assigned-addresses" delete-property
my-space dup 18 + 10100 swap config-l!
4 + dup config-l@ h# FFFFFFF4 and 2 or swap config-l!

This first bit of code sets up the PCI bridge chip to have the right options. You can leave it alone.

Code:
new-device 0 0 " 0,0" set-args
my-make-properties 0 100000 20 claim-real
swap drop dup dup 100000 " map-range" $call-parent
dup my-space h# 10 + config-l!
dup 0 my-space h# 82 d# 24 << or h# 10 + encode-3ints
1000 0 encode-2ints encode+ " assigned-addresses" property
finish-device

new-device 0 0 " 1,0" set-args
my-make-properties dup 1000 + my-space h# 10 + config-l!
dup 1000 + 0 my-space h# 82 d# 24 << or h# 10 + encode-3ints
1000 0 encode-2ints encode+ " assigned-addresses" property
finish-device

These two bits set up the two device nodes, one for USB and one for Firewire. The things to note here are the "0,0" and "1,0" strings. These need to be adjusted to fit what the card expects. I'll post another comment below this one with how to find out what the card expects. You can add more devices here, but some challenges start emerging.

Code:
dup dup h# 10 >> or my-space h# 20 + config-l!
my-space h# 3c + dup config-l@ h# 800000 or swap config-l!
" ranges" delete-property
dup 0 h# 82000000 encode-3ints
rot 0 h# 82000000 encode-3ints
h# 100000 0 encode-2ints encode+ encode+ " ranges" property
my-space h# 18 + config-l@ dup 8 >> h# ff and swap d# 16 >> h# ff and
encode-2ints " bus-range" property ;

This last chunk of make-nodes sets up some more global properties of the bridge that one doesn't need to poke to patch the patches.

We're on the final stretch now: the remaining code glues the above together.

Code:
: x
['] select-dev
catch if 2drop else
check-node if make-nodes then then ;

" pci1/@d" x " pci1/@e" x

This defines a procedure "x" that selects a device, checks whether it exists and is the right one, and if so, it runs make-nodes on it. This procedure is then invoked twice for the PCI card at D and the PCI card at E.

Ta daa.
 

Knez

Well-known member
Got it compiled etc and it seems to be writing NVRAM correctly, but my 5500 still can't see beyond "pci-bridge".
 

cheesestraws

Well-known member
The sub-devices won't appear in System Profiler, that's known; it doesn't with the old Tango 2.0 either. Do you have a USB bus under 'devices'? Try plugging in a USB stick?

If you mean in OF, can you send me an 'ls' under that device?
 

Knez

Well-known member
I don't have "USB" under devices and nothing I connect to the USB ports work (tried one keyboard, one mouse and one USB stick on all the ports). Getting into OF is a bitch on the 5500, but I can give it a try :)
 

Knez

Well-known member
Just to be specific; how do I "ls" under that device? Just "cd" into the device tree and "ls"?
 

Trash80toHP_Mini

NIGHT STALKER
I read through this thread again after loosely following the lost version. I started thinking about the Gazelle machines and where they fit into the product lineup. A quick trip to EveryMac's 1997 release specs and I'm wondering if you're fixing a bug here or working around intentionally hobbled machines? It's not like Apple hadn't done such things in previous generations.

Given Sonnet's accelerators and multiple function cards like Tempo Trio coming out in support of Alchemy boards, at least to me it stands to reason that Apple would have shot Gazelle in the foot to keep that development line firmly in the consumer Mac category? With fast G3/Cache, a great VidCard and Trio in a 6500 released the same year as the 9600/604 (with a tad slower bus no less) you could do a lot of stuff for a lot less money I'd think.

Sonnet had been trying to support the Trio in Gazelle, but gave up on it, makes me wonder.

Great stuff @cheesestraws as is. Might looking for a cauterized, Apple inflicted bullet wound in Firmware be another worthwile approach to this?
 

Cory5412

Daring Pioneer of the Future
Staff member
Cheesey: this is fun to follow along with, thank you. These kinds of cards aren't always the most exciting (well, I mean, besides the Tempo Trio and similar multifunctions cards as to what you're working on here) but it's neat to see work on expanding the available inventory of this kind of thing for any era of Mac.

jt:
I think it would be unwise to think too hard that this was a super clever dastardly plan to "intentionally hobble" the expansion capacity of these machines.

For a handful of reasons, I think it's better to presume that this is a genuine mistake.

and Trio in a 6500 released the same year as the 9600/604

Notably -- the Trio was launched in 2002, around 4-5 years since any 6500s had shipped.
 

Trash80toHP_Mini

NIGHT STALKER
Yep, Apple made plenty of boo-boos too, but they were working from Alchemy, which was pretty solid all things considered. Seems strange they borked something so basic, so badly in the transition? The notion hit me, so I asked, the only stupid question is ths one . . .

I thought the Trio was Crescendo L2 era? I'll have to check the dates on mine. THX, C.
 

cheesestraws

Well-known member
I'm wondering if you're fixing a bug here or working around intentionally hobbled machines?

Hanlon's razor applies here. In the absence of any evidence to the contrary, cock-up is more likely than conspiracy. Given that I suspect that the patch I'm working on actually originated from Apple (perhaps?), since it turns up in multiple patchers for combo cards, this seems doubly unlikely.

Sonnet had been trying to support the Trio in Gazelle, but gave up on it, makes me wonder.

Having just tried to support a three-function card where one of the functions isn't just "here's a blob of memory mapped I/O", I don't. The relevant patch probably won't trivially fit in nvramrc. Unless one is seriously good at crunching Forth by hand.
 
Top