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

shulman@topaz.UUCP (04/27/86)

Delphi Mac Digest          Sunday, 27 Apr 1986      Volume 2 : Issue 16

Today's Topics:
     68000 Assembly Language Tools
     RE: 68000 Assembly Language Tools (Re: Msg 7402)
     RE: 68000 Assembly Language Tools (Re: Msg 7403)
     RE: 68000 Assembly Language Tools (Re: Msg 7402)
     RE: 68000 Assembly Language Tools (Re: Msg 7402)
     'HOT' Tip!!!
     Lightspeed C
     TWO hard disks on Mac+
     RE: Volumes 0.5 (Re: Msg 6735)
     Interleave/DiskBench
     Watch out for DataPak Software
     Where's Sierra Info. Systems?
     Re:  Hyperdrive Removal request
     RE: Open Mac rumors cont'd (Re: Msg 7570)
     MDS and Lightspeed C
     Dollars & $ense
     Is Mac Really Naked?
     MS Word HELP!!!!
----------------------------------------------------------------------

From: GBL (7402)
Subject: 68000 Assembly Language Tools
Date: 17-APR 23:02 Developer's Corner
 
I'm just finishing up a book on Mac assembly language. I thought I'd include an
appendix on "Invaluable Development Tools" or something like that. I'd like to
include references to the most useful commercial and shareware utilities like
Fedit, ConCode, etc.
 
I'd like to hear comments on what you feel are the best utilities for a 68000
programmer to have at hand.
 
Thank you.
 
------------------------------

From: PEABO (7403)
Subject: RE: 68000 Assembly Language Tools (Re: Msg 7402)
Date: 17-APR 23:40 Developer's Corner
 
MacsBug (from Apple) or TMON (from ICOM simulations, a commercial product) are
a necessity for debugging.
 
I'll also plug a public domain product of my own, TextDiff, which is
available in the Tools topic of the database here.  Over the years I
have come to depend of a good utility to compare successive versions
of source code for what changes took place, and that's what TextDiff
does.  Currently in beta test, but there will a another version out in
a little while with bug fixes and some nifty new features.
 
peter
 
------------------------------

From: RICFORD (7406)
Subject: RE: 68000 Assembly Language Tools (Re: Msg 7403)
Date: 18-APR 00:43 Developer's Corner
 
I assume you've already included ResEdit and other Apple utilities. Other... is
important for testing DA's, and I'd suggest a modem and Red Ryder as important
development tools...
 
Ric
 
------------------------------

From: LOFTUSBECKER (7407)
Subject: RE: 68000 Assembly Language Tools (Re: Msg 7402)
Date: 18-APR 07:43 Developer's Corner
 
        1. MDSMake (Shebanow).
        2. BaseTool (32-bit hex/decimal/octal/binary converter)
        3. TMON (debugger).
 
------------------------------

From: JIMH (7411)
Subject: RE: 68000 Assembly Language Tools (Re: Msg 7402)
Date: 18-APR 19:07 Developer's Corner
 
The best single tool for assembly language programming is TMON.  The best tool
to learn how to program in 68k ASM is MacNosy as theres no teacher like
examples.  jim
 
------------------------------

From: MACINTOUCH (7408)
Subject: 'HOT' Tip!!!
Date: 18-APR 17:02 Business Mac
 
I got a great piece of info today which confirms a previous rumor that I posted
here....
 
dBASE III+ will be out for the Macintosh in the last
quarter of this year.  My source at Ashton-Tate didn't
know whether the programs would be compatable between
the IBM and Mac but he assumed that the data would be.
 
Josh Wachs - MacInTouch

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

From: ASMCOR (7415)
Subject: Lightspeed C
Date: 19-APR 00:30 Programming
 
All: Been playing with LightSpeed C, here are my first impressions:
I have been working in Megamax for a good year now, and I've been quite happy
with it, but LightSpeed is really going to spoil me... it's very easy to work
in.  I have a little application than I am using as a test bed for the List
Manager routines, to get them all working right so I can use them. It took me a
couple of full evenings, I would guesstimate approximately 10 hours to get the
thing running in Megamax.  I wrote all the glue routines in assembly, and it
took about 6 of those hours.  Tonight, inside of three hours I was able to
convert the entire LIST application from Megamax to LightSpeed, and get it
running.  And that *includes* re-writing all the glue routines for Lightspeed,
which doesn't support inline assembly.  I used the little trick posted here
yesterday of declaring something like:
pascal  Boolean  Pack0() = 0xA9E7;
and using that to create the inline traps.  Works great.
 
