[net.micro.mac] Delphi Mac Digest V2 #13

shulman@topaz.RUTGERS.EDU (Jeff Shulman) (04/06/86)

Delphi Mac Digest          Sunday, 6 Apr 1986      Volume 2 : Issue 13

Today's Topics:
     RE: Usenet Mac Digest V2 #17 (Re: Msg 6876)
     MDS Edit 2.0 and hard disks
     DiskBench results
     Polaroid disks
     Benchmarks
     Whither Club Mac ? ? ?
     Picture needed!!!
     RE: Whither Club Mac ? ? ? (Re: Msg 7093)
     RE: Usenet Mac Digest V2 #18 (Re: Msg 7099)
     RE: Whither Club Mac ? ? ? (Re: Msg 7093)
     Re: MacWorkstation & Mac+ thoughts/comment
     Re:  WORD -> MacWrite
     Re:  WORD -> MacWrite
     Re:  WORD -> MacWrite
     Re: Text Diff bug?
     RE: Challenge (Re: Msg 7089)
     RE: Challenge (Re: Msg 7089)
----------------------------------------------------------------------

From: PEABO (6925)
Subject: RE: Usenet Mac Digest V2 #17 (Re: Msg 6876)
Date: 30-MAR 19:52 MUGS Online
 
re:  MacDraw non-feature ...
 
The problem is worse than just the mixing of font names and sizes in
one menu.  MacDraw records the font in use by its position in the
menu, not its font number and you cannot switch systems (to one with a
different collection of fonts) and still have your document display
properly.  It makes no sense, but that's the way it "works".
 
Re:  printer drivers and PostScript
 
Apple does produce real PostScript.  What you may be thinking of is
the LaserWriter prep file which customizes the PostScript that comes
in ROM by adding new words to its vocabulary.  These new words perform
commonly needed functions required by the translation from QuickDraw
to PostSCript.  Without the LaserWriter pre file, you cannot process a
PostScript file produced by the Apple LW drivers.
 
Re:  Mac+/HFS compatibility ...
 
The compatibility issue is just all the more reason for application developers
to adhere to the published interface recommendations in programming their
applications.  Apple iterates that applications MUST check the ROM revision
before using new features, but nothing is said about what to do if the old ROM
is in use.  (A dialog box that says "Upgrade your Mac logic board ... OK"
perhaps?)  Presumably a developer could have a code segment that performs the
function that would otherwise be done by the ROM, but where would the incentive
be to do that?
 
Re: Damn Dealres! (About upgrades really) ...
 
The dealer is supposed to accept a third-party upgraded board for
logic board upgrade, but charge for it as if it were a 128K board.  I
don't recall hearing anything about a policy for ROM upgrades of 128K
machines, but I don't see why a dealer should be concerned about the
presence of a reputable third party upgrade as long as it doesn't
interfere mechanically with the new ROMs (unlikely) or the mounting of
the 800K disk drive (less unlikely, but still a remote possibility).
There is a $200 difference in the logic board upgrade price for 128K
vs. 512K boards.  Note, the heap is smaller when using a 512K 128K ROM
than it is for a 64K ROM.  If the same logic is used for 128K, the
heap might be unacceptably small, leading to problems.
 
peter

------------------------------

From: PEABO (6933)
Subject: MDS Edit 2.0 and hard disks
Date: 30-MAR 20:21 Programming
 
MDS Edit 2.0 has an additional fix.  It no longer updates the Modification date
of a file if you close the file without making changes.  I noticed this because
my MAKE procedures no longer recompile things that I merely looked at.
 
peter

------------------------------

From: BRECHER (7032)
Subject: DiskBench results
Date: 3-APR-05:30: Hardware & Peripherals
 
The DiskBench application does low-level performance testing on hard disks,
providing some indication of the relative speed of the disk hardware and driver
software combination among competing products.
 
Multiple reports on the same kind of disk from multiple testers are
welcome, so that anomalies can eliminated.  Anomalies might include
media defects in the test area requiring controller retries, data
correction, or revectoring to an alternate area.  Results on only one
specimen should be regarded as provisional.
 
 
Moving the mouse during the test will degrade the results!
 
64K ROM/Sony floppy note:  the Sony driver disables interrupts for relatively
long periods (more than 1/60th second) during reads of the size requested by
DiskBench, and thus interferes with the timing mechanism used by DiskBench (the
system variable "Ticks") so that the reported time is much less than the actual
time. Hence the data transfer (read) times for some 400K floppies are omitted
("N/A") below.  Since the Access Time test requires more than 1MB, DiskBench
does not perform it on any floppies.
 
