The Great Gazelle PCI Hack Thread, Part 2

[Phipli]

Thanks, I seem to have an issue with Maczip I cant seem to just drop the Zip file on the icon or on an alias of Maczip, it just moves the file to the same location. I think this is where my problem lies because I'm having to use the maczip gui to extract it.

If I bring the zip file over to the Stuffit expander Alias the icon goes dark has expected and when I let go it unpack it but not how Maczip would, so I'm trying to see what I'm not doing correctly

Don't use Stuffit to extract zips, it isn't the best at it.

I'd suggest redownloading maczip. Grab a copy here.

The big thing with Mac files is not to move them via non-macs uncompressed, so don't open the file until it is on a Mac, and don't move it via a PC or PC formatted disk (or PC style network) once you expand it.

PCs don't understand the structure of Mac files and strip out important data. Using file formats like hqx protects the contents.

 

[Timtheloon]

I wasn't using stuffit to do the extraction I was just giving an example of what the Maczip isn't doing when I drag the zip file over to it to explain the difference I'm seeing. What's frustrating is I'm sure it just worked on my 5400 mobo Maczip that is not this patch.

I'm setting up my network card to get the files over and see how I get on I'll give you all an update later

Thanks @Phipli for you assistance here very much appreciated

 

[Timtheloon]

Found out what my issue was I now tried an older version of stuffit expander 4.0.2 and it unpacked Maczip correctly and it would let the drag and drop function work woohoo.

It extracted and it lets me install the patch

However I still get no change and looking through this thread I see @cheesestraws mentions a similar card which he hasn't got to work yet

I've attached some pics of the card I was hoping to get to work

 

[Phipli]

Found out what my issue was I now tried an older version of stuffit expander 4.0.2 and it unpacked Maczip correctly and it would let the drag and drop function work woohoo.

It extracted and it lets me install the patch

However I still get no change and looking through this thread I see @cheesestraws mentions a similar card which he hasn't got to work yet

I've attached some pics of the card I was hoping to get to work

Have you installed drivers for the ethernet portion?

You may also need to install stuff to make USB and FW work.

What does System Info say now?

 

[Timtheloon]

Have you installed drivers for the ethernet portion?

You may also need to install stuff to make USB and FW work.

What does System Info say now?

I was hoping the ethernet driver would be the same has the one on the current ethernet card I use because the IC on both cards are the same number

I've not gone any further because I thought I would see more PCI devices when I added the patch

All that seems to have happened is my PCI bridge is now at the top of the list above the Display adapter, added screenshot

 

[Phipli]

The correct USB stuff is only installed by the OS if you have a working card installed, so install this :

USB Adapter Card Support 1.4.6 - Macintosh Garden

kmos9: USB PCI card under Mac OS 9.2.2 by Joerg Weise London, UK Q: I have installed a USB PCI card in my beige PowerMac G3 (or any other Power Macintosh computer without built-in USB ports) running Mac OS 9.2.2, but the card is not working / not recognized by the system. What can I do?

macintoshgarden.org

Also this just in case :

https://macintoshgarden.org/apps/apple-firewire-drivers-mac-os-86-9

And... This might work for your ethernet, but that is a big old "it depends".

https://macintoshgarden.org/apps/realtek-rtl8169s-gigabit-ethernet-card-driver

Note this is a bit off topic for this thread as this is just normal use of a PCI card. If you continue to have issues, please spin up a new thread about sorting the drivers for your card.

 

[Timtheloon]

Apologies if I'm on the wrong thread but I thought this thread was about getting unsupported Combo PCI cards to see past the PCI bridge which is stated in Post 1 of this thread?

 

[Phipli]

Apologies if I'm on the wrong thread but I thought this thread was about getting unsupported Combo PCI cards to see past the PCI bridge which is stated in Post 1 of this thread?

It's about patching open firmware to get the bridge chips working. You've done that now. You're now having driver issues.

I worry that this thread should have been locked with the solution posted at the end to keep it useful. It's less confusing then and if people are having issues implementing it they can spin up a new thread (for example, your issue was actually initially a problem with decompressing the file, and is now driver issues, neither... Are directly applicable to the firmware patch)

The tricky thing is that the solution that this thread is about is now buried on page 12 of 17 on this thread. It is getting harder and harder to find, and I'm the one that posted the applet

 

[Timtheloon]

I get what you saying but nothing has changed after applying the patch, should I not see 3 more PCI devices available in my system info I added a screen shot earlier ref this

 

[Phipli]

I get what you saying but nothing has changed after applying the patch, should I not see 3 more PCI devices available in my system info I added a screen shot earlier ref this

Combo cards are weird, and FW and USB can be weird and don't show properly. I'm surprised I can't see the ethernet.

If your machine is a 5500 board, it is identical to the 6500 board I have personally used the patch on. The patch is known to work based on a number of people installing it. If you have applied the patch. Then the issues are specific to your setup.

 

