alexis@ccnysci.UUCP (03/31/86)
This article has just expired; since it is still current I am reposting it...
BTW, is there anyone out there who is willing to route this to the ARPAnet and/
or COMPUSERVE (and the replies back to me)? I don't have access to either.
Alexis
-------------------------------------------------------------------------------
The Mac Expo has come and gone, and while the Mac Plus is a nice upgrade to the
current Mac, it's nothing like the machine I (or many other people) have hoped
for. I am creating this survey in the hope that if Apple has not finalized its
"TurboMac" (or "Open Mac", whatever), there may yet be some chance for us to
have some say in its design. At the very least, Apple will have some idea what
upgrades to build for THAT machine.
This survey is not addressed solely to Mac owners; If you own a Mac, I want to
hear from you, but if you don't, this is a good chance to tell the world why
you haven't bought a Mac yet, and what it would take to change your mind, so
for example:
1) Unix hackers would want an alternative (not "replacement") OS
2) Graphics people could ask for larger, High Resolution screens
3) etc... use your imagination!
After each question on the survey, I have given my own answer, as an example.
If you have a non-obvious reason for your non-obvious answer, please write it
in, don't just say "PAL compatible" (that one would take some explaining...)
In any event, don't flame me on the net; if you disagree, put it on the survey!
Please send all replies to ...ihnp4!physics!ccnysci!alexis
or USMail to:
Alexis Rosen
110 Riverside Drive
New York, N.Y. 10024
(212) 877-4854
A summary will be posted to the net, as well as to all the people in Apple who
might be interested in this...
Thanks for responding...
/Alexis
------------------------------------Cut Here------------------------------------
A Survey on Possible Future Macintosh Architectures February 9, 1986
Section 1 -- The Hardware
1) What main processor chip should be used in the next Macintosh? If *NOT*
the 68020, why not? Would you be willing to pay for a machine that cost
$300 more than otherwise so as to have the 68020? If the 68000 or 68010 is
used, should the 68020 be available as an Apple-made upgrade?
"I feel that the 68020 is the only way to go, even if it does cost $300 more
than a 68000 machine (the number is the most I can see a '20 raising the
price of the machine). People who don't need that power can get a Mac Plus.
If the '20 isn't the standard chip, it damn well ought to be available as an
option. The 68020 should run at 16.67 MHz; don't cripple it unnecessarily.
Furthermore, I don't know if the rumors about the '68040' are true, but if
they are, I'll bet Apple has the preliminary stats. If so, it would be nice
if Apple made the motherboard pin-compatible with it."
2) What coprocessors, if any, should be supported? Should they come with the
machine? If none, why?
"The 68881 *MUST* be available at purchase time or as a *USER UPGRADE*.
After all, it's just a single chip (Note that this assumes an open box...).
SANE calls must be re-written to support this chip, if present.
I would also like to see some hardware to assist in the graphics. For now,
maybe just a dedicated 68000 w/ROM, although other things would be okay too.
I don't know if Motorola makes a graphics chip, but if so, it would make
sense to use it. Either way, QUICKDRAW could be re-written, making the
change completely transparent to all software.
Also, while this is much further down the road, I think there is great
potential for a QUICKDRAW coprocessor. It should support the line-F traps
like 68xxx coprocessors are supposed to."
3) How much memory should be supported? How much standard?
"One megabyte in 256k chips, able to hold 4M in 1M chips- at least. 2-8M
would be better. Depending on the chip situation, the 256k's might be
unnecessary. The machine should support (addressing & ROMs) at least 16M,
although a full 32-bit address space would be nice. I realize that entails
changing the current memory map, but what's life without problems? It's
worth it, even though some old programs might not work."
4) What other special chips should be standard? Supported? Why?
"Nothing looks absolutely necessary. An MMU might be a good idea, especially
if UNIX is supported. I don't think sound support (beyond current levels) is
necessary, as most music-oriented people can buy the Mac Plus and throw on
a MIDI device or two. Possibly a better LAN chip(set) (see #6).
Coprocessors that perform various functions of the toolbox would be great
(especially the Resource Manager, then you might not need an MMU), but I
don't think that's practical now in terms of cost & development time. If
I'm wrong, well, great..."
5) In general, what kind of architecture (open, closed, in between) should the
new Mac have? If *NOT* open, why?
"Slots -- Eight seem to be sufficient for most computers. The slots should
have the full bus available, not some mickey-mouse 'sufficient' subset.
For those maniacs who must have 256M of memory on cards, it would be nice if
the slot scheme did not map those slots directly to the address space, like
the Apple ][ does, so expansion boxes could be added on. However, I wouldn't
give that requirement a high priority. Other things are more important (like
having the slots at all...).
I am undecided as to whether the cardcage should be separated from the rest
of the system (presumably CPU, floppy, monitor, etc.). If it gets really
big, it should be able to stand upright on the floor. However, I think that
all could be fitted into a box about the size of the IBM PC- though I pray
that it looks nicer!"
6) What I/O capabilities should be standard? Supported?
"Minimally, the current Mac Plus ports should be standard. I don't think a
parallel port is really necessary for printers, as converters are getting so
cheap. A DMA port isn't really important either, now that the SCSI port is
there. Of the two I'd rather have DMA, but SCSI is already in use, and
there's no sense in changing things around like that. On the other hand, the
system should definitely be designed to allow DMA hardware (probably on a
card, for an internal HD, see #7). The SCSI ports should run at double the
current speed but remain compatible with the current Mac Plus ones.
Unless the monitor is in the same unit as the CPU, there should be a video
jack with a standard plug (to allow different monitors). Even if it is, that
would be a good idea.
I think the most important addition to the I/O capabilities would be some
sort of higher-speed network. AppleTalk just isn't fast enough. The two most
logical possibilities are EtherNet and a high-speed AppleTalk. EtherNet
would be good because of all the systems that use it, but that might kill
AppleTalk, which would be a terrible idea this late in the game... The
better answer would be a high-speed AppleTalk link. I believe Zilog makes
an SCC that runs at four times the speed of the current chip. AppleTalk at
1 Mbit/sec. might be fast enough. The benefit to this setup is that it
would probably be easy to build a cheap step-down box to connect the high-
speed AppleTalk machine to a regular-speed network, if necessary.
An EtherNet, or even high-speed AppleTalk, might be too expensive to build
into every unit. However, there should either be room for one in the box, or
else a dedicated connector in back (it could link directly to the bus)."
7) What peripherals should be standard? Supported? Should the monitor have the
same size as the current Mac? Why or why not?
"The most important peripheral is a hard disk. There should be a controller
and HD standard, but the HD should be available in several sizes from 20-
80+ MB. The drives should be fast, at most ~40 msec. avg. access time. The
reasons are simple: HD's are coming down in price, and software is getting
hungrier all the time (we all knew that already, right?). Databases are
getting more popular, so more people will be needing large HD's. It would be
nice if the controller did DMA. I am not 100% sure that an HD should be
standard, though. A big database task might require a bigger disk than Apple
sells, and why should anyone be saddled with an HD that's too small?
The second most important peripheral is the screen. Right now, it's much too
small for some jobs, like drafting or page layout. A Lisa-sized screen (but
keep the 1:1 aspect ratio!), 720 x 364 is an absolute minimum. I would much
rather have the monitor in a separate enclosure. This would make it easier
to offer several different screen sizes. I for one would spend a lot extra
for a full 1k x 1k resolution screen (17" or 19" monitor). An in-between
size (~800 x 600) would also be good for those who want more resolution but
don't want a two-foot monitor on their desk. The small screen is the most
critical shortcoming in the current Mac.
800k floppies are okay, but I remember reading about 1.6Mb compatible ones.
If they exist, and are compatible, and aren't ridiculously expensive, they
should be used, but this isn't critical (every unit has an HD). Byte just
had an article about the Atari 1040 in which their cheif engineer claimed
that 10 Meg FLOPPIES were due by the end of this year. If so, not only does
it make sense to offer one as an external drive, but they should be used for
the hard disk backup system. (If they can actually read and write 800k, then
they could be used for the internal drive.)
The keyboard needs another redesign. The brain-damaged engineer who layed
out the Mac Plus keyboard should let someone else try it... the old layout
(fat Mac), with a keypad and SEPARATE cursor keys, would be much better.
This probably wouldn't be wider than the base unit of the system anyway.
An alternate keyboard with built-in trackball should be offered.
OPTIONAL PERIPHERALS:
The most important optional peripheral is an HD backup system. Right now
tapes are the most popular. 20 and 60 Mb Backups should be offered
internally. Cartridge HD's or bernouliis are okay, but I doubt if they're as
cheap per Mb as tape drives. That 10 meg floppy would be great. Either way
the system should understand streaming devices and COME WITH a backup
utility for copying HD --> floppy (like MS-DOS's 'BACKUP').
An internal modem is not necessary. That's what Ser. port A is for.
The ImageWriter ][ is a great dot-matrix printer. It won't be out of date
for another two years, probably.
The LaserWriter definitely needs a higher-speed big brother. This is another
place where a 68020 could be put to good use. In the long term, the Laser-
Writer needs to become a real Print Server. The logical thing to do is stick
a 40 or 70 meg disk in it to spool network requests. The disk could also
hold fonts (or cache most-commonly-used bit images). It shouldn't be
impossible to upgrade current models as well. I have it on good authority
that there is a third Apple LaserWriter coming soon. Let's hope it looks
like this.
CD-ROMS are interesting devices, but I don't think Apple need make them
itself. True Read/Write optical disks won't be available for a while, but
Apple should offer one when they are."
7a) Does the Mac need Color? Why or why not? How should it be implemented?
"I think that color would be nice but not necessary. It is certainly true
that, barring a major breakthrough, high-res color screens will be far too
expensive to justify making them standard, for a few more years at least.
However, there is enough of a need for them that support would be a good
idea. From what I remember of QuickDraw's color commands, I guess that it
wouldn't be difficult to get them to draw multiple bit planes (especially if
graphics hardware is used, see #2). One of my clients just layed out $4500
for a 19" color monitor & graphics board that a special Mac program uses.
Just this one program (EZ-Draft) justified that purchase. Many more people
would get color monitors if the price were ~$1000, not the majority, but
a significant fraction.
If color is just too expensive, then half-tones should be implemented.
The details on how to do color are best left to Apple engineers, but if the
user could set graphics modes through the control panel, it would keep B&W
programs from chewing up time drawing into multiple planes. (When you set
the mode to B&W, one plane is used; when COLOR, 3 (?) planes are used.)"
8) Please list any other requirements/suggestions for Mac HARDWARE.
"Cycle-stealing by the video circuitry slows down the current Mac quite a
bit. This is a big waste of CPU time. The 68020 (with the cache helping)
shouldn't suffer quite as much but still there must be a better way to setup
the video memory. If the screen is fixed in size (I hope not) then it's easy
to build a separate bus for the video ram. If the video ram is variable-
sized, there are two possibilities:
1) Dual-ported RAMs for the video
I think this will be too costly. I'm not even sure if there are 256k
d-p's yet, much less 1M chips.
2) Allocating a chunk of the memory map to screen
If the top 1Mbyte of memory were put on a separate bus, that would take
care of the biggest possible screen anyone would want, and all physical
memory not in that chunk would not be subject to cycle-stealing. This is
the way many RAM-expansion boards work today (Levco's, MassTech's, etc)."
Section 2 -- The Software
1) Should the Mac support any other operating system? UNIX? MS-DOS? OS-9?
Any other? Why or why not?
"The most important point here is that the Mac should NEVER be able to run
MS-DOS (without something like MacCharlie). If the Mac ever could, that
would spell the death of Apple. Not as a 'culture' or anything so
metaphysical; people would simply stop developing software for it, and then
people would stop buying it. Look what happened to the Apple ][ when CP/M
came along. Now, however, there's no lack of serious competition to save
Apple.
UNIX is another story. It is not so common or popular that it can sate the
average user's software needs, and thus drain away talent from the Mac
programming environment. Rather, it is a good system for scientists, who
already use it alot. It would allow them to port over the kind of software
that ISN'T generally found or likely to be produced for micros. Apple
should definitely do this themselves and not farm it out to some guys like
Microsoft, who'll do a second-rate job, or UniSoft, who'll do a straight
port.
I *DON'T* think Apple should just port UNIX to the Mac and let it sit in a
big text window. It would be easy for Apple to do right what AT&T did all
wrong -- put a windowing Mac-Like shell in UNIX. Of course this wouldn't
exclude the usual shells. I am unsure whether or not all shell functions can
be usefully put in such an environment. What would you do about arguments?
What about pipes? Easy to do graphically, but is that easier or more
difficult for the user? I think that shells should allow typed commands too.
In any event, subroutine libraries should be provided to make it relatively
painless for users to put a mac-like interface on their programs.
As I don't know much about OS-9 other than its name, I have nothing to say
about it, except that like Unix, it does not appear to threaten the Mac's
future.
Apple has been sitting on SmallTalk for three years. WHY?"
2) Should any major changes be made in the Mac ROMs or System File? What?
"The limit on the number of trap vectors should be eliminated. The resource
manager needs the 32k max res. size bug fixed. I think these are both fixed
in the Mac Plus ROMS. We need Sub-Menus. We need a working CoreEdit-type
text manager. HFS must be cleaned up. The entire memory map needs to be
reorganized to support larger RAM size. The 31 (?) Driver limit should be
removed. The Print Manager needs total redesign. The cache (new ROMs) needs
a better algorithm. Et cetera...
Some routines and data structures need to be redone because of the 32-bit
wide memory addresses. The only one I can think of off the top of my head is
the Window record, which has an address field which stores 4 bits of data in
the top byte of the address. However, I remember that there are others.
AppleTalk is one big timing-loop disaster. FIX IT!!!!!
SANE should be rewritten to support the 68881. Quickdraw should use some
hardware help. It should support color. (See hardware- #2&7)."
3) What enhancements should be made to the current Finder?
"The most important, easy, and logical step is to integrate the Finder with
Switcher. In fact, Andy Hertzfeld told me that that was his next project
(although he hinted there was more than that). This would provide a true,
multi-tasking environment (assuming programs start getting written switcher-
compatible).
While I haven't gone into this in depth, it also seems to me that it should
be possible to have different (switching) programs all occupying one screen.
Whereas now, switcher cuts in when it detects appropriate mouseclicks or
command-keys, it could auto-activate the application which owns the object
the mouse was last clicked in (this code might sit in the front of the OS
Event Mgr. GetNextEvent routine). All applications that behave well with
desk accessories should function with this as well, as all the windows
belonging to other applications could look like desk accessories. Of course,
the Menu bar would be stored and redrawn for each application.
This would be especially useful for people with large screens. Screens the
size of the current Mac's, or even the Mac XL's, would be a too small to
take full advantage of this (but it would still be a big improvement over
the current Switcher).
A crucial feature, but one easily overlooked, is the ability to drag a large
file to a device with insufficient space if the device has ejectable media.
Appropriate alerts etc. would of course provide an easy abort.
There is one other major function that should be integrated into the Finder:
Networking. However, since the majority of users (at least for now) will not
be on a network, there should be two versions, Finder and NetFinder. I would
not mind buying the networking portion of the Finder separately (and paying
a good amount) as long as it integrated seamlessly with the (new switching)
Finder. There are two major features it should have:
1) Network Disk Access
This is a very difficult topic, because I don't have any experience with
external file systems for the Mac. Neither does anyone else, though, as
far as I know (except the MicroDesign people). It should adhere to the
Apple FileServer protocols. It should also allow the easy inclusion of
third-party network-drive access routines, so that a product like
MacServe (which runs very nicely already, by the way) doesn't have to
play funny games with the Finder, but instead works hand-in-hand with
the external FS access already performed by the Finder.
It does not have to understand DISK servers (that's MacServe's job).
2) Network Mail
The most glaringly obvious failure of AppleTalk to date is the complete
lack of a decent mail system, or even a standard. The Videx is a poorly-
designed overexpensive joke. TopExpress looked okay, but I haven't heard
of them since the Boston MacExpo. Aegis was 'forced' to cancel their
mail program...
It is crucial that such a program always be accessible in a moment; it
is also necessary that the user be flagged when a letter comes in. Both
these criteria now mean a desk accessory, but when switcher-finder
becomes a reality, that's no longer the case, and it can reside in the
S-Finder where it really belongs."
4) How much concern should there be about compatibility with the old Mac?
"The new Mac should conform to Inside Mac where possible, but not at really
large expense of power (i.e., change the ROMs for 32-bit addresses!). That's
rather vague, but I can't nail it down any better. One important thing-
DON'T work to be compatible with software that doesn't conform to the IM
User Interface Guidelines!
Given this, I would expect a lot of software to run, mostly business, and a
lot of software to fail- mainly games. This seems a reasonable tradeoff, and
there's no reason why software companies can't recompile with new equates
(or recode a few small things). It can't be such a big job..."
5) Should the new Mac be packaged with software?
"There's been a lot of discussion recently about whether the free MacWrite
was responsible for the lack of variety of word processing section for the
Mac. I'm sure it is, but the alternative- a Mac that comes without software-
is a highly unappetizing thought.
I think the best way is for Apple to develop a 'Software Coupons' scheme.
That way the user could pick and choose $200 (or whatever) worth of software
to go with the machine. The program would have to prevent dealers from
keeping the coupons themselves (last year IBM tried something like this, and
the dealers generally kept the free software themselves, to sell). I don't
really have a cut & dried solution to this one (hardware's much easier...)."
6) Any other comments about software? What would you like to see for the Mac?
"Just as spreadsheets and integrated packages were the hot new programs at
one time, databases are starting to become really popular. Their use
encompasses many separate areas; people are just beginning to realize what
db's can do for them. This trend probably won't top out until after we can
build machines that can talk back to us and say 'What the ---- do I care
about your census data?'
Long before true AI we should be able to get a database program that makes
fast *CUSTOM* applications building easy. I want to be able to build a
system that does (for example) inventory management, six real-time stations
doing point-of-sale inventory decrement, auto-reordering, sales reports,
with flow-through to a complete accounting system... in two weeks (but I'll
settle for four). I can do this now... In four years. Or I can do it on a
Vax, with a database like Ingres linked with C, but that's expensive, and
it'll still take a year, and it's extraodinarily difficult to maintain.
This could be achieved, in the required amount of time, with three things:
a relational db system, a fairly sophisticated expert system, and a really
good report formatter. A complete programming language (either optimized for
db's or else C or LISP) should be an extension of the rules system.
This is just the first step. The real research will deal with the RIGHT way
of doing this, not just the easy way. What kind of db model should be used?
Relational db's work, but surely there is something better? How should
multiple machines use a single database? Is it better to have a single back-
end machine fielding data requests?
Apple should start a major research effort on databases. The result should
be an open-ended system with strong standards, powerful enough to handle
anything within the limits of the (evolving) hardware. This is a good thing
for Apple to do for several reasons. First, it won't be stepping on any
software developer's toes. This is an enormous project, way beyond any
software house's resources (except maybe Ashton Tate, and they aren't doing
it...). This means there won't be much competition. Second, this would open
up innumerable vertical markets, collectively so vast as to make all the
current markets seem relatively insignificant (just count... how many
vertical-market database needs are there?)
I am stressing the business aspects of this, but this IS a research project.
To make it real requires more than just a dBase VI. It must be a synthesis
of all the best efforts made. For example, can 'hypertext' be done in a
reasonable way, IN THE FRAMEWORK OF a real-world business database? Does it
even make sense (where would it fit into the inventory management system?)"
7) Any last comments on Mac software?
"The biggest problems for serious programming on the Mac have come from lack
of standards. Networking is still confused, and File Serving is as yet very
primitive. If Apple created (or adopted) strong standards, vendors would be
less confused and hesitant to bring out products. Customers would also be
confident that the hardware they were buying wouldn't be a dead-end path.
After all, the Mac's biggest success has come from it rigorous standards:
the ROMS."
------------------------------------Cut Here------------------------------------
Thanks for responding...
Alexis
...ihnp4!physics!ccnysci!alexis