info-mac@uw-beaver (info-mac) (07/12/84)
From: Richard Furuta <Furuta@washington.arpa>
1) 14-Jun Jeff.Fleisher@CMU-CS Re: Error message on trying to eject disk
2) 14-Jun Randy Schulz Mac clock gains time
3) 14-Jun Mike Schuster Croft's fromhex in MacForth
4) 14-Jun DEUFEL at DEC-MARLBO External Disk Drives
5) 14-Jun Malcolm B. Brown More comparative benchmarking
6) 14-Jun Ed Pattermann INFO-MAC subscribers
7) 15-Jun ihnp4!cfg!pcpond!far Hard disk for mac
8) 15-Jun Bill Croft SUMACC bugfix in lib/io.s, lib/mactrap.s
9) 15-Jun Bill Croft "fromhex" in C
10) 15-Jun Bill Croft SUMACC file IO
11) 15-Jun Robert.Aarhus at CMU Mac Clock
12) 18-Jun Bill Croft SUMACC installation with Lisa I (no Sony's)
13) 18-Jun Mike Schuster Cursor Programming
14) 18-Jun Bill Croft MacTerminal bug (vers -0.15X April 18, 1984)
15) 20-Jun Tim McNerney Quickdraw Regions internals
16) 20-Jun wert.pa@XEROX.ARPA Re: Mac Clock
17) 20-Jun John Palevich MacPaint Picture Enlarger
18) 20-Jun KSPROUL@RUTGERS.ARPA MACTEP
19) 20-Jun Jim Forrest MBASIC & MACPAINT
20) 20-Jun Piersol.pasa@XEROX.A Re: Cursor Programming
21) 20-Jun Ed Pattermann Updated list of recipients
22) 21-Jun Leslie Zatz REPAIRS
23) 21-Jun Dick Kalagher Macpascal
24) 21-Jun winkler@harvard (Dan Re: Quickdraw Regions internals (It's a secr
25) 21-Jun Nicholas.Caruso at C Bug in the new macpaint...
Message 1 -- ************************
Mail-From: PATTERMANN created at 14-Jun-84 08:54:23
Return-Path: <JF01@CMU-CS-A.ARPA>
Received: from CMU-CS-A.ARPA by SUMEX-AIM.ARPA with TCP; Tue 12 Jun 84 17:18:09-PDT
Date: 12 Jun 84 2013 EDT (Tuesday)
From: Jeff.Fleisher@CMU-CS-A.ARPA
To: Jeff Rosenschein <ROSENSCHEIN@SUMEX-AIM.ARPA>
Subject: Re: Error message on trying to eject disk
CC: info-mac@SUMEX-AIM.ARPA
In-Reply-To: "Jeff Rosenschein's message of 11 Jun 84 14:49-EST"
Message-Id: <12Jun84.201345.JF01@CMU-CS-A.ARPA>
ReSent-date: Thu 14 Jun 84 08:54:23-PDT
ReSent-From: Ed Pattermann <Pattermann@SUMEX-AIM.ARPA>
ReSent-To: info-mac: ;
I had the same error a week ago. It turns out that the directory got
trashed and the command-shift-turnon&off trick did not seem to help.
I ended up trashing the directory even more on purpose by using the
guided tour disk (old finder) and forced the system to realize that it
was in need of repair. I said ok and it fixed itself! It's nice that
the recover capability is there (if you understand what is going on) but
it was tense for awhile.
Jeff
Message 2 -- ************************
Mail-From: PATTERMANN created at 14-Jun-84 08:54:27
Return-Path: <lcc.randy@UCLA-LOCUS.ARPA>
Received: from ucla-locus.arpa by SUMEX-AIM.ARPA with TCP; Wed 13 Jun 84 01:51:51-PDT
Date: Wed, 13 Jun 84 01:38:08 PDT
From: Randy Schulz <lcc.randy@UCLA-LOCUS.ARPA>
To: info-mac@SUMEX-AIM
Subject: Mac clock gains time
ReSent-date: Thu 14 Jun 84 08:54:25-PDT
ReSent-From: Ed Pattermann <Pattermann@SUMEX-AIM.ARPA>
ReSent-To: info-mac: ;
Shortly after I got my Mac I noticed that its clock was gaining a lot
of time. The first few times this happened I figured I had done
something wrong in setting the time and just reset it. Eventually I
decided something was wrong. The clock was gaining time VERY fast, in
fact at something near a two to one ratio. So I sat down to watch with
both the Alarm clock and Control panel on the desktop and the Control
panel active. Lo and behold every few minutes the clock takes a big
leap forward! Has anybody noticed this behaviour? Is Apple aware of
the bug?
Randy Schulz
Locus Computing Corp.
lcc!randy@ucla-s
{ihnpr,randvax,sdcrdcf,ucbvax}!ucla-s!lcc!randy
{trwspp,ucivax}!ucla-va!ucla-s!lcc!randy
Message 3 -- ************************
Mail-From: PATTERMANN created at 14-Jun-84 08:54:32
Return-Path: <MIKES@CIT-20>
Received: from CIT-20.ARPA by SUMEX-AIM.ARPA with TCP; Tue 12 Jun 84 16:37:52-PDT
Date: 12 Jun 1984 1634-PDT
Subject: Croft's fromhex in MacForth
From: Mike Schuster <MIKES@CIT-20.ARPA>
To: info-mac@SUMEX-AIM.ARPA
ReSent-date: Thu 14 Jun 84 08:54:32-PDT
ReSent-From: Ed Pattermann <Pattermann@SUMEX-AIM.ARPA>
ReSent-To: info-mac: ;
Here is a translation of Bill Croft's 'fromhex' Pascal program into
Creative Solutions MacForth. The program takes its input from a file
called 'C' and places the output the resource fork of a file called 'C
prog'. You must use the 'Set File' program to set 'C prog's type to
'APPL', its creator to 'CCOM', and its 'bundle' bit. (If anyone knows
how to do this with MacForth, and thus avoid the need for 'Set File',
let me know!) Refer to Bill's SUMacC Development Kit note for more
information.
Mike
(mikes@cit-20)
5 constant c.file create c.filename ," C"
variable c.i variable c.p 512 constant c.recsize
create c.buffer c.recsize allot
6 constant cprog.file create cprog.filename ," C prog"
variable cprog.i variable cprog.p 512 constant cprog.recsize
create cprog.buffer cprog.recsize allot
variable c.count variable c.check variable c.val
: open.c ( -> )
c.recsize c.i ! 0 c.p !
c.filename c.file assign c.file open
io-result @ if ." can't open C" abort then ;
: close.c ( ->) c.file close ;
: open.cprog ( -> )
0 cprog.i ! 0 cprog.p !
cprog.filename cprog.file assign cprog.file delete
cprog.file create.file cprog.file open.rsrc
io-result @ if ." can't open C prog" abort then ;
: close.cprog ( -> ) cprog.file flush.file cprog.file close ;
: getchar ( -> char )
c.i @ c.recsize = if
0 c.i ! c.buffer c.recsize c.p @ c.file read.virtual c.recsize c.p +!
then c.buffer c.i @ + c@ 1 c.i +! ;
: putflush ( -> )
cprog.i @ 0 = not if
cprog.buffer cprog.i @ cprog.p @ cprog.file write.virtual
cprog.i @ cprog.p +! 0 cprog.i !
then ;
: putchar ( char -> )
cprog.buffer cprog.i @ + c! 1 cprog.i +!
cprog.i @ cprog.recsize = if putflush then ;
: handlechar ( char -> )
dup 80 < over 64 < not and if
64 - c.val @ 16 * or c.val ! 1 c.count +!
c.count @ 1 and 0 = if
c.val @ putchar c.val @ c.check +! 0 c.val !
then
else drop then ;
: handlesum ( -> )
0 c.val ! 9 1 do
getchar 15 and c.val @ 16 * or c.val !
loop c.val @ c.check @ c.count @ 2/ + = not if
." check failed" then ;
: c.to.cprog ( -> )
0 c.count ! 0 c.check ! 0 c.val !
begin getchar dup 124 = not while handlechar repeat drop
putflush handlesum
cr ." bytes = " c.count @ 2/ . ." check = " c.check @ . ;
: fromhex ( -> )
open.c open.cprog c.to.cprog close.c close.cprog ;
fromhex
-------
Return-Path: <MIKES@CIT-20>
Received: from CIT-20.ARPA by SUMEX-AIM.ARPA with TCP; Wed 13 Jun 84 08:22:53-PDT
Date: 13 Jun 1984 0819-PDT
Subject: MacForth 'fromhex' update
From: Mike Schuster <MIKES@CIT-20.ARPA>
To: info-mac@SUMEX-AIM.ARPA
Here is a patch to the MacForth version of 'fromhex' that sets 'C prog's
type, creator, and bundle bit, thus avoiding the need for the program
'Set File'. Warning: the X and Y coordinates of 'C prog's icon in the
disk folder are both 0, so its icon may overlap existing icons when
'fromhex' terminates.
Mike
(mikes@cit-20)
: close.cprog ( -> )
cprog.file flush.file cprog.file close
cprog.file get.file.info
" APPL" 1 + cprog.file >fcb 32 + 4 cmove
" CCOM" 1 + cprog.file >fcb 36 + 4 cmove
8448 cprog.file >fcb 40 + w!
cprog.file set.file.info ;
-------
Message 4 -- ************************
Mail-From: PATTERMANN created at 14-Jun-84 08:54:34
Return-Path: <DEUFEL@DEC-MARLBORO.ARPA>
Received: from DEC-MARLBORO.ARPA by SUMEX-AIM.ARPA with TCP; Wed 13 Jun 84 10:38:58-PDT
Date: 13 Jun 1984 1333-EDT
From: DEUFEL at DEC-MARLBORO
To: INFO-MAC at SUMEX
Subject: External Disk Drives
Message-ID: <"MS10(2124)+GLXLIB1(1136)" 12023164218.19.385.28936 at DEC-MARLBORO>
ReSent-date: Thu 14 Jun 84 08:54:34-PDT
ReSent-From: Ed Pattermann <Pattermann@SUMEX-AIM.ARPA>
ReSent-To: info-mac: ;
I just received mine and I love it.
I was overjoyed to find that Apple did the boot code "Right". If you
power up the Mac and insert a systems disk into the external drive, you
will receive a "HAPPY MAC" on the screen for your efforts and a running
system!!!
Even better:
It appears that Apple did disk volume labels correctly, too! If you boot
on the external drive, eject the disk and insert it into the internal
drive, the system continues to run with no apparent problems!!!
HURRAY!!!
Cheers, (for Apple!)
-Abdul-
--------
Message 5 -- ************************
Mail-From: PATTERMANN created at 14-Jun-84 12:06:34
Return-Path: <MBBROWN@SU-SCORE.ARPA>
Received: from SU-SCORE.ARPA by SUMEX-AIM.ARPA with TCP; Thu 14 Jun 84 10:50:33-PDT
Date: Thu 14 Jun 84 10:49:29-PDT
From: Malcolm B. Brown <MBBROWN@SU-SCORE.ARPA>
Subject: More comparative benchmarking
To: INFO-MAC@SUMEX-AIM.ARPA
ReSent-date: Thu 14 Jun 84 12:06:33-PDT
ReSent-From: Ed Pattermann <Pattermann@SUMEX-AIM.ARPA>
ReSent-To: info-mac: ;
The following are the results of some benchmarking I have done.
Since the only language that is common to all the computers in
question is BASIC, I used BASIC programs. I took them from the April
issue of BYTE, where they were used to test Apple's BASIC for the
Mac. Each program (except for the sieve) repeated some function
5,000 times. The programs included:
Loop (empty for/next loop)
GOSUB (GOing to an empty subroutine)
Midstring search
Integer division
Real division
Eratosthenes sieve for the first 1,899 prime numbers
In cases were I ran the tests myself, I ran the programs twice and
averaged the times.
Times for the Macintosh with Apple's MacBASIC are given according
to the results listed in the BYTE article, page 328.
Here are the results (time given in seconds):
IBM PC HP150 Macintosh Macintosh HP9816
8088 8088 68000 68000 68000
(4.7MHz) (8MHz) (8 MHz) (8MHz) (8MHz)
MS BASIC MS BASIC MacBASIC MS BASIC HP BASIC 2.1
--------------------------------------------------------------------------
LOOP 6 6 1.5 5 .82
GOSUB 12 11.5 3 9 1.5
Midstring 24.5 20 9 22 2.45
Int div 22 17 3 15 3.04
Real div 20 17 18* 32 3.15
Sieve 3:44 3:12 31.5 grrf** 16.5
* N.B. For the MS BASIC programs, I used double precision division
(R#=S#/3#).
grrf*** MS BASIC on the Mac ran out of memory when the sieve program
tried to DIM an array of over 8,000 elements! The largest
array I could construct was 6,770 elements. This enabled the
program to find the first 1,602 primes and accomplished this
with an average run time of 1:44.
--- Malcolm Brown
---------*
-------
Message 6 -- ************************
Mail-From: PATTERMANN created at 14-Jun-84 12:06:36
Mail-From: PATTERMANN created at 14-Jun-84 10:55:48
Date: Thu 14 Jun 84 10:55:48-PDT
From: Ed Pattermann <Pattermann@SUMEX-AIM.ARPA>
Subject: INFO-MAC subscribers
To: info-mac@SUMEX-AIM.ARPA
ReSent-date: Thu 14 Jun 84 12:06:36-PDT
ReSent-From: Ed Pattermann <Pattermann@SUMEX-AIM.ARPA>
ReSent-To: info-mac: ;
For your information, here is a current list of all recipients of INFO-MAC ;
ADVANCED COMPUTER COMMUNICATIONS
ADVANCED INFORMATION and DECISION SYSTEMS
APPLE
ATARI
BANG WORLD COMMUNICATIONS CENTER
BETHESDA RESEARCH LABORATORY
BOLT BERANEK and NEWMAN
BROOKHAVEN NATIONAL LABORATORY
BROWN UNIVERSITY
CALIFORNIA INSTITUTE of TECHNOLOGY
CARNEGIE MELLON UNIVERSITY
COLUMBIA UNIVERSITY
COMPUTER THOUGHT INC.
CORNELL UNIVERSITY
DARTMOUTH UNIVERSITY
DEFENSE COMMUNICATION ASSOCIATES
DIGITAL EQUIPMENT CORPORATION
FORD AEROSPACE
HARVARD
HEWLETT PACKARD
HONEYWELL
INFORMATION SCIENCES INSTITUTE (ISI)
JET PROPULSION LAB
LUCASFILM
LAWRENCE BERKELEY LAB
LAWRENCE LIVERMORE LAB
LOS ALAMOS NATIONAL LAB
MASSACHUSETTS INSTITUTE of TECHNOLOGY
MICROSOFT INC.
MITRE CORPORATION
NASA AMES RESEARCH CENTER
NATIONAL BUREAU of STANDARDS
NATIONAL LIBRARY OF MEDICINE
NATIONAL SCIENCE FOUNDATION
NAVAL RESEARCH LABS
NAVAL WEAPONS CENTER
NEW YORK UNIVERSITY
PHOENIX COMPUTER OPERATION
PURDUE UNIVERSITY
RICE UNIVERSITY
RUTGERS UNIVERSITY
SRI INTERNATIONAL
STANFORD UNIVERSITY
SUN MICROSYSTEMS
SYMBOLICS INC.
TEKTRONIX INC.
THE RAND CORPORATION
UNISOFT
UNIVERSITY of ARIZONA
UNIVERSITY of BRITISH COLUMBIA
UNIVERSITY of CALIFORNIA at IRVINE
UNIVERSITY of CALIFORNIA at LOS ANGELES (UCLA)
UNIVERSITY of DELAWARE
UNIVERSITY of MARYLAND
UNIVERSITY of MASSACHUSETTS
UNIVERSITY of MICHIGAN
UNIVERSITY of ROCHESTER
UNIVERSITY of SOUTHERN CALIFORNIA
UNIVERSITY of TEXAS
UNIVERSITY of TORONTO
UNIVERSITY of UTAH
UNIVERSITY of WASHINGTON
WHITE SANDS MISSILE RANGE
XEROX
YALE UNIVERSITY
VANDERBILT UNIVERSITY
-- Ed
-------
Message 7 -- ************************
Mail-From: PATTERMANN created at 15-Jun-84 12:22:15
Return-Path: <ihnp4!cfg!pcpond!farber@Berkeley>
Received: from UCB-VAX.ARPA by SUMEX-AIM.ARPA with TCP; Thu 14 Jun 84 17:03:22-PDT
Received: by UCB-VAX.ARPA (4.28/4.31)
id AA08053; Thu, 14 Jun 84 17:02:47 pdt
From: ihnp4!cfg!pcpond!farber@Berkeley
Message-Id: <8406142350.AA10107@ihnp4.ATT.UUCP>
Received: by ihnp4.ATT.UUCP; id AA10107; 14 Jun 84 18:50:25 CDT (Thu)
To: info-mac@sumex-aim.ARPA
Subject: Hard disk for mac
Date: Thu Jun 14 19:46:56 1984
ReSent-date: Fri 15 Jun 84 12:22:15-PDT
ReSent-From: Ed Pattermann <Pattermann@SUMEX-AIM.ARPA>
ReSent-To: info-mac: ;
is there any experience out there with the Tecmar alleged hard disk?
Message 8 -- ************************
Mail-From: PATTERMANN created at 15-Jun-84 12:22:17
Return-Path: <croft@safe>
Received: from safe by SUMEX-AIM.ARPA with TCP; Thu 14 Jun 84 17:38:01-PDT
Date: Thu, 14 Jun 84 17:40:57 pdt
From: Bill Croft <croft@safe>
To: info-mac@sumex
Subject: SUMACC bugfix in lib/io.s, lib/mactrap.s
Cc: croft, sumacc@sumex
ReSent-date: Fri 15 Jun 84 12:22:17-PDT
ReSent-From: Ed Pattermann <Pattermann@SUMEX-AIM.ARPA>
ReSent-To: info-mac: ;
As promised, SUMACC is a beta release, and here are the first bugfixes
to prove it. If you have a bugfix in the future, please send it to
info-mac@sumex and "cc" sumacc@sumex; the latter will cause the message to be
filed in <info-mac>sumacc.mail.
The fixes sent out will be applied as "incremental" fixes to the original
tar distribution; we plan to update the tar file only upon "final"
release.
The fix to mactrap.s below handles "ostype" or "restype" strings (4 byte
strings passed on the stack) that were not word aligned. The fix to
io.s corrects a typo.
Thanks to Mike Schuster at CALTECH for writing a "fromhex" in C to check
this out. I'll post Mike's program in a following message.
+ diff mactrap.s- mactrap.s
72,73c72,80
< movl a0@+,a1 | short structure
< movl a1@,sp@-
---
> movl a0@+,a1 | short struct (includes os/restype strings)
> movb a1@+,d1 | may not be word aligned
> lsll #8,d1
> movb a1@+,d1
> lsll #8,d1
> movb a1@+,d1
> lsll #8,d1
> movb a1@+,d1
> movl d1,sp@-
+ diff io.s- io.s
319c319
< .globl fswrite
---
> .globl _fswrite
324c324
< fswrite:
---
> _fswrite:
Message 9 -- ************************
Mail-From: PATTERMANN created at 15-Jun-84 12:22:22
Return-Path: <croft@safe>
Received: from safe by SUMEX-AIM.ARPA with TCP; Thu 14 Jun 84 17:57:19-PDT
Date: Thu, 14 Jun 84 18:00:15 pdt
From: Bill Croft <croft@safe>
To: info-mac@sumex, sumacc@sumex
Subject: "fromhex" in C
ReSent-date: Fri 15 Jun 84 12:22:22-PDT
ReSent-From: Ed Pattermann <Pattermann@SUMEX-AIM.ARPA>
ReSent-To: info-mac: ;
Here is Mike Schuster's translation of fromhex.p into fromhex.c.
It appears to still speak with a "Pascal accent", but he was probably
just being conservative.
Date: 14 Jun 1984 1035-PDT
Subject: fromhex in C
From: Mike Schuster <MIKES@CIT-20.ARPA>
To: croft@SU-SAFE.ARPA
Bill,
Thanks for the updates to mactrap.s. Here is 'fromhex.c'. I added code
to set the bundle bit as well as a call to 'allocate' so that disk full
errors are caught.
Mike
----
#include "quickdraw.h"
#include "osintf.h"
#include "toolintf.h"
#define bufsize 512
#define InName "C"
#define OutName "C prog"
int rout, rin, io, i;
int l, val, bytes, sum, getsum;
char bin[bufsize], bout[bufsize];
int count, szin, bini, bouti;
FInfo fInfo;
putflush()
{
if (bouti)
{
count = bouti;
io = FSWrite(rout, &count, bout);
bouti = 0;
}
}
putchar(ch)
int ch;
{
bout[bouti++] = (char) ch;
if (bouti == bufsize)
putflush();
}
int getchar()
{
if (bini == bufsize)
{
bini = 0;
count = bufsize;
io = FSRead(rin, &count, bin);
}
return ((int) bin[bini++]);
}
badnews()
{
int j;
io = FSClose(rin);
io = FSClose(rout);
SysBeep(1);
for (j = 0; j <= 20000; j++)
l = 0;
SysBeep(1);
ExitToShell();
}
main()
{
bouti = 0;
bini = bufsize;
io = FSDelete(OutName, 0);
io = Create(OutName, 0, "CCOM", "APPL");
io = GetFInfo(OutName, 0, &fInfo);
fInfo.fdFlags |= fHasBundle << 8;
io = SetFInfo(OutName, 0, &fInfo);
io = OpenRF(OutName, 0, &rout);
if (io)
badnews();
io = FSOpen(InName, 0, &rin);
if (io)
badnews();
io = GetEOF(rin, &szin);
count = szin >> 1;
io = Allocate(rout, &count);
if (io)
badnews();
val = 0;
bytes = 0;
sum = 0;
getsum = 0;
while (szin && !getsum)
{
l = getchar() & 127;
szin--;
if ((l >= 64) && (l < 80))
{
bytes++;
val = (val << 4) | (l - 64);
if (!(bytes & 1))
{
putchar(val);
sum += val;
val = 0;
}
}
if (l == 124)
getsum = 1;
}
putflush();
io = FSClose(rout);
if (!getsum)
badnews();
sum += bytes >> 1;
val = 0;
for (i = 1; i <= 8; i++)
val = (val << 4) | (getchar() & 15);
io = FSClose(rin);
if (val != sum)
badnews();
ExitToShell();
}
-------
Message 10 -- ************************
Mail-From: PATTERMANN created at 15-Jun-84 12:22:25
Return-Path: <croft@safe>
Received: from safe by SUMEX-AIM.ARPA with TCP; Thu 14 Jun 84 18:19:52-PDT
Date: Thu, 14 Jun 84 18:22:29 pdt
From: Bill Croft <croft@safe>
To: info-mac@sumex
Subject: SUMACC file IO
Cc: croft, engel@harvard
ReSent-date: Fri 15 Jun 84 12:22:25-PDT
ReSent-From: Ed Pattermann <Pattermann@SUMEX-AIM.ARPA>
ReSent-To: info-mac: ;
Date: Thu, 14 Jun 84 16:36:23 edt
From: engel@harvard (Stephen Engel)
To: info-mac@SUMEX-AIM.ARPA
Subject: C files.
Can someone help me with Macintosh file manipulation from C? Two things
in particular bother me. The one is the second variable in the i/o
functions listed in libos.c ; what purpose does it serve? The other is
that lint refuses to accept the type ioPParam, but is perfectly happy
with ioParam (The type in osintf.h is ioPParam). Why?
I would greatly appreciate any suggestions.
Steve Engel
Please try to check your Inside Macintosh first before sending a question
to info-mac. If you are receiving the Inside Mac updates, you should have
a new File Manager document dated 5/21/84. Look at the section titled
"High Level File Manager Routines"; a sample of these calls can be
found in the cmd/fromhex.p program in the distribution, or in Mike
Schuster's translation, fromhex.c.
The calls you are refering to are discussed in "Low Level File Manager
Routines" and are normally not used. The second parameter on these
calls is a boolean (0 or 1) to indicate whether the function is
asynchronous or synchronous.
The osintf.h on the distribution looks OK to me; the structure defined
there is "ioParam".
Message 11 -- ************************
Mail-From: PATTERMANN created at 15-Jun-84 12:22:27
Return-Path: <rta@cmu-cs-spice.arpa>
Received: from CMU-CS-SPICE.ARPA by SUMEX-AIM.ARPA with TCP; Fri 15 Jun 84 10:05:17-PDT
Date: 15 Jun 1984 12:56:52-EDT
From: Robert.Aarhus at CMU-CS-SPICE
Subject: Mac Clock
ReSent-date: Fri 15 Jun 84 12:22:27-PDT
ReSent-From: Ed Pattermann <Pattermann@SUMEX-AIM.ARPA>
ReSent-To: info-mac: ;
I've discovered on my Mac that the interval for one second
(Macsecond?) is not consistent - i.e. two seconds will pass
on my wristwatch while only one passes for the Mac, then the
Mac speeds up and catches up with itself. All in all, the
clock is usually accurate with wristwatch time, unless you
consider using it as a second timer.
Message 12 -- ************************
Mail-From: PATTERMANN created at 18-Jun-84 13:22:32
Return-Path: <croft@safe>
Received: from safe by SUMEX-AIM.ARPA with TCP; Fri 15 Jun 84 14:54:10-PDT
Date: Fri, 15 Jun 84 14:57:10 pdt
From: Bill Croft <croft@safe>
To: info-mac@sumex
Subject: SUMACC installation with Lisa I (no Sony's)
ReSent-date: Mon 18 Jun 84 13:22:32-PDT
ReSent-From: Ed Pattermann <Pattermann@SUMEX-AIM.ARPA>
ReSent-To: info-mac: ;
Date: Wed, 13 Jun 84 13:14:38 EDT
From: barkley@nbs-vms
Subject: SUMACC is up and running at NBS
Myself and Dave Itkin of the University of Maryland
took a copy of SUMACC and after some amount of struggle,
we now have it up and running on 4.1 at both NBS and UofM.
Because our lisa 2's have not been delivered yet and
because our copy of the 2.0 workshop is on Sonys, we had
to bring up fromhex.p on an earlier workshop version
(dated 2/22/84). Basically, the problem was with the
"Create" and "FSWrite" routines. If anyone else has this
trouble, we will glad to share our experiences.
It's really great what you are doing. We have several
people (like myself) who would much rather work in C. Also,
I think that anyone would rather develop in a unix
environment rather than the lisa workshop environment even
if it does take longer to download.
thanks!
john barkley
Message 13 -- ************************
Mail-From: PATTERMANN created at 18-Jun-84 13:22:34
Return-Path: <MIKES@CIT-20>
Received: from CIT-20.ARPA by SUMEX-AIM.ARPA with TCP; Fri 15 Jun 84 15:07:17-PDT
Date: 15 Jun 1984 1505-PDT
Subject: Cursor Programming
From: Mike Schuster <MIKES@CIT-20>
To: info-mac@SUMEX-AIM.ARPA
ReSent-date: Mon 18 Jun 84 13:22:34-PDT
ReSent-From: Ed Pattermann <Pattermann@SUMEX-AIM.ARPA>
ReSent-To: info-mac: ;
Now that Bill Croft's SUMacC has been distributed, I guess <info-mac>
will be subjected to more programming questions and info. May I?
[Ed. By all means! Thats what this list in intended for.]
When text editing, the shape of the cursor may be either 'ibeam' or
'arrow' depending if the cursor is pointing to text or not. The
obvious code to handle cursors tests to see if the cursor position is
within some rectangle containing the text. If so, the cursor is set
to ibeam, otherwise it is set to arrow. This position test is
repeatedly performed in the main event loop of the program, even if no
mouse or other events occur.
Unfortunately, this simple scheme will not always work correctly. For
example, suppose you have just selected a time consuming command like
Save from the File menu. While your file is being saved, you quickly
try to pull down the File menu once again, holding the mouse button
down as you move the cursor to the expected position of the command
you now wish to invoke. You keep holding the button down until the
save is finished and the menu actually appears. Don't let go of the
button and look at the shape cursor. It should be an arrow, but using
the above code, it might be an ibeam if the cursor is over text.
Can someone suggest a better way to handle cursor shapes?
Another question: When editing programs or tabular data, its handy if
some rectangular region of text can be cut, copied, pasted, indented,
etc. Does the Text Edit Manager have hooks so that such selections
could be implemented?
Mike
(mikes@cit-20)
-------
Message 14 -- ************************
Mail-From: PATTERMANN created at 18-Jun-84 13:22:38
Return-Path: <croft@safe>
Received: from safe by SUMEX-AIM.ARPA with TCP; Fri 15 Jun 84 15:20:29-PDT
Date: Fri, 15 Jun 84 15:23:31 pdt
From: Bill Croft <croft@safe>
To: info-mac@sumex
Subject: MacTerminal bug (vers -0.15X April 18, 1984)
ReSent-date: Mon 18 Jun 84 13:22:38-PDT
ReSent-From: Ed Pattermann <Pattermann@SUMEX-AIM.ARPA>
ReSent-To: info-mac: ;
From: Joseph I. Pallas <PALLAS@SU-SCORE.ARPA>
Subject: MacTerminal
To: croft@SU-SAFE.ARPA
Just out of curiosity, I wonder if you know anything about a problem I
had with the new MacTerminal. I tried to create two configuration
files with different phone numbers in them for calling Score and
Pescadero. However, if I created Score and then created Pescadero,
when I reopened Score it had Pescadero's configuration. The problem
persisted even if I wiped out all of the MacTerminal documents before
starting. Finally, I looked at MacTerminal with EXAMINE and RMOVER,
and saw that there was a resource in the application itself (named
CNFG) that contained the configuration! When I deleted that resource,
my problem went away. Is this a bug, a feature, or what? Do you have
any idea?
Message 15 -- ************************
Mail-From: PATTERMANN created at 20-Jun-84 16:21:09
Return-Path: <@MIT-MC:TIM@MIT-MC>
Received: from MIT-MC by SUMEX-AIM.ARPA with TCP; Tue 19 Jun 84 14:55:27-PDT
Date: Sun, 17 Jun 1984 04:34 EDT
Message-ID: <TIM.12024114565.BABYL@MIT-OZ>
Sender: TIM%MIT-OZ@MIT-MC.ARPA
From: Tim McNerney <TIM@MIT-MC.ARPA>
To: info-mac@SUMEX-AIM.ARPA
cc: TIM@MIT-MC.ARPA
Subject: Quickdraw Regions internals
ReSent-date: Wed 20 Jun 84 16:21:09-PDT
ReSent-From: Ed Pattermann <Pattermann@SUMEX-AIM.ARPA>
ReSent-To: info-mac: ;
Does anyone know the internal representation of the "region definition data"
of Quickdraw Regions? Inside Macintosh merely states that "The region
definition data for nonrectangular regions is stored in a compact way which
allows for highly efficient access by Quickdraw procedures." and leaves it
at that. [Quickdraw Programmer's Guide, p.10, 3/2/82]
Tim McNerney
MIT LCS
Message 16 -- ************************
Mail-From: PATTERMANN created at 20-Jun-84 16:21:18
Return-Path: <wert.pa@Xerox.ARPA>
Received: from Xerox.ARPA by SUMEX-AIM.ARPA with TCP; Tue 19 Jun 84 16:12:38-PDT
Received: from Concord.ms by ArpaGateway.ms ; 19 JUN 84 16:12:52 PDT
Date: 19 Jun 84 16:10:08 PDT
From: wert.pa@XEROX.ARPA
Subject: Re: Mac Clock
In-reply-to: "Your message of 15 Jun 84 12:56:52 EDT"
To: Robert.Aarhus@CMU-CS-SPICE.ARPA
Cc: info-mac@SUMEX-AIM.ARPA
ReSent-date: Wed 20 Jun 84 16:21:18-PDT
ReSent-From: Ed Pattermann <Pattermann@SUMEX-AIM.ARPA>
ReSent-To: info-mac: ;
I've discovered on my Mac that the interval for one second
(Macsecond?) is not consistent - i.e. two seconds will pass
on my wristwatch while only one passes for the Mac, then the
Mac speeds up and catches up with itself. All in all, the
clock is usually accurate with wristwatch time, unless you
consider using it as a second timer.
This behavior is typical of all the Macs that I have seen. This is NOT
the clock speeding up or slowing down. When you think about it, that is
a silly idea. How could it ever work at all? What you are seeing is the
latency between when the clock changes and the display is updated. This
can be affected by any number of things, depending upon how busy the Mac
is at the moment, and whether it has to expand the heaps to do anything,
etc.
My Mac keeps time accurate to withing about 15 seconds a month, compared
to WWV. It only gets around to updating the clock display about every
1.5 seconds, thus making it appear that the clock jitters.
Scott
Message 17 -- ************************
Mail-From: PATTERMANN created at 20-Jun-84 16:21:21
Return-Path: <palevich%atari.csnet@csnet-relay.arpa>
Received: from csnet-relay by SUMEX-AIM.ARPA with TCP; Tue 19 Jun 84 18:49:55-PDT
Received: From atari.csnet by csnet-relay; 19 Jun 84 21:19 EDT
Date: Tue, 19 Jun 84 15:44 PST
From: John Palevich <palevich%atari.csnet@csnet-relay.arpa>
To: info-mac%sumex-aim@csnet-relay.arpa
Subject: MacPaint Picture Enlarger
ReSent-date: Wed 20 Jun 84 16:21:21-PDT
ReSent-From: Ed Pattermann <Pattermann@SUMEX-AIM.ARPA>
ReSent-To: info-mac: ;
Here is a program I wrote the other day. It enlarges any MacPaint compatible
picture file into four files, each of which contains one quarter of the
original image, doubled in size. These quarters may be printed out, using
MacPaint, and pasted together to form a large picture that is twice as high
and twice as large as the original. Or, each quarter can be enlarged,
producing sixteen pictures which can be cut and pasted to form a very large
picture which is four times as wide, and four times as long as the original.
Of course, the enlarged pictures have larger pixels, but the results are quite
striking, as well as practical for group presentations, posters, etc..
The four output files are named <input file name>+0 thru <input file name>+3.
This program is written in Microsoft Basic, and, as a result, runs slowly.
It contains code taken from MacTEP 1.8?, (C) 1984 Brothers Associates, which
is used to get and set file types. Information about the internal structure
of MacPaint files comes from Inside Macintosh. The internal representation
of compressed pixels is undocumented, but look at the code to see what I
think the representation is....
If you're enlarging screen dumps, note that only the first two files contain
information, so you can break the program after it starts to process line 360.
Jack Palevich
5 DEFINT A-Z
7 GOSUB 20000:REM Initialize machine language subroutines
10 DIM PIXBUF(143),DBYTE(16),PARAMLIST(39)
20 CALL TEXTFONT(1):CALL TEXTSIZE(12)
30 CLS:PRINT"MacPaint Picture Enlarger"
35 PRINT " ";CHR$(169);"1984 John Howard Palevich"
37 PRINT"Converts input MacPaint file into four output MacPaint files."
40 PRINT:PRINT"File to enlarge";
50 INPUT IFN$
55 F$=IFN$:GOSUB 10000:IF LEFT$(TYPEAPPL$,4)="PNTG" THEN 60
57 PRINT"That's not a MacPaint file.":GOTO 40
60 RESTORE 90
65 FOR I = 0 TO 15
70 READ D:DBYTE(I)=D
80 NEXT I
90 DATA &h00,&h03,&h0c,&h0f
92 DATA &h30,&h33,&h3c,&h3f
94 DATA &hc0,&hc3,&hcc,&hcf
96 DATA &hf0,&hf3,&hfc,&hff
100 OPEN IFN$ FOR INPUT AS #1
110 REM Skip the first 512 bytes of the MacPaint file
120 FOR I = 0 TO 3: A$=INPUT$(128,#1):NEXT I
130 OPEN IFN$+"0" FOR OUTPUT AS #2
140 OPEN IFN$+"1" FOR OUTPUT AS #3
150 N$=CHR$(0):FOR I = 1 TO 7:N$=N$+N$:NEXT I:REM fill n$ with 128 nulls
155 REM Write MacPaint Header to output files
160 FOR M = 0 TO 3: PRINT #2,N$;:PRINT #3,N$;:NEXT M
200 FOR I = 0 TO 719:REM for each scan line
205 PI=0
206 PRINT "Procesing line ";I;
210 COUNT=ASC(INPUT$(1,#1))
220 IF COUNT >= 128 THEN 300
230 REM 0..127 -> COUNT+1 bytes of raw data
240 A$=INPUT$(COUNT+1,#1)
250 FOR J = 0 TO COUNT
260 PIXBUF(PI+J) = ASC(MID$(A$,J+1,1))
270 NEXT J
280 PI=PI+COUNT+1
290 GOTO 400
300 REM 128..255 -> 256-COUNT repeats of the next byte
310 N = 256-COUNT
320 B=ASC(INPUT$(1,#1))
330 FOR J = 0 TO N
340 PIXBUF(PI+J)=B
350 NEXT J
360 PI = PI + N + 1
400 REM See if the pixel buffer is filled up yet
410 IF PI < 72 THEN 210
500 REM Pixbuf(0..PI-1) now has the picture. (PI == 72)
505 IF PI <> 72 THEN PRINT"Woops, illegal file format.":END
510 FOR J = 71 TO 0 STEP -1
520 H=INT(PIXBUF(J)/16):L=PIXBUF(J)-16*H
530 PIXBUF(2*J+1)=DBYTE(L):PIXBUF(2*J)=DBYTE(H)
540 NEXT J
600 REM Compact the Pixels.
610 PI=0:GOSUB 2000:PRINT #2,OP$;OP$;:PRINT"[";LEN(OP$);",";
620 PI=72:GOSUB 2000:PRINT #3,OP$;OP$;:PRINT LEN(OP$);"]"
630 IF I <> 360 THEN 1000
640 REM We've filled up one set of files. Open the next set.
645 CLOSE#2:CLOSE#3
650 OPEN IFN$+"2" FOR OUTPUT AS #2
660 OPEN IFN$+"3" FOR OUTPUT AS #3
665 REM Write MacPaint Header to output files
670 FOR M = 0 TO 3: PRINT #2,N$;:PRINT #3,N$;:NEXT M
1000 NEXT I
1010 CLOSE#2:CLOSE#3:CLOSE#1
1020 PRINT"Done Processing."
1200 REM Change file type to MacPaint
1210 TYPEAPPL$="PNTGMPNT":REM MacPaint Painting code
1220 F$=IFN$+"0":GOSUB 11000:F$=IFN$+"1":GOSUB 11000
1230 F$=IFN$+"2":GOSUB 11000:F$=IFN$+"3":GOSUB 11000
1900 PRINT"Done."
1999 END
2000 REM Pixbuf(pi..pi+71) -> op$
2010 OP$="":K=PI:Z=PI+71
2020 REM Duplicate bytes?
2030 IF K > Z THEN RETURN:REM We're done.
2035 IF K=Z THEN 2200
2040 IF PIXBUF(K)<>PIXBUF(K+1) THEN 2200
2050 REM See how many repeated bytes
2060 K2 = K+1
2070 IF K2>Z THEN 2100
2080 IF PIXBUF(K)=PIXBUF(K2) THEN K2=K2+1:GOTO 2070
2100 REM pixbuf(k..k2-1) is a repeat count
2110 OP$ = OP$+CHR$(257-(K2-K))+CHR$(PIXBUF(K))
2120 K = K2:GOTO 2030
2200 REM See how many random bytes there are:
2210 K2=K+1:IF K = Z THEN 2300
2220 IF K2 >= Z-1 THEN K2=Z+1:GOTO 2300
2230 IF PIXBUF(K2)<>PIXBUF(K2+2) THEN K2=K2+2:GOTO 2220
2240 IF PIXBUF(K2) <> PIXBUF(K2+1) THEN K2=K2+1:GOTO 2220
2300 REM pixbuf(k..k2-1) is random
2310 OP$=OP$+CHR$(K2-K-1)
2320 FOR K3 = K TO K2-1
2330 OP$=OP$+CHR$(PIXBUF(K3))
2340 NEXT K3
2350 K=K2
2360 GOTO 2030
10000 REM Subroutine to get type and application of a file
10010 REM
10015 FP!=0:PARAM!=0:I=0:FL=0:GETFILEINFO!=0:TYPEAPPL$=""
10020 FL=LEN(F$)
10030 F$=CHR$(FL)+F$
10035 FP!=VARPTR(F$):PARAM!=VARPTR(PARAMLIST(0))
10037 GETFILEINFO!=VARPTR(GETFILEINFOCODE(0))
10040 FOR I = 0 TO 79:POKE PARAM!+I,0:NEXT I
10050 POKE PARAM!+19,PEEK(FP!+2)
10060 POKE PARAM!+20,PEEK(FP!+3)
10070 POKE PARAM!+21,PEEK(FP!+4)
10080 CALL GETFILEINFO!(PARAM!)
10090 FOR I = 0 TO 7
10100 TYPEAPPL$=TYPEAPPL$+CHR$(PEEK(PARAM!+32+I))
10110 NEXT I
10120 RETURN
11000 REM Subroutine to set type and application of a file
11010 REM
11015 FP!=0:PARAM!=0:I=0:FL=0:GETFILEINFO!=0:SETFILEINFO!=0
11020 FL=LEN(F$)
11030 F$=CHR$(FL)+F$
11035 FP!=VARPTR(F$):PARAM!=VARPTR(PARAMLIST(0))
11037 GETFILEINFO!=VARPTR(GETFILEINFOCODE(0))
11038 SETFILEINFO!=VARPTR(SETFILEINFOCODE(0))
11040 FOR I = 0 TO 79:POKE PARAM!+I,0:NEXT I
11050 POKE PARAM!+19,PEEK(FP!+2)
11060 POKE PARAM!+20,PEEK(FP!+3)
11070 POKE PARAM!+21,PEEK(FP!+4)
11080 CALL GETFILEINFO!(PARAM!)
11090 FOR I = 0 TO 7
11100 POKE PARAM!+32+I, ASC(MID$(TYPEAPPL$,I+1,1))
11110 NEXT I
11120 CALL SETFILEINFO!(PARAM!)
11130 RETURN
20000 REM Set up GetFileInfo ROM call
20010 REM From MacTEP 1.81, (c) 1984 Brothers Associates
20015 PRINT"Initializing.";
20020 DIM GETFILEINFOCODE(25)
20030 RESTORE 20100
20040 I = 0
20050 READ A:GETFILEINFOCODE(I)=A
20060 I=I+1
20070 IF A<> -1 THEN 20050
20080 REM
20090 REM
20100 REM Machine Language code to invoke GetFileInfo ROM function
20110 REM
20120 DATA &h4e56, &hfff8, &h48ee, &h0101, &hfff8, &h206e, &h0008, &ha00c
20130 DATA &h4cee, &h0101, &hfff8, &h4e5e, &h4e75
20140 DATA -1
20150 REM
20160 REM
20200 REM Set up the SetFileInfo ROM call
20210 REM
20215 PRINT".";
20220 DIM SETFILEINFOCODE(25)
20230 RESTORE 20300
20240 I=0
20250 READ A:SETFILEINFOCODE(I)=A
20260 I=I+1
20270 IF A<>-1 THEN 20250
20280 REM
20290 REM
20300 REM Machine language code to invoke SetFileInfo ROM
20310 REM
20320 DATA &h4e56, &hfff8, &h48ee, &h0101, &hfff8, &h206e, &h0008, &ha00d
20330 DATA &h4cee, &h0101, &hfff8, &h4e5e, &h4e75
20340 DATA -1
20350 REM
20355 PRINT"."
20360 RETURN
Message 18 -- ************************
Mail-From: PATTERMANN created at 20-Jun-84 16:21:27
Return-Path: <KSPROUL@RUTGERS.ARPA>
Received: from RUTGERS.ARPA by SUMEX-AIM.ARPA with TCP; Tue 19 Jun 84 19:21:28-PDT
Date: 19 Jun 84 22:21:21 EDT
From: KSPROUL@RUTGERS.ARPA
Subject: MACTEP
To: info-mac@SUMEX-AIM.ARPA
ReSent-date: Wed 20 Jun 84 16:21:27-PDT
ReSent-From: Ed Pattermann <Pattermann@SUMEX-AIM.ARPA>
ReSent-To: info-mac: ;
Could someone send me the latest version of MACTEP, I know that the version
I am curently using is a very old version...
[Ed. If someone can send the latest MACTEP to INFO-MAC@SUMEX, I will post to
the list and store on SUMEX-AIM. Thanks.]
Thanks,
Keith Sproul
KSproul@Rutgers.arpa
-------
Message 19 -- ************************
Mail-From: PATTERMANN created at 20-Jun-84 16:21:31
Return-Path: <JFORREST@SIMTEL20.ARPA>
Received: from SIMTEL20.ARPA by SUMEX-AIM.ARPA with TCP; Wed 20 Jun 84 05:47:12-PDT
Date: Wed 20 Jun 84 06:48:04-MDT
From: Jim Forrest <JFORREST@SIMTEL20.ARPA>
Subject: MBASIC & MACPAINT
To: INFO-MAC@SUMEX-AIM.ARPA
cc: JFORREST@SIMTEL20.ARPA
ReSent-date: Wed 20 Jun 84 16:21:31-PDT
ReSent-From: Ed Pattermann <Pattermann@SUMEX-AIM.ARPA>
ReSent-To: info-mac: ;
Anyone know if there is a way to put a Macpaint drawing at the top of
a page when lprinting in MBASIC on the Macintosh?
Help greatly appreciated.
Jim
-------
Message 20 -- ************************
Mail-From: PATTERMANN created at 20-Jun-84 16:21:33
Return-Path: <Piersol.pasa@Xerox.ARPA>
Received: from Xerox.ARPA by SUMEX-AIM.ARPA with TCP; Wed 20 Jun 84 11:29:33-PDT
Received: from PinotNoir.ms by ArpaGateway.ms ; 20 JUN 84 11:28:46 PDT
Date: Wed, 20 Jun 84 11:28 PDT
From: Piersol.pasa@XEROX.ARPA
Subject: Re: Cursor Programming
In-reply-to: "MIKES@CIT-20.ARPA's message of 15 Jun 84 15:05 PDT"
To: Mike Schuster <MIKES@CIT-20.ARPA>
cc: info-mac@SUMEX-AIM.ARPA
ReSent-date: Wed 20 Jun 84 16:21:33-PDT
ReSent-From: Ed Pattermann <Pattermann@SUMEX-AIM.ARPA>
ReSent-To: info-mac: ;
The difficulty with such 'rectangular' selections comes when a variable
width font is used. As many of us have experienced, columnar output
doesn't line up very well if the font is something like New York. This
means that a selection out in the white space at the end of lines has an
indeterminate value. Since tab marks on this kind of editor are pixel
based rather than column based, they also pose problems with this sort
of selection. Only with the assumption of fixed width fonts do
'rectangular' selections become easy to implement and use.
Kurt
Message 21 -- ************************
Mail-From: PATTERMANN created at 20-Jun-84 16:21:35
Mail-From: PATTERMANN created at 20-Jun-84 14:40:16
Date: Wed 20 Jun 84 14:40:16-PDT
From: Ed Pattermann <Pattermann@SUMEX-AIM.ARPA>
Subject: Updated list of recipients
To: info-mac@SUMEX-AIM.ARPA
ReSent-date: Wed 20 Jun 84 16:21:35-PDT
ReSent-From: Ed Pattermann <Pattermann@SUMEX-AIM.ARPA>
ReSent-To: info-mac: ;
Here is an updated list of INFO-MAC recipients. Thanks to all those who
cited the omissions in the previous list. -- Ed
ADVANCED COMPUTER COMMUNICATIONS
ADVANCED INFORMATION and DECISION SYSTEMS
APPLE
ATARI
BANG WORLD COMMUNICATIONS CENTER
BETHESDA RESEARCH LABORATORY
BOLT BERANEK and NEWMAN
BROOKHAVEN NATIONAL LABORATORY
BROWN UNIVERSITY
CALIFORNIA INSTITUTE of TECHNOLOGY
CARNEGIE MELLON UNIVERSITY
CASE WESTERN RESERVE UNIVERSITY
COLUMBIA UNIVERSITY
COMPUTER THOUGHT INC.
CORNELL UNIVERSITY
DARTMOUTH COLLEGE
DEFENSE COMMUNICATION ASSOCIATES
DIGITAL EQUIPMENT CORPORATION
FORD AEROSPACE
FORTUNE SYSTEMS
HARVARD
HEWLETT PACKARD
HONEYWELL
IMAGEN
INFORMATION SCIENCES INSTITUTE (ISI)
JET PROPULSION LAB
LUCASFILM
LAWRENCE BERKELEY LAB
LAWRENCE LIVERMORE LAB
LOS ALAMOS NATIONAL LAB
MASSACHUSETTS INSTITUTE of TECHNOLOGY
MICROSOFT INC.
MITRE CORPORATION
NASA AMES RESEARCH CENTER
NATIONAL BUREAU of STANDARDS
NATIONAL LIBRARY OF MEDICINE
NATIONAL SCIENCE FOUNDATION
NAVAL OCEAN SYSTEMS CENTER
NAVAL RESEARCH LABS
NAVAL WEAPONS CENTER
NEW YORK UNIVERSITY
PHOENIX COMPUTER OPERATION
PURDUE UNIVERSITY
RAND CORPORATION
RENSSELAER POLYTECHNIC INSTITUTE
RICE UNIVERSITY
RUTGERS UNIVERSITY
SRI INTERNATIONAL
STANFORD UNIVERSITY
STATE UNIVERSITY OF NEW YORK AT STONY BROOK
SUN MICROSYSTEMS
SYMBOLICS INC.
TEKTRONIX INC.
TELTONE
UNISOFT
UNIVERSITY of ARIZONA
UNIVERSITY of BRITISH COLUMBIA
UNIVERSITY of CALIFORNIA at BERKELEY
UNIVERSITY of CALIFORNIA at IRVINE
UNIVERSITY of CALIFORNIA at LOS ANGELES (UCLA)
UNIVERSITY of DELAWARE
UNIVERSITY of MARYLAND
UNIVERSITY of MASSACHUSETTS
UNIVERSITY of MICHIGAN
UNIVERSITY of PENNSYLVANIA
UNIVERSITY of ROCHESTER
UNIVERSITY of SOUTHERN CALIFORNIA
UNIVERSITY of TEXAS
UNIVERSITY of TORONTO
UNIVERSITY of UTAH
UNIVERSITY of WASHINGTON
WHITE SANDS MISSILE RANGE
XEROX PARC
YALE UNIVERSITY
VANDERBILT UNIVERSITY
-------
Message 22 -- ************************
Mail-From: PATTERMANN created at 21-Jun-84 15:03:24
Mail-From: ZATZ created at 20-Jun-84 21:28:09
Date: Wed 20 Jun 84 21:28:09-PDT
From: Leslie Zatz <ZATZ@SUMEX-AIM.ARPA>
Subject: REPAIRS
To: INFO-MAC@SUMEX-AIM.ARPA
ReSent-date: Thu 21 Jun 84 15:03:24-PDT
ReSent-From: Ed Pattermann <Pattermann@SUMEX-AIM.ARPA>
ReSent-To: info-mac: ;
An inquiry to the Stanford Microdisc repair group regarding
cost of repair: the logic board and the power board are
not repaired but replaced at costs off $500+ and $150+ if they
go down including return of the defective board. At present
the Stanford group is experiencing about a 2% failure rate
in the 600 or so MACS distributed since April.
This is a very high charge by APPLE in my opinion.
One must pay this cost even if one component on the board
fails. This makes the extended warranty
sound like a bargain.
Is it likely that alternate repair sources will appear?
Comments?
-------
Message 23 -- ************************
Mail-From: PATTERMANN created at 21-Jun-84 15:03:26
Return-Path: <kalagher@mitre>
Received: from mitre by SUMEX-AIM.ARPA with TCP; Thu 21 Jun 84 04:53:28-PDT
Date: 21 Jun 1984 7:48:02 EDT (Thursday)
From: Dick Kalagher <kalagher@mitre>
Subject: Macpascal
To: info-mac at sumex-aim
ReSent-date: Thu 21 Jun 84 15:03:26-PDT
ReSent-From: Ed Pattermann <Pattermann@SUMEX-AIM.ARPA>
ReSent-To: info-mac: ;
On page 19 of the new (July/August) Macworld it is stated that Macintosh
Pascal is in retail stores as of press time. Has anyone actually seen
it in a store? Where?
Thanks, Dick Kalagher
Message 24 -- ************************
Mail-From: PATTERMANN created at 21-Jun-84 15:03:29
Return-Path: <winkler@harvard>
Received: from harvard.ARPA by SUMEX-AIM.ARPA with TCP; Thu 21 Jun 84 07:02:21-PDT
Received: by harvard.ARPA (4.12/4.27)
id AA17439; Thu, 21 Jun 84 10:11:09 edt
Date: Thu, 21 Jun 84 10:11:09 edt
From: winkler@harvard (Dan Winkler)
Message-Id: <8406211411.AA17439@harvard.ARPA>
To: TIM@MIT-MC.ARPA, info-mac@SUMEX-AIM.ARPA
Subject: Re: Quickdraw Regions internals (It's a secret.)
ReSent-date: Thu 21 Jun 84 15:03:29-PDT
ReSent-From: Ed Pattermann <Pattermann@SUMEX-AIM.ARPA>
ReSent-To: info-mac: ;
I'm afraid that Apple considers the data structures and algorithms
used by Quickdraw to be trade secrets. Bill Atkinson told me he'd
be glad to explain it all "when Apple let's me" but said he didn't
know when that would be.
Message 25 -- ************************
Mail-From: PATTERMANN created at 21-Jun-84 15:03:31
Return-Path: <rael@cmu-cs-spice.arpa>
Received: from CMU-CS-SPICE.ARPA by SUMEX-AIM.ARPA with TCP; Thu 21 Jun 84 09:40:54-PDT
Date: 21 Jun 1984 12:34:30-EDT
From: Nicholas.Caruso at CMU-CS-SPICE
Subject: Bug in the new macpaint...
ReSent-date: Thu 21 Jun 84 15:03:31-PDT
ReSent-From: Ed Pattermann <Pattermann@SUMEX-AIM.ARPA>
ReSent-To: info-mac: ;
Has anyone else had trouble getting a "print directory" of another volume
(not the boot volume) under the latest release of macpaint?
A system error occurs every time we attempt to directory a volume
that isn't the one we booted from. I' not sure what the id= xx number is.
-Nick Caruso
(Rael@cmu-cs-spice)
-------