Jan 88 Letters
Volume Number: 4
Issue Number: 1
Column Tag: Letters
Letters
By David E. Smith, Editor & Publisher, MacTutor
Colorizer Restores CMD-Shift-3
Kenelm W. Philip
Fairbanks, AK
I think you owe an apology to Joel West (Palomar Software). In the November
issue of MacTutor, you comment on page 12: “There is still no way to capture the
screen image of a color display.” On page 6 of the same issue is an ad for Colorizer,
which mentions that this program will “Record full-color screen images to disk or
printer”. Apparently the left hand knoweth not what the right hand is doing
As a satisfied user of Colorizer, I can vouch for the fact that the package contains
an FKey which will dump a color screen to disk as a PICT file. To my mind, this FKey
alone is worth the price of the package. [We agree! -Ed]
Finally, a tip that may be worth passing on to those Mac II owners who happen to
have more than one monitor hooked up: If you hold down the Command key when you
drag the grow box on a window, you can overcome the built-in limits on window size
that many programs have (for example: Reflex+), but fails for a few (for example:
MacWrite 4.6, whose window will snap back to the built-in limit as soon as you
release the grow box). [If Reflex Plus has any limitation on it’s window size, we can’t
see it on an Apple color monitor! -Ed]
IBM Versus Mac
Romanas J. Buskus
Just read one of those evaluation articles in Information Week that compared the
IBM PS/2 Model 25 with the Mac SE. Before I go any further, I should tell you that
Information Week is slanted toward IBM and thinks they are the greatest thing since
sliced bread. I would even go as far as to say that the entire editorial staff wears blue
underwear. So, is it any wonder that the Model 25 got 101 lines of evaluation text
while the SE got only 59. (The author stated that the SE’s “biggest drawback may still
be the fact that it’s not built by IBM). Even still, this is progress. A year ago, the SE
would have been called a toy. The IBM’ers are beginning to realize that the MAC is a
powerful business machine and are starting to make ridiculous compromises. For
example, the article presented the author’s idea of the “Dream Machine”. It is as
follows:
The Configuration:
• 101-key IBM keyboard (Apple’s keyboard doesn’t “feel” like an IBM)
• Apple mouse and controller software (thought they didn’t like mice?)
• 13-inch VGA color monitor (small screen?)
• Apple 3.5-inch disk drives (doesn’t IBM make these?)
• 20-Mbyte hard disk (I thought this was a dream machine!)
• Apple tutorial and documentation (Apple’s is more FUN!)
• Mac OS with DOS compatibility (for old time’s sake)
• IBM SAA and Appletalk compatibility (can’t figure this one)
List Price:
• Under $2000.00 (now you’re talking!!!)
Who is this guy?
68020 versus 80386
William Clodius
Los Alamos, NM
I have a few comments on the recent discussions that have appeared in your
magazine on the relative performance of the 80386+80387 compared with
68020+68881. I believe your readers are incorrect in implying that a flawed design
necessarily implies lower performance. The problems with the 80x86 design include
the use of segmented memory, a smaller number of registers, and incompatible
memory modes for different sizes of memory space (the 80286 protected mode
problem). These problems complicate the design of programs, particularly of large
ones, and make it impossible to write a program for earlier chips that take advantage
of the larger memory space of subsequent chips. The need to implement several
memory modes on the 80386 also increased the complexity of the design, and hence
may be a contributing factor to Intel’s well publicized difficulty in manufacturing the
80386.
However, while the above problems complicate a programmer’s task and increase
the cost of a working 80386+80387 system, they do not directly affect the
performance of the system. For systems of comparable complexity, ie. two CISC
designs, the performance should be roughly proportional to the MIPS rating. Because
the 80386 includes the MMU on chip and uses a higher transistor density to
implement faster algorithms for some instructions, it takes one to two less clock
cycles than the MC68020 with MMU to perform an instruction so that it is effectively
15-33% faster than the MC68020 at the same clock speed. This increased
performance is not unreasonable given that the 80386 appeared well over a year after
the MC68020, and its designers could both study the MC68020 for ideas and take
advantage of improvements in manufacturing technology. However, it is significantly
less than that suggested by the recent notorious Byte articles.
The above disagrees with analyses by some of your readers that assume that the
80386+80387 differs in performance from the 80286+80287 only by a factor
proportional to their clock speed. However, by the same reasoning a 16MHz MC68020
should be only twice as fast as an 8MHz MC68000, instead of about four times as fast.
In such comparisons it should be noted that a 32-bit bus in and of itself will give an
additional factor of two improvement for 32-bit operations over a 16-bit bus (ie.
floating point operations), and can give additional performance increases for 8- and
16-bit operations by using the registers as caches and by sometimes performing
operations in parallel. Further performance increases occur for newer designs
because the increased transistor density allows the implementation of faster
algorithms and special techniques, such as putting the MMU on chip, to reduce the
number of clock cycles per instruction. Such techniques allow the MC68030 to be
about 50% faster than the MC68020. The increased transistor density also allows the
use of new instructions, such as the transcendentals implemented on both the 80387
and MC68881. As a result, your readers should not predict the performance of an
80386 system using an 80286 compiler, although some of them have attempted to do
so.
Finally, a few assorted points. Neither the 80387 nor the MC68881 is the
fastest available floating point unit. The Weitek processors, for example, are much
faster than either chip at floating point operations. Although I believe the
80386+80387 is faster than the MC68020+MC68881, the performance difference
between the two groups of chips is not significant compared with reasonable
differences in compilers, operating systems, and bus characteristics. However, if
Motorola’s performance goals for the MC68030+68882 are achieved, then their
performance should be much faster than the Intel chips for reasonable variations in
other aspects of the system design, ie. a Mac “III” should decisively outperform any
80386+80387 system.
Watch Your System File
Neil Ticktin
Encino, CA
Thank you very much for publishing my letter in the November issue. The only
problem is that you slightly misquoted me on page 12, second column. In the last
paragraph of my letter, you quoted me as “...begging to sell kits...” when I actually
wrote “...beginning to sell kits...”. Not a big mistake, but it gave the wrong
impression to your readers and to ComputerWare. Could you please print a correction
and get me out of trouble?
Recently, I have had to help a lot of my clients with problems ranging from hard
disks to programs not running correctly. What I have found time and time again is that
their System file has been mutilated. This has e specially contributed to hard disk
problems. My suggestion to anyone and everyone is to have a copy of their System
backed up on floppy. If you suspect a problem, replace the System file on your hard
disk or boot floppy and restart your machine. Apple might think about ways of making
their System more bullet proof and protected.
To re-initialize the parameter RAM, that is used by the control panel, press
CMD-OPTION-SHIFT as you select the control panel from the apple menu. I found this
useful when a Macintosh II would not boot from an internal F140. A squirmy public
domain desk accessory had zapped the parameter RAM.
Does Font/DA Move 3.6 have any bugs?
Peter Trinder
Berkshire, England
I have a technical question to ask in respect of MultiFinder. I have received from
Apple Developers group (the UK version of APDA), the UK localized version of
MultiFinder and I have encountered some weird problems using the 3.6 Font/DA
Mover. The main trouble seems to be that when I remove more than one Font, the
Font/DA Mover fails with an error (-108) and the font file becomes damaged (or if I
am removing from the system, the System is damaged). I only seem to get this
problem using a MacPlus with more than 1Mb of memory, in my case it is a TurboMax.
A friend has had this problem on a standard MacPlus with 4 Mb! I checked with Apple
UK and they told me on 16th of November that the release of MultiFinder [in the UK?]
had been delayed. Does anyone know if this is the reason? I called Steve Brecher about
a week before I heard of the delay and he was puzzled but could not offer a solution.
[Multifinder is shipping here and we have not seen this problem with the
Font/DA Mover. However, you cannot ‘edit’ your system file while running
Multi finder. You must return to the normal Finder before you move fonts and DA’s in
and out of the system. The only problem we have verified is that which we reported last
month: some fonts may need to have their flag word checked in their FOND resource to
make sure it is $6000 to work correctly under Pagemaker 2.0a. We also noticed that
Edit has problems with more than 24 fonts under the new system. -Ed]
MultiFinder Patch for PageMaker
He did however give me a patch for PageMaker 2.0 & 2.0a which will allow it to
switch correctly in MultiFinder; the problem is that PM only recognizes 31 entries in
the Apple Menu. Switching in MultiFinder looks for the entry in the Apple Menu; if it
is more than 31, nothing happens. To fix this, search for 0102 011F and change it to
0102 01FF. This will allow PageMaker to honor 255 entries. Thanks Steve, you are
great!!
Riccardo Ettore came to the MacUser show in London (10-12 Nov.) and gave me a
disk with his new Sound Mover Package. This has a converter for taking SoundCap files
and producing .snd resources for both HyperCard and the Mac II. He has also included a
Sound Mover which is designed like the Font/DA Mover and this will install sound
resources into the system. Of interest to MacPlus and SE owners is his IBeep2 CDEV
which is placed in the system folder and appears in the Control Panel (System 4.1 or
higher) and allows the Mac II beep sound facility on these machines. He has included an
assortment of sounds, I have the Beatles HELP! Makes a nice change. It should be on
CompuServe by now. [Note to authors: We would dearly like to publish some type of
sound mover CDEV that explains how to add sounds to the Mac II ‘library’ of exception
beeps. -Ed]
What about 512KE Machines?
Ian McLellan
Waterloo, Ontario, Canada
Is it safe to use the new System 4.1 and Finder 5.5 on a 512KE? Every time I
ask the dealers around here, I get memory upgrade offers instead of answers. Do I
really need the extra memory? Is disk space a problem (I don’t have a hard disk)? Is
there something else I should know? [System 4.1 is not new, but yes, 4.1 and Finder
5.5 work fine on a 512KE, at least on mine! The really new System 4.2 and Finder 6.0
also appear to work on the 512KEso far However, you should upgrade to at least a
plus. I don’t think 512KE machines will be usable for very much longer, given the
growth in application size we are seeing. -Ed]
Draw over the Menu Bar in Basic
Anthony J. Oresteen
Batavia, IL
One of my biggest frustrations with ZBasic for the Mac was I couldn’t control the
ENTIRE screen. I wanted to draw over the menubar but just couldn’t. Well, thanks to a
hint from Ann Arbor SoftWorks (FullPaint) I figured it out.
The solution is simple (as most are once you know them!). You can draw visable
windows only on the defined region of the desktop. When the Window Manager is
initialized, it draws the desktop and empty menu bar. It stores the desktop as a region
and the global variable GrayRgn (&9EE) holds a pointer to it. By expanding the
desktop region to the full screen size, you can draw windows over the full screen.
Below is a program that draws a full screen, inverts it to BLACK, and then
restores the desktop. NOTE that it will work with any size screen as it checks the
global screen.bits for the screen size.
Two bugs remain. First, the lower corners of the desktop do not return to “round
rect” types. They are square but should be rounded. Secondly, when scrolling text in
the black window, you get funny white bars. Any help on solving these minor bugs
would be appreciated. Thanks.
(1)
REM THIS DRAWS WINDOW OVER MENU BAR