HyperDrive note: Run DiskBench from the Startup drawer.  For the
access time to be valid, Startup must be more than 1MB in size, and it
must be unfragmented -- it must have reached 1MB+ in size (possibly
via restore to a newly-initialized HyperDrive) before any other
drawers were created.  Do not run DiskBench with the HyperDrive cache
turned on.
 
Current collection of results from the DiskBench program:
 
                               Data transfer  Access   Tester
                              ---- time ----   time
                              Reads   Writes
 
 400K floppy drive, Apple      8756    11816    N/A    S. Brecher
 400K floppy drive, Apple      N/A     12392    N/A    G. Frascadore
 400K floppy drive, Apple      8796    11629    N/A    C. Nicolais
 400K floppy drive, Apple      N/A     12351    N/A    R. Perez
 800K floppy drive, SS, Apple  8758    11407    N/A    S. Brecher
 800K floppy drive, SS, Apple  7544    11550    N/A    C. Nicolais
 800K floppy drive, DS, Apple  7701    10874    N/A    S. Brecher
 800K floppy drive, DS, Apple  7523    10913    N/A    N. Fong
 800K floppy drive, DS, Apple  7737    10897    N/A    C. Nicolais
 AST 4000, AST Research        1495     1533    159    KATZ, Mousehole BBS
 AST 4000, AST Research        1495     1549    160    KATZ (second drive)
 AST 4000, AST Research        1495     1537    169    KATZ (third drive)
 Bernoulli Box, 5MB, Iomega    4174    24437     66    JCOM, Mousehole BBS
 DataFrame 20, SuperMac        1319     2233    488    J. Bean
 DataFrame 20, SuperMac        1344     2233    487    S. Brecher
 DataFrame 20, SuperMac        1319     2233    446    L. Custer
 Hard Disk 20, Apple           7029     7938    368    M. Chally
 Hard Disk 20, Apple           7074     7871    368    N. Fong
 Hard Disk 20, Apple           7054     7944    370    KATZ, Mousehole BBS
 Hard Disk 20, Apple           9883(?)  6948    368    R. Wiggins
 HyperDrive 10, obsolete model 1591     1616    401    S. Brecher
 HyperDrive 10, GCC (V2R1)     8000(?)  7982(?) 648(?) H. Conover
 HyperDrive 10, GCC (V2R1)     7985(?)  6892(?) 485    R. Perez
 HyperDrive 20, GCC (V2R1)     1703     1506    640(?) R. Ford
 HyperDrive 20, GCC            1704     1506    241(?) W. Luckie
 MacBottom 10, v2.1, PCPC      4159     6897    686    M. O'Connor
 MacBottom 10, v2.6, PCPC      4159     6897    608    S. Aronian
 MacBottom 20, v2.1, PCPC      4110     6817    601    L. Becker
 MacDrive, Tecmar              6102     6704    440    L. Custer
 MacDrive, 10MB Fixed, Tecmar  6017     6719    401    C. Nicolais
 MicahDrive 20 AT, Micah        508      507    488    S. Brecher
 Quark QC-20                   6476     6488     82(?) R. Thacker
 QuickDrive external RAMdisk   2411     2479     52    R. Bates
 QuickDrive external RAMdisk   2466     2535     33    J. Eugenides
 RamStart RAMdisk/Beck-Tech RAM 186      186    N/A    G. Frascadore
 Warp 20, Warp Nine Engin'rng 14537    14537    321    G. Frascadore

------------------------------

From: RICFORD (7080)
Subject: Polaroid disks
Date: 4-APR-12:52: Hardware & Peripherals
 
I just talked with Mary Clark from Polaroid.  They're offering double-sided 3
1/2" disks, with a 20 year guarantee, and a 48-hour data recovery service for
the following prices.  I'd like to hear from anyone who's familiar with these
disks -- they're gray.
 
1-5 boxes: $43.00 6-10 boxes: $37.00 (each) 11+ boxes:  $33.00 (each)
 
Ric Ford
 
"MacInTouch"
 
(The phone number is 1-800-241-4403)
 
------------------------------

From: RICFORD (7081)
Subject: Benchmarks
Date: 4-APR-13:06: Hardware & Peripherals
 
