INFO-MAC@SUMEX-AIM.STANFORD.EDU (Moderator Dwayne Virnau...) (07/27/87)
INFO-MAC Digest Sunday, 26 Jul 1987 Volume 5 : Issue 109
Today's Topics:
FCMT and MPW help
FCMTs and DeskTop file rebuilding...
Detecting numeric keypad keypresses
Keyboard theories (V5 #108)
Adobe Fonts
Chooser 3.X
variable at $BAE
Cards & Drivers manual?
How do you determine software version numbers?
Re: terminal emulators for the macintosh
Summery - fast data acquisition with Mac II/SE
Prototyping software for Macintosh
Site Licences etc.
Re: Phospors, Smoked video screen
Mac II video
Mac II and color monitors
Mac II Hard Drives
Comparisons of Mac II internal HD with externals?
Re: DataFrame 40 XP vs internal Mac II hard drive
Screeching drives
----------------------------------------------------------------------
Date: Wed, 22 Jul 87 14:46:38 MET
From: norbert%germany.csnet@RELAY.CS.NET
Subject: FCMT and MPW help
I'd like to support Nihar Gokhale's suggestion and to extend it a bit:
Currently all the help information for all MPW tools is packed into a
single giant file, so if you want to add a new tool you always have to edit
that file. I think Apple should take a more modular approach and leave the
help information for any tool with that tool - in a resource named 'HELP'
or the like. Thus it would be easier to keep the help information
consistent with the tool configuration in use. The information could also
be used by the tool itself to give some help if it encountered erronous
parameters.
Norbert Lindenberg
Universitaet Karlsruhe, West Germany
------------------------------
Date: Thu, 23 Jul 87 09:12 EST
From: Paul Christensen <PCHRISTENSEN%rca.com@RELAY.CS.NET>
Subject: FCMTs and DeskTop file rebuilding...
Storing Finder comment information in the resource fork of each file
would be a bad move. If this were done, each time the user changed a
comment box, the file's modification date and file size would change.
It is relatively easy to keep the modification date from changing, but
consider a file with NO resource fork. Considering comments are usually
less than 60 characters long, and file allocation blocks range from 256
bytes to 2Kbytes, if many of these files have short comments, this can
add up to a BIG waste in disk space. User-oriented data such as file
Finder comments is best kept in a centralized location, as it is now.
One must also consider the remote possibility that the Mac crashes at
the very instant the Finder is updating an application's resource map
for the new comment resource. In this instance, the application would
cease working, which is DEFINITELY not user-friendly. In the present
implementation, if the Mac crashes when the Finder is updating the
DeskTop file, it is simply rebuilt the next time the disk is mounted,
and all that is lost is file comments, not data.
Many users have complained that when the DeskTop file is rebuilt
(which is a good move every so often) that all file comments are lost.
Although this would be relatively easy for Apple to correct, in the
meantime, I use one of two methods for recreating the DeskTop files on
my disks, INSTEAD of using command-option to have the Finder rebuild it:
By "brute force", I use ResEdit to remove ALL resources from the
DeskTop file EXCEPT types FCMT and STR. The next time the Finder
encounters this disk, it sees the STR 0 resource, realizes that this
is its own file, and simply re-fills it with the icon and path info
for the applications on that disk, without purging the file comments.
The more elegant way to purge the DeskTop file is to run DiskExpress and
select "compact desktop" for the disk. DiskExpress is smart enough to
search the disk, and remove only the icon information that is not needed
by any of the files on the disk, retaining the file comments. DiskExpress
also allows you to verify media and remove file fragmentation. At less
then $40, this program is a real bargain, and is a MUST for every Macintosh
owner.
Paul Christensen
CSNET: PCHRISTENSEN@RCA.COM
------------------------------
Date: Tue, 21 Jul 87 22:55 EST
From: FMQDM9%IRISHMVS.BITNET@forsythe.stanford.edu
Subject: Detecting numeric keypad keypresses
I've seen this topic come up several times, but I don't recall seeing
an answer. Herewith my technique:
Mask the event message with $00004000. If the result is non-zero,
the key pressed is either in the numeric keypad or is a cursor key.
This works on an SE with the standard keyboard. I don't know if it's
documented anyplace; I worked this out by trial & error.
Bill Gobie
Department of Chemical Engineering
University of Notre Dame
FMQDM9@UNDMAIL1 (Bitnet)
------------------------------
Date: Wed, 22 Jul 87 20:30:53 pdt
From: palomar!joel%beowulf@sdcsvax.ucsd.edu
Subject: Keyboard theories (V5 #108)
> In Volume 5 #108, Earle R. Horton wrote:
>The "=/*+" keys are SHIFTED, while the cursor keys are not. That is,
>the "=/*+" return the shiftKey bit set in the modifier flags. If you
>hold down the shift key and type one of the cursor keys, the application
>gets the keypad key, every time. Shifted: keypad, unshifted: cursor.
>This was done because Apple was in such a rush to release the Mac Plus
>that they were willing to ship it with an un-fixable hardware bug that
>few people would notice, rather than do the job right. This, to me,
>is an unacceptable business practice.
While I agree with the factual content, I take issue with the commentary.
Apple had to ship a keyboard that worked with a Mac 128, 512 and Plus,
and support the old keyboard on the Plus as well, so there were some
serious constraints on what could be done in hardware. The shifted-keys,
while brain-damaged, perfectly emulate the numeric keypad on the old
512 (see MacTutor, 8/86) Although this is the tail wagging the dog, the
lot was cast with the decision to provide an upgrade path for all the picky
512 owners and allow them to use either keyboard.
Incidentally, under System 4.1, Shift-arrows produce the keypad values
(as the ASCII numbers), but Command-Shift or Option-Shift come in
as the arrow values ($1C to $1F) with the appropriate modifiers set.
------------------------------
Date: Fri, 24 Jul 87 09:37:54 -0400
From: Alan Dahlbom <adahlbom@CC4.BBN.COM>
Subject: Adobe Fonts
David Gelphman writes in Vol 5 Issue 108:
> Basically I've been
> trying to modify the Adobe screen fonts so that I can install them
> into the system file and have only one font name appear in the
> fonts menus for each font family. I've been reasonably successful
> in some cases and sometimes there are some severe problems.
There is a fairly easy way to do this that I picked up from a local BBS.
Here is what you do:
1. Open the font file with ResEdit.
2. Open the FOND type resources.
3. Rename all FOND resources except the FOND that has the family name.
(e.g Rename Times-Bold but not Times) Rename them this way: Insert
a '%' character before the name.
4. Close the FOND resource window.
5. Open the FONT resource entry with the **option** key
6. About 1 out of every 4 or 5 resources should have a name in the
newly created window. Rename those that are not the family name as
in step 3, by inserting '%' before the name. Don't rename the
resource with the family name (e.g. Times).
7. Close everything up.
8. Install file with Font/DA Mover.
This works well with everything but Word 3.0, but is supposed to work
with Word 3.01.
------------------------------
Date: Wed, 22 Jul 87 11:30:58 GMT
From: Paul Skuce <mcvax!hatfield.ac.uk!comt-ps@seismo.CSS.GOV>
Subject: Chooser 3.X
Does any one know why the Appletalk bit in the PRAM has changed in the 3.x
releases on the chooser. Using PRAM4.0 the last byte of VALID is 30hex for
appletalk off on the control panel setting and 31hex. With the 3.x chooser
it is 31hex for AT on and 32hex for it off. I know this is trival but my
corvus gives an error id10 if AT is off with the 3.x choosers. Why Apple
did things change????
Regards
Paul Skuce
Hatfield Polytechnic, School Information Science, P.O. box109
College Lane, Hatfield, England, AL10 9AB
comt-ps%hatfield.ac.uk%mcvax%seismo%.. from States
comt-ps%hatfield.ac.uk%mcvax%.. From Eur
comt-ps@hatfield.ac.uk JANET
Thank God For Jesus
------------------------------
Date: Fri, 24 Jul 87 15:04:30 PDT
From: andy maas <maas@portia.Stanford.EDU>
Subject: variable at $BAE
Can anyone tell me what location $BAE (on MacII) is for?
Where can I get the list of low memory globals including the ones MacII uses.
Andy
------------------------------
Date: Wed, 22 Jul 87 20:14:31 pdt
From: Kevin R. Martin <martin@usc-cse.usc.edu>
Subject: Cards & Drivers manual?
Has anyone received an updated version of the Macintosh II and Macintosh
SE Cards & Drivers manual? I have an early draft version that references
a non-existant Appendix A in two places: once on page 10-6 refering to
NuBus test card PAL equations, and again on page 11-11 refering to
sample configuration ROM code for the Mac-II video card. Since I am
trying to build a video board to drive in house low resolution digital
monitors (and associated s/w drivers), this Appendix could be very
helpful to me!
Thanks.
email: martin@usc-cse.usc.edu
(213)-648-9531
------------------------------
Date: 23 Jul 87 13:46:00 EDT
From: Greg H. Hamm <hamm@biovax.rutgers.edu>
Subject: How do you determine software version numbers?
System software (System, Finder, LaserWriter, etc., etc.) which comes
from Apple usually has a version number noted in the "Get Info" box.
Most such software delivered with other products (including that present
on my DataFrame when it was delivered) omits this information.
Two questions and one flame:
1) How can one determine the version numbers when they are not
present in the info box?
2) Why on earth would a software (or hardware) manufacturer
remove this information? [I presume it takes a willful act to do
so, since the info text is normally copied with the file.]
**flame** Will all you manufacturers listening either explain
why you take this seemingly irresponsible action, or stop?
Greg H. Hamm || Phone: (201)932-4864
Director, Molecular Biology Computing Lab ||
Waksman Institute/NJ CABM || BITNET: hamm@biovax
P.O. Box 759, Rutgers University || ARPA: hamm@biovax.rutgers.edu
Piscataway, NJ 08854 * USA ||
------------------------------
Date: 20 July 1987, 12:50:40 PST
From: David M. Gelphman 415-854-3300 x2538 DAVEG at
From: SLACVM
Subject: Re: terminal emulators for the macintosh
I don't know about the white pine software programs but I am a big
VersaTerm user. Regarding your points about VersaTerm:
a) Full VT100/VT102 support -- there may be something lacking in the
emulation but the software I use doesn't use those features. Advanced
Video blink may be missing but I've never run into any problems in
my work environment.
b) Sliding windows Kermit is not in any version of VersaTerm that I am aware
of. I also can use this and have suggested to Lonnie that he include such
support.
c) XMODEM (MacTerminal 1.1) This has been supported for quite a while. Also
included is MacBinary XMODEM which is handy for dialup services.
d) keypad menu -- there is no keypad menu...personally I needed a keypad so
badly that I bought one. I hated reaching for the mouse to generate the
keypad characters. VersaTerm fully supports the keypad on ALL keyboards
so the menu is unnecessary.
e) No VT240 emulation.
To answer some of your other questions....YES it does color on the Mac II
in Tektronix 4105 mode. It supports color on the screen AND printing to the
ImageWriter II. As far as upgrades are concerned, this program is improved
regularly through reasonable ($10) updates. Lonnie regularly incorporates users
suggestions into the program and the updates are program improvements, not
bugfixes. As you can tell, I'm a satisfied customer.
One point you didn't mention and I wasn't sure whether you knew about it
is the ability of VersaTerm Pro to save Tektronix graphics in PICT format.
I find that to be quite useful (in addition to the other stuff).
Hope you find what you are looking for...
David Gelphman daveg%slacvm.bitnet@forsythe.stanford.edu
------------------------------
Date: Wed, 22 Jul 87 15:44:53 IST
From: Ami Zakai <RPR1ZAK%TECHNION.BITNET@forsythe.stanford.edu>
Subject: Summery - fast data acquisition with Mac II/SE
As I promised here is the summery of responces to my query about fast
data aqcuisition for the Mac II and Mac SE. I want to thank for the help:
Tom Coradeschi <tcora@ARDEC.ARPA>
Cal Teague <CCT@SIERRA.STANFORD.EDU>
Bruce Taylor <BGT.WB@GEN.BITNET>
From national Instruments there are these new cards:
NB-MIO-6 multifunction analog, digital & timing I/O board.
12-bit ADC, 16 channels, 111K samples/sec
2 12-bit DAC, unipolar or bipolar outputs
8 lines TTL I/O, up to 24mA sink
3 16-bit counter/timers
NB-AO-6 6 DACs, each 4-20 mA or 2.5 V or 10 V
up to 1 MHz sample rate
NB-DIO-32F 32-bit parallel digital I/O
NB-DIO-24 low cost 24-bit parallel digital I/O using 8255 PIA
NB-DMA-8 multifunction interface board
DMA transfer
RTSI board support
IEEE-488 interface, up to 1 Mbyte/sec
RTSI Real-Time System Integration
custom high speed bus and crossbar switch, interrupts, etc.
CERN has developed interfaces for the complete Macintosh family
which allow data acquisition at well over 100 Kbytes/sec.
The system is called MacVEE (Microcomputer Applied to the Control
of VME Electronic Equipment), and it provides direct access to
single or multi-crate VMEbus or CAMAC systems from the Macintosh,
Macintosh Enhanced, Macintosh Plus or Macintosh SE.
The MacVEE interface for Macintosh II (MICRON - MacVEE Interface Card
Resident On NuBus) is currently being polished for production and
should be available 4Q/87. It is compatible with the same VMEbus
master module and CAMAC crate controller as the earlier systems.
Installation is easier, because MICRON simply plugs into a NuBus slot
in Mac II.
****
Disclaimer: I have no comercial relation with any of the above.
'now, here, you see, it takes all the running you can do, to keep in the same
place. If you want to get somewhere else, you must run atleast twice as fast
as that.' /TtLG
------------------------------
Date: 22 July 1987 0202-PDT (Wednesday)
From: melmoy@nprdc.arpa (Mel Moy)
Subject: Prototyping software for Macintosh
Is there any software that will provide a prototyping facility on
the Macintosh in a fashion similar to the way that Dan Bricklin's
Demo program does for the IBM? My goal is to construct displays
and interface examples which play to the strength of the user
dialogues possible in the Mac environment.
Melvyn C. Moy
melmoy@nprdc.arpa
------------------------------
Date: Tue, 21 Jul 87 09:54:02 PDT
From: Lionel_Tolan%SFU.Mailnet@umix.cc.umich.edu
Subject: Site Licences etc.
I have two requests for information regarding Macintosh
software in use on University campuses.
1. I am trying to gather information about Macintosh software
which is available on a site licence basis. If you have
any site licenced software in use at your campus please
send me a message with the name of the package, the
suppliers name and address, and any comments you think
appropriate.
2. I am looking for a word processing package which would be
available for general distribution on campus. This could
be public domain, shareware, or site licenced. The main
thing is that it could be handed out in class for use on
machines distributed around campus without the instructor
or the university violating copyright. We have a site
licence for PCWrite on the MS-DOS machines and it fulfills
our requirement very well and makes software distribution
and monitoring much easier. I would appreciate any
information you have about what's good and what's not and
if you have an extra 5 minutes to drop me a line I'd
appreciate comments on how you handle these issues on your
campus.
In order to lighten the load for the moderator send responses
directly to me. I'll collect the responses and send a biggie
(I hope). Thanks in advance for your time on this.
USERLION@SFU.BITNET or LIONEL_TOLAN%SFU@UM.CC.UMICH.EDU
------------------------------
Date: Thu, 23 Jul 87 09:18:32 EDT
From: Jerry_McCarty@um.cc.umich.edu
Subject: Re: Phospors, Smoked video screen
> Date: 22 Jun 87 07:55:00 EST
> From: "ERI::SMITH" <smith%eri.decnet@mghccc.harvard.edu>
> Subject: Phospors
>Following up on a recent question, I'd like to start a discussion on phosphors
>because questions keep coming up ...
> ...No numeric data on persistence and decay is given.
This may help somewhat:
Persistence Time to decay to
10% of initial brightness
Very Long 1 Second and Over
Long 100 milliSeconds to 1 Second
Medium 1 milliSecond to 100 milliSecond
Medium Short 10 microSeconds to 1 milliSecond
Short 1 microSecond to 10 microSeconds
Very Short Less than 1 microSecond
Source: RCA Storage Tubes and Cathode Ray Tubes STC-900B
Dated Nov. 1966 (In other words, don't throw out the old stuff)
They cite the same JEDEC Publication for their reference.
> In general, CRT screens show obvious, gross departures from any kind of
> simple exponential decay model. At the very least many screens show an
> "afterglow." A Mac screen, for example, obviously has some decay on the
> order of 1/20 second, but also has an afterglow that lasts for minutes.
For your information, the official term for when the phosphor is
excited is called 'flourescence' and the afterglow is
'phosphorescence'. That may or may not help if you pursue the matter
any further.
> was drifting; it turned out that with the kind of measurement they were
> making, they were able to detect phosphor aging as they watched. (They were
> using an unscanned dot; current density was high, but NOT at a level that
> would startle any experienced CRT user. There was NO visible burning of
> the screen. Just that the output from the dot would slowly, slowly, but
> measurably keep s-a-a-a-a-a-g-i-n-g--and whenever they moved the dot slightly
> to a fresh place it would recover).
Beware: If the CRT under test has a shadow mask or an aperture grille
or whatever term is applied to the particular unit, it can and will
deform under high beam currents causing the effect you described. Some
night while you are home watching your favorite Clint Eastwood movie,
look for a large, high brightness scene (as compared to the rest of the
picture). After about a half a minute or so you can start to see some
color contamination in the white areas. This is not a phosphor problem.
It is the mask moving slightly resulting in the purity changing. Seems
to me that TV sets are more prone to this now than they used to be (15
years ago it was grounds for warranty replacement of the CRT. Not any
more) and that the larger screen sizes are more prone than the smaller
ones.
> Date: Tue, 30 Jun 87 17:24 CDT
> From: TILLEY%UOFMCC.BITNET@wiscvm.wisc.edu
> Subject: Smoked video board
> While downloading a large hqx file, my screen narrowed, funny interlacing
> and overlapping LARGE characters appeared and smoke poured out the top
> left of my 1984 stock fat mac (normally left on).
>
> I removed an obviously burnt capacitor (C1 25V 3.9uF bipolar) and
> temporarily tacked in an approximate replacement. Powered on and
> screen was perfect. This was too easy.
Your assumption that the replacement was 'approximate' may be off.
I do not know the function of the capacitor which burnt, however, in some
television sets some of the capacitors are exposed to abnormally high currents
which cause them to overheat. The ones used are special low-dissipation
versions which are built to handle the higher currents. Replacing a
low-dissipation version with an ordinary capacitor will cause overheating and
early failure of the replacement. My suggestion would be to try and match a
replacement based on make/model numbers off the original part. The other
suggestion would be to call up your local TV shop, play dumb and ask for his
advice on finding a replacement since I think may of these are available only
from the original manufacturer.
> Powered off, shorted CRT anode to chassis (a bad thing??) and permently
Probably is a bad thing to discharge the anode to ground. Since there is
usually a zillion volts or so on the anode, discharging to chassis could be
catastrophic when considering that no ground connection is perfect. Even a few
milliOhms of resistance could produce a rather large voltage differential
(large in reference to the operating voltages of the IC's) across the ground
planes which in turn could exceed the maximum safe levels of the IC's. It has
been my experience that waiting a period of time (10-15 minutes) is sufficient
to have the anode discharge by itself through the reverse leakage of the HV
rectifier. This will NOT bring the voltage down to 0! It will bring it low
enough so that any subsequent discharge will be at a much lower voltage. The
other thing to keep in mind is that it would be preferrable to discharge to the
outer conductive coating of the CRT rather that the chassis. Better yet,
disconnect the chassis completely before trying to discharge. (I know, easier
said than done)
------------------------------
Date: Wed, 22 Jul 87 20:30:58 pdt
From: palomar!joel%beowulf@sdcsvax.ucsd.edu
Subject: Mac II video
With the Apple RGB monitor delayed indefinitely, the preferred
monitor is the Sony Multiscan, model CPD 1302. It's available
from discount dealers for less than $600, and most of the color
monitors you'll see at Macworld will probably be this one.
Its color fidelity and resolution seems as good as the Apple prototypes.
The only problem I've heard reported so far (from 4 sites I know using it)
is inadequate shielding against hard disk RF during disk seeks, which
can sometimes be cured by moving the monitor or disk.
Other alternatives include SuperMac's new 19" 800x1000 Sony monitor,
which has a comparable quality; or their earlier big screen monitor,
which is not as good as the Apple or the SuperMac Sony.
I'm personally using a NEC Multisync JC-1401P3A, which has a poorer
resolution and lousy hues, but was available on rental cheap while
I wait for my Apple monitor. This is how I hooked it up:
SETTINGS: Analog/TTL: Analog
CABLE
NEC DE9 Description Apple video card ("DB-15")
1 Red 2 Red
2 Green 5 Green
3 Blue 9 Blue
4 Composite Sync 3 CSync
5 V. Sync N/C or 1 Ground
6,7,8,9 Ground 1 Ground
There's nothing magic about the cable; if you have an analog RGB monitor
all you have to do is read the manual to find the pins for the R,G,B and
ground lines (the sync may be optional; I haven't tried it without it...)
Hope this helps.
Joel West ihnp4!gould9!palomar!joel
Palomar Software, Inc. joel%palomar.UUCP@beowulf.ucsd.edu
P.O. Box 2635, Vista, CA 92083 joel@palomar.cts.com
------------------------------
Date: Thu, 23 Jul 87 10:33 EST
From: "RCSDY::YOUNG%gmr.com"@RELAY.CS.NET
Subject: Mac II and color monitors
At the present time, the Apple [Sony] Color Monitor for the Mac II is
not yet available. Since the Mac II generates 66.7 Hz vertical, most
monitors won't work. The 35 KHz horizontal is also fast but many
existing color monitors do accept that rate. I tried a host of very
expensive and high quality color monitors without success...they all liked
to lock at 60 Hz and would not sync to the Mac II despite their willingness
to accept 50 MHz input in analog form.
I have now discovered the NEC MultiSync monitors work fine with the Mac II.
I am using the model JC-1401P3A which is spec'd to work from 56-62 Hz
vertical. However, it works just fine at the 66.7 Hz rate anyway. Note
that this model is NOT one of the new [and more expensive] MultiSync
monitors. It the kind commonly being used for IBM PC/ATs.
I believe any of the MultiSnyc monitors will work with the Mac II. At the
present, connectors are a problem because Mac II is different from the NEC
which is different from Sony which is different from... I found a good
source for oddball connectors (Cables To Go, 1-800-826-7904)
Connectors:
Mac II (DB-15)
------------------------------ 4:G 5: ground
\ 1 2 3 4 5 6 7 8 / 7:R 8: ground
\ 9 10 11 12 13 14 15 / 15:B 13: ground
-------------------------- (note: Green carries composite Sync)
NEC MultiSync (DB-9)
---------------- 1:R, 2:G, 3:B
\ 1 2 3 4 5 / 4,5: not used
\ 6 7 8 9 / 6,7,8,9 ground
------------
Steve Holland
GM Research Labs
[holland%gmr.com@csnet-relay.csnet]
------------------------------
Date: Tue, 21 Jul 87 16:28:42 CDT
From: Paul Fons <FONS%UIUCVMD.BITNET@forsythe.stanford.edu>
Subject: Mac II Hard Drives
Hi, I had a question for this group. I just bought a Mac II at the
University of Illinois and am wanting now to get a hard drive. I didn't
buy the apple drive as it is rather expensive I thought (and I have to
add 6.5% sales tax to it besides here in Illinois). I wanted to ask for
any recommedations for cheap 20-30 MB hard drives (internal or external SCSI)
that would be appropriate for the Mac II. Please feel free to mail notes
to me at the address above directly. I am contemplating a Warp-9 20 MB
hard drive at the moment, but only because it was just about the cheapest
thing I can find (my wife is putting her foot down about how much more money
I can spend on my Mac!). Thanks in advance.
------------------------------
Date: Fri, 24 Jul 87 12:56:24 EDT
From: Steve Buyske <ST401266%BROWNVM.BITNET@forsythe.stanford.edu>
Subject: Comparisons of Mac II internal HD with externals?
Does anyone know of a comparison of the Mac II internal drive with
various external drives hooked up to the Mac II? I'm particularly interested
in the Jasmine 40meg drive, which costs about the same as the Apple
40meg internal with educational discounts.
Steve Buyske
ST401266 at BROWNVM.BITNET
------------------------------
Date: 20 July 1987, 13:05:41 PST
From: David M. Gelphman 415-854-3300 x2538 DAVEG at
From: SLACVM
Subject: Re: DataFrame 40 XP vs internal Mac II hard drive
InfoWorld did some timing tests and determined that (for their tests
at least) the Apple Mac II internal 40 MB drive was even FASTER than the
DataFrame 40 XP. I'm not clear how valid this test is because disk i/o
is processor bound on the Mac and I suspect their numbers for the XP are
on a standard Mac, not the Mac II.
I've been using an XP 40 on my Mac II and it is VERY fast. I've also
seen an internal 40 MB drive from Apple that appeared to be a bit faster.
As usual, you really need to set the disks up with the same contents and
fragmentation to see for real. I'll try to give a summary when Apple finally
delivers my internal 40 MB drive.
David Gelphman daveg%slacvm.bitnet@forsythe.stanford.edu
------------------------------
Date: Wed, 22 Jul 87 12:34:20 EDT
From: <meltsner@athena.MIT.EDU>
Subject: Screeching drives
We had the same problem, except since the room was climate-controlled,
it was a constant headache. When we called MD Ideas, the technician
said, "Oh, I can just shoot some WD40 on it." We shipped it back, and
got a brand new drive, luckily.
The origin of the noise is friction and chatter between a pad on the
underside of the antistatic arm and the end of the drive spindle.
We've found on our our Vaxstations that the arm can indeed have a bit
of WD40 dripped on the contact pad and spindle end and the noise goes
away. We also tried 3-in-1, but that only worked for about 3 weeks.
DON'T SPRAY into your drive -- we sprayed the WD40 onto a swab so that
we could control where it went.
Personally, I figure since manufacturers aren't making many drives with
the antistatic arm anymore, it may not be necessary, but I'd rather use some
WD40 every couple of months than rip up an otherwise perfectly good drive.
Disclaimer: Any of the above techniques are dangerous to you or your
drive, and don't blaim me or MIT if something goes wrong!
Ken
------------------------------
End of INFO-MAC Digest
**********************