[CC_333]

I worry that this thread should have been locked with the solution posted at the end to keep it useful. It's less confusing then and if people are having issues implementing it they can spin up a new thread (for example, your issue was actually initially a problem with decompressing the file, and is now driver issues, neither... Are directly applicable to the firmware patch)

The tricky thing is that the solution that this thread is about is now buried on page 12 of 17 on this thread. It is getting harder and harder to find, and I'm the one that posted the applet

Or, perhaps, start a new thread with your page 12 solution posted on top. Then that thread can be stickied and locked.

Or, better still, create a wiki page for it on the 68kMLA wiki site, if and when it ever gets fixed.

c

 

[CircuitBored]

Please could the owner of a Gazelle system run .properties on the nvram when they get the opportunity? I'm messing around with the SuperMac S900 and am trying to establish if its nvram is located in the same place in memory.

For reference, this is the S900's nvram.properties:

name                    nvram
device_type             nvram
reg                     0001D000  00000010
                        0001F000  00000200
existing                00000000 00002000

 

[joevt]

Please could the owner of a Gazelle system run .properties on the nvram when they get the opportunity? I'm messing around with the SuperMac S900 and am trying to establish if its nvram is located in the same place in memory.

For reference, this is the S900's nvram.properties:

name                    nvram
device_type             nvram
reg                     0001D000  00000010
                        0001F000  00000200
existing                00000000 00002000

I don't remember where this came from:

/bandit@F2000000/ohare@10/nvram@60000
PROPERTIES:
name                    nvram
device_type             nvram
reg                     00060000  00020000 
existing                00000000 00002000

Anyway, it shouldn't matter where the NVRAM is at because the NVRAM drivers in Open Firmware and Mac OS 9 know how to access the nvram. You use the methods provided by each environment to read the NVRAM. For Mac OS 9, you use the ExpansionManager.

{$PRAGMAC MARK -}
CONST
	_ExpansionManager			= $AAF3;

{$DEFINEC SIZE_CODE(size)
	ORD((size) = 4) * kFourByteCode + ORD((size) = 2) * kTwoByteCode + ORD((size) = 1) * kOneByteCode
}

{$DEFINEC RESULT_SIZE(sizeCode)
	BSL(sizeCode, kResultSizePhase)
}

{$DEFINEC STACK_ROUTINE_PARAMETER(whichParam, sizeCode)
	BSL( sizeCode, kStackParameterPhase + ((whichParam) - 1) * kStackParameterWidth )
}


CONST
	uppReadNVRAMProcInfo = kD0DispatchedPascalStackBased
		 + RESULT_SIZE(SIZE_CODE(sizeof(SignedByte)))
		 + STACK_ROUTINE_PARAMETER(1, SIZE_CODE(sizeof(Integer)))
		 + STACK_ROUTINE_PARAMETER(2, SIZE_CODE(sizeof(LongInt)));


	uppWriteNVRAMProcInfo = kD0DispatchedPascalStackBased
		 + STACK_ROUTINE_PARAMETER(1, SIZE_CODE(sizeof(Integer)))
		 + STACK_ROUTINE_PARAMETER(2, SIZE_CODE(sizeof(LongInt)))
		 + STACK_ROUTINE_PARAMETER(3, SIZE_CODE(sizeof(SignedByte)));


	kReadNVRAMSelector			=	$022E;
	kWriteNVRAMSelector 		=	$032F;


FUNCTION ReadNVRAMByte(offset: LongInt): SignedByte;
{$IFC TARGET_OS_MAC AND TARGET_CPU_68K AND NOT TARGET_RT_MAC_CFM}
INLINE $303C, $022E, $AAF3;
{$ELSEC}
BEGIN
	ReadNVRAMByte := CallUniversalProc( GetToolboxTrapAddress( _ExpansionManager ), uppReadNVRAMProcInfo, kReadNVRAMSelector, offset);
END;
{$ENDC}

PROCEDURE WriteNVRAMByte(offset: LongInt; value: SignedByte);
{$IFC TARGET_OS_MAC AND TARGET_CPU_68K AND NOT TARGET_RT_MAC_CFM}
INLINE $303C, $032F, $AAF3;
{$ELSEC}
BEGIN
	IF CallUniversalProc( GetToolboxTrapAddress( _ExpansionManager ), uppWriteNVRAMProcInfo, kWriteNVRAMSelector, offset, value ) = 0 THEN;
END;
{$ENDC}

 

[KnobsNSwitches]

I just wanted to say thanks to @cheesestraws for this hack!

I purchased a tango 2.0 NIB on ebay awhile ago, but never installed it. I assumed it was the original version that worked on the TAM, as it said TAM on the box...but it didn't work with the original sonnet firmware patch.

But with Tango2.0new from this thread, it's working on my TAM.
Now if only my 3rd gen iPod would behave itself in Mac OS 9....