SE/30 RAM Banking QUESTION

JDW

Administrator
Staff member
Founder
Sep 2, 2021
1,577
1,373
113
53
Japan
youtube.com
According to this LEM page, unless you are installing 17MB, you should be putting the larger sized SIMMs into Bank A, with the smaller sized SIMMs into Bank B.

1673218405359.png

However, when I put four 16MB SIMMs into Bank A, and nothing in Bank B, I get death chimes and a crazy display. But if then put 4 sticks of 4MB SIMMs into Bank A and my 4pcs of 16MB SIMMs into Bank B, then the Mac boots just fine and shows the correct 82MB of RAM in the Finder.

No doubt at least one of you have tried this with 16MB SIMMs before, so what are your thoughts? Is this another except to the rule like when installed 17MB of RAM? Please read the LEM article for more info.)
 
  • Like
Reactions: retr01

croissantking

Tinkerer
Feb 7, 2023
89
37
18
Very interesting. I've obviously not tried that app. :)

This raises the importance of have a comprehensive list of vintage software that works fine in 24-bit mode but which crashes in 32-bit. Would be interesting to see how many apps beyond Shufflepuck are affected.
This is a great idea actually.
Given the possible compatibility problems with non-32-bit-clean software when running in 32 bit addressing mode, I have chosen to just run in 24-bit mode anyway.
This is likely a little over-cautious. Unless you have software you specifically want to run that's incompatible, you may as well just leave 32-bit mode enabled - and disable as necessary.
 
Last edited:

MacOfAllTrades

Tinkerer
Oct 5, 2022
168
183
43
This is likely a little over-cautious. Unless you have software you specifically want to run that's incompatible, you may as well just leave 32-bit mode enabled - and disable as necessary.

You're probably right -- My reasoning was that I got a bunch of games and such for my SE first and many of them were from the time or earlier when the SE was the new computer (so like before 1987). So as a result a lot of the applications I have installed on my SE/30 were just copied over from the applications I had on my SE.

Long story short, I tried like 5 of my applications in 32-bit mode and 2 of them crashed unless I was in 24-bit mode (Arkanoid maybe and one other one).

System 7 was introduced in 1991 and it had 32-bit addressing as an option out the gate. The Macintosh II was advertised as 32-bit and had 32-bit memory addressing support... So I guess any software released before 1991 is 'sus' though I assume Apple gave developers a heads up some time (maybe years maybe months?) in advance to get them to update their apps to be 32-bit clean. I don't know what was involved (by the time THINK C 5 .0 came out it was just a check-box in one of the settings windows...). Definitely any software released before the MacII's introduction in 1987 is almost definitely 24-bit.
 

Patrick

Tinkerer
Oct 26, 2021
434
1
224
43
related but slightly off topic. It is Andy Hertzfeld apologizing for using the bits above 24 when creating the OS. Which created a pattern for other developers to follow.

Its a pretty good post that talks about decisions one makes that you don't always fully know the consequences. (in this case, leading toward programs not working in 32-bit mode.)
 
  • Like
Reactions: MacOfAllTrades

MacOfAllTrades

Tinkerer
Oct 5, 2022
168
183
43
related but slightly off topic. It is Andy Hertzfeld apologizing for using the bits above 24 when creating the OS. Which created a pattern for other developers to follow.

Its a pretty good post that talks about decisions one makes that you don't always fully know the consequences. (in this case, leading toward programs not working in 32-bit mode.)
Ah thanks! Makes sense.

So a “master pointer” is a structure that includes a pointer to a pointer. That inner pointer points to the memory for the application to use. When you call GetHandle(..) you are returned a handle that is the pointer to the pointer and the memory manager will have allocated the memory for you so you are good to use that pointer. But the whole point of master pointers is that the system can manage memory invisibly to your application by moving around the memory your data uses without you knowing (as long as you double dereference the pointer to the pointer you are good). They give you a way to tag your memory so that the memory manager won’t move your memory behind the scenes as there are times when appropriate (it’s up to you the developer to decide tho! One example is if youre using a function that works on a pointer to memory then you give it the dereferenced handle but if you don’t tag that block as Locked then the OS might move your memory while you’re working with the pointer! Purgeable is more a you can be a good citizen and tell the OS it is ok if you take this memory away from me and I can just repopulate it later or whatever.) These are the locked and purgeable attributes Andy mentions.

So he / the mac team had to store those flags somewhere so the system would know if a block of memory was purgeable or locked and he used some of the 8 bits that were of no use to the 68000 chip since it could only address 24 bits of memory it would never use the remaining 8 bits in the 32-bit address. A nice use if a wasted byte of memory that comes in every 32-bit address but alas the pitfall is clear with hindsight ;-)

Sounds like some developers started using some of those 8 bits as well. And the result is what we all call “32-bit dirty” because by the time system 7 came, those bits were used as actual parts of valid addresses of memory so nobody (not the OS or the applications) could do anything with them. System 7 had updated its mem managers etc to not use them so it was clean from the get go but apps that had gotten away with being slick with those bits now had problems because they were accessing and manipulating memory that was not what they thought it was (likely belonging to other apps or the system) and of course that would cause problems.

Sorry for my diatribe i just thought someone might be interested in some deeper info. Anyone plz correct anything I got wrong