INFO-MAC Digest V3 #18
info-mac@uw-beaver
INFO-MAC Digest Friday, 5 Jul 1985 Volume 3 : Issue 18
Today's Topics:
Delays in distribution
MacAfrica
Re: Segment loader bug
Bug in Minifinder?
Distributing .HQX Files
toolvars.h: new sumacc header file
Apple delay of ROM upgrades?
2MB Macintosh!
Broadcast packets and games
Power Board, a request
----------------------------------------------------------------------
Date: Fri 5 Jul 85 16:35:57-PDT
From: Rich Alderson (Temporary Moderator)
Subject: Delays in distribution
I apologize for the week's gap in the distribution of INFO-MAC. I was
called out of town unexpectedly. I intend to catch up this weekend.
One item to note in today's digest: The deadline for registration for
MacAfrica has been extended due to this delay, until Wednesday.
However, in order that the organizers be able to order enough copies
of disks and papers, please call them as early as possible to indicate
your interest.
Rich Alderson
Temporary Moderator
------------------------------
Date: Sun 30 Jun 85 21:23:44-PDT
From: PIE...@SRI-KL.ARPA
Subject: MacAfrica
A Mac Programming class is scheduled for Saturday, July 13 at Stanford
under the sponsorship of Stanford Macintosh Users Group (SMUG).
I **highly** recommend the class for programmers who are interested in
learning how to program the Macintosh. (Very experienced Mac
programmers need not apply - see the attached agenda.) The class
notes are spectacular! They do not eliminate the need for Inside
Macintosh, but do help understand and use it. The class is taught
primarily in Pascal (because Inside Macintosh is written for Pascal)
so you should be able to read a Pascal program, but the information is
equally suitable for 'C' programming.
For more details, call Dave Wilson directly or leave a message for me
and I will get the answer.
Pierce@SRI-KL
(My only association with the course is friendship with Wilson)
The following announcement will go out this week. Space is limited so
early sign-up is recommended.
------------------------------------------------------------------------------
Announcing MacAfrica: A One-Day Macintosh Programming Seminar To
Raise Funds For Emergency Airlifts International
MacAfrica is a one-day seminar on programming the Apple Macintosh
Computer, presented by David A. Wilson, Ph.D. This is a condensed
version of the three-day Macintosh Technical Training Seminars given
by Dr. Wilson for Apple Computer. The seminar has a nominal value of
$100, and we request that checks for donations be made out directly to
Emergency Airlifts International. We have chosen this charity,
sponsors of Airlift: Africa, because all food, clothing, and medical
supplies are purchased in the United States, and their distribution in
Africa has been carefully documented by the news media.
MacAfrica will be held on Saturday, July 13 at Annenberg Auditorium on
the Stanford Campus, beginning at 9:00 am and continuing until at
least 6:00 pm.
The seminar will focus on four unique features of Mac programming:
Resources, Events , Memory Management, and the hundreds of useful ROM
routines. Sample source code will be provided in Lisa Pascal, Megamax
C, and MacPascal for various demo programs. Lectures will include
QuickDraw, Windows, Menus, Desk Accessories, and Debugging. An
optional 300-page notebook and two 3.5-inch disks full of sample
programs will be available for attendees only.
Attendees must register by July 6, and attendance will be limited.
MacAfrica is sponsored by Personal Concepts and the Stanford Macintosh
Users' Group. It is not associated with Apple Computer.
For further information contact:
David Wilson (415) 494-6763 Cheryl Wilson (415) 494-0904
To sign up send a check for $100 made out to Emergency Airlifts
International. If you wish the book and two disks send an additional
check for $24 made out to SMUG. Send the check(s) to
David Wilson
635 Wellsbury Way
Palo Alto, CA 94306.
---------------------------------------------------------------
MacAfrica: Details
General Information
1. Attendance is limited - you must pre-register by July 6.
2. MacAfrica will be held at Annenberg Auditorium, in the basement of the
Cummings Art Building at Stanford, just to the right of Hoover Tower.
3. Lectures begin at 9:00 am sharp. Please come early to pick up your
materials, and get settled in. Doors open at 8:00.
4. We recommend a brown-bag lunch, as lunch will be less than 45 minutes.
Soft drinks will be available.
5. Please do not bring Macs - there will not be any place for them.
Agenda
------
Morning
Introduction
Preview
The Macintosh Family
Development Systems 101
Resources
Sample Programs
Strategy for Program Design
Tools for Program Design
Pascal and C Review
Afternoon
ROM Overview
Events
Menus
Dialogs
QuickDraw
Windows
Debugging
Development Systems 102
Where To Go Next
Questions and Answers
Notes only (no time for lectures)
Desk Accessories
The Scrap
Controls
TextEdit
Miscellaneous subjects: File System, Printing, Serial I/O
Memory Management
Trap List and Quick Reference
------------------------------
Date: Sun, 30 Jun 85 16:33:44 cdt
From: br...@ut-sally.ARPA (Brian H. Powell)
Subject: Re: Segment loader bug
Date: Wed 26 Jun 85 02:12:51-EDT
From: Robert Woodhead <Y.AJAJ-WOODHEAD-ROBERT%CRNL20A.BITNET@Berkeley>
Subject: Some helpful tips from a developer (LONG!)
>The Nasty Segment Loader Gotcha
>This bug only hits very large programs with lots of segments, where
>you keep only parts of the program in memory at a time. When a
>segment is loaded off disk, it is placed as low in memory as can be
>done (which is great). When it is UnLoadSeg'd, it is free to float
>around memory OR be purged. BUT!! When it has been UnLoadSeg'd and
is >still in memory, and the Segment Loader is called to load it, it
says >"oh, here it is, lets lock it in place".. Can you say "heap
>fragmentation" boys and girls? I knew you could.
>Apple Tech Support earned $50 worth of cookies fixing this one with a
>special patch to the loader. So if you are having massive memory
>bombs on 128k Macs, check with them for the LSinstall and LSremove
>patches.
I might mention that this patch is apparently not perfect. A
friend of mine did some work on an extremely large game for the Mac.
He said it worked great; "really cut down on the disk activity". (By
large game, I mean ~70 segments.)
Unfortunately, it crashed the game every 50000 or 60000 moves.
After searching and searching, the bug turned up in the segment loader
or its patches. The guy's boss decided that 50000 moves was too
often. Out goes the patch. After a lot more work, the game began to
again run on a 128K mac, but disk activity was a lot more common.
Potentially, this is a great patch to have, but only if it works.
Brian H. Powell brian@ut-sally.{ARPA,UUCP}
U.S. Mail: Southwestern Bell
P.O. Box 5899 451-0842
Austin, TX 78763
AT&T
(512) 451-0842
------------------------------
Date: 3 Jul 1985 09:10-EDT
Sender: GLA...@BBNA.ARPA
Subject: Bug in Minifinder?
From: GLA...@BBNA.ARPA
When using an external disk drive and the MiniFinder you can wedge the
Mac as follows:
1. Put a disk with the system and Minifinder in the external drive
2. Put a disk with no system and no Minifinder in the internal drive
3. Get to the Minifinder window (run and application and quit)
4. Eject both disks (using the Minifinder)
5. Put the systemless disk in the external drive
6. Put the disk with Minifinder in the internal drive (the Minifinder
window should now be displaying the system disk)
7. Click on Finder
The desktop will come into view, but no icons appear; the disk whirrs
interminably. Hitting the reset button produces the smiling Mac
followed by the sad Mac or a mutilated Minifinder window (I didn't
experiment too much at this point). Putting the system disk back in
the external drive (after ejecting the disk manually and hitting the
reset button) produced an unwedged Mac.
------------------------------
Date: Wed 3 Jul 85 14:40:41-EDT
From: Frank da Cruz <SY....@CU20B.ARPA>
Subject: Distributing .HQX Files
At Columbia, we are including Macintosh Kermit on our Kermit
distribution tapes, most of which are written in formats (like ANSI or
OS standard label) that don't accommodate binary (e.g. .RSRC) files.
The concensus of opinion was that Binhex Version 4 (.HQX) format is
the best way to encode the resource file for distribution on tape.
Everyone was supposed to know what Binhex was, and was assumed to have
it handy.
However, it seems that in fact most of our tape recipients have no
idea what Binhex is, nor where to find it. (Question 1: where does
someone "out in the world" go to get Binhex?) The solution would seem
to be to include Binhex on our distribution tapes. However, even this
is not as simple as it sounds. The following summarizes my
understanding of the situation; I'd appreciate any corrections or
suggestions:
Binhex was originally written in MS Basic and released in source form.
It has since gone through several additional releases, not in source
form. To complicate matters, the new releases provide new
encoding/decoding formats that the earlier releases do not support.
Most applications nowadays (Mid-1985) are being released in Binhex
Version 4 format, which is not decodable by Binhex Version 3.
Therefore, the Binhex Version 3 source is also distributed with the
Binhex Version 4 application in Binhex Version 3 format (BINHEX.HEX).
Now, suppose you have received an application in Binhex Version 4
Format, say on magnetic tape or via electronic mail. How do you get
it onto your Macintosh? Here are the steps:
1. Somehow, get BINHEX.BAS (Binhex Version 3) onto your Macintosh
disk:
a. Copy it from someone who already has it on disk, or...
b. Capture it from the remote system using Macterminal, or...
c. Type it in (ugh, it's 456 lines long).
2. As in (1), get the file BINHEX.HEX onto your Macintosh disk.
3. As in (1), get the Binhex-Version-4-format applications you want to
convert onto your Macintosh disk. These should have the file type
.HQX, and their first line should say:
(This file must be converted with BinHex 4.0)
4. Get into MS Basic, open BINHEX.BAS, and run it on BINHEX.HEX, to
produce a runnable copy of BINHEX Version 4.
5. Quit from MS Basic.
6. Run Binhex Version 4 on your applications.
A Binhex-Version-4 application contains most of the information needed
for the application to be set up correctly -- its application name,
type, the bundle bit set so the icon will appear on the desktop, etc.
This is in contrast to a binary resource file, which comes without
this information and must have it added with Setfile (a utility from
Apple's MacStuff disk).
Did I get it right? Is this the preferred way to distribute Macintosh
applications when you can't send Macintosh diskettes? Can anyone
suggest a better (easier, more sensible) way to do it?
------------------------------
Date: Sat, 29 Jun 85 23:22:56 edt
From: Doug Moen <ihnp4!watmath!watcgl!kdm...@uw-beaver.arpa>
Subject: toolvars.h: new sumacc header file
This is a C header file which provides definitions for all of the
toolbox global variables (memory locations 0x980 - 0xAFF). It is
intended to be used with Sumacc, but others may also find it useful.
With this file, you can use all of those nifty global variables
documented by the Window Manager, etc, under 'Assembly Language
Information'. There are also some interesting looking undocumented
variables.
There is a distinct possibility that I got the capitalization of some
of the names wrong. Please send comments and corrections to
Doug Moen (watmath!watcgl!kdmoen)
University of Waterloo Computer Graphics Lab
PS: If anybody knows what the 'Mr. Macintosh Hook' (mrMacHook) does,
drop me a line.
PPS: In the process of testing toolvars.h with Sumacc release 2, I
made 2 changes to toolintf.h:
Removed 'DlgFont', since it is now in toolvars.h
Changed FMOutPut to FMOutput to conform with spelling in I.M.
[You can find this file archived as <INFO-MAC>UTIL-TOOLVARS.C at
SUMEX. --rma]
------------------------------
Date: Tue 2 Jul 85 23:40:08-PDT
From: Barry Eynon <EY...@SU-SCORE.ARPA>
Subject: Apple delay of ROM upgrades?
From INFOWORLD, July 1, 1985, pp35-36: "Although Apple will not
comment on unreleased or unannounced products, sources outside of
Apple expect those products to be:
[several items deleted]
* New read-only memory (ROM) semiconductors that will support an upcoming
generation of mass storage devices such as compact disk optical storage
media. Other ROMs were also promised by Apple. Surprisingly, the company
is now telling developers it will postpone the introduction of new 128K
ROMs for the "existing" Macintosh;"
Anybody have any hard information on this? I can't believe Apple would
dust off their installed user base, but weirder things have happened.
If this is anything other than a wild rumor, perhaps some mass protest
to Apple will change their mind before policies are set in concrete.
-Barry Eynon
------------------------------
From: crash!bweb...@SDCSVAX.ARPA
Date: Sun, 30 Jun 85 01:26:31 PDT
Subject: 2MB Macintosh!
Well, space cookies, I did it. In a fit of passion, I went down to
Levco Enterprises (which is conveniently located here in SD) and had
my 128K Mac upgraded to 2MB. A bit of a jump, what? I'm still
waiting for the final PROM set (due in a few days); when those come,
I'll really start wringing it out and let you know the results. In
the meantime, I've had fun running it, usually with a 1MB RAMdisk and
1MB of application RAM. Makes the Little Beige Toaster scream along.
"What," you may ask, "about the ROM upgrade problem?" My basic
response is, "I don't really care." However, since the big shakeup at
Apple, new rumblings have come out indicating that Apple is suddenly
concerned about supporting 3rd party upgrades and that the previous
hard-nosed attitude is becoming very soft indeed. This would tend to
confirm suspicions that the previously promulgated (if not announced)
policy sprang from the brow of Steve Jobs.
..bruce..
[Usual disclaimer...I'm *paying* for my upgrade.]
Bruce F. Webster/BYTE Magazine
ARPA: crash!bwebster@ucsd
uucp: {ihnp4, cbosgd, sdcsvax, noscvax}!crash!bwebster
CIS: 75166,1717
USPS: c/o BYTE, 425 Battery Street, San Francisco, CA 94111
------------------------------
Date: 1 Jul 85 20:25:17 EDT
From: Walter.Smith@cmu-cs-wb1
Subject: Broadcast packets and games
Macs do have special hardware for packet reception, although not very
special. The serial chip detects the destination node number in the
packet header, and ignores the packet if it's not for that Mac.
Broadcast packets do cause some resource-wasting, since all the Macs
that don't care about the packet have to read it and throw it away
(and there's also some wasted bandwidth, of course).
If it were possible to change the node numbers of all the playing Macs
to the same number, then with some careful software could you do the
Alto Trek fake-host trick? Not that I have any idea how to go about
it...
- Walt (w...@cmu-cs-k.arpa, ...!seismo!cmu-cs-k!wrs)
P.S. I am writing an Alto Trek equivalent for the Mac in my spare time
(you're right, it's a great game), and I haven't figured any viable
way around using SOME broadcast packets. Of course, that's not a big
problem in my network: two Macs and a cable.
P.P.S. If anyone else is working on a Trek, please let me know... I
hate re-inventing things.
------------------------------
Date: 1 Jul 85 16:41:53 EDT
From: Phillip.McKerrow@CMU-CS-H
Subject: Power Board, a request
I have a 220 volt international Macintosh. The power supply board has
gone down. I have been told by the computer store here (Carnegie
Mellon University) that they can not obtain a 220 volt board from
Apple to repair it. Evidently the 220 volt boards are not available in
USA, or the components to go on it. So I am stuck in America with a
broken down American computer that I can't get fixed. I bought the
mac in Australia and will return there at the end of the year so I am
not keen on buying a $500 110 volt power board. Does anyone know of
anyway I can get it fixed short of taking it back to Australia? I am
going to England in August, would it be possible to get it fixed
there?
------------------------------
End of INFO-MAC Digest
**********************