Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!elroy.jpl.nasa.gov!jarthur!nntp-server.caltech.edu!toddpw From: toddpw@nntp-server.caltech.edu (Todd P. Whitesel) Newsgroups: comp.sys.apple2 Subject: Re: Apple II Forever! Message-ID: <1991Apr4.094946.18646@nntp-server.caltech.edu> Date: 4 Apr 91 09:49:46 GMT References: Organization: California Institute of Technology, Pasadena Lines: 118 SHBOUM@MACALSTR.EDU writes: > Thirdly, there IS money in the 8/16 bit machines. Yeah, but apparently as game machines. That's not the kind of business _Apple_ _management_ wants to be in. Electronic Arts president whats-his-name told Sculley once that hardware designed for games is automatically well designed for multimedia. So what has Apple done? Hardware designed so poorly for games it isn't funny, and system software that is game-hostile. In stark contrast is the Amiga, whose original purpose was to be the perfect game machine of the mid-80's (and it was, to be honest), but is now struggling to gain the kind of prestige that the Mac has finally obtained -- the Amiga's only serious market at this point is low-end video and animation, things the Mac is incapable of because only high-end macs &/or mac peripherals can do it. Amiga users do have a right to snicker when Mac people talk about multimedia -- it's really sad that so many of them are egotistic snobs. (Please prove me wrong on that.) >Super NES units in stock sold out on its opening day. Two weeks later when the >next shipments came in, another 400,000 units sold out in one day. Plus those >super NES run on a 65C816 at 3.86Mhz with 512x488x256 graphics with a palette I believe the figure is really 7 mhz. The Super NES is the first game machine that _I_ would consider investing in -- the specs blow the 68K based turbographix and Genesis away, because Nintendo realized a fundamental truth about game boxes: The graphics and sound hardware are where the real power is, and the ideal controller for that hardware is a CPU that has nearly every property the 65xxx series has: a simple ALU whose instructions execute efficiently, a bus interface designed for fast turnaround instead of raw bandwidth, quick branches, efficient in-memory instructions, simple and adequately powerful addressing modes, FAST interrupt response, and the ability to simulate lots of registers (with a speed penalty) that do not need to be saved and restored constantly since they are accessed through a 'base pointer' register -- this is what the 65816 direct page and stack addressing modes do. Unfortunately, some grave mistakes in the Apple II firmware were made early on -- the BRK/IRQ handler was not re-entrant and could fail if a BRK and an IRQ occured in a small window (about 30 microseconds if I remember right, I'd have to check the listings). Worse, when the enhanced //e came out, the interrupt handler saved and restored the auxiliary memory state -- this was unnecessary since (a) old programs and peripherals that would break wouldn't use auxilary memory either, and (b) new peripherals and programs could have been told to either set interrupts or inform the ProDOS interrupt handler when the memory switches might be in an unsafe state for interrupts. Anyway, Apple picked the bulletproof limousine approach. When the GS came out, its interrupt handlers made two mistakes -- one is the tiny window of unreliability when a COP or BRK occurs in emulation mode, because the firmware jumps out of bank 0 without ensuring that the CPU is in native mode, and the IRQ manager is responsible for going to native mode as soon as possible. The other is that the firmware IRQ manager (which could be patched out by an init, admittedly) POLLS its sources instead of dispatching them. It would be much more efficient to have the IRQ manager save the machine state and check the following sources in this order: AppleTalk Serial/MIDI "high priority user IRQ" internal sources: scan-line, sound, VBL, quarter-second, etc. "low priority user IRQ" where the checking process for all internal sources consists of directly confirming the interrupt source and calling the handler, and clearing the interrupt after the handler returns and then IMMEDIATELY returning from the interrupt. The user IRQ sections would be handling dynamically, much like BindInt, but would be controlled by the Miscellaneous tool set. I don't know why Apple didn't think of something like this in the first place -- and at this point it's not really important. The existing firmware most definately works (except for AppleTalk and serial, but that's the fault of the AppleTalk driver and not the firmware itself). My aesthetic approval (or lack thereof) is not going to change anything. And how do I know that the above system would actually work? I haven't actually tried it. But I am going to see what I can do to my good ol' //+ if I permanently enable the 16K card and start from scratch. I've recently installed a 65802 in it, and my good ol' VT52 emulator is going to get a complete rewrite into a tiny multitasking system with mini drivers for the 6551 and the 80-column card that push each to their theoritical limit. A Mockingboard C (two 6522's, plus sound & speech, I'll consider writing drivers for them later) will be used for task switcher interrupts and VBL interrupts for the 80-column card, and perhaps VBL for the //+ itself (once I figure out which pin of D14 you're supposed to use). I'm not worried about disk access for now -- I intend to use it as a kick-butt terminal, with term, scrollback, text edit, and a simple command shell running simultaneously as pre-emptively switched processes. There are three reasons why I'm bothering to do that much: I want to add more features to the terminal program and it's really badly hacked at this point; I want to teach myself some basic O/S design since our CS dept. doesn't teach it (All the research here is into graphics, multiprocessor architectures, or self-timed IC's); and I want to finally have a concrete example of why I prefer the 65xxx architecture in spite of what history's done to it. I'll be using Orca on the GS to develop and compile the code, with binaries produced by MakeBin. I'll have to use DOS or ProDOS to bootstrap the O/S since I really don't want to write my own disk drivers. One of my goals is to be able to install and replace code on the fly (this is going to be a fun one, but FORTH systems and Niklaus Wirth's Oberon system can do it), so I can boot it once and download new code to it whenever I want to change something. I'm not sure how to do that yet, but I have some ideas that may or may not work. The point is I'll have an excellent test bed for trying new ideas, with reset hooked to drop into the monitor for a post-mortem. Damn. I wish I could get credit for this -- I'm too interested in the idea to leave it alone now... Todd Whitesel toddpw @ tybalt.caltech.edu P.S. Those of you who are waiting for LHG, a PROTOTYPE release is going out to various people. I need to totally restructure LHG so I can put a real interface on it and get it to handle low-memory conditions intelligently. I am extremely sorry to make you all wait (heck, I want the money!) but I'm not releasing betas publicly. There is too damn much beta software for the GS that will be beta forever, and the way I program, when it's done it's DONE except for truly obscure bugs that the beta testers don't usually find. I have 20 megs of GIFs of all kinds and the current LHG handles each and every one of them. The release version of LHG will do some other awesome things (assuming I can get DTS's help on something) and will not violate Apple Guidelines AT ALL (bet you wonder how I can pull that off).