zefrenchtoon
Well-known member
Hi!
It was funky to read this quest just after viewing this video from dosdude1
It was funky to read this quest just after viewing this video from dosdude1
The Great Gazelle PCI Hack Thread, Part 2
- Thread starter cheesestraws
- Start date
ried
Well-known member
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.
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
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
zefrenchtoon
Well-known member
May the forth be with you @cheesestraws
Phipli
Well-known member
It would work if we put a longer script on a floppy disk...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
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
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.
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
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
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
Ah sorry, I misremembered - thanks for clarifying. Much appreciated.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
dosdude1
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.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
cheesestraws
Well-known member
jeremywork
Well-known member
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
Well-known member
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.
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?
cheesestraws
Well-known member
Welp! There goes that strategy.
I'd be well up for a couple of these for a couple of machines.
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 & $XHere'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.
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
Phipli
Well-known member
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
Member
while youre at it designing a new card add a nubus slot or 10
Similar threads