The turnaround in Lightspeed is very fast, and the error messages are
much clearer than Megamax. It also only gives you one error message at
a time, so it's less confusing, and it's more accurate at flagging the
line where the error actually occurs.  Interestingly, the LIST
application was 8930 bytes in Megamax, and 9744 in Lightspeed.  About
10% larger, but that may be because it's linking in more than it has
to.  I think the difference would be less in a more fully-fleshed
application.  Still, it is significant.  Jan

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

From: JIMWEINRICH (7431)
Subject: TWO hard disks on Mac+
Date: 19-APR 14:34 Hardware & Peripherals
 
Is it possible to put TWO hard disks onto a Mac+ in the following config: One
SCSI disk on the SCSI port; one old-style Mac hard disk on the serial port? If
so, is it also possible to put the imagewriter onto the back of the old style
disk (assuming of course the proper disk)? Thanks guys!
 
------------------------------

From: MACLAIRD (7450)
Subject: RE: Volumes 0.5 (Re: Msg 6735)
Date: 20-APR 17:54 MUGS Online
 
As an addendum to my earlier Forum message about Volumes:
 
I reported a problem running MDS from a remote host over the AppleBus.
After applying patches to allow use of System 3.1.1, the applications
(Exec, Link, and PackSyms) began to work with Volumes 0.5 as well.
 
These patches are described in the introductory notes to the "December 1985
Software Supplement Additions".  See the heading "MDS (Macintosh 68000
Development System) Update"; it's on the first page.
 
One other difference was that I ran Volumes and MDS from a 5 megabyte
ProFile not shared with Lisa software.  I can't see how this should
make a difference.  Now, PackMacs.Txt has SFGetFile as an EQU.  Can
anyone explain how I can write a SFGetFile macro without completely
revising PackMacs.Txt?

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

From: BRECHER (7507)
Subject: Interleave/DiskBench
Date: 22-APR 10:19 MUGS Online
 
Which Interleave is best?
-------------------------
 
Recently John Bass pointed out that 1:1 interleaving is sometimes
disadvantageous due to the frequency of logically-contiguous
single-sector requests.  He estimated that interleaving of
approximately 6:1 would be optimal for handling such requests.  I
tested that estimate by modifying DiskBench to issue 64 single-sector
requests on increasing sector addresses, in place of each prior 32KB
request. I ran this "SSDiskBench", as well as the original DiskBench,
on a MicahDrive at various interleaves; results were as follows (read
and write results were in all cases identical or nearly so, so I show
here only the read results):
 
Interleave        SSDiskBench         DiskBench
   1:1              6801                 507
   2:1              7206                 812
   3:1              7511                1116
   4:1              7518                1523
   5:1              6513                1827
   6:1              2538                2233
   7:1              2538                2537
   8:1              2943                2943
 
These results clearly confirm Bass's "about 6:1" estimate for optimal
handling of consecutive single-sector requests.  However, Bass claimed
that this is also the best system interleave -- i.e., that assuming
that all requests are single-sector is appropriate.  This is not to
say that Bass claims that ALL requests actually are single-sector --
just that such requests are so relatively frequent that the best
interleave is one which accommodates them.
 
I gathered some statistics on the distribution of disk I/O requests by
writing a hook into _Read and _Write which records the size of each
request and the the sector (logical block) distance from the end of
the previous request to the start of the current request.  I invoked
this recorder, and then performed the following activities on a 512K
Mac, 128K ROMs, System 3.2b3, Finder 5.2, big TMON loaded, MicahDrive
HFS volume about 9MB full, starting in Finder with the disk directory
window open:
 
Open folder; double-click MacWrite document; change document, quit
with save; close folder; open folder; double-click MacPaint document;
change document; quit with save; duplicate (Finder copy) 22K document;
close folder; open folder; open MDS Asm; use SFGetFile to select
document (go up, down, down in directory hierarchy); assemble;
transfer directly to Consulair Link 1.5; Link; quit to Finder; close
folder; open folder; double-click Excel worksheet document; change
worksheet; quit with save; close folder.
 