We are currently testing the MicahDrive AT 20 (in a Mac 512/128K ROM).
I've uploaded a new MacInTouch benchmark file to the Hardware database
containing our initial test results.  To summarize, we are finding it
to be the fastest hard disk we've tested yet, but not twice as fast as
others.  The comparison is clouded by the unusual hardware
configuration.  The sample we have is also somewhat noisy.  Next on
the agenda is loading it up and using it in daily work situations.
We'll keep you posted.
 
Ric Ford
 
"MacInTouch" newsletter

------------------------------

From: FRANKPATRICK (7093)
Subject: Whither Club Mac ? ? ?
Date: 5-APR-10:19: MUGS Online
 
Has anybody got any insight as to what happened to CLub Mac? First their BBS
disappears. Then they stop offering logoed "golf shirts" (a sure sign of
potential demise if I ever saw one. Then their monthly stops at about February
or so. Then their Boulder, CO phone number is disconnected.
 
Are they gone for good?  And just after I resubscribed? FrankPatrick
 
------------------------------

From: FRANKPATRICK (7094)
Subject: Picture needed!!!
Date: 5-APR-10:46: Creative Pursuits
 
Please!!!
 
I NEED A DIGITIZED MACPAINT FILE SHOWING A MAC SYSTEM!!!
 
If just the Mac, fine; if it also shows a 400k drive, Apple mode, and
Imagewriter I, perfect.
 
Does anybody know of or have such a MacPainting or even a particularly well
hand-drawn either Paint or Draw?

------------------------------

From: DBRANDT (7097)
Subject: RE: Whither Club Mac ? ? ? (Re: Msg 7093)
Date: 5-APR-13:21: MUGS Online
 
Well, the BBS still seems to be there, but their Boulder phone # was
disconnected and the phone co. doesn't know of any new number. I tried
to send a message to BOZO/MAC asking him what happened, but have not
received a reply (I initially called Boulder to see if they had
installed a packet switching network, as they said it would be
available in 6 weeks for about 2 months.)  
David Brandt

------------------------------

From: PEABO (7106)
Subject: RE: Usenet Mac Digest V2 #18 (Re: Msg 7099)
Date: 5-APR-15:02: MUGS Online
 
Re:  Super/Subscripts and TextEdit
 
The TextEdit routines do not allow for any style, size, or typeface variations
with the text, but the original 100-day Inside Macintosh had documentation for
another edit package called CoreEdit.  If you can find the original IM you can
see if CoreEdit will really do what you want.  I think CoreEdit is available
from Apple Licensing for $50/product annual license fee.  Call the Apple
Licensing department at (408) 973-4667 for more info.
 
peter
 
------------------------------

From: RICKLEPAGE (7103)
Subject: RE: Whither Club Mac ? ? ? (Re: Msg 7093)
Date: 5-APR-14:27: MUGS Online
 
Club Mac has ceased operation, at least on the magazine/product level.
We talked with a couple people close to Wallace who told us that they
have no funds at all to even let their users know that it is no
longer.  We tried more than a few times to get in touch with Wallace,
but he wouldn't return our calls.  The BBS was up at least till early
last week.
 
Rick LE Page "MacInTouch"

------------------------------

From: PEABO (7114)
Subject: Re: MacWorkstation & Mac+ thoughts/comment
Date: 5-APR-15:31: MUGS Online
 
Re:  MacWorkstation
 
That is a licensed product from Apple.  Call (408) 973-4667 [I'm
getting good at this, didn't even have to look up the number this time
:-)] for more info.
 
Re:  Mac+ thoughts/comments
 
The function of setting the clock time and date was removed from the control
panel and put into the Alarm clock.  Just open the Alarm clock, flip down its
tab, and click on either the time or date.
 
peter
 
------------------------------

From: PEABO (7116)
Subject: Re:  WORD -> MacWrite
Date: 5-APR-15:37: MUGS Online
 
