hassell@tramp.Colorado.EDU (Christopher Hassell) (12/23/88)
We the people, in order to form a more perfect computer do solomnly declare
and proclaim our annexation of the R&D department of Apple Computer Co.
Any resistance will be met with harsh penalties not discluding the repeated
saying of "Nih!" and many other nasty things we'll think up.
"Ecky ecky ecky ftang zoop boing", may not be used unless as last resort.
AHHHHHHHHHH, wouldn't that be nice.
But wait, here goes at an idea <not a wet dream of any sort>.
[A+ put out just a little wish-list and it was too boring.]
IF "BIG RED" cares to listen to and/or implement the following design outline
I assume no copyright of any sort or ability to claim ownership of anything
stemming from this article. Under such provision it is public property,
copyable at will by anyone. [An attribution would be nice though :-]
Allright, that was just to swell my head a little.
This is argumentation, the design proper follows.
THE idea is as such. I have found a pocket of resistance to NOT ONLY the
elimination of Apple // as a product line BUT to the @#$@ 3-M's of the
now Macintosh-style (Originally *>IBM<*) architecture. They are used
solely as the criteria of a computer these days and are listed thus:
Meg's : The problem with this is 360K programs meant to manipulate 60K data
all inside memory. This "memory race" makes programs bigger: makes
memories bigger: makes no USEFUL usage of memory. The tide should be
stemmed in principle, and finally memory used as a true storage
medium of very high speed for ARBITRARY data, unreproducible.
Mhz : The computer industry is now SLAVE to the chip people and their
"Our clocks are more eclectic than yours!!" principle. As some
people have noted, the measure of Mhz is becoming rediculous
as a means to check "speed" *across architectures*.
(i.e. 2.3 Mhz 65816 is almost "faster" than a 4 Mhz 8088)
MegaVBits: This relates to the surge [a good idea at first] to produce
the Largest Bandwidth VidDisplay in Megabits <pixels*bits/pixelbits>
without better techniques to handle them...resulting in WORSE
interfaces with slower systems because of all the "red tape" in
doing anything to the screen/system in general.
Now if everyone is still interested I will also complain a bit about
the OS systems these days. I have seen MORE than a few programmers
who simply circumvent the Typical System Calls. This makes compatibility
an issue obviously but They Don't Care. Speed speed and more speed
and not to mention useless preparations for system calls seem almost as bad
as writing them oneself sometimes.
That is a complaint without an answer mostly. The only possibilities I can
think of are LESS preparations <for smaller programs> and much simpler cord-
ination of Firmware compatibility insurance. THERE IS A BETTER WAY
SOMEWHERE. Methods are up for discussion.<How 'bout lots of indirection>
AS for the suggested design:
For the Apple computer to survive we must kill some of the demons forcing
it into the 3-M mold.
For memory - There must be better ways to organize firmware. I would like
to discuss this if anyone wants to. Firmware could handle
the Constantly Duplicated problems/algorythms out there.
Once again j'accuse the op-sys for striving too much for too
complex a method of clipboarding. What about stuff like Unix
has? In Unix files can be stuffed *anywhere* from anywhere.
<its called "ascii" formatting> <handling programs provided>
Bingo! Because of simple redirection from an O/S <desktoppable?>
endless conversions/movements could be made Unnecessary!
[note "abilities" of standard system would be amplified & costs-reduced by this]
For Mhz
For MBandwidth (User-Computer Bandwidth)
Both of the above are related to the next idea.
A graphics coprocessor was suggested in this month's A+ magazine.
I DON'T SEE why you couldn't go all the way and get a second processor.
This IS the Trend Of The Future. Mainframes have kept their market
because of their unique ability to handle massive I/O. They do this
by the constant work of PARALLEL <but not equivalent> processors handling
all that type of stuff. The number crunching aspect of most mainframes
is even downplayed at times because all it is is a BIG switchboard system.
& just a Bit of memory too. <No flames please, I know they aren't Really>
Hardware stuff relating their working together is at end of article.
HERE'S THE GOOD STUFF.
One original processor <ideally only a 65816>, DUTIES:
- Compatibility all the way back to Apple II (almost) [note: nothing to
prevent this should be introduced]
- Runs normal *interactive* programs most easily of two [speed is favored]
[few or NO interrupts]
- General Number-Crunching and Processor-bound tasks. Most up-front
user-sees-results-OR-appreciates-the-necessary-delay stuff put here.
THE SECONDARY PROCESSOR, <Another if not better 65816> duties:
- Provide a NEW environment for programs to be tailored to.
- Could introduce // MULTITASKING w/interrupt-protection req'd.
Also, multitasking support means multiprocessing support later..
- Any kind of new Standard outlets could be introduced. [DMA, Coproc's?]
- Anything could be done to this to get any new possibilities
started in a new "compatibilty environment".
- Take on the load of non-critical tasks from the main processor.
- Get graphics backed OFF from slowing actual INTERFACES
<Imagine a sorta typeahead for windowing stuff, while it's still
drawing useless stuff you could be opening a new window, pushing
that button, loading that file. It should be queued!>
- Users generally ONLY need ONE -background- task [printing/downloading]
so it would be ideally suited if programs easily adapt to bg status.
- If programs get smart then ANY Foreknown usage of the disk could
be pulled off WITHOUT ANY deficiency. [Remember the Amiga drives!]
- Simply provide a framework for a better use of a system without needing
new architectures/speed <or 68000, even though they ARE nice :->
- MANY system tasks usually done by interrupts or by external hardware
can be done by <sigh> software. This IS the APPLE DOCTRINE.
[YES, graphics coprocessor stuff could be done but it is soo brainless
that maybe a separate chip should do it, w/out too much expense?]
Being that this is the centerpiece of the change here are the benefits.
not already listed.
- The Apple line would extend of in a new and bold direction in computing.
Making rather sure that business won't want to follow it, at first.
[This would keep the Mac market Very Safe <just like Big Blue had it>]
- Orientation to the SMALLER user without endless number-crunching to do and
with quick I/O and user interface as a primary concern ----->
produced.... "For The Rest Of Us"
*** Note also that if us programmers get our act together memory will be
even LESS of an issue for -lower end- users. ***
- The whole issue of parallelism for a common op. sys. would push Apple into
the leading edge of many fields if the projects succeded.
- Connectivity, the new Direction of All systems is VERY well supported by
the concept of a background processor [Its like two people standing
back-to-back. You will cover ALL 360 degs as opposed to 180]. How's
that for your as-necessary-and-useful-as-a-phone Stevey-boy? <..Jobs>
[I see network/phone-connected computers common. A techy answering machine?]
Whew. As for some of the technical stuff, I'm not very well brushed-up but
here goes.
Each processor should have excluding access to *Output* to slots.
Output *includes* control lines. But the other could eavesdrop too?!
Both processors ?could? have multiplexed access to ALREADY "slowed"
memory and still not interfere w/each other (Both R&W access).
The background processor could have Read only access to some other memory
specifically for read code only and write only for disk data passing.
The graphics line-interrupts used in GS modes could go ONLY to the bckgrnd
processor unless a compatibilty req. undoes it. YES you got it!
Active Sprites made by SOFTWARE and only helped by a graph coproc if
necessary. "Windows" for separate *active* sections of memory too.
Upon uninterruptible tasks <specifically written for the background proc>
the foreground processor should be able to take over easily for
most tasks [compatibility is most likely maintained for some!]
Possibly the ability to partition the proc's. into two virtual machines.
Note: virtual memory is not *all* that required yet.
I have many other wierd ideas for a graphics copprocessor but that starts
to sound Commodorish so I'll leave those for later (168 lines already?)
Small conclusion:
NOW does anyone see why we should commandeer the R & D dept?
APPLE NEED NOT BECOME WHAT IT DISLIKED MOST <for a while> [IB*].
We don't NEED to get business products shoved down our throats. There is
STILL a difference between a home-user and business-user! Compatibility
these days is nearly a cinch because of all the cards and file fmt convs.
Vive la difference of Apple. We will see it live again. <music in backgrnd.>
In any case PLEEZE, let's see some discussion on these only slightly-raw ideas.
I'm going to send a sort of petition to the big fruit itself. Any more takers?
Mail is very appreciated as would be postings. Mail-only for simple agreement
or disagreement would be more appropriate. Let's turn this into reality!
### C.H. ### <Yes, now that you ask, I did think it would almost be this long!->
{rutgers!sunybcs,ncar,nbires}!boulder!tramp!hassell (I'm there somewhere)