Size of disk read/write requests, 512-byte sectors:
 
Number of sectors       Number of requests      Sectors transferred (%)
          1                     1785                    1785 (49%)
          2                       16                      32
          3                       16                      48
          4                        6                      24
          5                       23                     115
          6                        8                      48
          7                        3                      21
          8                       22                     176
          9                        4                      36
         10                        2                      20
         13                        1                      13
         14                        9                     126
         16                        1                      16
         17                        2                      34
         18                        2                      36
         23                        1                      23
         24                        1                      24
         25                        1                      25
         43                        1                      43
         44                        3                     152
         48                        1                      48
         49                        1                      49
         61                        1                      61
         63                        4                     252 ( 7%)
         70                        1                      70 ( 2%)
        374 (Excel PCOD resource)  1                     374 (10%)
                                ----                    ----
                                1916 total requests     3651 total sectors
 
Sector distance between chronologically consecutive requests (end of
request N-1 to start of request N; 0 means requests are physically
contiguous):
 
Sector distance          Number of requests
        0                       1060
        1                         20
        2                         13
        3                         14
        4                          5
        5                          8
negative or 6 or more            796
                                ----
                                1916 total requests
 
Clearly, consecutive single-sector requests predominate.  However,
this is not sufficient to establish the best interleave.  Consider:
for each consecutive single-sector request in a series, a 1:1 drive
takes about one disk revolution, and a 6:1 drive takes about one-third
of a revolution.  For a single 374-sector request, a 6:1 drive takes
about 124 revolutions; a 1:1 drive, about 21 revolutions.  Hence, in
terms of relative advantage, a single 374-sector request balances a
series of about 154 single-sector requests.  These calculations are
back-of-the envelope; the exact magnitude of the results is not the
issue.  The point is that a few big requests at 1:1 interleave can
offset the advantage of many contiguous single-sector requests at 6:1
interleave.
 
So, whether 1:1 or 6:1/7:1 is better from the standpoint of getting the user
home quicker depends on the user's job mix.  To find out what kind of
activities favor interleaving or lack thereof, I wrote another _Read/_Write
hook.  Here, if the request started in the same cylinder in which the previous
request ended, and if there were five or fewer intervening logical sectors,
the relative advantage of 6:1 vs. 1:1 interleave was calculated and
cumulated.  And, the relative disadvantage of 6:1 in terms of sectors passing
under the heads during actual data transfer was calculated and cumulated.
The following is a general summary of the net winner by activity:
 
Activity                                                Winner
 
All launches--
(MacWrite, MacPaint, Excel, MDS Asm, Consulair Link)      1:1
Finder copies                                             1:1
MDS Assembly                                              1:1
Consulair Link                                            6:1
Opening/Saving Write/Paint documents                      6:1
 
I presume that any backup program will do multi-sector requests, and therefore
would run faster with 1:1.
 
In general, if the user does a lot of document opening/saving, then
the 6:1 or so interleave is better.  If he does a lot of
launching/quitting (launching Finder), file copying, etc., then 1:1 is
better.  It should be noted, though, that with a "normal" mix of
activities the perceived difference will not be great.  I've been
running the MicahDrive at 7:1 for a couple of days (previously 1:1);
the perceived throughput is not noticeably different. I clocked a few
different activities at both interleaves, and the difference was
typically a few percent one way or the other.
 
 
DiskBench
---------
 
DiskBench has been aptly criticized for not being a realistic measure
of normal user I/O patterns.  (To which I have previously responded
that it was a quick hack that was never advertised as realistic.)  In
light of the foregoing data, I'd like to make clear (especially to
non-technical readers) that the DiskBench data transfer tests measure
only performance on large multi-sector I/O requests, and that in "real
life" such requests comprise only about 20% or so of the total data
that goes back and forth between the Mac and the disk.  Hence,
DiskBench data transfer results are not necessarily representative of
relative performance in real use.  FOR WHAT THEY ARE WORTH, here is
the last set of results I will publish:
 
The read data transfer test consists of 100 reads of 32KB from the beginning of
the volume; the write data transfer test consists of 100 writes of 32KB to the
beginning of the volume.  The access time test consists of 40 repetitions of:
read 512 bytes from an offset of 1MB into the volume; read 512 bytes from the
beginning of the volume.
 
