thecloud@pnet06.cts.com (Ken Mcleod) (06/18/88)
Yet another MultiFinder-related question, to accompany "how do I tell
whether MultiFinder is running, now that WNE is always implemented...":
How do I determine how much RAM is installed in the machine I am
running on under MultiFinder? I can't get this info through MemTop
anymore. There are potentially dangerous ways, involving assumptions
about the address of the screen base, etc., and I suppose I could
always write an INIT to save off MemTop before MultiFinder gets its
hands on it, but there has to be a good "new method."
Any answers to this two-headed problem would be appreciated greatly.
Ken McLeod ========================= ....... ======================
UUCP: {crash uunet}!pnet06!thecloud :. .: Chief Weapons of UNIX:
ARPA: crash!pnet06!thecloud@nosc.mil :::.. ..::: "Fear, surprise, and
INET: thecloud@pnet06.cts.com //// ruthless efficiency."dan@Apple.COM (Dan Allen) (06/22/88)
In article <231@hodge.UUCP> thecloud@pnet06.cts.com (Ken Mcleod) writes: > How do I determine how much RAM is installed in the machine I am >running on under MultiFinder? I can't get this info through MemTop >anymore. There are potentially dangerous ways, involving assumptions >about the address of the screen base, etc., and I suppose I could >always write an INIT to save off MemTop before MultiFinder gets its >hands on it, but there has to be a good "new method." This "feature" of MultiFinder is one of the most brain-damaged aspects of MultiFinder: changing MemTop. And not only do they change it (to help with compatibility with one or two apps), they FORGOT to document their call that returns the right value. I've yelled and yelled, but they won't leave MemTop alone... Here's the call as a Pascal inline: FUNCTION MFMemTop: LongInt; INLINE $3F3C,$0016,$A88F; Have a nice day. And if Erich and/or Phil are listening, (and they are both my friends, or at least were!) FIX MEMTOP!!! Dan Allen
tedj@hpcilzb.HP.COM (Ted Johnson) (06/22/88)
>Here's the call as a Pascal inline: > >FUNCTION MFMemTop: LongInt; INLINE $3F3C,$0016,$A88F; Do any of you LSC gurus out there know how to convert this to LSC? -Ted
fry@huma1.HARVARD.EDU (David Fry) (06/24/88)
In article <730037@hpcilzb.HP.COM> tedj@hpcilzb.HP.COM (Ted Johnson) writes: > >>Here's the call as a Pascal inline: >> >>FUNCTION MFMemTop: LongInt; INLINE $3F3C,$0016,$A88F; > >Do any of you LSC gurus out there know how to convert this to LSC? > pascal long MFMemTop() = 0xa88f; David Fry fry@huma1.harvard.EDU Department of Mathematics fry@huma1.bitnet Harvard University ...!harvard!huma1!fry Cambridge, MA 02138
fry@huma1.HARVARD.EDU (David Fry) (06/24/88)
In article <4817@husc6.harvard.edu> fry@huma1.UUCP I write: >In article <730037@hpcilzb.HP.COM> tedj@hpcilzb.HP.COM (Ted Johnson) writes: >> >>>Here's the call as a Pascal inline: >>> >>>FUNCTION MFMemTop: LongInt; INLINE $3F3C,$0016,$A88F; >> >>Do any of you LSC gurus out there know how to convert this to LSC? >> > >pascal long MFMemTop() = 0xa88f; Oops, that's wrong! This is right: #define MFMemTopNum 0x0016 pascal long OSDispatch(short) = 0xa88f; long MFMemTop() { return( OSDispatch(MFMemTopNum) ); } David Fry fry@huma1.harvard.EDU Department of Mathematics fry@huma1.bitnet Harvard University ...!harvard!huma1!fry Cambridge, MA 02138
earleh@eleazar.dartmouth.edu (Earle R. Horton) (06/24/88)
In article <730037@hpcilzb.HP.COM> tedj@hpcilzb.HP.COM (Ted Johnson) writes: > >>Here's the call as a Pascal inline: >> >>FUNCTION MFMemTop: LongInt; INLINE $3F3C,$0016,$A88F; > >Do any of you LSC gurus out there know how to convert this to LSC? > >-Ted long MFMemTop() { asm{ clr.l -(a7) ; Make room for return value. move.w #0x0016,-(a7) ; Push routine selector. dc.w 0xa88f ; JugglerDispatch move.l (a7)+,d0 ; Pop result into d0 } } The process I used to determine this may be of interest: Get into MacsBug >dh 3f3c0016 000000: 3F3C0016 MOVE.W #$0016,-(A7) That means the Trap wants a 0x0016, presumably as a routine selector. Since the function is declared as a Pascal function, we have to make room for the return value on the stack, then we pass it the selector. Call the trap, pop the result into d0, and we are done. This routine produces seemingly correct results on both machines I have tried it on. Flame section: Did the originator of the MPW Pascal INLINE code it first as shown, or did he use an assembler to determine the instructions to use? Either way, at some point he had to use an assembler or a Motorola handbook to find out that "move.w <word>,-(a7)" translates to "$3F3C <word>." I suspect that most of us would rather have the assembly code in addition to the hex code. In fact, I make the following suggestion: EVEN THOUGH THIS IS A PROGRAMMER'S NEWSGROUP, I FEEL THAT POSTING CODE IN HEX IS NOT THE LEAST BIT INSTRUCTIVE. PLEASE POST THE ASSEMBLY SOURCE IN ADDITION TO THE INLINE DECLARATION, SO WE CAN SEE WHAT YOU ARE DOING. End flame section.
thecloud@pnet06.cts.com (Ken Mcleod) (06/24/88)
Don't forget...you have to pass 22 ($16) to MFMemTop() in order to
get the correct value returned.
Ken McLeod ========================= ....... ======================
UUCP: {crash uunet}!pnet06!thecloud :. .: Chief Weapons of UNIX:
ARPA: crash!pnet06!thecloud@nosc.mil :::.. ..::: "Fear, surprise, and
INET: thecloud@pnet06.cts.com //// ruthless efficiency."