INFO-MAC@SUMEX-AIM.STANFORD.EDU (Moderator Dwayne Virnau...) (05/07/87)
INFO-MAC Digest Thursday, 7 May 1987 Volume 5 : Issue 86
Today's Topics:
scripting, interfaces, etc
re: BigScreen Init Problems (ref: Info-Mac Digest v5 #84)
MacSnoop 1.03
Where is microemacs 3.8 for the Mac?
Mac II Video choices
Monitors for Mac II: How to do everything you want
Re: TOPS on a Mac XL?
V5 #85: TOPS, System 3.2, and Mac XL
Meta-Macintosh problems
Mac SE & HyperDrive FX 40 -- Review
----------------------------------------------------------------------
Date: Wed, 06 May 87 10:21:36 -0800
From: duggie@portia.Stanford.EDU
Subject: scripting, interfaces, etc
I agree with David Gelphman's assesment of scripting capabilities on the
Mac-- it belongs in the system. Although much of the Macintosh interface
is 'standard' i.e. resizeable windows with scrollbars, menus, DA's (and
names of Juggler application tasks) under the apple menu, the only access a
macro program has to these is via the mousedown location. If things aren't
in fixed locations someone (you or the program) has to go through all sorts
of gyrations to get things done.
A larger problem is that many actions are ambiguous-- more so than text
commands. Is a click in a scrollbar a command to scroll up N lines or
scroll to line N? Do you want Geneva 12 or the first real size of the
current font? Is the path of the mouse important, or just where the next
mouseup or mousedown occurs? Letting the user make these choices
interactively provides greater ease of use (sometimes) but severely limits
the computer's ability to record the user's intentions.
Translating actions into a written command script which can then be edited
is a partial solution-- it's better if the editor is part of the scripter,
so that ambiguities can be flagged and a menu of alternatives offered as
you edit and replay the script. Another partial solution is to encode
strings of mac events as higher-order events. A mousedown in a menu item
is really a selection of a particular function or font or option. A click
and drag in the grow box of a window is really a command to resize the
window. 'Standard' encodings could be done by the Mac OS, and applications
should be able to extend them for sequences of events it attaches a meaning
to. If one were to combine these two approaches, of course, that means the
OS might have to query the application about the text representation of an
event and about what ambiguities the application recognizes. Since this
would have to be standard across applications, the protocol would have to
be specified by Apple.
Somehow I doubt they see this as a high priority. They want to keep their
application base and this precludes radical changes to the OS, of which
this would be just a small part. The 'accretion' model they're following
may trap them in a few years-- but who knows, they may have a solution. I
want them to build a completely new OS, but then I program for a living.
Doug Felt, IRIS
duggie@portia.stanford.edu
------------------------------
Date: Tue, 5 May 87 22:55:48 PDT
From: digiorgi@Jpl-VLSI.ARPA
Subject: re: BigScreen Init Problems (ref: Info-Mac Digest v5 #84)
Since I was mentioned (for my glowing report on the Big Screen Init), I
felt I perhaps I could help checkout the problems. First of all, my machine
currently is a 512K logic board, 128K ROMs, Max2 1.5MByte added memory,
Apple HD20, and 2x800K Sony drives. I'm running System 4.0/Finder 5.4,
ImageWriter 2.5 and a boot block configuration set at version 22, 65536
Byte System Heap. My machine is quite stable and reliable in this
incarnation, except for the odd moment when the Sony drives get lost(!).
>The first problem is that it's essentially unusable with SuperPaint (and
>possibly other drawing programs), because *the screen does not get updated
>while the mouse is down*, unless you move far enough to force the screen to
>be scrolled. ...
Well, it fails with FullPaint and Versaterm, it works fine with MacDraw,
Ready,Set,Go!3, Helix, and most of the other applications I have on tap here;
It almost works with SuperPaint: the PaintBrush is the only tool I can detect
that doesn't show up until you release the mouse button or go off the
regular screen... Text in Paint mode takes forever to get to the screen
also.
>... Could be this is SuperPaint's problem, but I don't
>think so ...
I think it may be. Something about how they are handling the pattern transfer
for the PaintBrush tool (and text) conflicts with the INIT's screen emulation.
>The second and far more serious complaint is that sometimes Finder disk
>windows are improperly displayed: ...
This got me scared for a brief moment... but then I remembered that I have had
NO, repeat NO, problems with files/directories. I have a feeling that the
DeskTop file on your hard disk is getting a touch on the smarmy side.
I did have a problem with files/directories before I began using BigScreen,
shortly after I started using System4.0/Finder5.4. I found that they persisted
until after I did a complete DeskTop file rebuild (after resetting the size
of the System Heap in the boot blocks.). I also regularly use DiskExpress to
clean up my disk and recompact files: I find that helps the operation of the
machine enormously. I'd really recommend a backup and rebuild DeskTop.
>BigScreen's a nifty idea ... too bad the implementation is so unreliable.
I don't find BigScreen an unreliable INIT - what it does it does fairly
well. To be honest, I don't use it too frequently as the big screen emulation
speed tradeoffs are not acceptable to me very often. What I do find useful
with it are: designing templates in Helix (Helix' scrolling is Very Slow),
occasional MacDraw and RSG!3 work, and with Smalltalk. If you are unaware of
it, Apple's Smalltalk screen refresh/updating is very slow (unsupported
versions currently available from APDA). The BigScreen Init just doesn't slow
it down much more than it already is and gives me a lot more breathing space on
the 9" wonder, like the Tektronics Smalltalk machines' ability to
pan around a much larger virtual screen.
In sum, I just use BigScreen where I feel is appropriate and it works fine for
what I use it. And it only cost five bucks.
Godfrey DiGiorgi
digiorgi@jpl-vlsi
May 5, 1987
And I still don't get anything for all this!
Comments are my own, free advice is worth what you pay.
------------------------------
Date: Wed, 6 May 87 11:02 EDT
From: Jeffrey Shulman <SHULMAN%slb-test.csnet@RELAY.CS.NET>
Subject: MacSnoop 1.03
[ Uploaded from Delphi by Jeff Shulman ]
Name: MACSNOOP
Date: 4-MAY-1987 22:19 by GPSART
MacSnoop is a Shareware file/volume editor released to take the place of
FEDIT as it leaves for the realm of commercial software. MacSnoop has some
unique features such as the ability to have multiple editing windows open
at the same time. In addition, a full complement of utility functions
(delete, rename, etc) is available. The documentation file is in MacWrite
format. Thanks for your support!
[
archived as
[SUMEX-AIM.Stanford.EDU]<INFO-MAC>UTILITY-MACSNOOP-103-PART1.HQX
[SUMEX-AIM.Stanford.EDU]<INFO-MAC>UTILITY-MACSNOOP-103-PART2.HQX
[SUMEX-AIM.Stanford.EDU]<INFO-MAC>UTILITY-MACSNOOP-103-PART3.HQX
DoD
]
------------------------------
Date: Mon, 27 Apr 87 22:37:06 EDT
From: matthews@tcgould.tn.cornell.edu (Dave Matthews)
Subject: Where is microemacs 3.8 for the Mac?
> Path: batcomputer!cornell!uw-beaver!mit-eddie!genrad!decvax!dartvax!earleh
> From: earleh@dartvax.UUCP (Earle R. Horton)
> Newsgroups: comp.sys.mac,comp.emacs
> Subject: microemacs 3.8 Macintosh differences and sources
> Keywords: diffs, sources, microemacs 3.8, Macintosh
> Message-ID: <5891@dartvax.UUCP>
> Date: 23 Mar 87 19:25:48 GMT
> Organization: Society for the Prevention of Cruelty to Graduate Students
>
> I just posted a Macintosh version of microemacs 3.8 to mod.mac.binaries.
> ...
> I am posting "diffs" to mod.mac.sources that show how to generate a
> Macintosh version of microemacs. I include diffs for all of the
> microemacs sources I used, although many of them are small. The
Did anyone receive these items? I might have missed the sources, but I'm
pretty sure the binary never appeared here. If you have it, *please* send
me a copy. (If you want it too, let me know.) Thanks,
Dave Matthews
ARPA: matthews@batcomputer.tn.cornell.edu In real life: anonymous
USENET:...{cmcl2,shasta,uw-beaver,rochester}!cornell!tcgould!matthews
BELL: 607-533-7820 DISCL: My employer ignores my opinions altogether.
[
I have not received anyting either, source or diff files. If someone can
send these things to INFO-MAC@SUMEX-AIM as well as to Dave,, I can post
them into the archives.
DoD
]
------------------------------
Date: Wed, 6 May 87 09:44:31 edt
From: stew%lhasa@hucsc.HARVARD.EDU
Subject: Mac II Video choices
According to Bob Perez at Apple, the NEC Multi-Synch and Sony Multi-Scan
monitors will both work with the Apple video board for the Mac II. He goes
on to say that no monitor he's seen looks half as good as Apple's own color
RGB Hi-Res monitor.
In other messages, it comes out that although the CPUs and 40Mb disks are
shipping, both the RGB and Monochrome monitors are delayed. There are
going to be a bunch of folks (me included) with a Mac II and nothing to do
but plug it in and watch the power light, unless I want to get a
Multi-Synch or Multi-Scan (about $550) for a month or two.
Anyone want to buy a slightly used Multi-Synch (delivery in August)?
------------------------------
Date: Wed, 6 May 87 09:20:30 EDT
From: bill coderre <bc@MEDIA-LAB.MEDIA.MIT.EDU>
Subject: Monitors for Mac II: How to do everything you want
Short Answer: The following monitors can be coerced to work with MacII
color card: NEC Multi-Sync, Taxan Super Vision 770, IBM PGA monitor.
("Keep in mind that these IBM monitors are of lesser quality than the
Apple monitor, so your resolution will be of lesser quality" -- MacDTS
person on AppleLink) For other monitors, you'd better contact the
manufacturer, I don't know.
BTW, the Apple monitor is extremely wonderful. Marvin Minsky was
kidding people, saying "How'd they put color in just the upper left
corner of the screen?" I do believe it's a Sony Trinitron tube, it has
the "Trinitron line" (a black hairline across the screen 2/3 of the
way down). My user impression is "very sharp, fine for black-and-white
small font work, b/w monitors still a touch better, but not by much!"
I went around the rosey a few times with MacDTS on AppleLink
concerning MacII color monitors, and here is what I found out. Hang on
tight! Technical mumbo-jumbo follows:
EXACT TECH SPECS: (for those that would roll their own)
HORIZONTAL:
Frequency 35 KHz exactly
Period 1/35 KHz = 28.5714 microseconds
Back Porch 96 dots
Front Porch 64 dots
Sync 64 dots
Active 640 dots
Blanking 96+64+64 dots (= 224 dots)
Pixel Clock 30.24 MHz (therefore one dot = 33.0687 ns)
VERTICAL:
Frequency 66 2/3 Hz
Back Porch 39 horizontal scan lines
Front Porch 3 lines
Sync 3 lines
Active 480 lines
Total 525 lines
Note that the MacII is non-interlaced video, of course.
SIGNALS AND PINOUTS: (You'll need this info to make the right cable.
Remember to shield everything, or you will throw away the goodness of
your monitor.)
The MacII Color Card (code name Beck's) provides a DB-15 female to
attach to. It provides separate red, green, and blue signals, with
composite sync on green and on a separate pin. (Composite sync means
horizontal and vertical sync on one line.)
1 GND
2 RED
3 CSYNC
5 GREEN
9 BLUE
You will have to consult your monitor's manual to find out how to
connect up. I do recall the NEC Multi-Sync being pretty easy to do.
Whew! There you go, the whole story in one message. Good luck!.....bc
------------------------------
Date: Wed, 6 May 87 14:08:29 PDT
From: George Pavel <gp@lll-lcc.arpa.ARPA>
Subject: Re: TOPS on a Mac XL?
I have run TOPS on a Mac XL with System 3.2 and Finder 5.3 with no problem.
I didn't do anything special to make it work; it worked first time.
George Pavel
Lawrence Livermore National Laboratory
P.O. Box 808 L-68
Livermore, CA 9455 Internet: gp@lll-lcc.arpa
(415)422-4262 UUCP: ihnp4!lll-lcc!gp
------------------------------
Date: Wed, 6 May 87 17:52 EDT
From: Hess@MIT-Multics.ARPA
Subject: V5 #85: TOPS, System 3.2, and Mac XL
TOPS works fine (although with many delays) on my Mac XL, System 2. My
understanding was that there was absolutely no reason to expect an HFS
System to run under MacWorks 3.0, and that Apple had no plans to release a
later version of MacWorks to make HFS work.
I don't think it's TOPS's fault, except that it must actually be using
some part of the HFS that isn't compatible with MacWorks.
By the way, if anybody gets it working, I'd like to hear about it; we'll
soon have a two-profile useless Lisa that could happily sit around
running AppleShare if only the Finder and System could work...
Brian
------------------------------
Date: Wed, 6 May 87 17:59 ADT
From: <FNCAH@ALASKA.BITNET>
Subject: Meta-Macintosh problems
I am not sure exactly who to address this question to, but it occurs in the
context of our university seeking an agreement for purchasing Macs, so I
thought I would start here.
As I am sure is the case for many, our university is very reluctant to use
anything but IBM-PCs as the *official* micro. A group of us has managed to
get Apple on campus and are in the process of trying to reach an agreement.
However, resistance is considerable: some members of the central
administration and the data processing dept. have even taken to trying to
prevent us from using the university's E-mail system to alert interested
persons on the Apple dealings (while promoting IBM-PC use on same). This
has resulted in a *discussion* on monitoring, censoring, or deleting mail
messages (which is getting nowhere fast). 8-(
I was hoping some of you might share your experiences on usings Macs in a
university environment, that I might pass along to show that we are not
wild-eyed MacLoonies, but users interested in getting the highest quality
work done with the least pain. Suggestions, comments or snide remarks on
using Macs or how your institution controls their E-mail systems with
respect to message content would be most appreciated! (A bit of background:
the UA is a public, land/sea-grant institution)
Thanks in advance for the help: I will try to summarize the responses and
forward if requested. Please reply to me directly by E-Mail, if possible.
Again, thanx.
Craig Helmuth Univ. of Alaska, Fairbanks
Bitnet: FNCAH@ALASKA US Snail: POB 83851
Fone#: 907 479-5534 Fairbanks, AK 99708-3851
Disclaimer: You know, if I knew they knew, then none of this would be new...
------------------------------
Date: 05 May 87 23:30:00 EDT
From: Marc Grondin <WCSCKCU@CARLETON.BITNET>
Subject: Mac SE & HyperDrive FX 40 -- Review
Recently the station acquired a Mac SE and a 40 Meg HyperDrive.
So here is a reveiw of the set up.
The Mac SE came to us with System 4.0 and Finder 5.4. Both of which appear
to run a bit faster than the older versions. The alerts and dialogue boxes
now have a flavour of "international signals", like the new red and white
yeild signs. Meaning that the icons are easier to relate to and make a bit
more sense. The new system to me is smother then the old one, but I find
the mouse tracks differently -- as if it is not sure how far you have moved
it. The Control Panel also offers a fancier style then the old ones, but I
find them not as user friendly. On the topic of the mouse, you can now
cover the standard screen with out moving your wrist, this is when in Fast
mode. Like wise, slow mode is SLOW and a large desk top would be needed.
The HyperDrive was delivered with System 3.2 (?) and finder 5.3. Of course
these were not installed. The FX Manager is version 2.20, and is easy to
use. The disk test is a bit slow, but I guess that it is digging out every
bit on the test. It is also very easy to set the SCSI priority number, it
uses a nice little picture of your Hard drives. The Park the heads option
does a good job. If the FX (HyperDrive) is not the boot disk, the drive is
deMounted and you get back to the finder. If it is the boot disk you are
warned that you must turn of the Mac if you go on to Park. There fore,
Parking the heads forces you to power down. BUT it will not eject the
floppies at this place, thus you find your 3.5s in the machine still
The FX is fast. Compared to the MDIdeas drive, I would say 2 times faster.
Other features :
Find File (System 4.0) : Finds a file on your HFS disk, a DA
from Apple, (Could be better).
Teach Text (Apple Util): Reads a generic text file, to be used
with Read-Me files.
ImageWriter Spooler : Comes with the FX and spools stuff to the
printer, does wonders to speed computing,
but a DA to "Flush Spool" would be nice
(Would save MUCH time and paper).
Laser Spooler : Have not used it, No Laser writer around here (yet)
Security : Encrypt and Decrypt files with a "Key" (I think any
person into code breaking can break the Key).
HD Backup : Both the Apple disks and the Hyper drive offered this,
but the Apple disks appear MUCH more simple to use.
Other utilities abound on these disks, but mostly like the ones you
get on the Mac+ a few months back.
ImageWriter Driver is version 2.5
Chooser is where you select Apple talk activity.
Find File works in the background.
Has an INIT file to be placed into your system folder.
LONG Font lists scroll
Keyboard is more inline with a computer persons board (ESC and
Control keys!! :-) )
Time to stop this long winded nonsense...
P.S. Do you have 50 800K floppies? I want to back this baby up!!
Marc Grondin (8->) <Marc_Grondin@CARLETON.BITNET>, <CKCU@CARLETON.BITNET>
------------------------------
End of INFO-MAC Digest
**********************