Results on only one specimen should be regarded as provisional.
 
                               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  6842    11462    N/A    D. Etchells
 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
 Corvus 45MB                  10080    16632    323    R. Scorer, Corvus
 Corvus 126MB                  9822    16438    240    R. Scorer, Corvus
 DASCH external RAMdisk        2482     2797    N/A    J. Eugenides
 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           9714     9718    263    R. Scorer
 Hard Disk 20, Apple           9883     6948    368    R. Wiggins
 HD-20, MDIdeas                1726     3260    446    S. Brecher
 HD-30, MDIdeas                1749     3576    406    S. Brecher
 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
 LoDOWN 10MB                   1504     1503    321    S. Brecher
 LoDOWN 20MB                   1503     1504    242    M. Bohlig
 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
 MacBottom 20, v2.6a, PCPC     4161     6901    657    S. Fischbach
 MacDrive, Tecmar              6102     6704    440    L. Custer
 MacDrive, 10MB Fixed, Tecmar  6017     6719    401    C. Nicolais
 Macintosh XL, 10MB            3489     3589    370    MACLAIRD, Delphi
 MagNet 20, Mirror Tech.      14539    14538    322    D. Etchells
 MicahDrive 20 AT, Micah        508      507    488    S. Brecher
 MicahDrive 20 AT, Micah        508      507    527    S. Harris
 OverDrive 60/16MHz CPU, Levco 1102     1102    121    S. Brecher
 Profile, 5MB, Lisa 2/5, Apple 4107     4407    721    MACLAIRD, Delphi
 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 (7531)
Subject: Watch out for DataPak Software
Date: 23-APR 11:00 Business Mac
 
One of our subscribers, Peter Fleischhacker, reports that he purchased
Executive Office from DataPak software, only to find that it was
obnoxiously copy-protected, so that it cannot be used on a hard disk
or an 800K floppy; furthermore, it comes without any manual -- only a
promise to send one when it's ready.  So, Peter decided to return the
product.  The company would not accept it, or refund his money!  A few
days later, he called for technical support. This time they said that
everyone was busy on a project and that it wasn't possible to help
him. When asked when he _could_ get help, they replied they had no
idea!
 
Our advice:  stay away from DataPak Software.
 
Ric Ford
 
"MacInTouch" newsletter
 
------------------------------

From: RICFORD (7532)
Subject: Where's Sierra Info. Systems?
Date: 23-APR 11:02 Business Mac
 
Does anyone know the status of Sierra Information Systems, the company
which was selling Accountant's Choice.  They seem to have disappeared,
at least as far as answering their phone goes.
 
Ric Ford
 
------------------------------

From: RDETCHELLS (7552)
Subject: Re:  Hyperdrive Removal request
Date: 24-APR 22:23 MUGS Online
 
To:  Michael C. Adler
 
All I've eveer known to do is to GENTLY pry the board-guides with a small
screwdriver, to release the board, allowing it to be removed in a downward
direction, rather than sliding it out.   --- David Etchells, DELPHI

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

From: MOUSEKETEER (7581)
Subject: RE: Open Mac rumors cont'd (Re: Msg 7570)
Date: 26-APR 17:20 Macintosh In Fact
 
Dear Ric,
 
