The Great Gazelle PCI Hack Thread, Part 2

[zefrenchtoon]

Hi!
It was funky to read this quest just after viewing this video from dosdude1

 

[ried]

Then it'll be a brief experiment Greg Hrutkay was considering an experiment with a combined SATA, FW & USB card on Facebook. Maybe he was also unaware of the limitation.

@zefrenchtoon Jinx! That's the one.

 

[cheesestraws]

I'm not going to rule it out as a possibility, I just think someone better than me at making very compact forth would have to have a go

 

[zefrenchtoon]

May the forth be with you @cheesestraws

 

[Phipli]

I'm not going to rule it out as a possibility, I just think someone better than me at making very compact forth would have to have a go

It would work if we put a longer script on a floppy disk...

But I'm not going to run my computer with a openfirmware boot script floppy disk forever



Other possibility is use dead space in the rom or a bigger rom and jump to it / load it somewhere.

But all of these things are more difficult than getting one of these cards working in a small number of machines feels like it is worth.

Also forth is horrible.

 

[dosdude1]

Just went around looking for this after someone mentioned it in a comment on my YouTube video about that combo card... Wouldn't it be possible to tokenize the patch into FCode (with some modification)? I'd assume that would decrease the size of it at least somewhat, and it can be executed from NVRAMRC... Or maybe it could be possible to add some sort of extra EEPROM containing said FCode, if space is still an issue after tokenizing?

Another idea I had was just to get rid of the PCI-PCI bridge altogether... Technically it shouldn't be necessary, as you can in theory just put all 3 devices (in this case SATA, FireWire and USB controller) all on the same PCI bus. That is if you don't end up reaching some sort of PCI device limitation on these machines.

 

[Phipli]

Just went around looking for this after someone mentioned it in a comment on my YouTube video about that combo card... Wouldn't it be possible to tokenize the patch into FCode (with some modification)? I'd assume that would decrease the size of it at least somewhat, and it can be executed from NVRAMRC... Or maybe it could be possible to add some sort of extra EEPROM containing said FCode, if space is still an issue after tokenizing?

Another idea I had was just to get rid of the PCI-PCI bridge altogether... Technically it shouldn't be necessary, as you can in theory just put all 3 devices (in this case SATA, FireWire and USB controller) all on the same PCI bus. That is if you don't end up reaching some sort of PCI device limitation on these machines.

It was me talking about it I'd have linked to it but youtube doesn't seem to like links these days :/

I think @cheesestraws already tokenised it... I might be wrong. It was certainly compact

 

[cheesestraws]

... Wouldn't it be possible to tokenize the patch into FCode (with some modification)? I'd assume that would decrease the size of it at least somewhat, and it can be executed from NVRAMRC

This would probably do it, if you can embed chunks of FCode in nvramrc. I didn't—and still don't—know how to do this, so I didn't . That would be the best way to expand it, though, definitely.

 

[Phipli]

This would probably do it, if you can embed chunks of FCode in nvramrc. I didn't—and still don't—know how to do this, so I didn't . That would be the best way to expand it, though, definitely.

Ah sorry, I misremembered - thanks for clarifying. Much appreciated.

 

[dosdude1]

This would probably do it, if you can embed chunks of FCode in nvramrc. I didn't—and still don't—know how to do this, so I didn't . That would be the best way to expand it, though, definitely.

Ah, I've dealt with loading FCode from NVRAMRC before, and have a usable script that will do so. I'm currently working on converting your "NewTango2.0" Forth script to FCode, so we'll see how small it can be made once tokenized.

 

[cheesestraws]

Ah, I've dealt with loading FCode from NVRAMRC before, and have a usable script that will do so. I'm currently working on converting your "NewTango2.0" Forth script to FCode, so we'll see how small it can be made once tokenized.

Oh, excellent stuff

 

[Byrd]

Ooh, that'd be interesting - no luck with my Tango 2.0 in TAM, USB OK, FW power OK but nothing mounts (using FW drivers as specified etc)

 

[jeremywork]

Managed to track down a Sonnet Tempo Trio (based on the early Tango 2.0). ATA-133, FW & USB in the TAM sounds like the dream. I'll give it a whirl and report back.

I tried this originally with the Sonnet OEM patch and it behaved just like its cousin Tango 2.0 (the one with unpopulated ATA connectors.) USB and Firewire both worked, but ATA didn't.

 

[ried]

Let's see if @dosdude1's efforts to shrink @cheesestraws' code changes things up

 

[dosdude1]

Alright, got it done, and converted into (what I believe is) usable FCode. I attached all files necessary. "fcode-test.fc" is the tokenized FCode in binary form. This can be loaded directly into Open Firmware using the "boot" command from a storage device (for testing). "fcode-test.txt" is the raw, untokenized FCode that I derived from the original "NewTango2.0.txt" file posted by @cheesestraws. It can be modified as you wish, and re-tokenized using "toke" from FCode utils. Finally, "NVRAMRC-FCode.txt" is the FCode binary loader that is executable from NVRAMRC, with the FCode tokenized binary pasted in as a series of hex bytes. This seemingly won't be of any use to us, unfortunately, as it is larger than the original script (LOL). I'll have to see if I can figure out how to load it without having to store it in string form. For now, hopefully the FCode can be tested by someone here, just as a sanity check to make sure it actually works as intended. I'll grab my PowerMac 6500 soon so I can test it myself, but I don't have it available at the moment.

 

