• 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

ried

Well-known member
That's amazing I'm so jealous of your trio, I've been hunting for one of those for ages.
The FW/USB/SATA cards that work in this application are probably a better solution. But the Trio is neat. Found mine on Buyee.jp in case you use that site.
 

macuserman

Well-known member
The FW/USB/SATA cards that work in this application are probably a better solution. But the Trio is neat. Found mine on Buyee.jp in case you use that site.
Yeah I have some of those I’ve just always wanted a trio neat bit of history that one. This whole thread is amazing though. I’ve yet to try out the latest hack here but I’m super excited to try it when I unbury those systems again.
 

CircuitBored

Well-known member
This is all very cool to see developing. One thing I'm curious about is whether or not this sort of patching could be applied to the ROM of the SuperMac S900 ("Storm Surge"?). As far as I know, the issue faced by the S900 is that four of its six PCI slots are behind a PCI-PCI bridge and because of this the ROM does not identify many installed cards correctly. PCI cards that themselves have PCI-PCI bridges do not work at all, AFAIK. Are these similar issues or am I barking up the wrong tree?

Bumping this as I think it got missed in the excitement!

Are the issues with the S900 at all related or similar to the Gazelle's issues?
 

joevt

Well-known member
Are the issues with the S900 at all related or similar to the Gazelle's issues?
The solution at #232 doesn't explain the real problem. It's a workaround which postpones the problem by probing the ATI fcode last after all the other PCI slots/bridges are handled.

Does the S900 have an ATI chip? If not, then it's probably a different problem.

Are there any posts that describing the S900 issue?

A patch depends on the version of Open Firmware and the type of machine. A rom dump is required to create a patch.
 

Trash80toHP_Mini

NIGHT STALKER
Wow! I hunted down several 5500/6500 boards over the years and was so disappointed when my pair of Trios proved incompatible with them. Playtime commences! Only have my 6360 and one 6400 board but their resolution limitations have kept the Trio itch at bay to date.

Fabulous work gang! 😀
 

Trash80toHP_Mini

NIGHT STALKER
The FW/USB/SATA cards that work in this application are probably a better solution.
What??? o_O Got a list of those cards to look out for? Just USB/SATA trumps Trio in my book.

The only FW device I have is a Zip Drive. If there's not a FW interfaced NIC -> fast Ethernet available, I can't think of much use for it these days given SATA? If there's none available, such might make a really neat project?
 

ried

Well-known member
What??? o_O Got a list of those cards to look out for? Just USB/SATA trumps Trio in my book.

The only FW device I have is a Zip Drive. If there's not a FW interfaced NIC -> fast Ethernet available, I can't think of much use for it these days given SATA? If there's none available, such might make a really neat project?
 

dosdude1

Well-known member
I still intend to make my own custom version of a combo card... Just let me know what devices would be best to implement. I can have up to 4 devices on the card using the PLX PCI6150 PCI-PCI bridge. The biggest constraint to a design with a lot of devices is physical space on the card... I’d probably try to stick with the dimensions of the SIIG card I’ve worked with before, unless someone can let me know what the absolute maximum dimensions of a card could be that would still fit in a TAM.
 

Trash80toHP_Mini

NIGHT STALKER
For the TAM you can make the card taller than standard PCI, at least up until it might conflict with the G3 card.

edit: If you can constrain it to fit within the space of the CSII NIC, I've got a project here somewhere around here where I developed the spec for a TwinSlot PCI riser to allow for a great VidCard to be installed in the primary slot and second PCI card in the NIC/Riser combo cubic. Besides, isn't a USB NIC a bit faster than the available CSII NIC? I've got a cardboard/connector prototype, but not up to board design/fab at this point in my quest.
 
Last edited:

dosdude1

Well-known member
For the TAM you can make the card taller than standard PCI, at least up until it might conflict with the G3 card.

edit: If you can constrain it to fit within the space of the CSII NIC, I've got a project here somewhere around here where I developed the spec for a TwinSlot PCI riser to allow for a great VidCard to be installed in the primary slot and second PCI card in the NIC/Riser combo cubic. Besides, isn't a USB NIC a bit faster than the available CSII NIC? I've got a cardboard/connector prototype, but not up to board design/fab at this point in my quest.
I’d like to make it compatible with other machines, so height would have to remain standard. Another idea I had was to make a custom riser for the TAM specifically with a device or two on it.
 

macuserman

Well-known member
I’d like to make it compatible with other machines, so height would have to remain standard. Another idea I had was to make a custom riser for the TAM specifically with a device or two on it.
What about a small daughter card that would probably not really add to the thickness but give you more PCB real estate. Seems an appropropriate solution given the vintage nature of our stuff as well, lots of our old cards did it that way to get extra room.
 

