mitchell@janus.Berkeley.EDU (Evan Mitchell) (03/23/90)
I asked this guy to e-mail me his paper on what he describes over in
comp.sys.apple as his "Amiga 500 killer." It looks interesting, but would
you buy one? I think he really wants an Amiga, but doesn't want to admit
it! :-). Anyway, I was just curious because he kept hyping this up as
an amiga killer...
DISCLAIMER: I don't work for Apple, Commodore, or any other computer company.
Hit 'n' now it you don't care about this subject.
The Apple //f: A Possible Future for the Apple //
by
Todd Whitesel
28-Feb-90 v.3
This is the second rewrite of a paper that began with a purpose: to
describe a successor to the Apple //gs that would be competitive in the low
end. I must now add 'AND be worthy of the Apple logo', or at least of what
the Apple logo used to stand for. (I address this in "Reality vs. Apple
Computer" which was to be the preface to this writing but addresses enough
issues besides neglect of the // to deserve its own paper.)
The Apple // needs concrete support from Apple if it is to survive, and
it MUST have a long term strategy if it is to eventually surpass its
competitors in the low end. The Apple // is about the only machine left which
is simple enough to be readily made into an inexpensive performer for the
90's, and this is one aspect of Apple's neglect which can be turned into an
advantage.
While producing a show-stopper that is IIGS compatible may sound like a
tall order, I think Apple's exhaustive push into the business market has left
it uniquely equipped. Molded cases and high-quality motherboards are
manufactured inexpensively using Apple's latest technology. The only price we
pay is that the surface mounted chip set cannot be cheaply upgraded.
A new chip set should therefore be designed with the future in mind;
its development cost will be returned many times by long term sales. The
motherboard should also have special connectors to support direct CPU, video,
sound, and ROM expansion which we can already see coming, and designing for
them now while the chip set is still on the drawing board will save everyone
lots of trouble and money later on.
* * *
The Apple //f: Product Description
The Apple //f is a 16 bit Apple II compatible general purpose microcomputer
and has the built-in features of the Apple IIGS. However, the motherboard has
been thoroughly redesigned to add capability while reducing cost, and to
eliminate shortcomings and bottlenecks inherent in the Apple IIGS.
The Apple //f is also suited for many special purpose applications. Major
market segments which would find the Apple //f particularly attractive
include:
Small Businesses
Home Productivity
Education, K-12 and College Level
Music and MIDI
Animation
Video Overlay and Desktop Multimedia
Enthusiasts and the Next Generation of Hackers
Product features of the Apple //f and its system components are as follows.
System Package:
- Internal hard drives are sold standard with most system configurations
- 20 MB 'Floptical' drives are available as alternatives to the hard drive
- Hypercard GS (or equivalent) is provided as part of the System Software,
along with an HFS File System Translator
- Choice of ADB keyboards with every system package
- CPU and all system components may be purchased separately for custom
packages
- Disk ]['s are available as an option
- Every Apple product is backed by a one year warranty
- Apple Customer Feedback Center addresses are provided
CPU Case:
- Compact case
- Mounting brackets for two internal drives
- Internal supports for peripheral cards; CPU may be stood on its side
without stressing the expansion connectors
- Drive mechanisms from Apple 3.5's and Unidisks may be mounted internally
(installation kit required)
- Heavy duty power supply, built in fan
- Fan is slow and quiet, air flows straight from front to back
Peripheral Ports:
- SWIM Disk Port controlled by an independently running coprocessor
- SCSI Ports, internal and external, support synchronous SCSI; also
coprocessed
- Stereo phone jack outputs true two-channel stereo
- Game I/O port is now recognized by the ADB microcontroller as an ADB
joystick
- Two ADB ports
- Composite NTSC video output
- Analog RGB video output
- Modem and Printer Ports; both may be used as Localtalk ports
RGB Monitor:
- has a high persistence picture tube with good beam focus, making it
excellent for interlaced graphics and video overlay
- accepts NTSC composite Video In, allowing it to be used with television
oriented devices such as VCRs and video cameras
- has two RCA jacks for stereo speakers built into the case, to complement
the computer and provide a basic stereo option
- comes with the necessary cables for connection to both computer and VCR for
viewing videotapes or watching television while the computer is off
- is now well worth the price
CPU features:
- 7 Mhz cached 65816 microprocessor; CPU, clock, and cache RAM are user
upgradable to over 20 Mhz in anticipation of the ASIC Technologies 65816
compatible
- 'Processor direct' slot can enhance or replace the CPU and cache system, to
allow high speed math coprocessing and Virtual Memory when cards
supporting them become available
- CPU controller and system bus support multiprocessing and real time bus
functions such as external wait states, bus locking, bus errors,
vectored interrupts, and breakpoints; everything, implemented or not, is
available at the processor direct slot
Memory System:
- System RAM is expandable to 12 Megabytes via 8 industry standard SIMM
sockets and is mapped to memory banks $00-$BF
- 256K, 1M, and 4M SIMMs are supported in a variety of configurations having
small upgrade steps between them
- DRAM controller supports high speed access modes to improve cache and DMA
performance
DMA Controller:
- Block transfers are performed with minimal intervention from the CPU
- Source and destination of a given transfer may be anywhere in memory
- DMA controller respects external wait states and all bus control functions
- Run Length Encoding compression and decompression may be optionally
performed during a transfer; PackBytes may also be supported; LZW would
be nice but might be too expensive to include
- Address offset list mode stores arbitrary data (or zeros) to arbitrary
relative addresses in rapid succession; this may be used to quickly draw
and erase fill mode animation frames
- Bitmap copy and paste mode allows characters from font strikes in ROM to be
moved directly to scratch areas in the Video RAM; the Blitter may be
used to produce typestyle effects and then palette expand the text image
onto a multicolor screen buffer
Video System:
- 128K of standard Video RAM mapped to Banks $E0-$E1; Video RAM is used to
reduce the effect of video refresh on VRAM availability
- Built in palette generator:
- supports all 16 IIGS palettes
- supports a single 256 color palette
- supports full 12 bit color in anticipation of video RAM expansion
- Fully programmable video generator and blitter unit
- Video generator:
- supports all Apple IIGS video modes
- is a superset of the Standard Apple II and New Video Generators
- allows buffer and display list start addresses to be programmed
- uses display lists in VRAM to allow scan line addresses and display
parameters to be programmed independently for each scan line; this
allows cheap and effective acceleration of animations and the desktop
- may be programmed to use external dot clocks
- sync timing defaults to control panel settings which may be
programmed to drive almost any monitor
- fully supports interlaced video (NTSC and non-NTSC)
- can lock onto external sync; accuracy may require optional hardware
- refresh address generation supports pixel sizes of 1, 2, 4, 8, 16,
and 32 bits in anticipation of Video RAM expansion
- detects a programmable key color for video overlay applications
- Blitter unit:
- operates on data in Video RAM with minimal intervention from the CPU
- uses video generator display lists for mapping X-Y coordinates into
buffer addresses
- performs BitBlts and palette expansions
- performs line drawing and patterned area fills
- Video RAM is expandable to an additional 1 Megabyte mapped as Banks
$C0-$CF; Video RAM is added via a dedicated expansion connector and may
be upgraded separately from the rest of the video system
- 'Video direct' expansion connector:
- allows the video generator, blitter, and palette generator to be
partially or wholly pre-empted
- interfaces to built in video generator features such as genlock,
overlay, and frame capture with minimal 'glue' required
- can get at the VRAMs and their shift registers directly; this could
be used to do 24 bit display and frame capture someday
- DIP socket for one external dot clock oscillator in addition to any
available via the video direct connector; this allows a bare motherboard
to drive other monitor resolutions if need be
Sound System:
- Sound RAM is 128K upgradable to 1 Megabyte via a SIMM socket; it is memory
mapped and is DMA compatible to assist buffer refills
- Enhanced Ensoniq DOC supports the additional sound RAM and fixes the swap
mode bug of the original DOC chip
- DOC registers are now memory mapped to simplify note sequencing and to make
a slot-based DMA sound sequencer viable
- 'Sound direct' expansion connector allows a high quality digitizer or
Digital Signal Processor to be easily supported; provisions for simple
16 bit sound could also be made
I/O System:
- Serial Communications Controller is supported by the DMA controller for
negligible overhead in serial port and AppleTalk reception
- SCC registers are now memory mapped to assist time critical serial and
AppleTalk drivers
- 128K per expansion slot is reserved for faster expansion cards as Banks
$E2-EF
- I/O ($Cxxx) in Bank $E1 is allocated to internal I/O functions or is
reserved for future use
- SWIM and synchronous SCSI interfaces are controlled by a separate disk
coprocessor with 32K dedicated RAM for 1:1 interleave reads and built-in
cache support; the RAM interface is DMA compatible and the DMA
controller handles the actual moving of the disk data
ROM System:
- ROM expandable to 1 Megabyte via a ROM SIMM upgrade, mapped to Banks $F0-FF
- ROM contents:
- most recent toolbox revision in its entirety
- Quickdraw fully supports the blitter, DMA, and programmable video
generator
- Memory Manager is enhanced to support the sound and video RAM
- standard font set
- latest smartport firmware; for example, an intelligent Disk ][ driver
- 8 bit Applesoft BASIC
- 16 bit BASIC interpreter which is fully toolbox compliant and may be
invoked via a Reset command or Finder
- New tool set for standard desktop operations (i.e. MacApp in ROM),
this is used by the new BASIC and any application which does not want to
reinvent the wheel of a standard HIG desktop
- ROMdisk driver for the ROM/EPROM disk connector
- EPROM disk:
- is located on a small dedicated connector to reduce motherboard costs
- may be up to 16 Megabytes in size
- is accessed via a 'slinky' style interface for Write Once Read Many
programming of 12V EPROMs
- is DMA compatible for ROMdisk reads
* * *
Design Ideas and Techno Ramble
(Warning. Many of these ideas are fairly sketchy and some are downright
contradictory. Somebody else knows what I don't so I'll put all this down in
hopes it gives somebody an idea that works.)
The idea of direct slots is the most important one I am suggesting. If
the motherboard is just going to be tossed within a few years then don't
bother making it. The unique way Apple manufactures their computers has a
limitation which only the direct slots and support for faster standard slots
can address in the eyes of people who buy with their own money.
The connectors themselves would not have to be Euro's which are pretty
expensive (lots of pins), maybe they could be D-sub's or something else which
gets good contact but does not require excessive through-holes in the
motherboard. Surface mounting the actual pins and providing support via
something in a few drilled holes would be cost effective, but I don't know
what the latest developments are so I submit this idea for consideration.
All digital system timing could be derived from one crystal (say 28 Mhz
or up); each memory or I/O system would divide off what they need to run
optimally without metastability problems. Wait states (use the RDY pin for
this, and then stretch the CPU clock instead) could then be inserted to the
main clock resolution and not to the CPU clock resolution which really costs
at relatively slow CPU speeds. The only problem here is making sure that slow
slot DMA reads and writes still work, but I think if the bus arbitration
respects it then it will not be a problem.
The 16 bit BASIC is also really important. If we could write desktop
programs that use the full capability of the machine (Appletalk, sound,
video, etc) from an efficiently interpreted language built into ROM then it
would open new markets by itself as people muck about and produce usable
programs with it. This BASIC would have to have learned all the lessons of
AppleSloth of course, and BASIC enhancers produced years ago solved most of
these problems, except they weren't widespread enough to become standards. I
propose we leave 8 bit Applesoft alone for compatibility and simple hacks and
forge a new BASIC which is really at home in the machine.
A fast bus extension may not really be necessary, but would be a good
idea. It would mean finally using all the pins Woz gave us and recycling a
few which are now useless like Inhibit. The only applications which really
require the fast bus (given that we have an efficient DMA controller) are
high-bandwidth ones like video frame capture and CPU acceleration, and the
direct slots take care of that. I tried to come up with a viable fast bus in
the first writing of this paper but it was too far-reaching for my experience
and I couldn't work out the details.
In any case, DMA protocols MUST be specified or we will probably hate
ourselves later for it. For instance, the rule that I want to see enforced is
"Thou Shalt Use RDY" because wait states are a useful concept which we can
afford to implement. Specifying timing values on DMA IN/OUT and running them
to a DMA arbiter would simplify things greatly if it didn't cost too much.
True vectored interrupts are also a must because the present O/S overhead on
interrupts is simply disgusting compared to the overhead inherent in the CPU.
One thing I would really like to see is each memory and I/O system
having its own DMA address generators. These could be built into the DRAM
address multiplexers on the GLU chips, and the DMA controller could then send
raw transfers straight across the data bus instead of reading and writing
them manually. However, if the system runs too asynchronously we have delays
and arbitration problems to deal with. Running the vast majority of the
machine at an acceptable but constant speed like 3.58 Mhz would be OK for
this but then there is the problem of DMA request and acknowledge lines
running everywhere.
Another thing which I tried to get at in the first writing was the idea
of each device having one or more DMA channels, which would have ready lines
and be able to get on and off a high speed data bus (say 14 mhz) as well as
latch data bytes from it; this would allow the source to read n bytes into a
little FIFO, request DMA, get the bus and transmit to the target's FIFO, and
then load more if it still has to. The target then gets around to writing
them however it wishes, and asserts DMA ready again and the process repeats,
somewhat piplined but very efficient in terms of bandwidth usage. The cost
would probably be too high but since most of the guts goes into the custom
chips then it really depends on just how cheap Apple can make them.
However, this idea does have some interesting properties: You get
bandwidth to spare because of the automatically split transactions handled by
the bus arbitrator; the slots could each be isolated by a surface mount HCT
transceiver to keep slow cards from mucking with the bus, and using a 646
would mean cheap 'latch-on-write' and a 1 byte FIFO in each direction for the
bus cards; there would be no arbitration overhead because it is all done
outside the bus itself.
This would of course all come at the cost of many control lines running
to the bus and DMA arbiter so I don't think it will be cost effective
compared to the direct slot approach. But if somebody at Apple can find a
way, we might get a fast bus for relatively cheap and that is something the
world needs. NuBus is industrial strength and is more powerful and expensive
to match. The Apple Bus run at full speed (1 Megabyte per second) is plenty
for lots of things. But we ought to at least define it in full and define
features that make life easier and cheaper on everyone, which is what it's
really all about.
* * *
Comments, questions, etc. to the addresses below. I can napkin out
quite a few implementation ideas, and I'd be happy to explain myself if
somebody doubts me. And who knows? One of us might learn something.
Todd Whitesel
toddpw @ tybalt.caltech.edu (internet)
toddpw (America Online)
1-55 Caltech, Pasadena, CA 91126 (US Snail)
This document may be distributed, posted, and made available for downloading
so long as it is preserved in its entirety.
____________________________________________________________________________
-Evan Jay Mitchell
mitchell@janus.berkeley.edudfrancis@tronsbox.UUCP (Dennis Francis Heffernan) (03/23/90)
> I asked this guy to e-mail me his paper on what he describes over in > comp.sys.apple as his "Amiga 500 killer." > -Evan Jay Mitchell > mitchell@janus.berkeley.edu (posting on someone else's behalf) What's described sounds nice enough, I guess.... ...but doesn't everything? In other words, when he's actually bent some metal and MADE this thing, we'll know how good it is. As far as the idea goes, everyone has good ideas. It's doing something with them that's the hard part. Dennis Francis Heffernan | "Great spirits have always dfrancis@tronsbox | encountered violent opposition ...uunet!tronsbox!dfrancis | from mediocre minds" Killer GM- Reasonable fees | --Albert Einstein