Jul 90 Mousehole
Volume Number: 6
Issue Number: 7
Column Tag: Mousehole Report
Mac IIfx and MacApp 
By Larry Nedry, Mousehole BBS
From: Dhands
Re: MacII vs MacIIfx
I had the opportunity to compare a Mac II and a Mac IIfx on MPW compile/link times
and here are the results. The command executed was a complete rebuild of 5 MacApp
examples repeated 5 times, average total time in seconds.
MABuild -make -e “{MAExamples}Calc:Calc”
MABuild -make -e “{MAExamples}Cards:Cards”
MABuild -make -e “{MAExamples}DemoDialogs:DemoDialogs”
MABuild -make -e “{MAExamples}DemoText:DemoText”
MABuild -make -e “{MAExamples}Nothing:Nothing”
RAM Cache | Mac II | Mac IIfx | II:IIfx
Off | 1495 | 870 | 1:1.7
512k | 842 | 374 | 1:2.25
I was sort of surprised that the IIfx was “only” 2.25 times faster (in this test) than
the II. I was expecting at least 3x based on Apples press and other reviews. This is a
narrow view of the IIfx speed, but to a software developer the compile/link time is an
important bench mark.
Both Macs were running Multifinder 6.1, System 6.0.5, MPW 3.1, 2 meg. MPW
partition.
From: Nobutoge
Re: MacII vs MacIIfx
Interesting. It may be because MPW takes a lot of disk I/Os to get compile/link done
and those I/O periods basically remain the same whether you are on the II or IIfx [I
don’t know... this is just my guess. I mean that the IIfx may be fast on the I/O
processing but the time to get to right sectors on the disk would remain the same.]
From: John Hestenes [Mousehole: Johnh;Compuserve: 76216,1540]
Re: Console/tty for MPW C++/C
I need information to obtain or build a console or tty window and keyboard interface in
C code to support STDIN,STDOUT and STDERR streams and CIN, COUT and CERR in
applications (not within MPW as a tool). I am using a Mac IIcx, 4MB RAM, 40MB
disk, System 6.0.4, MPW C++, C and assembler. The standard MPW manuals appear
to omit needed information to do this. This interface is needed for teaching university
students (Drexel University, PA) C++ from the standard C++ books so the code may
be compiled also on UNIX and IBM-compatible systems. I am aware of “console”
implementations in THINK C and other Mac compilers. Were is it for MPW? Any help
is appreciated!
From: Atom
Re: console/tty for MPW C/C++?
Language Systems has a nice console window for their MPW Fortran compiler that
could be used. It’s scrollable and editable and there are documented routines to send
text to and from it from any MPW language. To use it in C++ you would create a custom
streambuf class, make its overflow and underflow methods call the LS code, and assign
the standard C++ streams to instances of it. I hope this helps.
From: Noisy
Re: Mystery globals & Macsbug
If you can’t get something to work...see how someone else did it. This works fine until I
decided to peer into the guts of MacsBug to try and determine how to implement a
breakpoint in ROM. While Nosying around, I discovered a rather interesting
phenomenon: there are no CODE resources (or recognizable object code as ANY
resource) in the MacsBug file. Hacking at the boot code revealed that a low ram global
($120) the Nosy titled ‘MacJmp’ got bashed around a lot during MacsBug installation.
Any sages out there able to identify this beasty and how MacsBug interacts with the
rest of the world?
From: Mrteague
Re: Mystery globals & Macsbug
I too learn by hacking other people’s work. Although at one time I probably reverse
engineered MacsBug and System Boot up, I have forgotten some of it. But I can tell you
the way *I expect* MacsBug interacts with the rest of the world. It all revolves around
the idea of exceptions on the 680x0 family, and the associated exception (interrupt)
vectors that are stored in low memory (I think $100 on). Normally the ROM vectors
them to the System Error trap - like if you don’t have MacsBug installed, and you get
an Address error, you will be greeted with the bomb box with ID = 2. However if
MacsBug is present in your System Folder on bootup, the bootup code loads the data
fork of MacsBug (that’s why you don’t see any CODE resources etc, if you having been
looking with ResEdit) into high memory (where BufPtr points to, and subsequently the
value of BufPtr is set to below MacsBug for other uses), and patches the interrupt
vectors to point to MacsBug entry point(s), and probably MacJmp as well (I haven’t
bo thered worrying about that particular interaction). Now when you get an address
error, you will dropped into MacsBug. MacJmp is probably used when tracing or
single-stepping through code among other things. The newer versions of MacsBug are
much more sophisticated than earlier versions, in that they have user callable
routines to do things like get data from a user, and display data to the user - so there is
probably some kind of jump table in MacsBug for the various common routines.
Among more interesting things, I think MacsBug keeps a checksum on itself, so it can if
it ever gets corrupted (I’m sure you have seen some of the infamous “MacsBug caused
an exception” type of msgs). I tried patching MacsBug 6.x once, to allow use of
alternate keyboard chars rather than up/down arrow of the ADB
From: Cforden
Re: 2 questions re: Memory Mgmt.
1. Is there any disadvantage to calling MaxApplZone() at the beginning of a program?
It seems like it would be very handy to always know how much memory was actually
available. If MaxApplZone() is not called first, then FreeMem() seems to not report
any memory that would automatically be added to the application heap if needed.
2. Is there any nice way to detect a failure of the segment loader to load a CODE
segment (due to, for example, an out-of-memory condition)? I presume such an
occurrence would likely result in something ungraceful happening, like a system
crash. The only way I can think of doing something about this is to call
GetResource(‘CODE’, xxx) before any subroutine call that might not get loaded
successfully and check for a NIL handle. However, that approach would get tedious if
used often.
From: Mrteague
Re: 2 questions re: Memory Mgmt.
1) The only disadvantages to calling MaxApplZone at the beginning of your program I
can think of - if you wanted to reduce the size of the current heap zone by say
modifying BufPtr or the stack size sometime in your program (you should do these
first before MaxApplZone), and there would be no room to do this, if the zone was
extended to it’s fullest first. Or things like DAs etc. that wanted their own heap couldn’t
do it. Probably less of a problem now with MultiFinder and newer System software.
2) The only way I can think of trapping failure of the segment loader to load a CODE
Referenced by (2):