Subject: Apple //f... Path: lobby!newstf02.news.aol.com!portc03.blue.aol.com!newsfeed.cwix.com!192.26.210.166!sunqbc.risq.qc.ca!News.Dal.Ca!halifax.chebucto.ns.ca!ab616 From: Tony Cianfaglione Newsgroups: comp.sys.apple2 Date: Sun, 27 Jun 1999 03:01:31 -0300 Organization: ISINet, Nova Scotia Lines: 357 Message-ID: NNTP-Posting-Host: chebucto.ns.ca Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: News.Dal.Ca 930463293 11930 192.75.95.75 (27 Jun 1999 06:01:33 GMT) X-Complaints-To: postmaster@Dal.Ca NNTP-Posting-Date: 27 Jun 1999 06:01:33 GMT 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.