info-mac@uw-beaver (03/21/85)
From: Moderator John Mark Agosta <INFO-MAC-REQUEST@SUMEX-AIM.ARPA>
INFO-MAC Digest Wednesday, 20 Mar 1985 Volume 2 : Issue 18
Today's Topics:
Skel - a Sumac C version
Revision to sumac verison of skel.
key mapping in macterminal
Animating DAs
MacWrite 4.2 is NOT final
RE: Finder 3.0X
binhex
INFO RE: CENTA SYSTEMS 512 UPGRADE
Bad MacWrite Files
256K DRAM chips
Questions about the Mac XL under Uni+ and Xenix.
Request on Display decay time
----------------------------------------------------------------------
Date: Mon 18 Mar 85 13:42:05-EST
From: Charlie C Kim <US.CCK@CU20B.ARPA>
Subject: Skel - a Sumac C version
Here's a sumac C version of the skeleton macintosh application in shar
format (includes makefile, c source, and resource control file).
Charlie C. Kim Columbia Univ. Ctr. for Computing Activities
[ Please find the shar archive in <info-mac>utility-skel.shar -jma ]
------------------------------
Date: Mon 18 Mar 85 15:38:23-EST
From: Charlie C Kim <US.CCK@CU20B.ARPA>
Subject: Revision to sumac verison of skel.
I let myself give in to the classic malady--the last minute change. I
messed up the resource maker file. The following should fix it. Any
real problems will probably show up in the finder info part. Also,
there is a problem with extra char's on the end of strings. I believe
rounding needs to be turned on (but didn't bother trying to figure out
how).
[The Correct version has replaced utility-skel.shar -jma ]
------------------------------
Date: 19 March 85 10:50 EST
From: RGG%CORNELLC.BITNET@Berkeley
Subject: key mapping in macterminal
Several requests have gone by recently for information on how to
change the key mappings for MacTerminal. The following ramble
describes (I think) how to do this. I hope it is useful.
Keyboard Mapping in MacTerminal
When a key is pressed in Macterminal, the keydown event is
detected and a routine called KbdEvent is called. KbdEvent takes the
key code (see Inside Mac Event Manager for the key codes) and
translates it to an internal form through a map stored as resource
KCKI-256 (VT100) or KCKI-257 (IBM 3278). This map has one byte per
possible key code from 00 to 95. The purpose of this translation is
just to eliminate the unused key codes so that the next translation
table can be more compact.
KbdEvent then takes the output of KCKI and translates it through a
second map which is stored as resource KICH-256 (VT100) or KICH-257
(IBM 3278). This map has sixteen bytes per entry, which correspond to
the possible permutations and combinations of the status of the
option, caps lock, shift, and command keys. The following table tells
which is which.
Option CapLock Shift Command
1 up up up up
2 up up up down
3 up up down up
4 up up down down
5 up down up up
6 up down up down
7 up down down up
8 up down down down
9 down up up up
10 down up up down
11 down up down up
12 down up down down
13 down down up up
14 down down up down
15 down down down up
16 down down down down
The entries in this table can be either characters to transmit
(values between 0 and 127) or action codes (values between 128 and
255). The action codes are interpreted through a rather complex sceme
involving a state table (resource STTB) and a bunch of hard wired
logic. Fortunately, it is not really necessary to understand that
part to accomplish most key re-mapping projects.
Suppose, for example, we wish to make the Enter key act the same
as the Return key. Tracing through the various resources, we see that
key code 36 (the return key) is mapped to 37 by the KCKI resource.
Looking then at the 37th sixteen-byte entry in the KICH resource we
find that all eight entries are 13, the ASCII carriage return code. To
make Enter (key code 52) behave the same way , we could either change
its KCKI entry to map to entry 37 in the KCKI resource, or we could
change the enter key entry in KCKI.
(my thanks to Martin Haeberli, co-author of Macterminal, who explained
most of this to me) Tom Dimock RGG@CORNELLC on BitNet
------------------------------
Sender: Hoffman.es@XEROX.ARPA
Date: 20 Mar 85 15:22:24 PST (Wednesday)
Subject: Animating DAs
From: Andy Stadler c/o <Hoffman.es@XEROX.ARPA>
Has anyone else tried to write desk accessories which use animation?
Beause I am, and I think I've found a problem.
I am depending on the 'dNeedTime' bit, which is purported to give the
desk accessory control at a periodic rate, up to 60 times a second.
This seems to work fine, and 60 Hz is more than enough for my
animation. But this depends on the application calling SystemTask at
least that often. Quoting 'Inside Macintosh', Desk Manager, 4th
draft, page 10: "SystemTask should be called at leat every sixtieth
of a second." Word of Apple is Word of God, right?
But the FINDER doesn't do this!
At best, it seems to give me 20 - 30 Hz. Almost every other program
I've tried has no problem. I'm concerned because most DAs are tried
out in the Finder, and honestly, the slow animation makes my code look
pretty bad. Yet as soon as you run MacWrite (or whatever), it speeds
up and becomes a fun game.
As far as I'm concerned, the solution is pretty trivial. Most main
even loops look like this:
Loop:
Repeat
SystemTask;
If Event then ProcessEvent;
HouseKeeping;
Until QuitSelected;
Since the user is usually just staring at the screen, there shouldn't
be all that many events. So the slowdown is in the housekeeping
(whatever that involves). Quoting Apple again, same source, "Call
[SystemTask] more than once if your application does an unusually
large amount of processing each time through the loop." The solution
is therefore trivial:
Loop:
Repeat
SystemTask;
If Event then ProcessEvent;
SomeHouseKeeping;
SystemTask;
MoreHouseKeeping;
Until QuitSelected;
Anyway, regard this as a plea from us DA developers to you Application
developers. Keep those SystemTasks coming. Or if anyone has a
solution for the DA writer, please respond. One idea: Is it safe to
call QuickDraw routines from Vertical Interrupts?
Andy Stadler c/o <Hoffman.es@XEROX.ARPA>
P.S. If you're listening, Microsoft, Multiplan is fine but Word is
pretty slow. And Apple, your other programs are great, except
MacDraw, which is marginal.
------------------------------
Date: Tue 19 Mar 85 23:06:00-PST
From: michael tchao <TCHAO@SU-SCORE.ARPA>
Subject: MacWrite 4.2 is NOT final
MacWrite 4.2 is NOT the final release of MacWrite. Release
4.3 was distributed 3/19/85 and release 4.2B was released before that.
Dealers were shipped 4.1 to demo the LaserWriter, NOT as final
software.
On the subject of 3.0+ experimental FINDERs, beware. I had
file copying problems running 2.9x with my Tecmar 2.0 hard disk.
Copying FINDER 3.4x to my Tecmar apparently trashed some file used in
the Tecmar boot process. The result was that I could not access any
of my files on the Tecmar and the Mac Drive had to be re-initialized -
all files were lost because Tecmar has no available scavenger program
(at least their tech support people don't know of one) A friend says
Finder 3.3x works fine with MacWorks on an XL. Remember, you take
your chances with any unreleased software.
michael
------------------------------
Date: Tue 19 Mar 85 21:41:22-PST
From: Gustavo Fernandez <FERNANDEZ@SU-SCORE.ARPA>
Subject: RE: Finder 3.0X
The 3.0X finder is indeed nice. To fill in some details left out in a
previous digest, the SET QUICK QUIT function works as follows:
Select a RANGE of icons using the box outline or shift-click, then set
quick-quit. This will install an init resource in the system file
which will intercept a return to the finder and bring up a quick-quit
menu which allows you to jump directly to any of the files that you
had originally selected. Eject, shut-down, and Finder buttons are also
available at this level. This is very much like the skip-file desk
accessory in <INFO-MAC>. Although quite different in detail, it
performs essentially the same function.
There are still a few bugs in this finder. Every once in a while, one
of the icons disappears. This may indeed be a "deliberate" bug, as was
mentioned in the "official" release notes for finder 2.6 which I read
some weeks ago. This is so that nobody gets any ideas about releasing
this thing with any products! X is for eXperimental!
On the subject of Beta software streaming from Apple, the latest
switcher I've seen (1.5) has a cute little icon showing the hand
holding a match over a bomb! This has obvious connotations!
Does anyone have the scoop on the new Macterminal 2.0? (The fact that
many people still prefer the old -.15x version says something about
the current release!)
Gus
fernandez
------------------------------
Date: 20 Mar 1985 10:13-EST
From: Henry.Kautz@rochester.arpa
Subject: binhex
A big problem with Binhex4.0 is that it does not ignore comments which
appear before the first colon (:) in column 1 in the input file, as
binhex2.0 did. This is very inconvenient, since it is very useful to
keep a description of the contents of the file there. I urge the
author of binhex (and xbin) to restore this "feature".
- --- Henry Kautz
:uucp: {seismo|allegra}!rochester!henry
:arpa: henry@rochester
:mail: Dept. of Comp. Sci., U. of Rochester, NY 14627
:phone: (716) 275-5766
------------------------------
From: John Clark <clark@rand-unix>
Date: 19 Mar 85 11:33:38 PST (Tue)
Subject: INFO RE: CENTA SYSTEMS 512 UPGRADE
In reply to the query of Steven B. Munson <sbm@Purdue.ARPA> re Centa
Systems, Inc:
Centa is owned and operated by a friend of mine, Chris Griffin.
Centa's primary business at this time is in upgrading Macs from 128K
to 512K. Chris is an accomplished hardware hack who has worked for
Wicat and Signetics in the past. He is an avid Mac enthusiast with
some interesting ideas for future Mac hardware enhancements.
Thus far, Chris has upgraded well over a hundred Macs, with no
problems. Several of his customers are acquaintances of mine, and
they are all uniformly happy with their upgrades. I plan to have my
Mac upgraded by Centa as soon as I can scrape together the cash.
Chris uses 150 ns chips, soldered on the board; he does not install
sockets unless the customer requests it. He will modify your board
directly, or, for faster turnaround, he will simply do a board
swap--your choice. Either way, the cost is $350. RamDisk software is
included (I don't know which RamDisk program he provides--a public
domain one, I presume). He warrantees his work for 90 days.
Chris is more than happy to provide details about his upgrade. I
suggest you contact him directly if you have questions. Centa's
address and phone are:
Centa Systems, Inc.
5308 Derry Ave., Suite C
Agoura Hills, CA 91301
818/889-6246
The usual disclaimers apply...other than my friendship with Chris, and
my soon-to-be-a-customer status, I have no connection with Centa
Systems.
- -John Clark
(clark@rand-unix)
------------------------------
Date: Mon 18 Mar 85 17:39:32-CST
From: CMP.BARC@UTEXAS-20.ARPA
Subject: Bad MacWrite Files
I've recently been having a lot of MacWrite files go bad. By "bad", I
mean that the files contain a large amount of garbage characters and
that all the MacWrite formatting is gone (e.g., tabs, fonts. In fact,
the rulers don't even appear.). The predominant garbage character is
a box, which corresponds to an unmapped keystroke sequence and leads
me to believe that I'm seeing MacWrite's control information being
displayed instead of executed. It's as if MacWrite has saved it as a
MacWrite file but opened it as a text file. Incidentally, when a file
goes bad, it incurs a disk space penalty (probably being charged with
the format characters that have become text).
The question I have is: Is there any way I can salvage these files or
avoid problems in the future?
Since the bad files initially seemed to arise exclusively from
"recording off the top" in MacTerminal 1.1, I thought the problem
dealt with some confusion in the system (or in me) about the
conversion of MacTerminal files to MacWrite or Text files. My
standard procedure was to open the MacTerminal file, edit it a little
to improve the format, etc., save it as "Text Only". However, I have
tried all the variations in saving and resaving the files, and have
used other communication programs (MacTep, TTY and Kermit) to
download, all with the same result: After opening the file several
times, it suddenly and unpredictably goes bad. I have also tried the
Utah File Editor instead of MacWrite, again to no avail. I tried this
on several disks and several systems, including Lisa/MacWorks. Since
most of the files are fairly large, I thought that size might be
causing the problem. I still use the old MacWrite 2.20 (precisely so
I can avoid file corruption or disappearance), for which space is
still a problem. However, I recently had the same experience with a
half page file, that had been created by MacWrite 2.20 and manipulated
only by that program. Moreover, I had a backup of an earlier version,
but it too was bad. I have changed a lot of the variables -- comm, WP
and system software, as well as hardware -- but the result persists.
I have tried Set File and the Resource Editor/Mover, to see if I can
reset some appropriate parameter, but haven't stumbled on the key.
Moreover, I haven't found anyone in our (rather large) local users'
groups that has had this same problem.
Dallas Webster
------------------------------
Date: Mon 18 Mar 85 13:36:48-PST
From: J. Todd Bridges <B.BRI%LOTS-A%LOTS-A@SU-SCORE.ARPA>
Subject: 256K DRAM chips
Advertisement in the San Jose Mercury news of 18 March 85:
41256 - 150ns, min 100 pcs......$5.99
NEC, Fujitsu, Toshiba
Digital Innovations Corp. (408) 738-3893
No information is given regarding ordering procedure, handling or
shipping charges, etc. As usual, this is not an endorsement; merely a
report. On the phone, a salesman told me the qty 1 price would be
$9.00 and the qty 50 price would be $8.00. Note that one could upgrade
7 Macs with 112 chips, so maybe user groups will be interested.
Todd Bridges B.BRI%LOTS-A@SCORE.ARPA
------------------------------
Date: Thu, 14 Mar 85 06:08:42 est
From: rogerio%gvax@Cornell.ARPA (Rogerio Drummond)
Subject: Questions about the Mac XL under Uni+ and Xenix.
Does anyone in the net has had experience with Uni+ or Xenix on the
Mac XL ?
I have a Mac XL (1MB) and want to use it as a small software
development machine in Brazil where I'll be teaching in the near
future. Specificly I would like to know: (the questions apply to both
Uni+ and Xenix)
-What response do you get with different system loads? For example,
how
many users can be editing, say with vi, and still get a reasonable
response?
-What are the transmissions rates of the hard disks that are
supported?
-Have you used any multiple serial ports boards ?
Is there any board other than the Tecmar board available ?
-How annoying it is to switch back and forth between the Apple
software
and Uni+ or Xenix ?
Can one exchange files between these operating systems ?
-What cross compilers are available (C, Pascal or Modula) ?
Given the resources, I would like to implement file transfer and/or
disk partitioning between the Apple OS and whatever Unix (-like)
system I end up buying.
Please answer direct to me, I'll post a summary if I get substantial
responces.
Rogerio Drummond (rogerio@cornell.arpa)
------------------------------
Date: Wed, 20 Mar 85 16:26:24 pst
From: kensteen%ucbcoral.CC@Berkeley
Subject: Request on Display decay time
In order to use a MacIntosh as part of a laboratory display
system where we want to show information for millisecond intervals, we
need to know the phosphor decay rate. Any other information on
charateristics of the refresh rate and the minimal times needed to put
up full screen displays would also be helpful.
------------------------------
End of INFO-MAC Digest
**********************