What's the point of being 32-bit clean?

[bigmessowires]

Could someone help refresh my memory on what it means to be 32-bit clean, and why it matters? I remember the general concept - In a 32-bit address pointer, some older ROM versions (and software) used 8 bits as if they were extra flags instead of part of the address. ROMs that did this were not "32-bit clean". Connectix eventually came out with an INIT that patched these older ROMs to make them 32-bit clean.

What I don't really remember is why this is important. I think if your ROM wasn't 32-bit clean, you couldn't have more than a certain amount of RAM? Like 8MB max? Was that basically the only limitation of not being 32-bit clean?

Does anyone remember which System version introduced the ability to switch between 24-bit and 32-bit addressing in the memory control panel?

Which System version included Connectix's patch as a default part of the MacOS?

Which System version requires 32-bit clean ROMs?

Thanks for helping to shine some light into the shadowy cobwebs of my brain.

 

[olePigeon]

You could run System 6 in 32-bit mode with an enabler.  System 7, I believe, was the first system to let you toggle between the two in the Memory control panel.

32-bit clean ROMs just means that the system will let you run it in 32-bit mode without an enabler.  Otherwise you'll need one such as 32-bit Enabler or MODE32.

 

[TheWhiteFalcon]

7.6 was the first one that needed 32-bit clean IIRC.

 

[rsolberg]

System 7.6 and later require 32-bit clean ROMs.

 

[bigmessowires]

OK, and why do people care about 32-bit clean ROMs? Was I right about it being required in order to access more than 8 MB of RAM? Otherwise, what's the point of it?

 

[360alaska]

For SE/30 you can't do more the 8 without mode32 or a 32 clean rom... If you install a 32-bit clean rom you can run 7.6 and also os 8.1.

 

[Gorgonops]

Technically speaking "32 bit clean" doesn't just apply to the ROMs. In the early days there were a lot of non-32-bit clean applications, which caused Apple some grief as early as the System 6 days because, of all things, A/UX. A/UX required essentially "virtualizing" MacOS and any piece of software which wasn't 32 bit clean would trigger an illegal access trap by the MMU regardless of how much RAM one set aside for the Mac environment. (Later versions of A/UX *can* actually bring up a 24 bit addressing mode MacOS session, but at the cost of losing the ability to interact with the Unix running underneath because the horrible gymnastics the OS has to do to remap the same space 256 times over into the same process makes it basically impossible to do shared buffers with it safely.) Apple was working pretty hard to get application authors to cut it out well before System 7 even hit the streets.

And, yes, the reason for having 32 bit addressing is (mostly) to enable access to more than 8MB of RAM. However, it's also required for some NuBus peripherals to function at full capacity because the 24 bit addressing model limits you to 1MB of memory space per slot. Some video and other cards exceed this.

 

[uniserver]

the majority of people that buy rom's like the 8meg version, and they are SE/30 users.   They like clean roms because it gives them the opportunity to go past 7.5.5 all the way to 8.1…. witch with the 50mhz 030 pds upgrade card, screams.  Also 128 megs of ram just work…   again most people that buy roms like the 8meg rom because of the 7.5 megs of free space to build their own custom bootable rom.

 

[pathw]

I've never seen any discussion of this, but I assume that using MODE32 to access more than 8M of memory introduces a performance penalty. Capturing and remapping addresses in software sounds like a drag on performance to me. Have to think about whether there is an easy way to evaluate this on my Mac II ...

 

[Paralel]

I think it has been studied. As far as I'm aware it is fairly negligible in terms of typical usage patterns.

 

[Gorgonops]

I don't think MODE32 "captures" anything. Pretty sure it just replaces some dirty routines in the Mac's native ROM with ram resident replacements, similar to, for instance, the HD20 init replaces the floppy driver in early Macs' ROMs. Apple designed the ROM to accommodate software fixes like that by having most routines detour through a jump table maintained in RAM, so the "cost" should be essentially zero. (The code path goes through the same jump table even if you're using the ROM version anyway.)

 

[pathw]

> Pretty sure it just replaces some dirty routines in the Mac's native ROM with ram resident replacements

Thanks. That makes sense.

To answer the original question "why it matters?", the following may be useful: (https://support.apple.com/kb/TA47454?locale=en_US&viewlocale=en_US). It mentions being able to address more than 8M of memory, but also more efficient implementation of virtual memory (address space is contiguous). This  also means support for larger virtual memory, not just physical memory.

 

[bobo68]

see: https://en.wikipedia.org/wiki/Mac_OS_memory_management#32-bit_clean

 

[olePigeon]

I just realized something when a client of mine tried to install System 7.5 on an SE/30 with a dirty ROM.  It would get BUS errors and Sad Macs.  He did eventually get it to boot, but it started complaining that there wasn't enough memory.  I told him to make sure that the 32-bit Enabler was installed, and it was, except that the 32-bit Enabler only works with System 7.1

So I did some Googling, and low and behold, there's an Apple FAQ about just this issue.  System 7.5 won't install/run properlyl on a 32-bit dirty ROM, it has to be clean.  I'm surprised he got as far as he did.  I was prepared to send him a new motherboard and SCSI2SD, I couldn't understand why it wasn't working when it was working beautifully with System 7.1.1.

Now I know.

And knowing is half the battle.

G. I. Joe!

 

[tanaquil]

That's interesting, I didn't know that the SE/30 required a clean ROM for system 7.5. Now I know!

 

[CC_333]

Why, then, does 7.5.x work 100% fine on every SE/30 with stock ROMs I've ever tried it on?

Or am I missing something?

c

 

[rsolberg]

CC_333, you're not missing anything. Something else must be going on. System 7.5.x will install on a 32-bit dirty ROM. My guess is a problem with the installer, an incompatible version, (7.5.2 is PCI PPC only) or a leftover extension from 7.1 such as an old/incompatible version of the MODE32 control panel. (this will cause bus errors and sad Macs due to it patching the System file incorrectly) I've only ever installed 7.5.3, then updated to 7.5.5, but I've done so on many 32-bit dirty ROM Macs including SE/30s.

 

[olePigeon]

You have 8MBs of RAM or less?

 

[olePigeon]

No, wait.  I must be thinking of System 7.6.