I hadn't heard that Microsoft WORD could be converted to MacWrite by stripping
the high-order bits (and I don't believe that it is true), BUT, that technique
works just fine for converting Micropro WordStar documents.  One thing though,
they will be text files with a CR at the end of every line.
 
peter
 
------------------------------

From: PDNNOG (7121)
Subject: Re:  WORD -> MacWrite
Date: 5-APR-18:24: MUGS Online
 
Actually, most of the word file is plain ole ASCII with the first 64 or so
characters in the file being a header and some in the end being a footer. There
is a note by someone in the infomac archives for more details. I tried just
writing from the beginning of the ascii part to a dummy file with FEDIT, then
change the type to text, the creater to MACA, and then MW 4.5 will convert the
file...no format tho.
 
------------------------------

From: PEABO (7122)
Subject: Re:  WORD -> MacWrite
Date: 5-APR-20:06: MUGS Online
 
Yeah, it would be a real feather in someone's cap to do a decent job of
converting WORD docs to MacWrite with the formatting intact.  There are lots of
things you would have to approximate, since WORD does so much more than MW.
 
One specific reason I'm interested in this is that most of the technical docs
coming out from Apple are in WORD format.  I've been posting them double (the
second copy in TEXT-only) but that's not exactly a satisfactory solution.
 
peter
 
------------------------------

From: PEABO (7117)
Subject: Re: Text Diff bug?
Date: 5-APR-15:43: MUGS Online
 
Jeff, please forward by the most appropriate means:
 
Date: Fri, 28 Mar 86 09:31 pst
From: "pugh jon%e.mfenet"@LLL-MFE.ARPA
Subject: Text Diff bug?
 
Jon, thanks for the bug report.  I'll find out what's going on.
 
peter
 
------------------------------

From: MCOHEN (7120)
Subject: RE: Challenge (Re: Msg 7089)
Date: 5-APR-16:43: Bugs & Features
 
Try copying the disk using Copy ]['s Block Copy or Mac Zap. Both will write out
a good sector (usually containing 00's) in place of the bad one.
- Mike

------------------------------

From: LOFTUSBECKER (7134)
Subject: RE: Challenge (Re: Msg 7089)
Date: 6-APR-09:26: Bugs & Features
 
Joe,
        I'm pretty sure that MacZap will let you initialize any sector. And
if you copy the disk (use CopyII Mac, Sector Copy) I suspect that FEdit will
rebuild the directory properly.
                - Lofty

------------------------------

End of Delphi Mac Digest
************************

kearns@garfield.columbia.edu (Steve Kearns) (04/07/86)

I have Macdraw version 1.9 which I heard was "debugged".  But my copy
does some strange things:  for example I sometimes have to do "new"
4 times before getting a window that has a page I can draw in.  (The other
times it is just grey where the page normally is).  Also "page size" is
mortally screwed:  sometimes there are huge pages , sometimes 144 pages, 
etc..   Is it my version?  Has anyone else had these problems.  ?
-steve
(kearns@columbia-20)

ephraim@wang.UUCP (pri=8 Ephraim Vishniac x76659 ms1459) (04/09/86)

> Delphi Mac Digest          Sunday, 6 Apr 1986      Volume 2 : Issue 13
> ----------------------------------------------------------------------
> From: BRECHER (7032)
> Subject: DiskBench results
>  
> The DiskBench application does low-level performance testing on hard disks,
> providing some indication of the relative speed of the disk hardware and
> driver software combination among competing products.

It disturbs me to see the diskbench results gathered and disseminsated with
such enthusiasm when their value is so questionable.  Thinking about how the
benchmark works, I have two *major* reservations about it:

	1.  The data transfer size of 32K is *grossly* unrealistic.  While
	launching and running programs, opening, saving, and closing 
	documents, a read or write of 32K is almost unheard of.  Copying
	files under the finder is the only common activity that does large
	reads or writes.  The performance of a disk with 32K transfers may
	have little to do with its performance on more typical small
	transfers.

	2.  Doing the reads or writes consecutively with no delay causes
	a bias that is consistent for a particular disk but varies 
	unpredictably from one disk to another.  Since all the operations
	start at the same sector (zero), the disk has to rotate to a
	fixed point to start data transfer.  This forces an overhead
	between consecutive tests.  In "real" operation this overhead
	is randomized, averaging half the rotation time of the disk.  In
	DiskBench, this overhead is consistent for a particular disk,
	depending on where the previous operation ended and the time to
	return from the driver to DiskBench and start the next operation.

So, a *realistic* disk benchmark would have to survey a variety of transfer
sizes and would have to "dither" the delay between tests to avoid bias.
Note that the rotational bias problem also affects the seek test, since it
seeks to a particular sector, and not to a particular track.  By 
varying the interleaving of my disk, I've varied the "seek" result of
DiskBench from 315 to 367!  Obviously, this test is not a very pure test
of seek overhead.

Ephraim Vishniac
decvax!wanginst!wang!ephraim