shulman@topaz.RUTGERS.EDU (Jeff Shulman) (03/23/86)
Delphi Mac Digest Sunday, 23 Mar 1986 Volume 2 : Issue 11
Today's Topics:
Administrativia - Replying to digest messages
RE: Magic location in mac+ selects boot sequence
Re: bitmap form of MacPaint & cleaning the desktop &
Gutfreund (graphic representations)
Re: How to clean up an HD20 desktop
Re: sending a Break on Mac+
Re: Macintosh Hard Drives
Re: SCSI disk drives
Re: baud rate discussion & internal Mac hard disks
HARDWARE
Re: Record Holder
L.W. crashes Mac
Re: Servant and Andy's idea for opening a document
Re: InfoMac posting & MacTerminal question
Hard Disk Benchmark
RE: Hard Disk Benchmark (Re: Msg 6686)
RE: Hard Disk Benchmark (Re: Msg 6700)
Re: PackIt II/Switcher 4.6 bug
Mac+ and 3rd party ext. drives
Re: 128K ROM versions
Re: MAC SCSI drivers
External RAM drives
Re: Abaton scanner
Re: Servant addendum
Re: How do the 800K drives write to the disk?
Re: Mac/Mac+/3rd party upgrade strategies
----------------------------------------------------------------------
From: Jeff Shulman, moderator
Subject: Administrativia - Replying to digest messages
Date: 22 Mar 86 21:25:00 EST
If you wish to reply to messages in this digest you should send your
reply to INFO-MAC@SUMEX if you get this on the Arpanet *OR*
net.micro.mac if you get this on Usenet. DO NOT SEND TO BOTH. If you
mail it to me it gets included in the next Usenet Mac Digest which
Usenetter's do not get, thus miss out on your reply.
------------------------------
From: BRECHER (6600)
Subject: RE: Magic location in mac+ selects boot sequence
Date: 16-MAR 21:20 MUGS Online
In the copy of parameter RAM in the system global area, bit 4 set in
the SPMisc2 field ($20B) will cause the internal floppy drive to be
skipped in the first pass through the drive queue during the boot
sequence.
When you moved the System file to the root directory, there was no
longer a "blessed" folder -- but the starting default directory is the
root directory, so the system file was found, and hence the volume was
considered bootable past the point of no return. But the Finder was
not in the "system directory" (there was no such directory) so Launch
failed with a Segment Loader Error (ID=26).
If you had moved the System file to another folder instead of to the root
directory, and left Finder in its original folder, your scheme would have
worked.
The drive queue elements for floppies and/or the HD-20 are created at
boot time; if the drive isn't there (on) at that time, there is no way
to introduce it later -- except by writing custom software to add the
appropriate element to the drive queue.
------------------------------
From: PEABO (6651)
Subject: Re: bitmap form of MacPaint & cleaning the desktop &
Subject: Gutfreund (graphic representations)
Date: 20-MAR 00:04 MUGS Online
Re: bitmap form of MacPaint ...
That is easy ... a MacPaint document consists of one 512 byte header
block which you can ignore, and then a run-length encoded bit map of
720 lines, each 576 pixels wide. There are toolbox routines to decode
(and encode) a scanline and they are called UnpackBits and PackBits.
For making bit image files of the MacDraw and MacWrite documents, you
will probably need to write a sort of printing application. The print
manager images the document in horizontal bands in memory, and then
writes to a printer according to the specific printer graphics
commands needed. If you don't want to go to the trouble of doing
that, then you should probably capture the bit stream coming out of
the printer port as if you were an Imagewriter, and decode the escape
sequences. It takes two Macs to do this (or one Mac and another
machine of some sort). One clinker is flow control. You will have to
accept the data at burst rates of 9600 bps or respond with XON/XOFF or
control lead flow control signals.
Re: cleaning the desktop
Jeff -- the Purgeicons program we have here in the database was souped up by
Steve Brecher to include a dialog box to choose which volume was to be cleaned.
Bill Pugh's orginal just cleaned the Startup Volume. It is possible that
Brecher's souped-up version would work better under HFS than the original.
[ This program has been be posted - Jeff ]
Re: Gutfreund (graphic representations)
The proceedings of SIGGRAPH '83 (?? not sure which year) contain a
very interesting talk about cartography which goes into some detail
about how cartographers choose the appropriate level of detail for
maps at various scales. I recall also an article by Frank Crow (Ohio
State University) about rendering objects whose structure contained
components of widely differing sizes ... the objective being to avoid
doing hidden surface rendering of an object which would be of
sub-pixel size in the current view of the scene (for example).
------------------------------
From: BRECHER (6658)
Subject: Re: How to clean up an HD20 desktop
Date: 20-MAR 05:28 MUGS Online
There are multiple versions of PurgeIcons floating around. The one I
hacked to provide a dialog box allowing you to select the volume to be
purged seems to work OK for me on an HFS volume (128K ROM, System
3.1.1). However, in order for the "Purge" button to be enabled, the
program must be run from the root directory, since the dialog box is
really an SFGetFile box with the file list hidden, and SFGetFile/HFS
starts with the default (application) directory.
------------------------------
From: BRECHER (6659)
Subject: Re: sending a Break on Mac+
Date: 20-MAR 05:28 MUGS Online
The signal used to tell an application that a break is to be sent is
entirely application-dependent; hence there is no way to send a break
with Versaterm and the Mac+ keyboard, except to patch the application
to change the keycode that is associated with the Enter key. On the
old keyboard the keycode is 52 decimal; assuming that the keypad on
the Mac Plus keyboard sends the same keycodes as the original numeric
pad hardware option, Enter's new keycode is 76. (I can't be of any
help with regard to VersaTerm specifically.)
------------------------------
From: BRECHER (6660)
Subject: Re: Macintosh Hard Drives
Date: 20-MAR 05:29 MUGS Online
External drives connected through the floppy port (HD20) or serial
port ( MacBottom) will be considerably slower than internal drives or
properly-driven external SCSI drives. If speed is a criterion, forget
Warp 9; it uses basically the highly inefficient MacSCSI driver
software (it also requires a boot floppy). For speed among
currently-available internal drives, consider HyperDrive or
MicahDrive. Informal tests reported to but not verified by me
indicate MicahDrive to be somewhat faster. The MicahDrive uses 1:1
sector interleave (i.e., no interleave); I believe that current
HyperDrives use 2:1.
Claimer: I wrote the MicahDrive ROM/driver/manager.
------------------------------
From: BRECHER (6661)
Subject: Re: SCSI disk drives
Date: 20-MAR 05:29 MUGS Online
The following are the external SCSI hard disks I've seen advertised:
AST Colossus (70MB, with tape backup)
Iomega, Bernoulli Boxes, 10MB -- 40MB, removeable media
MDIDeas, 20MB
LoDown, 20MB
SuperMac DataFrame, 20MB
I haven't seen any Mac SCSI floppy disks (technically, the Bernoulli Boxes use
floppy media; but they perform like hard disks).
SCSI is an interface to the disk controller (more generally, it's a
bus specification, and the disk controller attaches to the bus).
Typically a drive manufacturer (taking your phrase literally) sells
only drives, not controllers, to OEMs who put together disk
subsystems. Some drive manufacturers, however, are starting to offer
drives with integral SCSI controllers. To such a combo the OEM must
add a power supply, box, cables, and software. For a disk with a SCSI
controller to be useable on the Mac it must have the proper cable to
connect to the Mac's SCSI port, and it must have a Mac device driver.
For it to be directly bootable, the driver and certain other code and
descriptive information must be written on the disk in the format
expected by the 128K ROMs.
------------------------------
From: PEABO (6653)
Subject: Re: baud rate discussion & internal Mac hard disks
Date: 20-MAR 00:13 MUGS Online
Re: baud rate discussion ... with some careful programming using
DrawString instead of DrawChar, it is possible to run a terminal
program at about 4800 bps, I think. The point of the slowness of the
Mac is that when you compare a Mac program against a VT-100 at the
next desk, the Mac seems sluggish. Either one will pause from time to
time during use of a full screen editor due to timesharing service of
other users, but the VT-100 is pretty crisp at 9600. And even more so
at 19.2kbps.
Re: internal Mac hard disks ... Hyperdrive vss. Warp 9 ... don't forget the
MicahDrive AT when doing your shopping.
peter
------------------------------
From: FREDDYO (6644)
Subject: HARDWARE
Date: 19-MAR 20:26 Hardware & Peripherals
Anybody got any ideas on what neat usage (Be nice now!) that I might make of a
Diablo 1650 previously configured as a terminal for a Big Blue? With all those
circuits, etc. I would hate to have it's usage limited to being a VERY heavy
letter quality
printer.
------------------------------
From: RICFORD (6645)
Subject: Re: Record Holder
Date: 19-MAR 21:54 MUGS Online
In reply to John Major's question about Record Holder, we did a mini-review of
it in the February issue of "MacInTouch," concluding that it was surprisingly
good for the price and well suited to many smaller data management tasks.
Ric Ford
------------------------------
From: RICFORD (6646)
Subject: L.W. crashes Mac
Date: 19-MAR 22:01 Bugs & Features
Anyone else having this problem? When the Mac is running, idle, and I
turn on the LaserWriter, the Mac crashes with ID=02. The System is
3.1, the Finder 5.2, and the 4.0/4.1 AppleTalk installer indicates
that I'm up-to-date there.
Ric Ford
------------------------------
From: PEABO (6670)
Subject: Re: Servant and Andy's idea for opening a document
Date: 20-MAR 23:38 MUGS Online
I hope he doesn't abandon the double-click method! It was pointed out at the
BCS MacTechGrp meeting yesterday that it would be a serious hassle to have to
open up the folder containing the application just to drag a document icon on
top of the application to run it.
peter
------------------------------
From: PEABO (6671)
Subject: Re: InfoMac posting & MacTerminal question
Date: 20-MAR 23:51 MUGS Online
Re: InfoMac posting ...
The December 85 Software Supplement (shipped in March 86) contains MDS Edit 2.0
which runs under HFS, and also contains instructions on how to patch the other
MDS programs.
Re: MacTerminal question
I have always assumed that the CNFG resource contains the various
settings which are remembered from session to session, and that the
Prec resource had something to do with printing. The LPtr resource
gets large in proportion to the size of the text saved off top, and
apparently contains pointers to the beginnings of lines in the text.
I don't have any idea what DStt is.
peter
------------------------------
From: BRECHER (6675)
Subject: Hard Disk Benchmark
Date: 21-MAR 05:48 Hardware & Peripherals
I wrote a simple disk performance benchmark program and have submitted it along
with its MDS assembler source code to the Hardware database.
The test is designed to measure hardware and disk driver performance, with no
influence from the file system (HFS/MFS) or volume/file/Finder configuration.
The program issues I/O requests directly to the disk driver.
The benchmark consists of three parts:
(1) 100 reads of 32KB of data from the start of the volume;
(2) 100 writes of 32KB of data to the start of the volume;
--the above two tests measure data transfer speed; 32KB was chosen to
be a reasonably large chunk, but not so large that it would cross a
cylinder boundary (thus not requiring any head movement).
(3) 40 iterations of: read one 512-byte block from an offset of 1MB, followed
by read of one 512-byte block from start of volume;
--the above test measures access time, i.e., seek or head movement speed.
The test is non-destructive -- test (2) writes the data that was read
in test ( 1). Test (3) is bypassed if the volume size is less than
1MB+512bytes. The volume tested is that from which the program is
run.
So far, the program has been run on three drives, with the following
results ( times are in ticks, i.e., sixtieths of a second):
Data transfer time Access Time
------------------
Reads Writes
DataFrame 20 1344 2233 487
HyperDrive, (see note) 1586 1600 563
MicahDrive 20 AT 507 508 528
Note: HyperDrive is original 10MB unit with old controller and version 5.1
software; current models are said to be faster.
I encourage those with access to other hard disks to report results with this
benchmark. On a Mac Plus, make sure disk caching is disabled in the Control
Panel.
[ This program has been be posted - Jeff ]
------------------------------
From: BRECHER (6700)
Subject: RE: Hard Disk Benchmark (Re: Msg 6686)
Date: 22-MAR 03:43 Hardware & Peripherals
You're right; the benchmark is *designed* to be non-destructive, but
it is potentially destructive if things go wrong (as they did for one
ICONtact member who had his HyperDrive Startup drawer trashed). BTW,
the HyperDrive reported on in the initial results I posted was my own.
I doubt that the DataFrame is doing a read-after-write. If it were, I
think the write time would be more than twice as long as the read time
(2x plus rotational latency). MicahDrive and DataFrame use the same
controller; I also had a "slow-write" problem during a stage of
MicahDrive development...
The MicahDrive driver does not do a verify on a write request. It does do a
verify (not a byte-by-byte comparison, but a read with ECC verification) if the
verify bit is set in the _Read trap word. This is a standard Mac disk driver
facility, documented in the Disk Driver chapter of IM.
------------------------------
From: NANOCHIP (6701)
Subject: RE: Hard Disk Benchmark (Re: Msg 6700)
Date: 22-MAR 04:01 Hardware & Peripherals
Steve>
DiskBench benchmark times for Tecmar MacDrive (10Meg Fixed).
Data transfer time Access Time
------------------
Reads Writes
Tecmar MacDrive (10M Fixed) 6017 6719 401
MicahDrive 20 AT 507 508 528
Performed on a Mac+ (System 3.1.1) with DiskCaching disabled.
I couldn't *believe* the difference... performed the benchmark a _number_
of times...just to be sure. The numbers speak for themselves :-) . Wow.
<Chip
------------------------------
From: CHESLEY (6690)
Subject: Re: PackIt II/Switcher 4.6 bug
Date: 21-MAR 22:21 MUGS Online
Geeez, that's weird! The reason it's weird is that while PackIt is
unpacking a file, it doesn't call GetNextEvent(). So the event should
stay queued until it finishes unpacking. I'll look into it further and
see what I can find.
Note: The bold file name means that the file was unpacked (as opposed to being
skipped). Skipped files are in normal face. That way you can remember which
files you unpacked and which ones you didn't.
P.S. Thanks for reporting the bug. I am, of course, always interested
in new bug reports, and will do my darndest (this is a family net,
right?) to fix them in PackIt III. Bugs can also be reported to my
BBS: 415-563-2491.
------------------------------
From: CVARGAS (6689)
Subject: Mac+ and 3rd party ext. drives
Date: 21-MAR 22:12 Hardware & Peripherals
There's been some messages in the Info-Mac digests about how the Haba and the
Mirror DS 800K floppy drives shouldn't work with Mac Plus. Well, maybe they're
not supposed to, but they do. Our user group sells the Haba drive, and we've
hooked it up to a number of Pluses and they've worked quickly and without any
problems (if not quite noisily). We've also hooked up our VP's Mirror drive to
our Pres's upgraded Mac w/new ROM, and it works great as well. This is not to
say they work under all configurations (like through a HD20, which we haven't
tried with the Mirror (Haba works, though)), but in all the ones we've tried
they've worked.
------------------------------
From: BRECHER (6698)
Subject: Re: 128K ROM versions
Date: 22-MAR 03:43 MUGS Online
Since you mentioned speculation about 128K ROM changes, here's the full story:
Three versions of the 128K (EP)ROMs have been delivered. They are, in
chronological order:
"Lonely Hearts" -- third byte of checksum (located at $400002) = $EE
"Lonely Hearse" -- = $F4
"Lonely Heifer" -- = $EA
As indicated by the monikers, only the "high" ROM has been changed. The net
change from Hearts to Heifer is two bytes (plus a checksum byte). Both changes
relate to SCSI bugs at boot time, which cannot be fixed by RAM patches.
According to an extremely reliable source at Apple, there will be no further
changes to the ROMs, except, of course, for future Macintoshes (future meaning
1987 at the earliest, rumors about a summer/fall 1986 new Mac notwithstanding).
------------------------------
From: BRECHER (6699)
Subject: Re: MAC SCSI drivers
Date: 22-MAR 03:43 MUGS Online
Apple provides a generic (example, skeleton) disk driver and driver
installation routine to disk subsystem vendors.
"Querying the drive size" may be simple to next-to-impossible, depending on the
controller in use. The SCSI command which returns such information is not
mandatory in the SCSI standard.
Cluster-size specification is a function of the standard Disk Initialization
Package (Pack 2), not of the disk-specific software.
------------------------------
From: ASMCOR (6694)
Subject: External RAM drives
Date: 22-MAR 02:20 Hardware & Peripherals
Everyone -
I am in the midst of writing a comparative review of the DASCH and the
QUICKDRIVE, both external RAM disks. The full review will be in the
MacInTouch newsletter, but here's a little advice based on what I've
seen so far. The DASCH is full of annoying little bugs - the
hardwareY./ seems just fine, but the software is less than perfect.
For example, it cannot work with the new Imagewriter driver, you HAVE
to use a special hacked-up version of the old Imagewriter driver,
which is much slower than the new driver, and has that horrible bug
when used with the Imagewriter // which crushes the top line of every
page. Item number 2, the system will hang completely if you have
inadvertently switched to another disk and made it the startup disk,
and then try to print. So if you run MACWRITE from a disk that has a
system and finder n you try to print something, it hangs. The
Quickdrive, on the other hand, has performed flawlessly, under MFS and
HFS, and even with the Mac+. No problems have surfaced thus far. And
it's cheaper. Look for the full review with benchmarks and all the
details in an upcoming issue of MacInTouch Jan
------------------------------
From: RICFORD (6712)
Subject: Re: Abaton scanner
Date: 22-MAR 13:12 MUGS Online
In response to Werner Uhrig's posting about the Abaton scanner, I
think it's important to note that Abaton is just a distributor, which
has focussed on carnival-style exhibits at MacWorld shows, and that
the device itself is manufactured by Microtek Labs, 17721 S. Western
Ave., Gardena, CA 90247 213-538- 5369. Probably the best software for
it is being done (slowly) by Bill Bates of Knowledge Engineering (he
also wrote JustText), GPO Box 2139, New York, NY 10116.
Ric Ford "MacInTouch" newsletter
------------------------------
From: PEABO (6718)
Subject: Re: Servant addendum
Date: 22-MAR 15:54 MUGS Online
There is some mention about the problem of launching an application
from within one or more nested folders, and having those folders
appear on the desktop after the application quits (this slows down the
Finder as well as cluttering the desktop). There is a way to avoid
that. If you hold down the option key while opening a folder, the
Finder will not remember that it is open when it launches the
application, and therefore will not try to open it again after the
application quits. Very handy. (However, I usually use WayStation to
start applications these days, so I don't often have to bother with
this trick.)
peter
------------------------------
From: BRECHER (6722)
Subject: Re: How do the 800K drives write to the disk?
Date: 22-MAR 17:25 MUGS Online
800K drives are written by cylinder (flip sides after each track).
------------------------------
From: BRECHER (6723)
Subject: Re: Mac/Mac+/3rd party upgrade strategies
Date: 22-MAR 17:25 MUGS Online
Some vendors are offering SCSI add-ins for the 512K, including Levco (I think)
and SuperMac. The latter, will, if you buy one of their DataFrame hard disks,
throw in a SCSI port add-in for $99 ($299 without the drive). It brings the
connector out through the battery compartment.
The advantage of SCSI is speed -- data transfer should be at least 2.5x as fast
as a serial-port drive.
------------------------------
End of Delphi Mac Digest
************************ir462@sdcc6.UUCP (ir462) (03/28/86)
> Subject: Hard Disk Benchmark > Date: 21-MAR 05:48 Hardware & Peripherals > > [summary of benchmark procedure > > [some test results...] > > I encourage those with access to other hard disks to report results with this > benchmark. As a Mac Plus owner I find these results surprising since I have noticed considerably superior performance of my machine to that to non-plus Macs I have used. In particular, I have found the disk cache to be quite useful when running large applications (e.g. Excel, MacDraw) which normally do a fair amount of segment swapping. I suspect that the structure of the disk cache is such that it does not help much with the type of disk access that this benchmark performs. Note: I am aware that the primary intention was to test hard disks, but the results caught my eye. Ethan Munson UCSD CS undergraduate sdcsvax!sdcc6!ir462
kearns@garfield.columbia.edu (Steve Kearns) (03/31/86)
> > Subject: Hard Disk Benchmark > > Date: 21-MAR 05:48 Hardware & Peripherals > > > > [summary of benchmark procedure > As a Mac Plus owner I find these results surprising since I have noticed > considerably superior performance of my machine to that to non-plus Macs > I have used. In particular, I have found the disk cache to be quite > useful when running large applications (e.g. Excel, MacDraw) which > normally do a fair amount of segment swapping. I suspect that the > structure of the disk cache is such that it does not help much with the > type of disk access that this benchmark performs. > Disk caches work by remembering blocks of memory that have been previously read in so that if they are referenced again they can be fetched from ram instead of the disk. Thus, unless the application (or benchmark) references the same data within a reasonable amount of time, the disk cache won't help. This might explain why the benchmark didn't show a performance increase. Note that a disk cache is like a ram disk that is loaded "as you go along" based on what you loaded so far. (For a more comprehensive discussion of disk caches see any good operating systems book under the topic of "page replacement strategies". ) -steve