[dosdude1]

On another note, I'm strongly considering just making my own combo card that doesn't utilize a PCI-PCI bridge at all, but rather just puts all the controllers on the main PCI bus, making this entire issue irrelevant. The only issue that WOULD arise from doing this would be the potential for one or some of the onboard controllers to conflict with other PCI cards in other slots, but that would be relatively simple to work around by making the IDSEL configurable, by way of setting resistors or jumpers. Would this be of interest (especially for TAM users)? Maybe make it a challenge to see how many controllers I can fit on one card... Maybe SATA, USB2.0, FireWire, and Ethernet?

 

[cheesestraws]

This seemingly won't be of any use to us, unfortunately, as it is larger than the original script (LOL).

Welp! There goes that strategy.

Would this be of interest (especially for TAM users)?

I'd be well up for a couple of these for a couple of machines.

 

[joevt]

Other possibility is use dead space in the rom or a bigger rom and jump to it / load it somewhere.

But all of these things are more difficult than getting one of these cards working in a small number of machines feels like it is worth.

Also forth is horrible.

How big does the script need to be to fix PCI bridges?

nvramrc scripts are limited to less than 2K.

nvram is 8K total. There's 4K of mostly unused space that could be used. I'm working on a version of XPostFacto that can use that space for some large nvramrc scripts. The example attach nvramrc script PowerSurge.of is for my Power Mac 8600. XPostFacto removes all the comments, then finds a suitable place to split the script - after the part of the script that reads the entire 8K of nvram into a buffer. The buffer is also added as a property for debugging later.

2000 buffer: tb 0 tb 2000 8F6 & $X

Of course, you need to replace 8F6 with the fcode number of the word that reads nvram. I would need a rom dump for a TAM or 6500 to find that.

Here's a thread with some PCI Open Firmware stuff and a link to some Open Firmware Forth code listings created from Mac rom dumps.
#1 #543

My latest lspci for Open Firmware is at
https://www.dropbox.com/s/j12r9t89dphq5ms/lspci For OpenFirmware.zip?dl=0
You can use it to dump the config space of all PCI connected devices in Open Firmware. Then use a script in Mac OS X to parse the result with lspci from pciutils.

It would work if we put a longer script on a floppy disk...

But I'm not going to run my computer with a openfirmware boot script floppy disk forever

Right. The reason you need to use a floppy is because Old World Macs can't read files from hard drives but can read files from a FAT (maybe HFS?) formatted floppy. I haven't tested FAT or HFS formatted partition - well, I guess every HFS+ partition with a HFS wrapper is HFS but mac-files is broken or doesn't work for HDs? I haven't looked into it.

Instead of requiring a file system, you could maybe use a small nvramrc script to read a Forth script from certain blocks of a SSD or hard disk - one that already exists in the device tree when your nvramrc script executes. I think built-in SCSI and ATA HDs should be available before pci-probe happens? That's what I've seen in my dingusppc testing for Beige G3 and Power Mac 7500. The devices exist but I haven't tried reading from them before probe-all.

The blocks can be in a specially created partition (use iPartition.app or pdisk). The nvramrc can use a hard coded device path, block start number, and block count to minimize the size of the script. Pad the script with spaces. Write text to the partition using dd in Mac OS X.

This is untested:

" pci1/@F/@2/sd@0" 2dup find-device open-dev u.
2000 alloc-mem value buf
buf 2468 10 read-blocks 1 = if
    buf 2000 evaluate
then
unselect-dev

" pci1/@F/@2/sd@0" = Open Firmware path to disk that contains the partition
2000 = size of the partition in bytes (2000 = 8K)
2468 = start of the partition (0x2468 = block #9320 - partitions usually start at a multiple of 8 blocks)
10 = number of blocks (assuming each block is 512 bytes, 0x10 = 16 blocks = 8K)

I used read-blocks in a script to list partitions in Open Firmware:
#222

And I have a Mac OS X script to list partitions (also shows Boot Blocks, HFS+ Volume Headers, and HFS Master Directory Blocks)
https://gist.github.com/joevt/a99e3af71343d8242e0078ab4af39b6c

 

[Phipli]

Right. The reason you need to use a floppy is because Old World Macs can't read files from hard drives but can read files from a FAT (maybe HFS?) formatted floppy. I haven't tested FAT or HFS formatted partition - well, I guess every HFS+ partition with a HFS wrapper is HFS but mac-files is broken or doesn't work for HDs? I haven't looked into it.

It doesn't read HFS either sadly.

Some very interesting stuff in your post I have hope we'll see my SATA/FW/USB card running in my 6500!

 

[testdriver]

while youre at it designing a new card add a nubus slot or 10