The Expandable Mac UGLY like the PC AT??  Don't worry!  I received a Kodak
Instant Print of the "artist's conception" of the unit this week from a secret
source at Cupertino, and really, it's kinda cute!  From the front, it looks a
lot like a normal Mac, but around 4 inches taller and 6 inches wider to allow
room for the new larger screen.  It's the side view that will take a bit of
getting used to.....
 
 
            -------------------------*------------------------
            |                                                 \
            (                                                  \
   FRONT    (                                                   \
            (                                                    \
            (                                                     \
            (                                                      |
            /                                                      |
           /                                                       |
           |        ----                               ----        |
           |       -------                            ------       |
            \-------------------------------------------------------
 
Yep, the new Mac is just over two feet deep!  Seems the original specs
were worded a bit vaguely, and required a "Bus Mac", and while WE all
know they *meant* EXPANSION bus, the folks at that were thinking rather
literally.  It's code-named the GRUMMAC, after the company who builds the
boxy buses.  I'm told, also, that the little doo-dad at the top is a "pull tab"
for access to the expansion "Chassis".
 
Hope this helps,
 
Alf

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

From: ASMCOR (7586)
Subject: MDS and Lightspeed C
Date: 26-APR 20:59 Programming
 
All-

For what it's worth, i had my first experience trying to get some MDS
things linked into a Lightspeed C program.  I have not used MDS much,
so I had a little problem figuring out how to set up the file so that
the labels would be available, but once I had that right all went
smoothly. The RelConv program from lightspeed worked just fine to
convert the REL file into a Lightspeed library, and it linked in and
worked right.  So, it does work, for those who are wondering.  
Jan

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

From: PIZZAMAN (7591)
Subject: Dollars & $ense
Date: 26-APR 22:12 Bugs & Features
 
Anyone get Dollars & $ense to work on an HD-20? I just bought a copy
to do some home finance stuff, and can't believe that this very
popular package is totally HD-20 incompatible. Could this be the case.
Even tried Hdutil with the patch. No luck. Hasn't there been an
upgrade since the origional release that wiwill let it be used with a
hard disk. They've added a file called "move to top", but this isn't
any better than just option control click finder. Any info available?
Barry

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

From: MOUSEKETEER (7594)
Subject: Is Mac Really Naked?
Date: 26-APR 22:47 Telecommunicating

I read an interesting book this morning, and am curious about how many here
might be interested in inviting the author to an online conference.  The book
is "THE CULT OF INFORMATION, The Folklore of Computers and the True Art of
Thinking" by Theodore Roszak (1986, Pantheon Books).
While it's rather expansive (perhaps too much so?), the book challenges the
computer's current status in our society, initially using as comparison the
figure of the Emperor and his New Clothes, suggesting that "Unburdened of
vainglorious ambition, dressed in more modest but palpable working clothes,
the computer, like the emperor in the fairy tale, may yet become a reasonably
valuable public servant."  Also, the author suggests that by giving an undue
importance to "information", which as been twisted to mean "knowledge", we
may be in danger of not teaching students how to actually think.
Surprisingly, the only two computer programs mentioned favorably in the book
are MacPaint and MacWrite.
While it would be impractical for everyone attending the conference to have
read the book, it might be possible to obtain the publisher's permission to
upload several selections for discussion.

I will post on poll you may "vote" in to express interest (or non).

Alf

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

From: MACINTOUCH (7595)
Subject: MS Word HELP!!!!
Date: 26-APR 22:57 Business Mac

I have an interesting problem using running heads with Microsoft word:

Everytime I do it, it doesn't work.  (Pretty interesting, eh?)

Anyway, here's the problem.  I do exactly as it says in the manual and I even
get the << sign in the left column but it NEVER shows up on the printout.  I
have it set for even and odd pages, at many different positions and NOTHING
works.  One weird thing does happen though: when I select and choose 'Running
Head' from the menu and select the choices, after I hit <ok>, the running head
in the document moves over 1.5 inches.  If I have the running head right
justified, it goes OFF the screen and center or left justified moves it to the
right, 1.5 inches!!

Any and all help would be very appreciated since I have a 30 page
paper due Mon. am and it NEEDS running heads.  Of course I could print
it on with one of the typewriter things or whatever they're called...

Thanks.

josh

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

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

dad@mit-vax.UUCP (David Duff) (04/30/86)

In article <4863@topaz.RUTGERS.EDU> shulman@topaz.RUTGERS.EDU (Jeff Shulman) writes:
>
>Delphi Mac Digest          Sunday, 27 Apr 1986      Volume 2 : Issue 16
>
>From: MACINTOUCH (7595)
>Subject: MS Word HELP!!!!
>Date: 26-APR 22:57 Business Mac
>
>I have an interesting problem using running heads with Microsoft word:
>
>Everytime I do it, it doesn't work.  (Pretty interesting, eh?)
>
>Anyway, here's the problem.  I do exactly as it says in the manual and I even
>get the << sign in the left column but it NEVER shows up on the printout.  I
>have it set for even and odd pages, at many different positions and NOTHING
>works.  One weird thing does happen though: when I select and choose 'Running
>Head' from the menu and select the choices, after I hit <ok>, the running head
>in the document moves over 1.5 inches.  If I have the running head right
>justified, it goes OFF the screen and center or left justified moves it to the
>right, 1.5 inches!!
>
>Any and all help would be very appreciated since I have a 30 page
>paper due Mon. am and it NEEDS running heads.  Of course I could print
>it on with one of the typewriter things or whatever they're called...
>

Sorry, but I don't think this will get to you in time for your paper.

When you declare a paragraph to be a running header or footer in MS
Word, the rulers for that paragraph are traslated from "indented" to
"absolute" (my terms).  What this means is that header and footer
paragraphs ignore the "right margin" and "left margin" settings in the
"page setup" menu.  Standard paragraphs align the zero on the ruler
with a point <left margin> from the left edge of the page, while
ruuning headers and footers align the zero point on the ruler with the
left edge of the page.  This is consistent with the "division layout"
commands for setting the vertical positions of the headers and
footers.  They are specified in units from top/bottom of the page.

I don't know if I made that clear.  If you print a character at the
zero mark in the rule of a regular paragraph, its position on the page
will depend upon the left-margin setting, while a character in a
header or footer paragraph would (theoretically) come out right at the
edge of the page. Keep in mind that the laserwriter can not print
closer than .5" from any edge of the page, so your head/footer margins
must be >.5" and <8.0" for printing in the regular orientation.  So,
even though your centered text appears to move off center on the
_screen_, it is still centered on _page_ (and between the margin
markers on the screen).

About the problem of headers and footers not showing up: That used to
happen to me, too.  I don't think I ever figured out exactly what the
problem was, but it doesn't seem to happen much anymore, so I must
have changed the way I use word.  Here are some things I would try: 1)
repaginate before printing.  Your're not supposed to have to do this,
but I have seen it correct a different problem.  2) Check the "header"
and "footer position" items in the "division layout" dialog box.  Then
check the size of your header or footer paragraph and the top and
bottom margin settings, to make syre that you left enough room for it
to fit without writing over other stuff.  Come to think of it, I'm
pretty sure that this is what my problem was.  In case that doesn't
work, try deleting them and re-entering them to see if that helps.  It
took me a couple of trys to master them, too.

The key to both your problems is the fact that word uses "absolute"
page coordinates to specify header and footer position.  This is quite
different from Mac Write's style.

Hope this helps.

Dave Duff

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

> Delphi Mac Digest          Sunday, 27 Apr 1986      Volume 2 : Issue 16
> 
> From: BRECHER (7507)
> Subject: Interleave/DiskBench
> Date: 22-APR 10:19 MUGS Online
>  
> Which Interleave is best?
> -------------------------
>  [results from SSDiskBench, which does single-sector operations]
> These results clearly confirm Bass's "about 6:1" estimate for optimal
> handling of consecutive single-sector requests.

Not really.  It actually confirms Bass's claim *assuming consecutive
requests are issued with minimal processing between them*.  The diskbench
program issued consecutive reads/writes as quickly as possible.  Do
most applications that do single-sector reads/writes do that, or do
they process each sector of data between operations?

> I gathered some statistics on the distribution of disk I/O requests by
> writing a hook into _Read and _Write which records the size of each
> request and the the sector (logical block) distance from the end of
> the previous request to the start of the current request.

The missing item here is the *interval* between requests.  Unfortunately,
the Mac's clock is to coarse to be much help here.  If the apparent time
between two requests is 0 or 1 ticks, they *might* be "back-to-back."
Or, enough time might have elapsed to defeat any attempted optimization
of the disk interleave.  If more than 1 tick has elapsed, you can be sure
that the disk interleave doesn't matter anymore, since typical disk
rotation times are on the order of 1 tick.

> So, whether 1:1 or 6:1/7:1 is better from the standpoint of getting the user
> home quicker depends on the user's job mix.  To find out what kind of
> activities favor interleaving or lack thereof, I wrote another _Read/_Write
> hook.  Here, if the request started in the same cylinder in which the previous
> request ended, and if there were five or fewer intervening logical sectors,
> the relative advantage of 6:1 vs. 1:1 interleave was calculated and
> cumulated.  And, the relative disadvantage of 6:1 in terms of sectors passing
> under the heads during actual data transfer was calculated and cumulated.
> The following is a general summary of the net winner by activity:
>  
Again, all this assumes that single-sector requests are issued with
no intervening processing.  I suspect that the real picture is very
different.

Ephraim Vishniac
decvax!wanginst!wang!ephraim