• Updated 2023-07-12: Hello, Guest! Welcome back, and be sure to check out this follow-up post about our outage a week or so ago.

The Great Gazelle PCI Hack Thread, Part 2

cheesestraws

Well-known member
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 :)
 

Phipli

Well-known member
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

:ROFLMAO:

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

Well-known member
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.
 
Last edited:

Phipli

Well-known member
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

Well-known member
... 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

Well-known member
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

Well-known member
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

Well-known member
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 :D
 

Byrd

Well-known member
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

Well-known member
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.
 

dosdude1

Well-known member
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.
 

Attachments

  • fcode-test.fc.zip
    755 bytes · Views: 1
  • fcode-test.txt
    2.1 KB · Views: 3
  • NVRAMRC-FCode.txt
    2.1 KB · Views: 3

dosdude1

Well-known member
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?
 

joevt

Well-known member
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.
Code:
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:
Code:
" 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
 

Attachments

  • PowerSurge.of.zip
    9.3 KB · Views: 0

Phipli

Well-known member
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!
 
Top