Phipli

Well-known member
@cheesestraws

Would it be feasible to combine your force32 with the nvramrc patcher program? An extension that on boot checks the state of nvramrc, and if it isn't patched, write the patch and reboot?
 

Trash80toHP_Mini

NIGHT STALKER
@cheesestraws was saying that booting from FDD was something he'd like to avoid. Was wondering if a purpose dedicated, tremendously simplified, read only version of BMOW's FloppyEMU setup would be a possible solution?

For TAM it doesn't matter, but for any other Gazelle machine it would be nice if they supported two FDDs for such purposes. I'm guessing not and hoping a bog simple EMU implementation might be scripted to eject/unmount itself to free up use of the single FDD available after it does the dirty?

Sorry if it's moot, haven't had a chance to re-read the project or even be able towrap my head around the goings on when/if I can make the time for review.
 

Phipli

Well-known member
@cheesestraws was saying that booting from FDD was something he'd like to avoid. Was wondering if a purpose dedicated, tremendously simplified, read only version of BMOW's FloppyEMU setup would be a possible solution?

For TAM it doesn't matter, but for any other Gazelle machine it would be nice if they supported two FDDs for such purposes. I'm guessing not and hoping a bog simple EMU implementation might be scripted to eject/unmount itself to free up use of the single FDD available after it does the dirty?

Sorry if it's moot, haven't had a chance to re-read the project or even be able towrap my head around the goings on when/if I can make the time for review.
Hey @Trash80toHP_Mini, it's probably worth catching up with the thread. The issues have been completely solved by joevt's script and it 'sticks' as long as you have a battery and don't nuke the nvramrc, just like the sonnet patch, but better and universally for all similar 'bridge' cards.

Don't mind my question to cheesestraws, it is just me thinking out loud, with me not having a battery in my 6500. I'm not sure that anything floppy related is needed at the moment and think you have in mind when we were talking about running a longer script from a floppy disk as a possible answer. Joevt's script is way shorter, so this doesn't matter.

Does that make sense, or did I misunderstand what you meant?
 

joevt

Well-known member
Don't mind my question to cheesestraws, it is just me thinking out loud, with me not having a battery in my 6500.
Is a battery required if you have AC connected? I guess it will be annoying when you get a power outage.
 

Trash80toHP_Mini

NIGHT STALKER
Hey @Trash80toHP_Mini, it's probably worth catching up with the thread.
No time and little understanding here, sorry

The issues have been completely solved by joevt's script and it 'sticks' as long as you have a battery and don't nuke the nvramrc, just like the sonnet patch, but better and universally for all similar 'bridge' cards.
I tend to think in terms of simple hardware hardware solutions that avoid problematic battery/power outage resets of systems.

Don't mind my question to cheesestraws, it is just me thinking out loud, with me not having a battery in my 6500. I'm not sure that anything floppy related is needed at the moment and think you have in mind when we were talking about running a longer script from a floppy disk as a possible answer. Joevt's script is way shorter, so this doesn't matter.
Good to know there is a workaround for needing boot media of any sort to set things up to run properly at startup. My machines tend to sit around for long periods while I play with others or work out theoretical flights of fancy.

Does that make sense, or did I misunderstand what you meant?
I think you got it, does my reply make sense to you?
 

Phipli

Well-known member
Is a battery required if you have AC connected? I guess it will be annoying when you get a power outage.
Sadly I think it resets with every cold start, but not having a battery is really my problem, not the computer's :)

The only full solution would be new ROMs and I wouldn't bother replacing them "just in case" even if there was a new fixed version. I don't mind re-applying at the start of the day.

My though tagging cheesestraws was if I fit a small IDE DOM to the IDE port, and install an OS with the patch as an extension that loads early in boot, it can check if the patch is applied, run it if not, restart and you're away.

Best thing is if the SATA is your boot drive it should double boot (initially partially from the DOM up to the point the check/patch extension loaded), but when you get to the desktop it will be your SATA drive, even if you didn't have the patch when you first powered on. You'd potentially only lose a few seconds on first boot.

You of course could still boot from the DOM if you selected it as your startup device.
 

Phipli

Well-known member
Other than the fact that I created the patch application, not @Phipli ... it would be nice if people's work was accurately credited in youtube videos, although I know the youtube crowd is not fond of me.
At least the screenshot of my post on the screen had my attributions to you and joevt!

I felt quite guilty just resedit hacking the patch together from other people's work that I didn't even understand. All I did was 10 seconds of copy pasting a text field.
 
Top