68k Determining amount of installed RAM

[ryandesign]

I'm having trouble programmatically determining how much memory is in the computer.

For the original Macintosh and later systems not running MultiFinder, the answer seems to be the TopMem() function, which returns the _MemTop global variable. However when running MultiFinder it returns the end of the current program's address space, not the machine's.

Gestalt has the gestaltPhysicalRAMSize and gestaltLogicalRAMSize selectors I could use, but Gestalt is only in System 6.0.4 and later. What do I do for System 6.0.3 and earlier when running MultiFinder?

 

[ryandesign]

I've now found a copy of Tech Note OV-17, MultiFinder Revisited: The 6.0 System, which seems to have the answer I'm looking for: MFTopMem(). (It mentions that MFTopMem() is documented incorrectly in the Programmer's Guide to MultiFinder and provides a corrected description.) My MPW 3.5 universal headers tell me that MFTopMem() is now called TempTopMem(). Unfortunately my THINK C 4 doesn't seem to know either of those names.

The next hurdle will be to know when to use TempTopMem() and when to use TopMem() since, in answer to the question "How Can I Tell If MultiFinder is Present?", OV-17 reminds us that "you cannot," though I choose not to believe that.

Over the years I've found many references to how the Programmer's Guide to MultiFinder is essential reading but I've never found an actual copy of it online. If anybody has it, please put it on archive.org!

 

[ryandesign]

Tech Note TB-14, MultiFinder Frequently Asked Questions, answers the question "How can I tell if the MultiFinder Temporary Memory Allocation calls are implemented?" (Check if the _OSDispatch trap A88F is implemented.)

 

[ryandesign]

Unfortunately my THINK C 4 doesn't seem to know either of those names.

Yes it does, I just have to #include <MultiFinder.h> first. That's not one of the headers that are auto-included via MacHeaders.

 

[JDW]

Tagging @David Cook , as he might find this dialog interesting.
(I myself found it interesting because the same person is both asking and answering!)

 

[ryandesign]

I find asking for help is often a great way to cause the answer magically to reveal itself.

If you wish to see this function put to use in an actual program, see https://github.com/ryandesign/memdump

The commit that added the code for this is https://github.com/ryandesign/memdump/commit/ff64fc537790e7d415306d39f7753a666898088e

 

[David Cook]

Looks good.

BTW: Gestalt in often implemented in compiler glue to provide basic services when the OS doesn't actually have Gestalt. Not sure whether Think C 4 provides that or not. For example, Apple provided this code, which (you'll be happy to see) mimics what you have already implemented.

************************************************************************ * RAM Size ************************************************************************ OSDispatchTrap EQU $A88F ;MultiFinder trap getRAMSize move.w #Unimplemented,D0 ; get loc of unimplemented trap _GetTrapAddress ,newTool ; get the address into A0 move.l A0,D2 ; save it for a sec move.l #OSDispatchTrap,D0 ; trap ID to check for multifinder _GetTrapAddress ,newTool ; get the address of it move.l MemTop,d0 ; assume multifinder is not running cmp.l A0,D2 ; is it unimplemented? beq.s @ramDone ; if not, we're done subq.l #4,sp ; make room for result move.w #$0016,-(sp) ; selector for total physical memory _OSDispatch ; get the value move.l (sp)+,d0 ; get it into d0 @ramDone bra gestaltGlueCommon ; save result and exit

 

[ryandesign]

Oh! You know, I've been spending too much time with Retro68, where you don't get much glue. I remembered that other environments have glue for SysEnvirons but I forgot about glue for Gestalt.

According to THINK Reference, "If you are using THINK C 5.0 or later, THINK Pascal 4.0 or later, or the MPW development system version 3.2 or later, […] these versions provides glue routines that allow you to call Gestalt, NewGestalt, and ReplaceGestalt even if they are not in ROM or in the System file." THINK C 4 doesn't seem to know anything about Gestalt; I get a link error when I try to call it. I suppose that makes sence since THINK C 4 was released on 1989-07-09 and there was no Gestalt until System 6.0.4 was released on 1989-09-20.

Unfortunately, I had previously found that THINK C 5 had removed glue for 64K ROMs, e.g. MaxApplZone; 64K ROM compatibility is a requirement for my project. I've now tried using Gestalt in THINK C 5 and it did generate the glue you posted. Unfortunately, under the 64K ROM, Gestalt is returning an error (a positive number not documented as a possible return value) and then crashes. Under the 128K ROM it works correctly.

I have some of my own 64K ROM glue routines written, but for this project I thought I'd try to use THINK C 4. Its bizarre keyboard shortcut choices are making it fairly frustrating. I should probably fix that with ResEdit.

On the plus side, my app is 242 bytes smaller when using my code instead of the THINK C 5 Gestalt glue, plus my version returns the right info and doesn't crash.

 

[David Cook]

64K ROM compatibility is a requirement for my project.

If you want to be compatible with Apple's Switcher, don't forget to check it's low memory global before calling MFTopMem. Otherwise you'll crash (?) or get the wrong value. See Technical Note #158.

my app is 242 bytes smaller when using my code instead of the THINK C 5

That is so funny. I've been updating my Tiny Transfer program and cringing as I consume an extra 100 bytes here and there. Part of me considers ditching Mac 128K compatibility, but another part enjoys the challenge of coding for size.

 

[ryandesign]

The size difference is pretty negligible, but the glue does include support for a bunch of Gestalt selectors I'll never use so it just seems wasteful to ship that code in my app.

I do care about Switcher—at least about not crashing under Switcher or other unusual configurations even if I can't get the right RAM size result.

I had read that old version of the tech note* and tried my program under an old version of Switcher and it did not crash. (It reported the RAM size as the program's memory partition size.) I will retry with newer Switcher versions; maybe the JugglDispatch trap wasn't part of Switcher until later.

*I "love" Apple's habit of updating tech notes to remove information or even the entire contents of notes. Another project on my todo list is to find the original MacWrite versions of all revisions of all tech notes ever, convert them to Markdown, and put them on GitHub. Or perhaps you already know of someone who's done that?