Search results

Yes, it varies. Some (non-SuperMac) cards hang on boot so they're fully incompatible. Some cards (like SuperMac) are just not fully configurable so they "work" but occasionally that can cause problems when you need to change the configuration :). Even then, SuperMac cards can't change display...

Oh curious...I'm surprised it boots at all with no PROM. Maybe it's detecting the chip type before flashing and doesn't recognize it? Or you actually flashed it manually and it refuses to even read it?

Ah good point. I think 3.0 adds support for PowerPC, just 1.7.2 is required for proper 7.5.2+ compatibility.

268/256 matches the Sonic LC and Etherlan cards. I'd be surprised if that driver doesn't work (it certainly wouldn't be to spec for that not to work, since, if I remember my read of Designing Cards correctly, drivers match this 4-tuple).

What's the DrSW and DrHW on the Network sResource? If I remember correctly they need to be 260/256 to match the generic DP8390 drivers. You could try programming another ROM with the DeclROM modified to match those. But who knows if it's mapped memory to the same regions...so it might work or...

In case anyone else stumbles here: ROM 3.0 should be good on 7.5.2+.

Likely dynamic addresses based on the ROM version it's patching?

Glad to hear it! You might try leaving auto-negotiation on (since it's easier to manage). Only some cards (mostly Asante?) are affected by the issues there so it's good to know if you don't have to bother. If you do leave it on manual configuration, I believe these are only half-duplex.

SSI stickers on the chips confirms this is a Sonic Systems card. Dumping the ROM would reveal more.

It looks like it patches the location of the StartBoot pointer. That seems to lend credence to the theory it's remapping memory before CPU execution starts since they're patching pretty close to the first entry point.

Yeah. Swapped it and updated the env vars that were slightly different. It seemed to start up and migrate all the resource forks properly.

Dang that's a sweet upgrade! My 180MHz R5K O2 can only be described as "sluggish". I imagine that screams, very nice work including the home-brew programming. Are you using the latest system PROM? It's possible it has better R7K support if not.

Yep! That made the difference. So debug needs to be enabled to expose the words to patch. Let me hunt for the proper offset: If I understand correctly, I'm looking to patch the statement just after the (endcase). findandadd-block starts at ff93b210 and the statement after is ff93b5bc. That's...

Just wanted to report upgrading my Docker container from 2.x to 4.0.1 worked great. So far my machines of all vintage are connecting correctly.

Dumb question, but have you tried just using it? With an ST-NIC on board (probably a DP8930) it might be compatible with the built-in drivers. A surprising number of cards used the same hardware configuration (probably the reference design) so they are driver compatible. Alternatively the Mac...

Yeah, that's when I realized it couldn't find the words. Yeah, I see where you're going with that and I had started to wonder the same thing myself...will test tomorrow if I have a chance. If that at least applies the patch, I can tinker with the offset!

I futzed around for awhile and realized I wasn't understanding the Forth errors. It seems like the findandadd-block words aren't defined in this ROM and/or package? 0 > dev /packages/bootpath-search ok 0 > : mypatch { ; loc0 loc1 loc2 loc3 loc4 } loc4 6 = if loc0 findandadd-block-usb then ...

Interesting. Just to confirm, this is specifically what's in my nvramrc: \ Enable OS 9 boot selection (MacRISC, MacRISC2) " /" select-dev " PowerMac10,1" encode-string " MacRISC" encode-string encode+ " MacRISC2" encode-string encode+ " MacRISC3" encode-string encode+ " Power Macintosh"...

A water slide decal might work...swear I've seen someone else here give those a try.

[double post]