Re: Apple //f...

[Frank Carney <frankc@cyberhighway.net>]

If you are going to make an Apple IIgs computer clone/successor then you will
have to use a fast CPU.  Nobody is going to buy a slow 7Mhz computer.  At least
use the fastest chip available for 65816s.  There is a 20Mhz version available.

Tony Cianfaglione wrote:

> Found this on the net awhile back...
>
>               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 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 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.
>