Nov 87 Letters
Volume Number: 3
Issue Number: 11
Column Tag: Letters
More on Self-Destructing LaserWriters
Rod Paine
Bethesda, MD
Just finished reading your “LaserWriters Self-destruct” letter. While you are
correct in terms of the effect the damage fuser roller has on the printed output, I don’t
believe that the “rubber paper guides” are the cause of the problem, at all. I have two
LaserWriters and have experienced the problem on one of them, requiring the
replacement of the fuser assembly. The second one is maintained based on correcting
what I found on the first and what appears to be a proper solution to the problem.
The problem is that toner builds up on the back side of the “Fuser Separation
Claws”, cooks and becomes hardened to a point where it begins to scratch away the
fuser roller surface coating. It appears to only build up on the two center claws, the
two outside claws don’t seem suseptable to this build up of tonner. [Mine is on the
outside claw! -Ed] I have since checked the two Canon PC-25 copiers that we have,
which have almost identicle fuser assemblies and they exhibit the same problem. So
does my own personal Canon PC-10 copier.
I discussed this with the two Apple dealers that we purchased these LaserWriters
from and made two phone calls to Apple at Cupertino. The dealers know nothing and
Apple has never returned my calls. I called Simplified Copiers, the firm that sold us
the canon PC-25 copiers, they also know nothing about this problem. I have looked at
the fuser assembly in detail (I replaced the damaged one, a very simple task) and am
confident this is the cause of the scratches. As the LaserWriter owner manual makes
no mention of cleaning this area I think this is a serious problem.
If you have any contacts at Apple who will address this problem, please include
my name. In fact, if you want to look at the fuser assembly I replaced, I’ll send it to
you. In the meantime, keep the back side of the fuser separation claws clean and clean
the fuser roller everyday, BEFORE you turn it on, including taking a look at the
cleaning felt strip, that slides into the “green felt cover”, look which is known as the
“fuser upper cover”. I’m glad to see you bring this up, I was getting nowhere fast!
Color Mac Not Finished
Lawrence D’Oliveiro
New Zealand
The Mac II arrived at work about three months ago, and the draft copy of Inside
Macintosh Vol.V not long after. After long hours wrestling with documentation that is
inadequate, incomplete, and often down right wrong, I managed to convert some
grey-scale pictures we have on the Vax into colour QuickDraw format. In the process,
I to learn how to create my own GDevice, in order to construct off-screen pix-maps.
Tech note #120 doesn’t really provide the answer, as I wanted to create PICTs with
256 colours in them, and my video card can only handle 16 colours/grey scales at the
moment. I expect lots of other people would have gone through this and already
discovered what I know, but if not, one or two of my programs might be worth
publishing.
I eagerly typed in Steven Sheets’ colour game of life in the september issue, and
had some fun with that. There was a bug in DoColorClick (which lets you change the set
of colours the program uses), which caused it to ignore any changes you specified -- to
fix this, just the following line:
mycolors[i] := ColorIt;
Before the call to MakeRGBPat, after the begin. Apart from that (and the missing
resource definitions), it’s a pretty demonstration, which I’ve shown lots of people.
Thanks, Steven.
Apple colour monitors are a little bit thinner on the ground than snow in
December over here, but I managed to borrow an NEC MultiSync to try out for a couple
of weeks. Picture quality isn’t 100%-- the picture narrower in the darker parts--
though I expect the newly-announced MultiSync Plus should work better.
I may be wrong, but it doesn’t look like all the pieces of colour supply for the
Mac II are in place yet. Some documentation mentions a control panel module for
changing the colour table, but I can find no such module anywhere. I wrote a
quick-and-dirty utility for doing a similar thing (using the SetEntries colour Manager
call), but my changes kept getting undone as soon as I exited the program. Eventually I
dumped out the current colour table to a “clut” resource, pasted this into the System
file, and put its resourse ID into the “scrn” resource, in the marked “CLUT rsrcID”.
Now my program worked, even though I wasn’t updating the clut resorce on disk! The
colours reverted to those in the resource when I rebooted-- I tested this by modifying
the resource, it did have the expected effect. The only trouble was when I changed
screen mode bit to 2 or 1 bit per pixel (the clut I created had 16 entries), and
rebooted-- the screen colours went all funny! Verdict: something is missing that Apple
should be supplying. [The Pallette Manager? -Ed]
The other thing I found is that MakeRGBPat, which approximates a colour you
specify by “ dithering” (making up a pattern using available coloursin the colour
table in the right proportions), isn’t very accurate. Quite frequently, I would ask it to
approximate a colour which exactly matched an entry in the colour table, and it would
mix in a bit of black instead of giving me a pure colour. Maybe in system 4.2...
I hope this information is of use to others. After the silence of the Mac Plus, and
the enhanced Fat Mac I was I was using before that, tha Mac II sounds like your in a jet
plane. But then it performs like one!
Apple Looking for a few Good Men
David E. Smith
At Apple’s request, we have sent a letter to each of the 385 past contributors of
MacTutor to advise them of employment opportunities at Apple. If you have made a
contribution or requested an author’s kit from MacTutor in the last three years, you
should have received this letter. If you did not, then you are no longer in MacTutor’s
editorial computer for one reason or another and you may wish to contact me for a new
author’s kit. Apple has a number of technical management positions open and are
looking for experienced Macintosh programmers such as those who write for Mactutor!
For more information, contact Dan Cochran at Apple.
Absoft Fortran Update
In last month’s MacTutor, we implied some problems with Absoft’s new version
of Fortran for the Macintosh II. We are happy to report that version 2.3 of
MacFortran/020 is now shipping, having received our copy on 25 Sept 1987. Mr.
Wood Lotz, President of Absoft also responded to the disgruntled customer and he is
perfectly satisfied now. The manual has been re-written and now includes new
information on the added features. The linker has been improved with a script builder
utility that automates the link process. The linker is now a batch facility rather than a
poorly designed interactive facility as it was in the past. In this respect it is more
similar to the MDS and Consulair linker. The compiler includes options for selectively
generating 68020 and 68881 instructions. It also continues to support the generation
of assembly source code, a feature we think is invaluable and lament that other
compiler makers have not supported this. Absoft’s Fortran remains the only Macintosh
compiler product that uses 32-bit offsets in it’s addressing and does not use the
segment manager. Thus there are no 32K code, segment or array limitations in
MacFortran/020 as there are with virtually all MPW compilers. Now that the product
is sold and supported directly by Absoft, we expect customer satisfaction to improve
considerably over the previous Microsoft implementation. Absoft can be contacted at
(313) 853-0050.
New MPW Fortran
Language Systems Corp. of Herndon, VA has announced their development of a new
MPW Fortran product. The product is scheduled to go into beta test in December. An
information booth on the product will be available at the January Mac Expo in San
Francisco. The product will feature 68020 and 68881 code options and will be
linkable with all MPW compiler products. Variable types will include 68881 extended
and complex precision as well as a new type called STRING for dealing with Mac Pascal
type strings with a length byte. Assembly source code output will also be available.
Since this Fortran operates under MPW and uses the MPW Linker, it will be impacted
by the segment manager limitations of other MPW products. However, arrays and
common variables will not be restricted to 32K, according to a company spokesman.
For more information, contact Language Systems at (703) 478-0181.
Power Supply Woes Revealed
Herbert M. Rosenthal
Albuquerque, NM
Chuck Rusch (June ’87, p13) hit it right on the head with his article on
soldering imperfections in the early Macs!!! He has my undying gratitude for his
comments and specifics which led me directly to the several intermittent, offending
unsoldered connection(s) that had me rapping on the side of the Mac more often than
one should, to restore the video. I had installed an internal fan and varistor (both
Radio Shack) a year ago, and am convinced that the fan kept my board from
“smoldering.”
One simply cannot see these cold joints without a magnifying glass, regardless of
his hardware experience. Further, simply re-heating joints will not make a good
connection; it is necessary to apply a wee bit of fresh, rosin solder to the joint as it is
heated; the flux will cause the solder to flow properly. Finally, if you’ve braved the
storm this far, clean up the work with a toothbrush dipped in alcohol; scrub till all the
flux is cleaned up, dry the brush and scrub some more.
MacApp Aids Complexity
Charles Turner
APO New York
For some time now I have been incorporating some of the structure and flow
concepts of MacApp, mostly gleaned from Kurt Schmucker’s book Object- Oriented
programming for the Macintosh, into my LightSpeed Pascal program in order to retain
a reasonable amount of generality, modularity and maintainabilty as it grows
increasingly complex. I looked to MacApp for inspiration since it was developed with
objectives similar, at least in part, to my own and with a lot more talent and
inspiration than I could put to that problem.
Anyhow, it seems that much of the structure and flow in MacApp is different from
the traditional generic program and may be generally useful. Also, fortunately, much
of it can be implemented without the need for object programming.
Since most of the programs you have published derive from the short sample in
Inside Macintosh Vol . I and Chernicoff’s Macintosh reaveled , a sample of somthing a
little different might be interesting to readers who are battling the problems of
increasing complexity. There are lots of ideas in MacApp just waiting for the light of
presentation, assuming that Apple doesn’t mind.
Of course talk is cheap and writing is dear, but if you think the subject has merit
and would send an author’s kit, perhaps I could postpone the 127th improvement to my
program and get something together. And then maybe, just maybe, a moment of
immortality on the cover of Mactutor. [Write away, author’s kit is ‘in the mail’. -Ed]
Camera Option for Cmd-Shift-3
Neil Ticktin
Encino, CA
Response to August 1987 - Macintosh II Hierarchical Menus - Documenting
programs (page 50). There is a desk accessory called “Camera” by Keith A. Esau. I
believe that it is public domain or shareware. It takes a “snapshot” of the screen after
a user specified amount of time. It also allows you to make the cursor invisible. The
resulting snapshot is in Macpaint format or can be sent to the ImageWriter. I believe
that you can get the desk Accessory from CompuServe or other information networks.
[The Camera DA does not work on a Mac II in color mode. In fact, none of the “paint”
type programs work on a Mac II set up for 256 colors. This is one of the great needs
for the Macintosh; new paint programs that can work with color monitors. There is
still no way to capture the screen image of a color display. -Ed]
Resonse to August 1987 - Mousehole Report - “more woes... from: mysteray”.
ComputerWare, of Palo Alto (CA 800-323-1133 or US 800-235-1155), is
begging to sell kits to replace the Macitosh SE fan with a much quieter fan. I believe
the kits sell for arround $40. I don’t know if it will also solve the interference
problems that I also have on my SE. I have not yet bought the fan , but I intend to.
“No-Fluff Stores”
David Kauffman
Vancouver, B.C.
In response to your APDAlog ad, I would like to commend what I consider to be
Vancouver’s best “no-fluff” computer store, Silicon-ections Books Ltd.. They stock
an excellent selection of user-oriented and technical-oriented books on
microcomputers, networking, publishing as well as sections on UNIX, Artificial
Intelligence and Computer Science. Thier staff are helpful without being pushy and
know thier stock very well. Thier knowledge of Mac technical issues is a little lacking
to be the kind of gurus you might be looking for, but I recommend thier store as the
best candidate in the Vancouver area. [Thank you. We encourage all Macintosh technical
users to send in their “No-Fluff” favorite so we can compile a list for the “rest of us“
technical types to patronize. -Ed]
Major Havoc vs. Mr. Clean
Jean-Michel Decombe
Paris, France
It’s always been a pleasure to recieve the latest issue of Mac Tutor. Your articles
are useful but I don’t understand why VIP is great in your opinion. I don’t know of any
good programmer who would use it. OK, you have two types of programmers: Major
Havoc & Mr. Clean. Major Havoc, of course, doesn’t use VIP; he simply transfers
garbage from his brain to the RAM via the keyboard; he doesn’t care much about fancy
graphics. And Mr. Clean can’t see an overview of his project with VIP; he can’t put
remarks where he’d like to; what he sees on a full screen is about four lines of code;
and scrolling isn’t fun. Now take a non-programmer. He won’t learn programming
faster with VIP. OK, you have direct access to the parameters of the ROM routines, but
it doesn’t help you a lot. You’ll have to learn how these routines work, when they
should be used, the side effects, and so on. I think Zippy is right: If I use VIP, do I have
to give my project manager ten per cent?? So, I’d like to know who should use VIP.
Thank you for your answer, if any.
I send you a very very small but very very handy trick if you frequently use any
debugger. Aldo Reset made it for me:
1) Jump to ResEdit, to open your System file, then open the FKEY resources.
2) Choose New from the file menu; a window appears with blinking caret. Type the
following hex string in:
487A 0006 ABFF 4E75 1842 6162 7920 4569 6E73 2773 2044 6562 7567 6765
72
4) Close the window and choose Get Info from the File menu. Change the type to BED
(Baby Einstein’s Debugger), the ID to a number between 5 and 9, or 0, Which
isn’t the ID of any of other FKEYs, then set the Purgeable attribute.
5) Close and save everything, then return to shell.
Now, you can access the debugger installed by typing Command-Shift-ID, where
ID is the ID of the BED FKEY. In the hex string, the underlined part is a Pascal string
that you can change whatever you want. Just remember the first byte is the length. You
can of course use a smaller or longer string, up to 255 bytes. Have fun!
[I think VIP is fun! VIP procedures replace ten to 20 ROM routines with a single
VIP command, which greatly reduces the code needed to generate a Mac program.
Printing text from a window is a single procedure call in VIP. Compared with a
compiled language like Pascal, the same effect would take several pages of complex
print manager code. All five translators for LS C, MPW C, MPW Pascal, Turbo Pascal
and LS Pascal are now completed. Mainstay translated and compiled a single VIP
program in all five languages and found out the MPW translations were twice as fast as
the Turbo and LS products. More on this work will be available next month. VIP may be