info-mac@uw-beaver (04/21/85)
From: Moderator John Mark Agosta <INFO-MAC-REQUEST@SUMEX-AIM.ARPA>
INFO-MAC Digest Sunday, 21 Apr 1985 Volume 2 : Issue 34
Today's Topics:
switcher.mail, and a suggestion.
re: macXL parallel printer
resizing windows
Macintosh-VMEbus and Macintosh-CAMAC interfaces
MacWrite file formats (2.2 and 3.x,4.x)
Lutzky-Baird Associates Phone number
PostScript on RS232 ?
plotting from the MAC ?
----------------------------------------------------------------------
Date: Sat 20 Apr 85 09:55:05-PST
From: John Mark Agosta <INFO-MAC-REQUEST@SUMEX-AIM.ARPA>
Subject: switcher.mail, and a suggestion.
Readers:
For those interested, the accumulating mail file on switcher bugs is
<info-mac>switcher.mail
Also, a suggestion: I there are several demo type programs that have
been submitted in downloadable form, but not in source code. I think
for a bboard read by so many developers, there would be much more
value in having the source and also the compiled version rather than
just the compiled version posted. Comments are welcome. -jma
------------------------------
Date: Wed 17 Apr 85 19:51:01-PST
From: Gustavo Fernandez <FERNANDEZ@SU-SCORE.ARPA>
Subject: re: macXL parallel printer
The February IM software supplement has a "Parallel printer install"
program that should be available to general users with the new release
of MacWorks XL. In the meantime, go find a Mac hacker who gets the
software supplement.
------------------------------
Date: Wed, 17 Apr 85 23:09 EST
From: Christopher Fry <cfry@OZ.MIT>
Subject: resizing windows
The idea: seeing Microsoft word and the technique of double clicking
on the title bar of a document and having it fill the screen (and go
back to the original size and location after this) makes me realize
that this technique should probably be a more global feature.
... Much of one's time is spent resizing windows on disks to
find what you are looking for.
This is an old problem as illustrated by the difference between Xerox
PARC D-machine windows and MIT Lisp Machine windows. D-machines give
you the ability to easily reshape the windows on the screen. When I
am on a D-machine, I notice myself constantly having to reshape the
windows. On a lisp machine, the user window layout style is more to
change between several full-screen formats. Although the Lisp Machine
allows you to reshape windows, a user rarely does. Usually the
full-screen formats are what you want. Switching between the full
screen formats is done either with 2 keystrokes, or selecting a menu
item.
Apple got MacIntosh windows from PARC and hence inherited the
flexibility and cumbersomeness of PARC window layout. I propose a
more general solution to the problem than simply "click on title bar
to expand window". The user and applications programmers should be
able to save screen configurations (in ram as well as on disk) and
allow the user to easily toggle between them (via a pull-down menu?).
The user should also be able to select every available window by
selecting a corresponding item on a menu. Double clicking on the menu
item causes the window's display to fill the screen, whereas
single-clicking causes it to be contained within a pre-specified size.
"click on title bar to expand window" is a good idea and I'd vote for
it if a more general mechanism like the one I just described weren't
available.
------------------------------
Date: 19 apr 85 12:55-GVA
From: BGT$WB%GEN.BITNET@WISCVM.ARPA
Subject: Macintosh-VMEbus and Macintosh-CAMAC interfaces
From: Bruce Taylor <BGT$WB@GEN.BITNET>
VMEbus and CAMAC interfaces for Macintosh have been developed by CERN
(The European Organisation for Nuclear Research). The system is called
MacVEE (Microcomputer Applied to the Control of VME Electronic
Equipment).
VMEbus (IEEE-P1014) is an international system supported by Mostek,
Motorola, Philips/Signetics and many other manufacturers. CAMAC
(IEEE-583) is an older modular electronics standard used mainly by the
high-energy physics community.
A MacVEE system consists of a Macintosh equipped with a special
interface which allows it direct memory-mapped access to single or
multiple VMEbus or CAMAC crates interconnected by a ribbon-cable bus.
The bus is driven by an electronics plinth called MacPlinth, which
attaches to Macintosh and becomes an integral part of the computer.
The installation of MacPlinth requires a few hour's work by a person
with technician or electronics hobbyist skills.
The total external address space accessed via MacPlinth is over 100
Mbytes, in up to 8 VMEbus crates, or up to 7 VMEbus crates and up to 8
CAMAC crates, in any mix. In a VMEbus system, Mac can execute
programs in VMEbus RAM or EPROM, and programs resident in one crate
can access facilities in any of the others.
MacPlinth also provides an external video signal for remote monitors,
and can accommodate 32 - 128 Kbytes of local EPROM for library
enhancements such as the ESONE standard CAMAC calls. It handles
user-vectored interrupts from VMEbus sources, merging them with
Macintosh internal interrupts. The vector numbers acquired from
VMEbus interrupters are offset to reference RAM addresses which are
not used by the Mac operating system.
The MacVEE VMEbus master module incorporates a release-on-request DTB
requester and a 3-level interrupt handler. It includes slot-1
functions (system clock, bus arbiter, global watchdog timer) and can
be employed as a system controller, or as a normal DTB master in a
multi-processor system.
The companion Macintosh dedicated CAMAC crate controller (Mac-CC) is
also memory-mapped. It is equipped with an IEEE-675 auxiliary
controller bus, supporting multiple controllers in a CAMAC crate with
either R/G arbitration or ACL, and is compatible with external
IEEE-596 LAM graders.
In a MacVEE system, selected VMEbus or CAMAC crates simply appear
within the address space of the Mac's 68000, so that no special
software drivers are required to access them. There is no address
translation, so that MacVEE is not limited to the execution of
position-independent code, and VME-resident software has direct access
to all Macintosh resources and the toolbox.
MacVEE allows the Macintosh direct access to a growing range of
VMEmodules including ADC's and DAC's, parallel I/O registers, large
RAM and EPROM modules, colour graphics drivers, SCSI, Ethernet and
IEEE-488 controllers, and interfaces for peripherals ranging from
9-track magnetic tape to optical disk storage devices.
Acknowledgment: The system was developed with the support of Carlo
Rubbia and numerous members of the CERN UA1 collaboration.
Bruce Taylor
Bitnet: BGT$WB@GEN
Mail: B.G. Taylor, EP Division, CERN, 1211 Geneva 23, Switzerland.
------------------------------
Date: Thu 11 Apr 85 17:27:40-EST
From: U.DMYJ-YOUNG-DOUGLAS-MILLER%CRNL20A.BITNET@Berkeley
Subject: MacWrite file formats (2.2 and 3.x,4.x)
There has been a lot of interest in the format of MacWrite documents,
specifically in terms of the compressed data format for the 3.x and
4.x test versions which will support disk-based files. I am hesitant
to type the entire documentation for 3.x and 4.x file formats here and
now, but if there is a sufficient uproar, I may be persuaded to do it.
[ This file is saved in macwrite234.format -jma ]
First, a word about MW 2.2. A MACA/WORD file whose first two bytes
are '00 03' is in 2.2 format. As we all know, 2.2 reads the entire
document into memory, and you manipulate the document within memory.
Here is the RECORD format for some global variables stored at the
beginning of a 2.2 file:
MWGlobals = RECORD
VerNum, Version number = 3 for MW2.2
ParaOffset, Pointer to start of first "paragraph"
MainPCount, Number of paragraphs in Main document
HeadPCount, Number of paragraphs in Header
FootPCount: Number of paragraphs in Footer
INTEGER;
TitlePgF, Title page?
ScrapDispF, Display scrap?
FootDispF, Display footers?
HeadDispF, Display headers?
RulerDispF, Display rulers?
Unused1: Byte for word alignment
BOOLEAN;
AcDocNum, Document that is currently active:
0 = Main
1 = Header
2 = Footer
StPgNum: Starting page number offset
INTEGER; END; MWGlobals
Every MacWrite formatted file has three sections (Main, header,
footer) each comprised of paragraphs. A "paragraph" can be either
text, a ruler, or a picture. The first paragraph is ALWAYS a ruler. So
if you are using Fedit, and you follow the ParaOffset pointer, you
will start at a ruler. The first two bytes of a paragraph are an
integer indicating what kind of paragraph it is (0=ruler, 1=text,
2=picture). The next two bytes are an integer indicating the length
of the paragraph. If you are only interested in text paragraphs, you
can follow ParaOffset to the first paragraph, read the paragraph type
and paragraph length, and skip that many bytes if it is not a text
paragraph. Then read the next paragraph, and so on. There are
MainPCount paragraphs for the main, followed by HeadPCount paragraphs
for the header, followed by FootPCount paragraphs for the footer.
If it is a text paragraph, there would be the two bytes for paragraph
type, two bytes for paragraph length, and then two bytes for the
length of the text. After the string of text characters, there is a
formatting run, the layout of which is rather grody.
Enough for MW2.2 format. That should be enough to get people started.
I encourage people to hack around in Fedit to learn more about it.
A real sticky wicket, a veritable nasty noodle, is MW 3.x and 4.x file
formats. They can be identified by a two-byte version number equal to
'00 06'. The format for the globals at the beginning of the file is
similar, but not identical, to 2.2:
MWGlobals = RECORD
VerNum, Version number = 6 for MW 3.x and 4.x
MainPCount, Number of paragraphs in Main document
HeadPCount, Number of paragraphs in Header
FootPCount: Number of paragraphs in Footer
INTEGER;
TitlePgF, Title page?
Unused1: Byte for word alignment
ScrapDispF, Display scrap?
FootDispF, Display footers?
HeadDispF, Display headers?
RulerDispF, Display rulers?
BOOLEAN;
AcDocNum, Document that is currently active:
0 = Main
1 = Header
2 = Footer
StPgNum: Starting page number offset
INTEGER; END; MWGlobals
After the starting page number, there is information for using the
"free list", which is how MW 3.x and 4.x manipulate pages on disk and
in memory. It is not at all necessary to understand the "free list"
unless you are writing a MacWrite clone where you need to be able to
swap and edit pages from a MacWrite-formatted file. If you only need
to be able to read, and perhaps display, a MacWrite document, you can
pretty much avoid the free list stuff altogether.
Reading a paragraph is tricky. There are "document variables" at
positions 00A0 (footer), 00CE (header), and 00FC (main). Bytes
12D-15D in the document variables contain the position of the
"information array" for the first paragraph. (There is an information
block for each paragraph in the header, footer, and main, and each
information block is a total of 16 bytes long.) The 8th byte in the
information block is the status byte for that paragraph. Bit number 3
is of special interest, in that it tells whether the paragraph is in
compressed format (to be discussed shortly). Bytes 9-11 contain the
location of the paragraph data, and bytes 12-13 are the length of the
paragraph data. To determine what kind of paragraph it is, bytes 0-1
of the information block contain the paragraph height. A positive
value indicates the paragraph is text, a negative value means a
picture, and zero indicates a ruler. Now follow bytes 9-11 to find
the paragraph data. If it is text, the first two bytes of the
paragraph data will be the length of the text in bytes. It is
important to note that the length is in bytes, not characters, since
the characters may be compressed.
***Text Compression*** This is one of the most interesting things
about MW 3.x and 4.x. In an attempt to save disk space, Apple came up
with a scheme to compress ASCII text down so that two compressed
characters would fit into one byte. It works as follows: for any
given language (in our case, English), the developers of the MacWrite
system determine the 15 most common characters in that language. Note
that for almost every language, the most common character is the space
character. After the space character, it varies from one language to
another, based upon statistical analysis. These 15 characters are then
combined to form a Str255 of length 15. In the resource fork of the
file, is a resource of type STR (id = 700) which is this string. For
the English language, it looks like this: ' etnroaisdlhcfp'. Now,
when it comes to compressing text, all you need is one NIBBLE to
represent one of these 15 characters. The nibbles that are used are
0-E. The nibble F is used to indicate that the two nibbles that
follow are NOT compressed characters, but comprise a complete ASCII
character. So for example, the word 'tent' would look like '21 32',
and the word 'Tent' would look like 'F5 41 32'. The string 'The tent'
would look like 'F5 4B 10 21 32'. Notice immediately that we gain a
nibble for each compressed character, but we lose one for each
non-compressed character. In the long run, this technique wins bytes.
If, however, the text was pathologically bizarre, and it had lots of
capital letters and punctuation and infrequent letters, then we would
be wasting space to use up an extra nibble on each uncompressible
character. That is why there is a compressed bit. The MacWrite
program determines whether it will win anything by using this
compression technique, and acts accordingly.
Let's try running through how we can read out the text of the main
part of a MacWrite document:
1) Verify version number = 6
2) MainPCount = bytes 0002-0003
3) M_IAP = bytes 0108-010B Main Info Array Pointer
The byte positions are calculated from the Main Document Variable
offset of 00FC, plus the offsets of 12D-15D into the MainDocVars.
4) Paratype = bytes (M_IAP) - (M_IAP+1)
5) psb = byte (M_IAP+8) Paragraph Status Byte
6) CompBit = bit 3 of psb Compression Bit
7) pdp = bytes (M_IAP+9) - (M_IAP+11) Paragraph Data Pointer
8) para_len = bytes (M_IAP+12) - (M_IAP+13) Paragraph length
Now, if Paratype is positive, we go to the paragraph itself...
9) text_len = bytes (pdp) - (pdp+1)
10) proceed to read text_len number of bytes, and decompress using the
scheme described above (if compressed bit is set)
The information described above is excerpted from documentation
furnished by: Encore Systems 20823 Stevens Creek Blvd. C1-B
Cupertino, California 95014 (408)446-9565
We can vouch for the above description, since we are currently
involved with developing software which will interact with MacWrite
files. If you have any questions about details of MacWrite file
format, or about our project here at Cornell, write or call us. We
may respond individually, or via the net.
Kate MacGregor and Douglas Young Decentralized Computer Services 401
Uris Hall Cornell University Ithaca, NY 14853 (607)256-4981
Doug Young's electronic address is DMYJARTJ@CORNELLA.BITNET
------------------------------
Date: 17 Apr 85 17:22:33 EST
From: Seymour <JOSEPH@RU-BLUE.ARPA>
Subject: Lutzky-Baird Associates Phone number
Lutzky-Baired Associates seems to be working with Zilog to produce an
Appletalk to Ethernet Gateway that will eventually provide Electronic
Mail and file services. Their Address is: Lutzky - Baird Associates
5601 Slauson Ave, Suite 222 Culver City, CA 90230
and their phone number is (213) 649 - 3570
Seymour
------------------------------
Date: Thu, 18 Apr 85 12:00 EST
From: Michael.Fryd@CMU-CS-A.ARPA (X435MF0E)
Subject: PostScript on RS232
Is it possible to get the Macintosh to talk to PostScript printers
other than the LaserWriter?
The problem is that the Mac talks to the LaserWriter using AppleTalk,
but other PostScript printers require a normal RS232 connection.
Perhaps I can patch the LaserWriter system file in some way to make it
talk RS-232?
-Michael Fryd @CMU-CS-A
------------------------------
Date: Sat 20 Apr 85 11:37:35-CST
From: Werner Uhrig <CMP.WERNER@UTEXAS-20.ARPA>
Subject: plotting from the MAC ?
a friend asked me about the existance of any code or information that
would allow him to use a plotter as an output device. I don't recall
anyone mentioning anything here, but I may not have paid any attention
to the topic.
Any leads?
------------------------------
End of INFO-MAC Digest
**********************