gwyn@smoke.BRL.MIL (Doug Gwyn) (03/18/90)
In article <1990Mar17.112032.18069@spectre.ccsf.caltech.edu> toddpw@tybalt.caltech.edu (Todd P. Whitesel) writes: >The Mega II was not originally designed for the IIGS and its presence is >the root cause of many common complaints about the IIGS as a product, ... I don't follow the logic. Certainly compatibility with existing Apple II peripherals and software adds substantially to the value of the IIGS, not detracts from it. Since existing Apple II peripherals were designed to work at 1MHz, the IIGS had to slow down when accessing them. Similar comments apply to the weird Apple II graphic modes. If I had wanted to buy a computer that would be incompatible with my shelves full of Apple II software, I sure as hell wouldn't have bought one based on the 65816. In fact I'd probably have gotten a PC clone despite its architectural ugliness, simply because of the vastly superior availability of new software.
toddpw@tybalt.caltech.edu (Todd P. Whitesel) (03/18/90)
gwyn@smoke.BRL.MIL (Doug Gwyn) writes: >In article <1990Mar17.112032.18069@spectre.ccsf.caltech.edu> toddpw@tybalt.caltech.edu (Todd P. Whitesel) writes: >>The Mega II was not originally designed for the IIGS and its presence is >>the root cause of many common complaints about the IIGS as a product, ... >I don't follow the logic. Certainly compatibility with existing Apple II >peripherals and software adds substantially to the value of the IIGS, not >detracts from it. I never said scrap the II compatibility, I said scrap the Mega II. The Mega II has to run at 1 Mhz and in the GS that's a big problem. If they had implemented its functions in a more distributed manner then the only part of the machine that would run slow would be the actual expansion slots. When the GS was originally designed they barely had the technological capability to do this, but for a couple of years now it is has been well within Apple's custom chip capability. > Since existing Apple II peripherals were designed to >work at 1MHz, the IIGS had to slow down when accessing them. That is true. > Similar >comments apply to the weird Apple II graphic modes. That is NOT true. The video RAM could have easily been made to run fast, but as they had already developed the Mega II and had to use it for something (I keep forgetting money wasn't as plentiful back then) it ended up going in anyway. In fact, you can implement the Apple II video modes with VRAMs (a la Mac II video cards) and it is *EASIER* than the new GS video modes. (The explanation of why this is true is a bit technical about how VRAMs work, so I won't post it unless a lot of people ask. I'll gladly answer via mail.) [ random flaming about non-compatibility with the II deleted ] What I keep trying to convince people is that the II compatibility is cheap and important but the way it is implemented in the GS positively sucks and could be done much better, especially now that Apple has more than adequate resources. That's all I'm saying, nothing about dropping II compatibility which I wouldn't give up for the world. I'm just saying that the GS needs a totally new chip set and that without one the GS or its successors will never stand a chance in today's market. The custom chip set in the GS implements a logical construct, that of the memory map and basic operation of the machine. We could scrap them all (not a bad idea) and make a complete new set that is designed to work together a hell of a lot better and more cost-efficiently but will still look the same to the software so compatibility suffers not one whit. With the silicon we'd be saving we could add more features to make the ToolBox's life easier, and my //f paper has numerous suggestions as to what can be done in this regard. Todd Whitesel toddpw @ tybalt.caltech.edu
JLS139@psuvm.psu.edu (Abaddon) (03/19/90)
In article <1990Mar18.095408.1765@spectre.ccsf.caltech.edu>, toddpw@tybalt.caltech.edu (Todd P. Whitesel) says: > >I never said scrap the II compatibility, I said scrap the Mega II. The Mega II >has to run at 1 Mhz and in the GS that's a big problem. If they had >implemented >its functions in a more distributed manner then the only part of the machine >that would run slow would be the actual expansion slots. When the GS was Correct me if I am wrong, but under DOS 3.3 wasn't disk access based in software (RAM) and wasn't writing based on critical timing loops. Seems to me that RAM would have to be running at 1Mhz for disk access(writes). Or am I wrong? How do the accelerator boards for older ]['s work in this instince? ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ...jeff stine...<jls139@psuvm.psu.edu>...Abaddon... "fiery the angels fell..." ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
toddpw@tybalt.caltech.edu (Todd P. Whitesel) (03/19/90)
JLS139@psuvm.psu.edu (Abaddon) writes: >In article <1990Mar18.095408.1765@spectre.ccsf.caltech.edu>, >toddpw@tybalt.caltech.edu (Todd P. Whitesel) says: >> >>I never said scrap the II compatibility, I said scrap the Mega II. The Mega II >>has to run at 1 Mhz and in the GS that's a big problem. If they had >>implemented >>its functions in a more distributed manner then the only part of the machine >>that would run slow would be the actual expansion slots. When the GS was > Correct me if I am wrong, but under DOS 3.3 wasn't disk access based >in software (RAM) and wasn't writing based on critical timing loops. >Seems to me that RAM would have to be running at 1Mhz for disk access(writes). >Or am I wrong? How do the accelerator boards for older ]['s work in this >instince? The RAM doesn't have to run at 1 Mhz, in fact it doesn't -- it runs at 2 mhz so the video (or refresh in a GS) can do its thing while the CPU is not using the RAM. If the RAM is run faster but is made available to the CPU when it asks for it, then the CPU runs at 1 mhz and the disk access still works; the RAM could be doing other stuff without the CPU caring or the disk messing up. Apple has yet to do something more useful with this idea, but my proposed //f would find plenty of uses for it (background DMA to sound and video during disk access with no penalties -- yeah!) All accelerators (and the GS) have to know when a disk access is occuring. They figure out when the disk motor has been turned on, and slow down to 1 Mhz until it is turned off. The GS actually detects the exact locations that turn the drive motor on and off; most accelerators slow down for 50 microseconds after any one of sixteen locations are accessed -- for disk drives and many other peripherals that might need to run at 1 mhz this stays in effect because the card is re-accessed and the 50 microsecond timer starts again. (AE's transwarp for the ][+ & //e does this, if memory serves me, and one card in particular -- forget which -- didn't work with it because it had to run at 1 mhz but it didn't reaccess its card and restart the 50 microsecond timer fast enough... I remember reading about it in the Nibble letter column some years ago.) Todd Whitesel toddpw @ tybalt.caltech.edu