bees@drutx.UUCP (05/23/84)
--------------- 1) 30-Apr David Spector 2) 30-Apr Ed Pattermann Upgrade of FINDER/WRITE/PAINT 3) 1-May John Palevich Alan Kay 4) 1-May STERNLIGHT@USC-ECL.A Finder/system and Macworks bomb 5) 1-May ERIK@SRI-AI.ARPA Japanese Macintosh 6) 1-May Bob Rees 1 vs. 2 floppy drives 7) 1-May bill coderre MacPaint stuff 8) 1-May STERNLIGHT@USC-ECL.A Mac configuration 9) 2-May mark@harvard (Mark L Re: MacPaint stuff 10) 2-May len MacWrite Bug report 11) 2-May David Potter, Softma Mice for the Ambidextrous 12) 2-May Edward.Tecot at CMU- Re: MacPaint Stuff 13) 3-May John Palevich My (educated) opinion on the Mac's design 14) 3-May John Palevich How to transfer a Mac file? 15) 3-May Jerry E. Pournelle deadlines 16) 3-May David.Anderson at CM What's in the manual? 17) 3-May INTMET@BBNA.ARPA MacForth Users Group. 18) 3-May Richard Reich Toolbox equates for peons 19) 4-May ERIK@SRI-AI.ARPA Accurate Info for your column 20) 4-May DBECK@SRI-KL.ARPA support 21) 4-May Ron MacAssembler requires * 2 * Macs!? 22) 4-May Christopher A Kent Re: MacAssembler requires * 2 * Macs!? 23) 4-May Chad Leland Mitchell standalone 24) 4-May Dick Kalagher Re: MacAssembler requires * 2 * Macs!? 25) 4-May Ronald A. Jarrell fixing a trashed disk 26) 4-May Ronald A. Jarrell MacWrite "Feature" 27) 5-May Peter.Monta@cmu-cs-g Quickdraw bug? 28) 7-May Walter.Smith at CMU- Re: user's groups 29) 7-May JSMCCLEES@BBNG.ARPA macpaint font bug, mac user group 30) 7-May Tim McNerney Teaching assembly language programming, Mac s 31) 7-May Bruce.Lucas at CMU-C bugs 32) 7-May ERIK@SRI-AI.ARPA This is not an Apple account 33) 7-May Bruce.Lucas at CMU-C Finder bug 34) 7-May Tony Siegman Query Re RS-232 Interface and Handshaking 35) 7-May Richard Furuta What is the University of California's Mac st 36) 7-May Ronald A. Jarrell Mac Hardware problem 37) 7-May John Shore Req. translation of Lisa error message 38) 8-May Dale Carstensen C-3 Mactep for 7 bit, even parity 39) 8-May Tim McNerney This is not an Apple account 40) 8-May Randy Frank Interfacing other disk to a mac Message 1 -- ************************ Return-Path: <PATTERMANN@SUMEX-AIM.ARPA> Received: from SUMEX-AIM.ARPA by UTEXAS-20.ARPA with TCP; Mon 30 Apr 84 13:18:27-CDT Return-Path: <SPECTOR@NYU-CMCL1.ARPA> Received: from NYU-CMCL1.ARPA by SUMEX-AIM.ARPA with TCP; Sun 29 Apr 84 17:06:13-PDT Date: 29 Apr 84 20:08 EDT From: David Spector To: info-mac@SUMEX-AIM.ARPA Sender: David H M Spector <SPECTOR@NYU-CMCL1.ARPA> Message-ID: <1206EA327.008C002C.1984@CMCL1.NYU-CMCL1.ARPA> ReSent-date: Mon 30 Apr 84 10:59:19-PDT ReSent-From: Ed Pattermann <PATTERMANN@SUMEX-AIM.ARPA> ReSent-To: info-mac: ; ________________________________________. |ARPAnet: SPECTOR@NYU-CMCL1 | |USEnet : ...floyd!cmcl2!acf4!spector| ________________________________________. Does anyone have any info regarding Apple shipments to the Consortium Schools? Is Apple yet making regular deliveries? Thanx, David Spector ------- Message 2 -- ************************ Return-Path: <PATTERMANN@SUMEX-AIM.ARPA> Received: from SUMEX-AIM.ARPA by UTEXAS-20.ARPA with TCP; Mon 30 Apr 84 14:51:01-CDT Mail-From: PATTERMANN created at 30-Apr-84 11:17:44 Date: Mon 30 Apr 84 11:17:44-PDT From: Ed Pattermann <PATTERMANN@SUMEX-AIM.ARPA> Subject: Upgrade of FINDER/WRITE/PAINT To: info-mac@SUMEX-AIM.ARPA ReSent-date: Mon 30 Apr 84 12:05:18-PDT ReSent-From: Ed Pattermann <PATTERMANN@SUMEX-AIM.ARPA> ReSent-To: info-mac: ; With regards to the upgrade of the FINDER, MACpaint and MACwrite, the dealers should be handling the actual upgrade, and it will be free. Apple will not get any money as a result of the upgrade, although the dealers may make a small charge for the media. Please don't ask me any questions on this, as this is all I could find out at the moment from Apple. -- Ed ------- Message 3 -- ************************ Return-Path: <PATTERMANN@SUMEX-AIM.ARPA> Received: from SUMEX-AIM.ARPA by UTEXAS-20.ARPA with TCP; Tue 1 May 84 10:21:24-CDT Return-Path: <palevich%atari.csnet@csnet-relay.arpa> Received: from csnet-relay by SUMEX-AIM.ARPA with TCP; Mon 30 Apr 84 17:35:50-PDT Received: From atari.csnet by csnet-relay; 30 Apr 84 20:08 EDT Date: Mon, 30 Apr 84 10:13 PST From: John Palevich <palevich%atari.csnet@csnet-relay.arpa> To: info-atari@su-score.arpa cc: info-mac@sumex-aim.arpa Subject: Alan Kay ReSent-date: Tue 1 May 84 08:10:08-PDT ReSent-From: Ed Pattermann <PATTERMANN@SUMEX-AIM.ARPA> ReSent-To: info-mac: ; (the Management page of the business section of the Saturday, April 28, 1984 San Jose Mercury News included the following item, reprinted in its entirety.) @b{Management changes} Alan Kay, who recently resigned as a "fellow" at Atari Inc., will join Apple Computer Inc. next week with the same title, his office said Friday. Kay reportedly was recruited heavily by Apple chairman Steve Jobs but apparently convinced Jobs to let him do most of his work out of his home in Los Angeles. An Apple spokesman refused to comment Thursday. When Kay left Atari earlier this month, he said he wanted to "persue some very basic work in artificial intelligence." Kay is best known for conceptualizing the "Dynabook," a small computer that would seem as much a part of a person as his arm or leg. Message 4 -- ************************ Return-Path: <PATTERMANN@SUMEX-AIM.ARPA> Received: from SUMEX-AIM.ARPA by UTEXAS-20.ARPA with TCP; Tue 1 May 84 10:33:55-CDT Return-Path: <STERNLIGHT@USC-ECL.ARPA> Received: from USC-ECL.ARPA by SUMEX-AIM.ARPA with TCP; Mon 30 Apr 84 19:31:30-PDT Date: 30 Apr 1984 1930-PDT From: STERNLIGHT@USC-ECL.ARPA Subject: Finder/system and Macworks bomb To: info-mac@SUMEX-AIM ReSent-date: Tue 1 May 84 08:10:37-PDT ReSent-From: Ed Pattermann <PATTERMANN@SUMEX-AIM.ARPA> ReSent-To: info-mac: ; The combination of the new finder/system on the Macterminal demo disk and the Macworks 3.12 sent to developers and marked 'release' seems to bomb on the Lisa when you open scrapbook. The bomb is a new one which is unrecoverable without powering the Lisa down. --david-- ------- Message 5 -- ************************ Return-Path: <PATTERMANN@SUMEX-AIM.ARPA> Received: from SUMEX-AIM.ARPA by UTEXAS-20.ARPA with TCP; Tue 1 May 84 11:04:54-CDT Return-Path: <ERIK@SRI-AI.ARPA> Received: from SRI-AI.ARPA by SUMEX-AIM.ARPA with TCP; Mon 30 Apr 84 20:42:12-PDT Date: Mon 30 Apr 84 20:42:45-PDT From: ERIK@SRI-AI.ARPA Subject: Japanese Macintosh To: Info-Mac@SUMEX-AIM.ARPA cc: Erik@SRI-AI.ARPA ReSent-date: Tue 1 May 84 08:11:05-PDT ReSent-From: Ed Pattermann <PATTERMANN@SUMEX-AIM.ARPA> ReSent-To: info-mac: ; The Japanese Macintosh indeed poses a set of problems different from the modifications required for European products. We want to find the best way to make Macintosh approachable, attractive and affordable to Japanese customers. Xerox J-Star, IBM 5550 and NEC PC-100 are some of the systems we have evaluated in our quest for solutions and models. The phonetic input method is indeed becoming a standard way to tackle the problem of Kanji. Better solutions (such as Xerox's J-Star) do grammatical pre-processing before conversion into Kanji, thus significantly simplifying the task of the typist. Meanwhile, Apple will put out a Kana Macintosh as a stopgap solution until the full blown Japanese (Kana/Kanji) system is ready. The majority (if not all) of the Japanese MANAGERS do not type and prefer to handwrite their notes: a keyboard is still associated with a typist or secretary. Simplifying the typing process will certainly help in making computers more appealing to managers. I hope this answers some of the questions raised by the Macworld article on International Macs. Joanna K. Hoffman International Marketing Manager ------- Message 6 -- ************************ Return-Path: <PATTERMANN@SUMEX-AIM.ARPA> Received: from SUMEX-AIM.ARPA by UTEXAS-20.ARPA with TCP; Tue 1 May 84 12:11:37-CDT Return-Path: <rrees@bbncca> Received: from bbn-unix by SUMEX-AIM.ARPA with TCP; Mon 30 Apr 84 22:15:26-PDT Received: from BBNCCA.ARPA by BBN-UNIX ; 30 Apr 84 23:00:59 EDT Date: Mon, 30 Apr 84 22:54:19 EDT From: Bob Rees <rrees@bbncca> Subject: 1 vs. 2 floppy drives To: info-mac@SUMEX-AIM.ARPA ReSent-date: Tue 1 May 84 08:12:49-PDT ReSent-From: Ed Pattermann <PATTERMANN@SUMEX-AIM.ARPA> ReSent-To: info-mac: ; When people point out the "flaws" in the design of the Macintosh, the one most frequently mentioned is the absence of a second built-in floppy disk drive. This seems to be a recurring theme in both computer journal articles and the `info-mac' mailing list. For example, here's a "typical" comment, quoted from the famous Macintosh review in the Feb. 84 issue of BYTE Magazine: I also feel strongly that the basic Macintosh package should include two disk drives. With a one-drive system, it will take at least eight disk swaps to back up a 3-1/2 inch disk. How many people (especially novices) will go to this trouble, and how many will suffer when they don't? (I am not alone in feeling this way; the first thing two BYTE editors said when they first saw the Macintosh was, "Only one disk drive? You've got to be kidding!" After numerous disk swaps when trying to load MacPaint from one disk and a drawing from another, I am convinced that most users will eventually buy the second drive.) I am a little surprised that no one (even for the sake of playing devil's advocate) has expressed the opinion that the single-drive architecture is "a good idea" or even "OK". In order to judge the wisdom (or lack thereof) behind the design decision, we need to consider the potential uses of the Macintosh. I have attempted to categorize the possible approaches according to disk configuration options. This list is not necessarily all-inclusive: 1) The "Spartan/Cheapskate" Approach: one built-in floppy drive (period). Suitable for students, hackers, or anyone else who doesn't place a high premium on the value of his/her time. The user does backups by multiple disk swaps (tedious but effective) or choses to not do backups at all. [There *are* applications where losing data and/or having to regenerate it is a minor inconvenience rather than a disaster, and the cost of doing the backup has to be weighed against the cost of loss multiplied by the probability of loss. Those of us used to storing large original documents (such as program sources or collected raw data) may forget that there are cases where the balance tips the other way.] 2) The "Expanded Memory" Approach: still only one built-in floppy drive, but with 512K bytes of main memory. Not an option yet, but we'll surely see it within a year. Apple plans to offer a board upgrade when the denser RAM chips become more economically feasible. Daring hackers could replace the chips themselves. With a half-meg of memory available, copying a 400K floppy could be done with a single swap! One could claim that having a disk with less capacity than memory represented a serious mismatch, although many applications could make good use of this configuration. 3) The "Standard" Approach: one built-in floppy, one external floppy. Only slighly less convenient than having both built in. Yes, it's obvious that it's going to cost a bit more because of the extra box, cable, and power supply (or does the external drive get its power from the Mac?). One could even argue (though I won't bother) that an external drive was *superior* to a second internal drive because the user is "less likely to get confused" about which disk is is which drive. 4) The "Professional" Approach: one built-in floppy, one external hard disk. The preferred configuration for many business applications. I understand that compatible hard disks are already available, and more are on the way. Certainly more cost-effective than floppy drives when judged on an on-line-bytes-per-buck basis, and the prices should continue to drop as these units become more popular. 5) The "Workstation" Approach: one built-in floppy, one serial line to a local or remote host mainframe. The Mac can be used as a (very) intelligent terminal, and can off-load many interactive tasks (such as document preparation and data entry/verification) from the host. The built-in floppy provides local/personal file storage, while the host provides mass storage. 6) The "Network" Approach: one built-in floppy, one serial line to a local area network. Similar to the "workstation" approach, but the Mac is not tied to any particular host -- in fact, the network need not have any "host" computers at all other than the Macs themselves. However, to eliminate the need for a second disk on each Mac, the network should include at least one file-server host, which provides access to large and/or shared data bases and space for back-up buffering. Notice that option 2) is the only approach that *needs* the cherished second floppy drive. In all the other options, the elimination of the (unnecessary) second drive represents a savings to the consumer. I'm not saying that we're saving the *entire* cost of the second drive (I haven't forgotten that Apple is trying to make a profit as well as a sucessful product), but we're certainly saving some of it. And while the "Standard" approach is currently the most popular, it doesn't represent such an overwhelming percentage of the potential applications that it makes sense to include an expensive option in every base unit. If the argument seems weak now, wait a year -- I predict that the "Standard" approach will diminish in (relative) popularity as some of the other approaches become more economically feasible and their advantages become better understood. As for me, I ordered my Mac without an extra drive. I'll start with the "Spartan/Cheapskate" approach (after all, since there's no software yet, anyone who buys a Mac *now* is in the hacker category anyway), see how painful it is, and when the need arises, chose an option for expanding (there will be more options to chose from then). I'm happy that I didn't have to start by buying into an approach that may not turn out to be best for me in the long run. I chose to buy a Mac, but I was not so blinded by love that I didn't see its faults and limitations. When I compared it to other personal computers, I counted pros & cons. The absence of a second floppy drive was not something that ended up in my "con" column. I think Apple got this one right. -- Bob Rees P.S.: The Macintosh *does* have two serious problems related to the single drive, but the problems are not with the hardware design -- the problems are with marketing and software. The marketing problem is obvious: external drives are simply *unavailable*! (My local Apple dealer has never even seen one.) The software problem is even more annoying. From what I've seen & heard, the software seems to have been designed for a 2-drive system, with the provision for disk swapping added as an afterthought. Little attention was given to reducing the number of times the software had to switch from one disk to another (by using clever buffering schemes and anticipating what code & data should be kept in memory). Given that Apple chose to design a 1-drive machine, it's really unforgivable that they didn't bother to optimize their software for the default configuration. Message 7 -- ************************ Return-Path: <PATTERMANN@SUMEX-AIM.ARPA> Received: from SUMEX-AIM.ARPA by UTEXAS-20.ARPA with TCP; Tue 1 May 84 19:41:03-CDT Return-Path: <@MIT-MC:SE.BC@MIT-EECS> Received: from MIT-MC by SUMEX-AIM.ARPA with TCP; Tue 1 May 84 10:10:30-PDT Date: Tue 1 May 84 13:10:01-EDT From: bill coderre <SE.BC%MIT-EECS@MIT-MC.ARPA> Subject: MacPaint stuff To: info-mac@SUMEX-AIM.ARPA ReSent-date: Tue 1 May 84 17:26:19-PDT ReSent-From: Ed Pattermann <PATTERMANN@SUMEX-AIM.ARPA> ReSent-To: info-mac: ; The following is a compartmentalized flame. Feel free to ignore the parts you don't like.... An Interesting (MacPaint) Hack: If you are in Pencil, and you hold the command key, clicking the mouse button toggles FatBits, and where the pencil on the normal screen is centered in the FatBits screen. Flame: Too bad this doesn't seem to be in the manual. It's an excellent idea, and points out a Great Concept in mousing (no claims of origin or originality...): GET BOTH HANDS BUSY! Allowing the left hand to option-modify the command increases the bandwidth of the keyboard and speeds things up a lot. Daydream: My vision of the ideal workstation keyboard is one with 5 keys on the left side of the keyboard to do single click, double click, constrained click, etc, and a trackball on the right side. This allows lap operation and shortens the hand travel distance. Trackballs can be made to be much more precise, too. It might become possible to do freehand drawing (or at least make it easier). I might (in the far future) hack together a mackeyboard like that. If any computer company wants to bring out a keyboard like that, by all means go ahead with my blessing. I'd like it. ...................................................................bc ------- Message 8 -- ************************ Return-Path: <PATTERMANN@SUMEX-AIM.ARPA> Received: from SUMEX-AIM.ARPA by UTEXAS-20.ARPA with TCP; Tue 1 May 84 19:56:35-CDT Return-Path: <STERNLIGHT@USC-ECL.ARPA> Received: from USC-ECL.ARPA by SUMEX-AIM.ARPA with TCP; Tue 1 May 84 12:41:28-PDT Date: 1 May 1984 1237-PDT From: STERNLIGHT@USC-ECL.ARPA Subject: Mac configuration To: info-mac@SUMEX-AIM ReSent-date: Tue 1 May 84 17:26:21-PDT ReSent-From: Ed Pattermann <PATTERMANN@SUMEX-AIM.ARPA> ReSent-To: info-mac: ; Since I`m getting a bit tired of the 1 vs. 2 drives and 512k discussions, let me offer the following hypothesis: the MAC was originally designed as a 2-drive, 512k machine. Then Apple discovered that they couldn`t get enough drives from Sony and that 512k was too expensive to make it to market before 1985. Not being willing to wait til then, they modified the design to get it out (it was already late). Perhaps (the clue is some software that takes color) the original design even had color. If this is so, it makes some of the handsprings Apple apologists have been turning a bit silly. (I write this as a supporter of the Mac and an Apple registered developer--just want some reasonableness to the discussion.) Note that the hypothesis is entirely my own; I don`t know anything official from Apple about these matters. --david-- ------- Message 9 -- ************************ Return-Path: <PATTERMANN@SUMEX-AIM.ARPA> Received: from SUMEX-AIM.ARPA by UTEXAS-20.ARPA with TCP; Wed 2 May 84 12:17:40-CDT Return-Path: <mark@harvard> Received: from harvard.UUCP (HARVARD.ARPA.#Internet) by SUMEX-AIM.ARPA with TCP; Wed 2 May 84 08:33:07-PDT Date: Wed, 2 May 84 11:34:39 edt From: mark@harvard (Mark Lentczner) Message-Id: <8405021534.AA19606@harvard.UUCP> To: SE.BC%MIT-EECS@MIT-MC.ARPA, info-mac@SUMEX-AIM.ARPA Subject: Re: MacPaint stuff ReSent-date: Wed 2 May 84 09:41:08-PDT ReSent-From: Ed Pattermann <PATTERMANN@SUMEX-AIM.ARPA> ReSent-To: info-mac: ; -=- Yes, not very much is documented in that small pamphlet for MacPaint. On the other hand: 1) that pamphlet does not claim to be a manual for MacPaint (read the first two pages), & 2) the feature you found IS documented, along with several other fun things under the Short Cut entry in the Goodies menu when you are in MacPaint. I wonder if, since there is also an Introduction entry in the Goodies menu, Apple never intended to give ANY printed documentation on MacPaint... As many of my friends have proven on my mac- you can just start playing and never read the printed doc. Pretty amazing concept! -mark lentczner electronic music studio harvard university cambridge, ma 02134 Message 10 -- ************************ Return-Path: <PATTERMANN@SUMEX-AIM.ARPA> Received: from SUMEX-AIM.ARPA by UTEXAS-20.ARPA with TCP; Wed 2 May 84 12:37:51-CDT Mail-From: LATTANZI created at 2-May-84 09:14:36 Date: Wed 2 May 84 09:14:36-PDT From: len <Lattanzi@SUMEX-AIM.ARPA> Subject: MacWrite Bug report To: info-mac@SUMEX-AIM.ARPA ReSent-date: Wed 2 May 84 09:41:37-PDT ReSent-From: Ed Pattermann <PATTERMANN@SUMEX-AIM.ARPA> ReSent-To: info-mac: ; Bug: MacWrite hangs when trying to initialize a disk for saving current file. Repeat-by: Use save as... then eject current disk and insert an uninitialized disk. Click Initialize in the next dialog box. And you'll stare at the message "Initializing Disk" forever. There's not even a whir of disk motion. I tried an interrupt (left hand side "programmers button") but a serious system error ensued. Luckily the file was already saved on another disk. Caveat, len Arpa: Lattanzi@Sumex-Aim.Arpa Phone: (415) 326-5209 USPS: Box 6032 Stanford Ca 94305 ------- Message 11 -- ************************ Return-Path: <PATTERMANN@SUMEX-AIM.ARPA> Received: from SUMEX-AIM.ARPA by UTEXAS-20.ARPA with TCP; Wed 2 May 84 15:08:36-CDT Return-Path: <POTTER@OFFICE-2.ARPA> Received: from OFFICE-2.ARPA by SUMEX-AIM.ARPA with TCP; Wed 2 May 84 11:03:44-PDT Date: 2-May-84 11:01 PDT From: David Potter, Softmark/McDonnell Douglas <DAP.TYM@OFFICE-2.ARPA> Subject: Mice for the Ambidextrous To: info-mac@SUMEX-AIM.ARPA Cc: MARKET.TYM@OFFICE-2.ARPA, DCE.TYM@OFFICE-2.ARPA Cc: DEV.TYM@OFFICE-2.ARPA Message-ID: <[OFFICE-2.ARPA]TYM-DAP-4L77T> Comment: An answer to Bill Coderre.... ReSent-date: Wed 2 May 84 12:23:27-PDT ReSent-From: Ed Pattermann <PATTERMANN@SUMEX-AIM.ARPA> ReSent-To: info-mac: ; If Bill Coderre wants something for his left hand to do while his right hand is busy with the mouse (a most understandable wish), he might be interested in taking a look at AUGMENT, the Tymshare product which evolved from Doug Engelbart's NLS, which was developed at SRI. That's where the mouse itself was invented. Its developers recognized the need for a control device usable by the hand not busy with the mouse, and developed a five-key "keyset." Looks sort of like a little piano keyboard, sitting (usually) to the left of the keyboard, with the mouse on the right. We've been using the keyset, together with a three-button mouse, since the late 60's (Doug Engelbart -- Engelbart@Office-2.ARPA) could give you a more precise date -- works beautifully, and does just exactly what Bill is asking for. As a matter of fact, I'm using one now -- mouse and keyset hooked to a PC/XT -- to send this message. It's nice to see people thinking along these lines. They used to laugh when I sat down at the mouse & keyset.... "What's THAT?" they said.... Regards -- David Message 12 -- ************************ Return-Path: <PATTERMANN@SUMEX-AIM.ARPA> Received: from SUMEX-AIM.ARPA by UTEXAS-20.ARPA with TCP; Wed 2 May 84 19:44:39-CDT Return-Path: <tecot@cmu-cs-h.arpa> Received: from CMU-CS-H.ARPA by SUMEX-AIM.ARPA with TCP; Wed 2 May 84 16:19:02-PDT Date: 2 May 1984 19:21:04-EDT From: Edward.Tecot at CMU-CS-H Subject: Re: MacPaint Stuff ReSent-date: Wed 2 May 84 17:20:13-PDT ReSent-From: Ed Pattermann <PATTERMANN@SUMEX-AIM.ARPA> ReSent-To: info-mac: ; The Option-Pencil hack, as well as many others, is mentioned in the short-cuts section of Goodies. You will notice that there are quite a few useful features mentioned there. I prefer having this information there instead of in the manual, for one reason: I don't want to read the manual! Has anyone actually seen a hard disk for the Mac? I would like to know about their reliability/ease of use/availability. _emt Message 13 -- ************************ Return-Path: <PATTERMANN@SUMEX-AIM.ARPA> Received: from SUMEX-AIM.ARPA by UTEXAS-20.ARPA with TCP; Thu 3 May 84 11:53:30-CDT Return-Path: <palevich%atari.csnet@csnet-relay.arpa> Received: from csnet-relay by SUMEX-AIM.ARPA with TCP; Wed 2 May 84 18:01:33-PDT Received: From atari.csnet by csnet-relay; 2 May 84 20:40 EDT Date: Wed, 2 May 84 15:14 PST From: John Palevich <palevich%atari.csnet@csnet-relay.arpa> To: info-mac@sumex-aim.arpa Subject: My (educated) opinion on the Mac's design ReSent-date: Thu 3 May 84 09:12:04-PDT ReSent-From: Ed Pattermann <PATTERMANN@SUMEX-AIM.ARPA> ReSent-To: info-mac: ; The following is the personal opinion of John Howard Palevich, and is not ment, in any way, to reflect the opinion or knowlege of either Apple Computer Inc or Atari Inc. It is based entirely upon publicly available information. Hi -- I worked on a high-end personal computer design team for a couple of months once, and I think you're all going off the deep end with your Mac speculations. Please remember that Apple is just an ordinary company composed of fallible, short-sighted engineers. The Mac design is great, but it's not part of some grand all-encompassing plan. In particular: The Mac will not have color. Ever. Give it up, guys. (More on this later...) A Mac designer gave an excellent talk at Stanford a while back, during which he gave a bit of the history of the Macintosh: Remember that the Mac project has been around for a very long time. The original Mac had: * a 256 x 256 bit-mapped display * 64K of RAM * a 8-bit (6809?) processor * integrated application software in ROM * transportability (original design looked like an Osbourne) * a "twiggy" (Lisa-1 style) disk drive The Mac was (obviously) ment to be a "model-T" machine, with no options. Anyway, they realized that the ability to display 80-column text was an absolute necessity, so they went to a 320 x 256 display. The 4 x 6 characters that this display produced proved so ugly that they gave up and went to the current 512 x 342 display, which gives an adequate 6 x 8 character size. A 512 h by 342 v by 1 bit-per-pixel by 60 hz display requires 22K of RAM and a video memory bandwidth of abou 2Mb per second. If you want your processor to have any access to video memory at all, you have to use a 16 bit data bus. (All other things being equal, a 16-bit bus transfers data twice as quicly as an 8-bit bus.) Sixteen 64K-by-1 RAM chips give you 128K of RAM, and by this time the 68000 had become cheap, and was being used on the Lisa project, so they adopted it. Inspection of the "Inside Macintosh" manual, "User Interface Guidelines", page 67, dated 10/11/82, reveals a Macintosh which is pretty similar to the one we know today. The only difference is that the disk drive's capacity is rated as 840K. WHY WE HAVE ONLY 400K ON OUR DISKS The Mac was designed to use the fabled "Twiggy" drives. These drives, designed for the Lisa computer, use 5 and 1/4 inch diskettes, store 840K by using both sides of the diskette surface, and have a reputation for being unreliable. Halfway through the Mac project, they decided to go with the fancy new Sony 3 and 1/2 inch drives for a number of reasons which can only be guessed at. I suspect that influencing factors included: * Sony diskettes could store the same ammount of data as the Twiggy drives * Sony hardware is superb * Sony hardware is cheap * The diskette's physical format was becomming a standard This design change was made late in the game -- Apple had already made the molds for the Mac cases with the larger cut-outs for the Twiggy drives. If you look at the photos on pages 128 and 130 of the "Premier" issue of Macworld, you'll see Macintoshs with the larger cut-outs. The only problem was that Sony couldn't make double sided drives in quantity, so we're stuck with single sided, 400K drives for a year or two. WHAT DO YOU MEAN, NO COLOR? Just that. Quickdraw has a tiny little hook in it for drawing on multiple bit-planes, and this might be of some use in preparing bit-maps for displaying multiple colors on a color printer. But that's it. The Mac is steeped in software concepts developed solely for high resolution black-and-white displays. Nobody has shown that color is useful for Mac-type applications, and high resolution color monitors are extremely expensive. ($600 for RGBI, MUCH more if you want grey scale.) Color is superb for games and for pictures, but it requires a vast ammount of RAM, computational power, custom display chips, and expensive monitors. In ten years, everyone'll have a color display, but right now, for a software- intensive, cheap, personal computer, black & white is the way to go. RUMORS, RUMORS, RUMORS Careful inspection of the "Inside Macintosh" documents yields some titilating odds & ends. On page 30 of the "User Interface Guidelines", under Desk Accessories, a list of standard desk accessories are given, including: "Telegram Form and In-Box (AppleGram)". I think that this is the tip of the AppleNet iceberg. In the "Application" section, a printout of some sample application programs are given. These printouts are probably from an Apple laser printer. One tell-tale mark of a networked laser printer is the print-job sepereator, a visual mark printed on the paper to indicate the start of a new print-job. The grey bar running down the right hand side of the first page of each of the listings serves this purpose. (Goodness, it also looks like QuickDraw was used to scan-convert for the laser printer page. My, but a general- purpose set of bit-map routines is useful!) Although there is absolutely no economic reason for Apple to make a LCD display for the Mac, it's not much harder than the one they're trying to make for the Apple IIc. The Apple IIc has two serial ports and a mouse port, just like the Mac. At least the company is being consistent in it's belief that the user really doesn't need expansion slots. WHAT DOES IT ALL MEAN? 1) The Mac's a pretty nifty machine. 2) Apple will make a great deal of money. 3) The guy on the wall-screen in the Mac commercial is more likely to be Mr. Jobs than any of his competitors. After all, the Mac screen is black & white, while the IBM PC is color. . . . Message 14 -- ************************ Return-Path: <PATTERMANN@SUMEX-AIM.ARPA> Received: from SUMEX-AIM.ARPA by UTEXAS-20.ARPA with TCP; Thu 3 May 84 12:31:06-CDT Return-Path: <palevich%atari.csnet@csnet-relay.arpa> Received: from csnet-relay by SUMEX-AIM.ARPA with TCP; Wed 2 May 84 18:01:50-PDT Received: From atari.csnet by csnet-relay; 2 May 84 20:41 EDT Date: Wed, 2 May 84 15:18 PST From: John Palevich <palevich%atari.csnet@csnet-relay.arpa> To: info-mac@sumex-aim.arpa Subject: How to transfer a Mac file? ReSent-date: Thu 3 May 84 09:12:08-PDT ReSent-From: Ed Pattermann <PATTERMANN@SUMEX-AIM.ARPA> ReSent-To: info-mac: ; Is there a standard format for transmiting the whole of a Macintosh file, both the data and the resource parts? Is the only format sort of buried inside MacTerm? I'd sure like to be able to transfer files and programes over the phones to other computers. . . . On a related note, anybody hear of a Macintosh user's group getting started? Message 15 -- ************************ Return-Path: <PATTERMANN@SUMEX-AIM.ARPA> Received: from SUMEX-AIM.ARPA by UTEXAS-20.ARPA with TCP; Thu 3 May 84 12:56:38-CDT Return-Path: <POURNE@MIT-MC> Received: from MIT-MC by SUMEX-AIM.ARPA with TCP; Thu 3 May 84 00:55:50-PDT Date: 3 May 1984 03:54-EDT From: Jerry E. Pournelle <POURNE @ MIT-MC> Subject: deadlines To: INFO-MAC @ MIT-MC ReSent-date: Thu 3 May 84 09:12:14-PDT ReSent-From: Ed Pattermann <PATTERMANN@SUMEX-AIM.ARPA> ReSent-To: info-mac: ; I have a column deadline first part of next week. Would appreciate information/comments on: 1. I have sources say that the reson you cannot get your Macdisk fixed if it dies (and many do) is that the replacement drives are being kludged by hackers to make second drives for their systems, and are being bought out the back doors of stores. May not be true, but I can certainly get goot source materials. 2. Is there ANY available applications software for Macintosh as of this date? (Not what will be out next week...) 3. A correspondent tells of buying a Mac which died within an hour. The store quoted a four week time to fix; Apple policy forbids supplying him with one from pipeline and swapping live for dead unit; calls to Apple produced sympathy from those taking call, but return call saying that was indeed policy. (Reader got refund and bought Kaypro.) Is this indeed Apple policy, and if so, why? I have a Mac. It's much fun. I agree that many people who would never play with computers find it fascinating. Without software, languages, or assembler, it m ay be a bit costly for some of us. Message 16 -- ************************ Return-Path: <PATTERMANN@SUMEX-AIM.ARPA> Received: from SUMEX-AIM.ARPA by UTEXAS-20.ARPA with TCP; Thu 3 May 84 13:15:13-CDT Return-Path: <dba@cmu-cs-g.arpa> Received: from CMU-CS-G.ARPA by SUMEX-AIM.ARPA with TCP; Thu 3 May 84 05:50:50-PDT Date: 3 May 1984 08:41:15-EDT From: David.Anderson at CMU-CS-G Subject: What's in the manual? ReSent-date: Thu 3 May 84 09:12:16-PDT ReSent-From: Ed Pattermann <PATTERMANN@SUMEX-AIM.ARPA> ReSent-To: info-mac: ; However, if you did read the manual you might find this under the entry for the command key under "Other Special Keys" on page 32: Enter and leave FatBits by clicking in the drawing window with the pencil. On the matter of locking files, and what sort of protection to expect, the Macintosh Owner's Manual states on page 105 that The Locked check box allows you to lock a document or application. When the Locked box is checked, that document or application can't be disposed of or replaced (either by saving or copying from another disk). It can be moved, its comment box can be edited, and it can be duplicated. So the behavior mentioned previously on this list should be treated as a BUG. Message 17 -- ************************ Return-Path: <PATTERMANN@SUMEX-AIM.ARPA> Received: from SUMEX-AIM.ARPA by UTEXAS-20.ARPA with TCP; Thu 3 May 84 13:35:45-CDT Return-Path: <INTMET@BBNA.ARPA> Received: from BBNA.ARPA by SUMEX-AIM.ARPA with TCP; Thu 3 May 84 07:14:34-PDT Date: Thu 3 May 84 10:12:41-EDT From: INTMET@BBNA.ARPA Subject: MacForth Users Group. To: info-mac@SUMEX-AIM.ARPA ReSent-date: Thu 3 May 84 09:12:23-PDT ReSent-From: Ed Pattermann <PATTERMANN@SUMEX-AIM.ARPA> ReSent-To: info-mac: ; If those people that have aquired MacForth send me their net mail address I will gather a list of MacForth users and send it to everybody on said list, creating a kind of broadcast n way mailing list. Sad to say I don't have the resources to manage a centralized list. I recieved some bug fixes from Creative solutions today. ben hyde ------- Message 18 -- ************************ Return-Path: <PATTERMANN@SUMEX-AIM.ARPA> Received: from SUMEX-AIM.ARPA by UTEXAS-20.ARPA with TCP; Thu 3 May 84 18:17:41-CDT Return-Path: <REICH@NYU-ACF1.ARPA> Received: from NYU-ACF1.ARPA by SUMEX-AIM.ARPA with TCP; Thu 3 May 84 15:35:21-PDT Date: 3 May 84 18:34 EDT From: Richard Reich <REICH@NYU-ACF1.ARPA> To: INFO-MAC@SUMEX-AIM.ARPA Subject: Toolbox equates for peons Message-ID: <124660CC3.05430040.1984@ACF1.NYU-ACF1.ARPA> ReSent-date: Thu 3 May 84 15:37:38-PDT ReSent-From: Ed Pattermann <PATTERMANN@SUMEX-AIM.ARPA> ReSent-To: info-mac: ; Will some certified developer please place the text of the Toolbox and QD equates files on a host allowing Anonymous FTP's?? I expect I am not the only peon, rejected for CD status by Apple, who believes that they can perhaps actually write a program for the Mac despite Apple's opinion. If the material I'm requesting is protected by copyright or non-disclosure please let me know (and we can work out an accident). Thanks. -r ------- Message 19 -- ************************ Return-Path: <PATTERMANN@SUMEX-AIM.ARPA> Received: from SUMEX-AIM.ARPA by UTEXAS-20.ARPA with TCP; Fri 4 May 84 11:47:10-CDT Return-Path: <ERIK@SRI-AI.ARPA> Received: from SRI-AI.ARPA by SUMEX-AIM.ARPA with TCP; Thu 3 May 84 20:19:59-PDT Date: Thu 3 May 84 18:52:41-PDT From: ERIK@SRI-AI.ARPA Subject: Accurate Info for your column To: Pourne@MIT-MC.ARPA cc: Info-Mac@SUMEX-AIM.ARPA ReSent-date: Fri 4 May 84 09:15:51-PDT ReSent-From: Ed Pattermann <PATTERMANN@SUMEX-AIM.ARPA> ReSent-To: info-mac: ; Dear Jerry, Here's some accurate information for next week's column. 1. The external 3 1/2 " drive for Macintosh will be available for sale at all dealers next week. The Sony drives are extremely reliable, and failure rates are very low. 2. Currently there are 9 applications out for Macintosh: MacWrite, MacPaint from Apple; MultiPlan and Basic from Microsoft; MAGICPhone by Artsci; ClickArt by T/Maker Graphics; MacForth by Creative Solutions; Transylvania by Penguin Software; and MegaMerge by MegaHaus. In May developers expect to ship ten applications (including Microsoft Chart), and in June there should be at least 35 additional applications (eg. Macintosh Pascal). 3. All Apple products are under 90 day warranty. All Dealers are required to stock spare parts for our computers. The Macintosh reliability rate has been extremely high. I'm surprised to hear that this particular person has had trouble with servicing his Macintosh. If he would call Apple (Donna Dubinsky, Manager of Distribution) in Cupertino I'm sure she would be more than happy to help solve the problem. Hope you continue to enjoy your Macintosh. Barbara Koalkin Macintosh Product Marketing Manager ------- Message 20 -- ************************ Return-Path: <PATTERMANN@SUMEX-AIM.ARPA> Received: from SUMEX-AIM.ARPA by UTEXAS-20.ARPA with TCP; Fri 4 May 84 12:00:37-CDT Return-Path: <DBECK@SRI-KL.ARPA> Received: from SRI-KL.ARPA by SUMEX-AIM.ARPA with TCP; Fri 4 May 84 07:20:23-PDT Date: Fri 4 May 84 07:23:33-PDT From: DBECK@SRI-KL.ARPA Subject: support To: info-mac@SUMEX-AIM.ARPA ReSent-date: Fri 4 May 84 09:16:22-PDT ReSent-From: Ed Pattermann <PATTERMANN@SUMEX-AIM.ARPA> ReSent-To: info-mac: ; Those waiting for third party support for the Mac, and those contemplatin{_g purchase, should consider the letter sent by Macworld to "Charter Subscribers". It says in part, "our estimate is that the majority of products for the Macintosh will not be available until later in the year." In other words don't hold your breath (support) and take your time (purchase). Interpolation is my own. Doug Beck dbeck@sri-kl ------- Message 21 -- ************************ Return-Path: <PATTERMANN@SUMEX-AIM.ARPA> Received: from SUMEX-AIM.ARPA by UTEXAS-20.ARPA with TCP; Fri 4 May 84 12:20:15-CDT Return-Path: <FISCHER@RUTGERS.ARPA> Received: from RUTGERS.ARPA by SUMEX-AIM.ARPA with TCP; Thu 3 May 84 13:41:10-PDT Date: 3 May 84 16:41:36 EDT From: Ron <FISCHER@RUTGERS.ARPA> Subject: MacAssembler requires * 2 * Macs!? To: info-mac@SUMEX-AIM.ARPA ReSent-date: Fri 4 May 84 09:18:17-PDT ReSent-From: Ed Pattermann <PATTERMANN@SUMEX-AIM.ARPA> ReSent-To: info-mac: ; Here at Rutgers we're interested in using Macs to teach intro computing courses. The current versions of these courses use Pascal and Macro-11 assembler. Now the problem... We talked to an Apple person and they informed us that MacAssembler requries 2 Macintoshes, one having the development environment, the other, a small debugging monitor in its kernel. The Macs are connected by their printer ports. A note in the conversation that seemed even more ominous was the representative saying that Apple does not plan to produce standalone development environments for the Macintosh. But what about the "C" that has been announced for end of summer? Perhaps it isn't for real? BTW, AppleNet has been cancelled whilst IBM finalizes its own networking plans. Recall that Apple wishes to be compatible with this standard. (ron) ------- Message 22 -- ************************ Return-Path: <PATTERMANN@SUMEX-AIM.ARPA> Received: from SUMEX-AIM.ARPA by UTEXAS-20.ARPA with TCP; Fri 4 May 84 15:50:44-CDT Return-Path: <cak@Purdue.ARPA> Received: from merlin.ARPA (PURDUE-MERLIN.ARPA.#Internet) by SUMEX-AIM.ARPA with TCP; Fri 4 May 84 09:52:18-PDT From: Christopher A Kent <cak@Purdue.ARPA> Message-Id: <8405041652.AA14632@merlin.ARPA> Received: by merlin.ARPA; Fri, 4 May 84 11:52:11 est Date: 4 May 1984 1152-EST (Friday) To: Ron <FISCHER@RUTGERS.ARPA> Cc: info-mac@SUMEX-AIM.ARPA Subject: Re: MacAssembler requires * 2 * Macs!? In-Reply-To: Your message of 3 May 84 16:41:36 EDT. <8405041648.AA01534> ReSent-date: Fri 4 May 84 13:08:23-PDT ReSent-From: Ed Pattermann <PATTERMANN@SUMEX-AIM.ARPA> ReSent-To: info-mac: ; I thought the C environment was going to come from Microsoft, not Apple, so of course "they" aren't going to produce a standalong development environment for the Mac. Is Microsoft listening? Would someone from there care to comment? chris ---------- Message 23 -- ************************ Return-Path: <PATTERMANN@SUMEX-AIM.ARPA> Received: from SUMEX-AIM.ARPA by UTEXAS-20.ARPA with TCP; Fri 4 May 84 17:30:26-CDT Return-Path: <M.CHAD@SU-SIERRA.ARPA> Received: from SU-SIERRA.ARPA by SUMEX-AIM.ARPA with TCP; Fri 4 May 84 14:07:21-PDT Date: Fri 4 May 84 14:03:27-PDT From: Chad Leland Mitchell <M.CHAD@SU-SIERRA.ARPA> Subject: standalone To: info-mac@SUMEX-AIM.ARPA ReSent-date: Fri 4 May 84 14:40:22-PDT ReSent-From: Ed Pattermann <PATTERMANN@SUMEX-AIM.ARPA> ReSent-To: info-mac: ; It depends what you call stand alone. Apple has told me that they will have a compiled Pascal by the end of the year. The problem with both that and the assembler is that to run the fancy debugger you need two Macs. (You can certainly develop, compile, and test with just one.) Since the Mac has no hardware memory management, a program under test could easily write into a debugger's data space and in any case it would have to somehow share the screen and limited RAM with the debugger. The interpreted Pascal and Basic avoid this problem by limiting what can be done, but for the assembler and compiled Pascal you would certainly want control of the full screen, menus, etc. The fancy debugger thus winds up on a second machine and built into the ROM is some kind of manager which allows the program being debugged to have the machine only sacrificing a tiny amount of RAM for some debugger state. I am sure that there will be languages with "stand alone" debuggers, but they will not be as nice as what can be done with two machines. Maybe when we have 512 you could have a debugger which would have its own copy of the entire screen and you could toggle between the application screen and the development screen. For Jerry: I know several students who feel that the Mac already has the programs they need. With just MacWrite and MacPaint they consider it the ideal homework machine. What other serious things could they need? They suggest maybe a spread sheet program (MultiPlan is out and the new version seems to work) and a few games (a few are already announced). They seem to feel that they can do everything on a Mac right now that they would be doing on any other machine and do it better. They would like to see sub/super scripts and longer files in MacWrite but a new release of it has been announced. They claim that they would rather segment papers for the time being on the Mac than deal with any of the ^X^Y^S.C.L style word processors they have used before, but they they are not hackers. They are of course hoping for even better software and sooner or later they will get it, but they are already satisfied and find the Mac a useful and important tool. About Color: There are two DIFFERENT color mechanisms according to my copy of Inside Macintosh. One is the one mentioned in a previous message which tells which of 32 bit planes in which to draw and is called by printing software for a color printer or other color imaging software. The other color mechanism is accessed by routines that set the foreground and background color of the pen. Thus you CAN set it to red and draw a box and then to blue and draw a circle or some text. It is very clear that this second mechanism is for the screen so I think that we may very well see color eventually. They even have predefined constants for colors red, green, blue, cyan, magenta, yellow and of course black and white and carefully specify that if you write to the screen in any color other than white it uses black instead for present. Chad ------- Message 24 -- ************************ Return-Path: <PATTERMANN@SUMEX-AIM.ARPA> Received: from SUMEX-AIM.ARPA by UTEXAS-20.ARPA with TCP; Fri 4 May 84 18:23:26-CDT Return-Path: <kalagher@mitre> Received: from mitre by SUMEX-AIM.ARPA with TCP; Fri 4 May 84 15:24:52-PDT Date: 4 May 1984 18:17:57 EDT (Friday) From: Dick Kalagher <kalagher@mitre> Subject: Re: MacAssembler requires * 2 * Macs!? In-Reply-to: Your message of 3 May 84 16:41:36 EDT To: Ron <FISCHER@RUTGERS.ARPA> Cc: info-mac at sumex-aim, erik at sri-ai, kalagher@mitre ReSent-date: Fri 4 May 84 15:46:16-PDT ReSent-From: Ed Pattermann <PATTERMANN@SUMEX-AIM.ARPA> ReSent-To: info-mac: ; I remember reading someplace that one of the major reasons Texas Instruments failed with the 99/4 was that they "correctly concluded that the hobbiests and hackers were a small part of their customer base, but incorrectly concluded that therefore they were unimportant" Perhaps Apple can survive with software from the big houses. But don't forget, Apple, that the hackers (I use this term in the positive sense) are the ones giving advice to others on what computer to buy. They also run users groups, write books and magazines articles, and develop much public domain software for free. Don't forget that it was software availability that made the Apple II so popular-- and it wasn't 1-2-3 and Wordstar. So what am I leading up to? Well, I love my Mac and I can't wait to program it. First I find out that not only is MS-BASIC a dog, but I can only use 10-15 percent of the memory. Than I hear that PASCAL is really only meant for learning and is definately not for software development. FORTH might be OK once the bugs are out, but you need a licence to distribute software. So I rest my hopes on the assembler. But now I hear it will take TWO MACS!! Come on Apple. You designed a great machine. Don't blow it by playing games with your best free advertizing media. I'm sure if you try you can develop an assembler (or PASCAL compiler) that can run on one MAC. Dick Kalagher Message 25 -- ************************ Return-Path: <PATTERMANN@SUMEX-AIM.ARPA> Received: from SUMEX-AIM.ARPA by UTEXAS-20.ARPA with TCP; Fri 4 May 84 23:32:38-CDT Return-Path: <TSDTEST%VPIVAX3.BITNET@Berkeley> Received: from UCB-VAX.ARPA by SUMEX-AIM.ARPA with TCP; Fri 4 May 84 17:29:55-PDT Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.24/4.27) id AA14153; Fri, 4 May 84 01:25:58 pdt Received: by ucbjade.CC.Berkeley.ARPA (4.14.3/4.16) id AA21666; Fri, 4 May 84 01:26:03 pdt Message-Id: <8405040826.AA21666@ucbjade.CC.Berkeley.ARPA> Date: Fri, 4-MAY-1984 04:14 EDT From: Ronald A. Jarrell <TSDTEST%VPIVAX3.BITNET@Berkeley> To: info-mac@sumex-aim.ARPA Reply-To: TSDTEST%VPIVAX3.BITNET@BERKELEY.ARPA Subject: fixing a trashed disk ReSent-date: Fri 4 May 84 20:49:05-PDT ReSent-From: Ed Pattermann <PATTERMANN@SUMEX-AIM.ARPA> ReSent-To: info-mac: ; I had a problem with a destroyed disk too. At 1am one morning I was playing with MacPaint, and decided to center the simple screen drawing I had made on the page. I moved it with the show page option. Of course, the mac then had to create a disk copy so it could page section in and out now. Well, there wasn't enough room on my paint disk to do that, which it promptly warned me of with the "Running out of room... OK" box. Sure, I said ok, then saved. Disk overflowed. No sweat. Start the cycle over again.. "Running out of room...OK" "Yes, save on *another* disk.." (it saved great). MacPaint then quietly stopped. I wanted to print it, so I checked my file size. Yep, there was enough room to put the painting back on the macpaint disk and print it. A few K left over too. I used the finder to copy it. I then got into Macpaint. First thing it did was tell me the disk was "Running out of room... OK"... Then promptly destroyed my disk with whatever it did upon terminating. Got ID 13's when booting, and 2's when reading after booting of another disk. Luckily after the 4 attempt I remembered Bruce's advice about using Option-Command. (Course, I didn't remember which keys they were, just had a hunch from the way the mac philosphy seemed to be going..) I tried it, and got EVERYTHING back, minus the folders.. No Biggie, folders are easy to make, especially since the Empty folder was there. I also lost my Info boxes, which was slightly less nice, but recoverable with a little searching of files. The only bad point about this (besides the fact it shouldn't had happened) is that this is NOT DOCUMENTED! If I wasn't reading this list, I would have basically lost a disk until I could find a magnet to unformat it. It would have been nice to find this note on the same sheet as the improved copying information was found! The systems user friendly.. the documentation isn't.. -Ron Message 26 -- ************************ Return-Path: <PATTERMANN@SUMEX-AIM.ARPA> Received: from SUMEX-AIM.ARPA by UTEXAS-20.ARPA with TCP; Fri 4 May 84 23:51:39-CDT Return-Path: <TSDTEST%VPIVAX3.BITNET@Berkeley> Received: from UCB-VAX.ARPA by SUMEX-AIM.ARPA with TCP; Fri 4 May 84 19:40:21-PDT Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.24/4.27) id AA14014; Fri, 4 May 84 01:15:38 pdt Received: by ucbjade.CC.Berkeley.ARPA (4.14.3/4.16) id AA21590; Fri, 4 May 84 01:15:53 pdt Message-Id: <8405040815.AA21590@ucbjade.CC.Berkeley.ARPA> Date: Fri, 4-MAY-1984 04:08 EDT From: Ronald A. Jarrell <TSDTEST%VPIVAX3.BITNET@Berkeley> To: info-mac@sumex-aim.ARPA Reply-To: TSDTEST%VPIVAX3.BITNET@BERKELEY.ARPA Subject: MacWrite "Feature" ReSent-date: Fri 4 May 84 20:49:08-PDT ReSent-From: Ed Pattermann <PATTERMANN@SUMEX-AIM.ARPA> ReSent-To: info-mac: ; Interesting little thing popped up while I was using MacWrite. I had a 5+ page document I had written to experiment with MacWrite. I added a header and a footer to the document, and printed it out. I went through each of the modes to check the differences. Draft mode is nice and fast, except for one minor problem.. With the header option on, the Mac writes them as seperate files. This is natural since it's 3 different windows and not just a "snapshot" of the file as in other modes. The Mac will meriily whip off a page, print the footer (in this case a page number and string of text) do a "formsuck", print any header text at the top of the page it just printed, line feed, think a moment, go back and print things like date time, formfeed, and start the cycle again for the next page... I think a little optimization is in order. I tried rearranging the windows to put header on top, but the Mac has it's own internal order it is concerned with. Amazing how much time 5 formsucks and 5 formfeeds add to the print time.. I was impressed with the Imagewriters ability to actually *do* a formsuck. Most single tractor printers can't easily. According to the manual there is a wealth of things the beastie can do. It also seems too have prodigious print buffer. -Ron Message 27 -- ************************ Return-Path: <PATTERMANN@SUMEX-AIM.ARPA> Received: from SUMEX-AIM.ARPA by UTEXAS-20.ARPA with TCP; Sat 5 May 84 00:06:27-CDT Return-Path: <monta@cmu-cs-g.arpa> Received: from CMU-CS-G.ARPA by SUMEX-AIM.ARPA with TCP; Fri 4 May 84 21:01:12-PDT Date: Friday, 4 May 1984 23:52:11 EDT From: Peter.Monta@cmu-cs-g.arpa To: info-mac@sumex-aim.arpa Subject: Quickdraw bug? Message-ID: <1984.5.5.3.40.28.Peter.Monta@cmu-cs-g.arpa> ReSent-date: Fri 4 May 84 21:18:35-PDT ReSent-From: Ed Pattermann <PATTERMANN@SUMEX-AIM.ARPA> ReSent-To: info-mac: ; There seems to be some sort of asymmetry in the ellipse drawer. From within MacPaint, set the black pattern and toggle into FatBits mode. Draw 3x5 pixel and 5x3 pixel filled ellipses. One will be a rectangle and the other will have corners chopped. The effect is most noticeable when drawing long narrow (3 pixels) horizontal ellipses. Pete (monta@cmu-cs-g) Message 28 -- ************************ Return-Path: <PATTERMANN@SUMEX-AIM.ARPA> Received: from SUMEX-AIM.ARPA by UTEXAS-20.ARPA with TCP; Mon 7 May 84 19:39:39-CDT Return-Path: <wrs@cmu-cs-spice.arpa> Received: from CMU-CS-SPICE.ARPA by SUMEX-AIM.ARPA with TCP; Sat 5 May 84 15:45:01-PDT Date: 5 May 1984 18:35:21-EDT From: Walter.Smith at CMU-CS-SPICE Subject: Re: user's groups ReSent-date: Mon 7 May 84 16:58:23-PDT ReSent-From: Ed Pattermann <PATTERMANN@SUMEX-AIM.ARPA> ReSent-To: info-mac: ; CMU now has a Mac user's group. Here's a post made on our local Macintosh bboard: If any of you out there need support for your Macs, the CMU Macintosh Users Group can help. We are an established group (well, three months at least) and will be gettting all sorts of goodies (software, mainly) starting next semester. Our next meeting is next semester. Write for details. Scott MacPherson (sm1p@cmu-cc-td) Anybody else have a user's group? Maybe we can exchange newsletters or something... - Walter Smith (wrs@cmu-cs-spice.arpa) Message 29 -- ************************ Return-Path: <PATTERMANN@SUMEX-AIM.ARPA> Received: from SUMEX-AIM.ARPA by UTEXAS-20.ARPA with TCP; Mon 7 May 84 19:51:09-CDT Return-Path: <JSMCCLEES@BBNG.ARPA> Received: from BBNG.ARPA by SUMEX-AIM.ARPA with TCP; Sat 5 May 84 18:32:01-PDT Date: Sat, 5 May 1984 21:30 EDT Message-ID: <JSMCCLEES.12013027443.BABYL@BBNG> From: JSMCCLEES@BBNG.ARPA To: info-mac@SUMEX-AIM.ARPA cc: klotz@BBNG.ARPA, jsmcclees@BBNG.ARPA Subject: macpaint font bug, mac user group ReSent-date: Mon 7 May 84 16:58:25-PDT ReSent-From: Ed Pattermann <PATTERMANN@SUMEX-AIM.ARPA> ReSent-To: info-mac: ; MacPaint has trouble handling text running off the right side of the screen. For instance, select 18 pt. Athens underline & outline; now hold down shift-option-' (upper left key). Those adorable pawprints lead to a ferocious system error (ID=28). The Boston Computer Society has a new Mac user group. It meets on the second Wednesday of each month. Upcoming mtg. May 9 at Mass. College of Art, Tower Auditorium, 721 Huntington Ave., Boston (2 blocks past MFA). Time: 7:30 pm. Mark Eckenwiler (jsmcclees@bbng) Message 30 -- ************************ Return-Path: <PATTERMANN@SUMEX-AIM.ARPA> Received: from SUMEX-AIM.ARPA by UTEXAS-20.ARPA with TCP; Mon 7 May 84 19:59:11-CDT Return-Path: <TIM@MIT-MC> Received: from MIT-MC by SUMEX-AIM.ARPA with TCP; Fri 4 May 84 22:21:42-PDT Date: 5 May 1984 01:20-EDT From: Tim McNerney <TIM @ MIT-MC> Subject: Teaching assembly language programming, Mac style To: FISCHER @ RUTGERS cc: TIM @ MIT-MC, info-mac @ SUMEX-AIM In-reply-to: Msg of 3 May 84 16:41:36 EDT from Ron <FISCHER at RUTGERS.ARPA> ReSent-date: Mon 7 May 84 16:58:21-PDT ReSent-From: Ed Pattermann <PATTERMANN@SUMEX-AIM.ARPA> ReSent-To: info-mac: ; While the two Mac arrangement will be indispensible to DEVELOPERS who want full control of the screen for their software products, for TEACHING purposes, the MacAssembler is probably not the right thing. When programming in assembly language it is so easy to screw oneself that for students first learning about how machines work inside, a constrained environment like MacPascal is much preferable. It looks like there is a need for a EDUCATIONAL PRODUCT here folks! How about a 68000 assembler and a very "careful" stepper/debugger that provides extensive error checking and displays the state of the registers and relevant segments of memory while the program is running? How about providing a "dial" that you can turn to slow your program down to a comfortable crawl if things are happening too quickly? Remember the days when computers had blinking lights, and you could tell what your program was doing just by gazing at the dancing patterns, or by sticking an FM radio next to the processor and listening to the buzzing and humming? Well, times haven't changed that much, we just have "bitmapped displays" instead of "front panels" and "sound generator chips" instead of transistor radios, that's all... Tim McNerney <TIM at MIT-MC.ARPA> Message 31 -- ************************ Return-Path: <PATTERMANN@SUMEX-AIM.ARPA> Received: from SUMEX-AIM.ARPA by UTEXAS-20.ARPA with TCP; Mon 7 May 84 20:03:40-CDT Return-Path: <bdl@cmu-cs-ius.arpa> Received: from CMU-CS-IUS.ARPA by SUMEX-AIM.ARPA with TCP; Sun 6 May 84 12:08:07-PDT Date: 6 May 1984 15:03:43-EDT From: Bruce.Lucas at CMU-CS-IUS Subject: bugs ReSent-date: Mon 7 May 84 16:58:27-PDT ReSent-From: Ed Pattermann <PATTERMANN@SUMEX-AIM.ARPA> ReSent-To: info-mac: ; The Quickdraw bug in ellipses you mentioned isn't the only one: long skinny ellipses have points missing. Also, the 45-degree portions of circles are like x x x x x rather than x x x x which some might consider a bug, others a feature. Is there any way to print the Notepad? I haven't found one (short of putting it in a MacWrite document...) Sure would be nice, e.g. so I don't have to lug my Mac with me to the grocery store. Should use draft mode. Also, selection extension (with shift-click) works differently in MacWrite and Notepad; in particular shift-clicks before the beginning of the original selection point behave differently. Consider a line a....b....c. Click at b, shift-click c, selection is from b to c. Now shift-click a; in MacWrite, selection is from a to b; in Notepad from a to c. Tsk-tsk. Message 32 -- ************************ Return-Path: <PATTERMANN@SUMEX-AIM.ARPA> Received: from SUMEX-AIM.ARPA by UTEXAS-20.ARPA with TCP; Mon 7 May 84 20:15:12-CDT Return-Path: <ERIK@SRI-AI.ARPA> Received: from SRI-AI.ARPA by SUMEX-AIM.ARPA with TCP; Sun 6 May 84 15:42:13-PDT Date: Sun 6 May 84 15:44:50-PDT From: ERIK@SRI-AI.ARPA Subject: This is not an Apple account To: info-mac@SUMEX-AIM.ARPA cc: Erik@SRI-AI.ARPA ReSent-date: Mon 7 May 84 16:58:32-PDT ReSent-From: Ed Pattermann <PATTERMANN@SUMEX-AIM.ARPA> ReSent-To: info-mac: ; Although I have on occasion answered questions about Mac and Apple, this is NOT an Apple mailbox. I'll take bug reports but can't answer any more questions. Mail of personal interest is always welcome, however. Thanks Bruce (Erik@SRI-AI) ------- Message 33 -- ************************ Return-Path: <PATTERMANN@SUMEX-AIM.ARPA> Received: from SUMEX-AIM.ARPA by UTEXAS-20.ARPA with TCP; Mon 7 May 84 20:28:10-CDT Return-Path: <bdl@cmu-cs-ius.arpa> Received: from CMU-CS-IUS.ARPA by SUMEX-AIM.ARPA with TCP; Mon 7 May 84 12:22:38-PDT Date: 7 May 1984 13:29:59-EDT From: Bruce.Lucas at CMU-CS-IUS Subject: Finder bug ReSent-date: Mon 7 May 84 16:58:34-PDT ReSent-From: Ed Pattermann <PATTERMANN@SUMEX-AIM.ARPA> ReSent-To: info-mac: ; After the Finder repairs your disk, it is confused about where the icons go in the disk window. In particular, if you select "clean up" the icons get bumped up to the very top of the window, instead of leaving a little border. Rebooting takes care of the problem. This occurred under the following circumstances: after working with the Mac for a while I began to notice that the Finder was taking a LONG time to start up after an application quit (it seemed to be going back and forth between two tracks several times), and that MacWrite documents (both existing and newly created ones) were being shown with a plain document icon (not the document with lines of text). Then after doing some folder rearranging, the Finder said there wasn't enough room on the disk to store the changes (even though the disk window said 32k). I rebooted (I think), and the Finder repaired the disk, which cured everything--except the icons were put in the wrong place by "clean up", and rebooting again solved that. Message 34 -- ************************ Return-Path: <PATTERMANN@SUMEX-AIM.ARPA> Received: from SUMEX-AIM.ARPA by UTEXAS-20.ARPA with TCP; Mon 7 May 84 20:40:12-CDT Return-Path: <SIEGMAN@SU-SIERRA.ARPA> Received: from SU-SIERRA.ARPA by SUMEX-AIM.ARPA with TCP; Mon 7 May 84 12:29:47-PDT Date: Sun 6 May 84 22:37:46-PDT From: Tony Siegman <SIEGMAN@SU-SIERRA.ARPA> Subject: Query Re RS-232 Interface and Handshaking To: info-mac@SUMEX-AIM.ARPA ReSent-date: Mon 7 May 84 16:58:38-PDT ReSent-From: Ed Pattermann <PATTERMANN@SUMEX-AIM.ARPA> ReSent-To: info-mac: ; I want to drive a Hewlett-Packard 7470A Graphics Plotter that has an RS-232 interface from the Mac running either Microsoft Basic or MacBasic, and would appreciate information on what handshaking support is available from the RS-232 port on the Mac when using either of these programs. The hp 7470A thinks it's a terminal, and I appreciate that a null modem cable which interchanges pins 2 and 3 between Mac and the plotter will probably be required. However, the plotter can then be set to do either hardwire handshaking via pin 20 (DTR), if the computer it's talking to monitors that signal; or Xon-Xoff handshaking. After a certain amount of grief in attempting to interface this plotter to a TRS-80 Model 100, I found that the Model 100 does not monitor the hardwire handshake when running Basic (though you can PEEK at that pin and monitor it yourself, if you want to); but the Xon-Xoff protocol does work automatically, if you OPEN the comm line right. Can anyone tell me what I'll encounter with the Mac? ------- Message 35 -- ************************ Return-Path: <PATTERMANN@SUMEX-AIM.ARPA> Received: from SUMEX-AIM.ARPA by UTEXAS-20.ARPA with TCP; Mon 7 May 84 20:51:44-CDT Return-Path: <FURUTA@WASHINGTON.ARPA> Received: from WASHINGTON.ARPA by SUMEX-AIM.ARPA with TCP; Mon 7 May 84 12:29:49-PDT Date: Mon 7 May 84 11:53:03-PDT From: Richard Furuta <Furuta@WASHINGTON.ARPA> Subject: What is the University of California's Mac status? To: info-mac@SUMEX-AIM.ARPA cc: Furuta@WASHINGTON.ARPA ReSent-date: Mon 7 May 84 16:58:40-PDT ReSent-From: Ed Pattermann <PATTERMANN@SUMEX-AIM.ARPA> ReSent-To: info-mac: ; I've heard reports that the University of California was negotiating as a whole with Apple either for membership in the Apple Consortium or for some sort of discount on purchases of MacIntoshes. When I first heard this report, a month or two ago, the agreement was supposed to be "very close." However, I've not heard anything since then. If someone knows about the status of any U.C./Apple agreements, I'd appreciate it if they could contact me with the current information. Thanks very much. --Rick ------- Message 36 -- ************************ Return-Path: <PATTERMANN@SUMEX-AIM.ARPA> Received: from SUMEX-AIM.ARPA by UTEXAS-20.ARPA with TCP; Mon 7 May 84 21:04:12-CDT Return-Path: <TSDTEST%VPIVAX3.BITNET@Berkeley> Received: from UCB-VAX.ARPA by SUMEX-AIM.ARPA with TCP; Mon 7 May 84 13:24:22-PDT Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.24/4.27) id AA26187; Mon, 7 May 84 13:23:56 pdt Received: by ucbjade.CC.Berkeley.ARPA (4.14.3/4.16) id AA08872; Mon, 7 May 84 13:24:25 pdt Message-Id: <8405072024.AA08872@ucbjade.CC.Berkeley.ARPA> Date: Mon, 7-MAY-1984 16:21 EDT From: Ronald A. Jarrell <TSDTEST%VPIVAX3.BITNET@Berkeley> To: info-mac@sumex-aim.ARPA Reply-To: TSDTEST%VPIVAX3.BITNET@BERKELEY.ARPA Subject: Mac Hardware problem ReSent-date: Mon 7 May 84 16:58:44-PDT ReSent-From: Ed Pattermann <PATTERMANN@SUMEX-AIM.ARPA> ReSent-To: info-mac: ; A few Mac's seem to have been shipped witha logic problem.. Mine and at least one other from my dealer have to get a new board because the clock is running at half speed. 2 real seconds to a Mac second. -Ron Message 37 -- ************************ Return-Path: <PATTERMANN@SUMEX-AIM.ARPA> Received: from SUMEX-AIM.ARPA by UTEXAS-20.ARPA with TCP; Mon 7 May 84 21:17:45-CDT Return-Path: <shore@nrl-css.arpa> Received: from nrl-css.arpa by SUMEX-AIM.ARPA with TCP; Mon 7 May 84 15:07:46-PDT From: John Shore <shore@NRL-CSS> Date: Mon, 7 May 84 18:02:46 EDT To: info-mac at sumex-aim Subject: Req. translation of Lisa error message Cc: shore at NRL-CSS ReSent-date: Mon 7 May 84 16:58:46-PDT ReSent-From: Ed Pattermann <PATTERMANN@SUMEX-AIM.ARPA> ReSent-To: info-mac: ; I'm running 2.0 on a Lisa 2/5 and have suddenly started getting a rash of "...technical difficulties...system will restart" messages when opening up a document or starting a backup operation. In every case the message number is 1033/21/n, where n=2759360 when I'm opening a LisaTerminal, LisaWrite, or LisaCalc document. For other operations, n is some other large number (looks like a disk address?). The problem is intermittent. I called the Apple "support" hot line, only to be told that the error usually occurs when pasting from Term to Write -- I've encountered that bug, and it's not the cause of my current problem. The person at Apple claimed that the value for n probably came from a line number and that the numbers were *undocumented* -- no-one there could tell me what they meant. Ridiculous. Can anyone out there tell me what the numbers mean? I'm reluctant to just reinstall the system and repair the disk since the last two times I've done the repair the system trashed some crucial directory files and cost me several days work (Apple tells me that this problem is also known to occur but the they don't understand it yet!). js Message 38 -- ************************ Return-Path: <PATTERMANN@SUMEX-AIM.ARPA> Received: from SUMEX-AIM.ARPA by UTEXAS-20.ARPA with TCP; Tue 8 May 84 00:37:29-CDT Return-Path: <dlc@lanl> Received: from lanl by SUMEX-AIM.ARPA with TCP; Mon 7 May 84 20:47:15-PDT Date: 5 May 1984 23:36:26-MDT From: Dale Carstensen C-3 <dlc@lanl> Reply-to: dlc@lanl To: info-mac@lanl Subject: Mactep for 7 bit, even parity ReSent-date: Mon 7 May 84 21:32:26-PDT ReSent-From: Ed Pattermann <PATTERMANN@SUMEX-AIM.ARPA> ReSent-To: info-mac: ; About 10 years ago, the data communications people at the Los Alamos (then Scientific, now National) Laboratory decided to use parity on asynchronous lines, and even parity at that. It may have had to do with the default configuration of Texas Instruments "silent 700" terminals, or someone may have thought that bad lines could be determined by noticing high error rates (they never had time to seriously monitor lines no one was complaining about, because were complaining about so many other lines). But 7 bit, even parity, seems to be here to stay .. so ..Mactep does nothing about character length or parity in the "SCC," the Zilog or AMD 8530 chip in the Macintosh, and Mactep as sent over "info-mac" will not work on the Integrated Computer Network at the Los Alamos National Laboratory. I made some changes to Mactep so that it will work, and ran into enough problems that I think sharing the changes will save others a few hours, in the unlikely event their computer cares about parity. The main problem I had was guessing the bits to set in the 8530 write registers 3, 4, and 5. Particularly the D5 and D4 bits of WR4. One would think that the sync character length would make no difference when one is in asynchronous mode, but the changes didn't work until I set both of these bits, which is the code the table calls "external sync mode." It would have been so much easier if one could read these control registers, but I suppose it is already difficult to put the functions the 8530 has on a single chip. I also noticed that Motorola data sheets for the 68000 include assembler mnemonics for the instructions, but not the bit patterns in the instructions! I guess these sheets are still preliminary, or the Motorola technical writers could never figure out how to document the bit patterns. The 68120 has a very nice description, though. The mods I made follow -- one note is that I think odd parity, 7 bit characters can be selected by making the 77 in 9154 a 75. 9151 INPUT "7 bit even (Y/N)", BSC$ 9152 IF BSC$<>"Y" AND BSC$<>"y" THEN GOTO 9157 9153 R=3:X=&H41:WXCCB!=VARPTR(ML(0)):CALL WSCCB!(R,X) 9154 R=4:X=&H77:WSCCB!=VARPTR(ML(0)):CALL WSCCB!(R,X) 9155 R=5:X=&HAA:WSCCB!=VARPTR(ML(0)):CALL WSCCB!(R,X) 9156 GOTO 9160 9157 R=3:X=&HC1:WSCCB!=VARPTR(ML(0)):CALL WSCCB!(R,X) 9158 R=4:X=&H74:WSCCB!=VARPTR(ML(0)):CALL WSCCB!(R,X) 9159 R=5:X=&HEA:WSCCB!=VARPTR(ML(0)):CALL WSCCB!(R,X) Dale Carstensen (dlc@lanl-a, lanl-a!dlc, or denelcor!dcarst) Message 39 -- ************************ Return-Path: <PATTERMANN@SUMEX-AIM.ARPA> Received: from SUMEX-AIM.ARPA by UTEXAS-20.ARPA with TCP; Tue 8 May 84 00:56:31-CDT Return-Path: <TIM@MIT-MC> Received: from MIT-MC by SUMEX-AIM.ARPA with TCP; Mon 7 May 84 21:18:37-PDT Date: 7 May 1984 23:38-EDT From: Tim McNerney <TIM @ MIT-MC> Subject: This is not an Apple account To: ERIK @ SRI-AI cc: info-mac @ SUMEX-AIM ReSent-date: Mon 7 May 84 21:32:28-PDT ReSent-From: Ed Pattermann <PATTERMANN@SUMEX-AIM.ARPA> ReSent-To: info-mac: ; Thank you for the time you have spent answering questions, taking bug reports, and playing go-between for Apple, but since it not your job, there should really be an "official" Apple mailbox and a person whose job it is to monitor this list and pass on useful info when possible. I noticed that you often forward mail from Apple people. This service has also been much appreciated, but shouldn't there be a way for them to "speak for themselves"? I am not proposing that Apple start giving away lots of free technical advice, but this list has potential for providing a wonderful two-way exchange medium between Apple and a lot of very bright MacHackers ("hacker" in the positive sense, of course). Tim McNerney <TIM at MIT-MC.ARPA> Message 40 -- ************************ Return-Path: <PATTERMANN@SUMEX-AIM.ARPA> Received: from SUMEX-AIM.ARPA by UTEXAS-20.ARPA with TCP; Tue 8 May 84 01:39:19-CDT Return-Path: <FRANK@UTAH-20.ARPA> Received: from UTAH-20.ARPA by SUMEX-AIM.ARPA with TCP; Mon 7 May 84 19:30:19-PDT Date: Mon 7 May 84 20:30:05-MDT From: Randy Frank <FRANK@UTAH-20.ARPA> Subject: Interfacing other disk to a mac To: info-mac@SUMEX-AIM.ARPA ReSent-date: Mon 7 May 84 21:32:24-PDT ReSent-From: Ed Pattermann <PATTERMANN@SUMEX-AIM.ARPA> ReSent-To: info-mac: ; I just attended a Mac developer's seminar put on here by Andy Hertzfeld of Apple. I (think?) that these are being put on for the various consortium schools (has anyone else been to one?) It was very worthwhile, as much for "fokelore" as for hard information; if you're offered the chance to attend, I'd recommend it. Anyway, one of the most interesting aspects was gaining an appreciation of the entire driver/file system structure, and how the design makes interfacing other disks or file servers easy. Basically, as I understood it, both the generic disk driver and file system driver, in addition to their normal (Apple supplied) routines have "exits" built-in, at appropriate places, for other (non-Apple supplied) versions of the routines for non-Apple disks. It's designed in such a way that the disk can either be "dumb" (analogous to the existing floppy) where the disk can only return sectors, or "smart" in the sense that the disk is really a "file server" which is passed file names and logical read/write requests in which case the Mac doesn't do directory processing locally. Apple's assumption for "big" hard disks is that they will be of the "smart" variety. For the Sony floppy, the Mac caches the entire directory in memory, since the memory requirements are nominal (they stated about 300 bytes). However, for a large hard disk sitting on one of the 422 ports, the assumption is that it is of the "smart" variety which is passed logical requests so that the Mac doesn't need to process locally the directory information. What is interesting about this approach is that it would seem to make using "big" host computers as file servers a relatively easy task, although admittedly you'd be constrained by typical serial line rates of the host (e.g., 19.2 Kbit/sec) - the problem is the typical hosts - vaxen, 20s, etc. - not the Mac. However, for bulk file storage this may not be as serious a problem. What's fantastic about this approach is that above the level of the file system such a server looks identically to a local disk; files on the host server appear as icons, and the host appears as just another disk. The seminar didn't go into any more details. However, I intend to follow up this information and see where it leads. It was clear from the presentation that Apple gave a great deal of thought about handling a wide variety of disks and file servers cleanly and uniformly, and that someone interfacing a "brand x" disk is definitely not at a disadvantage to Apple in terms of interfacing cleanly and uniformly to the Mac os. ------- -------