Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!usc!wuarchive!zaphod.mps.ohio-state.edu!swrinde!ucsd!ucbvax!LSUVM.BITNET!$CSD211 From: $CSD211@LSUVM.BITNET (Mark Orr) Newsgroups: comp.sys.apple2 Subject: Re: Building a NEW computer Message-ID: <9012061924.AA03548@apple.com> Date: 6 Dec 90 19:11:17 GMT References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 66 |From: Michael Tiernan |Mr Shekhel is dead right, the basic problem with the Apple II line |is/has-been/will be that it lacks a few required instructions at the processor |level to allow it to be a competative force. This has been the problem since |way back in the days of the Apple ][+ when they decided that no one will ever |need an inerrupt line so they took them out of the card slots. I'm not too |sure that I agree that it's largest lack of abilities revolves around the |concept of multiply and devide, yea it takes memory to do that with software |but memory is cheaper than microcode. The Apple II line has a history of lack I didn't mean to say that hardware multiply and divide were all that is wrong (or even the crux of what is wrong) with the 6502/65816. I merely offered it as a typical example of what the 65xxx series lacks. But still, you can't deny that the 65s are lacking in math capabilities. Memory may be cheaper than microcode, but it is also far slower. Too bad the 65s don't have an associated FPU. (of course you can use any on the market, but...) |of support of the concept of interrupts. ProDOS is really the first OS that |actively supports it. The UCSD p-system allowed it but didn't support it. |ProDOS does provide you with methods of hooking your routines in using a very |nice clean manner but then at EVERY interrupt, ProDOS runs a little ditty |before handing off control to your code. (I grant you, they did it for the |right reasons, to return the machine to a known state before you get control) |but hell, that's not their judgement to make beyond the absolute minimum. So very true. Interrupt handling in the OSs leaves something to be desired. |Aside from all that, the II line lacked a non-preempt style of instruction |that would allow you to run (cleanly) multiple tasks. Even the oldest IBM-PC |had an instruction to increment a memory word that blocked all attempts at |prememption until it completed. Using this, you could signal tasks into and |out of a run/ready state. We ain't got it. HOLD IT! Before the flames get |turned on, I am not saying I should be able to run a uucp transfer while I |recompile the great American program in the background, but even little things |like clean print spoolers, alarm clocks and the such are hindered in their |abilities without such a thing. Yes, I can see that that would be nice. This is what concerns me about the ASIC. If you're going to go to the trouble, why not correct the '816s deficiencies. Instead of building a '816 clone, why not build an enhanced '816 more along the lines of the Hitachi 64180 or the 68HC11 or one of those other well groomed device controllers. I can't believe that ASIC is cloning the '816 just for a fast GS (that's much too risky, it might not be there by the time they're done :( ) WDC makes good money on the '816 in device control applications (medical devices, I think)...but the '816 just dosen't have the hardware features of the HD64180 or 68HC11 (even though these are "smaller" chips, i.e. address space) |<< MCT >> | |GEnie : M.Tiernan |AppleLinkPE : M Tiernan or BCS Mike |Internet : pro-angmar!m.tiernan@alphalpha.com |UUCP : ...!uunet!alphalpha!pro-angmar!m.tiernan | |"God isn't dead, he's only missing in action." | - Phil Ochs ---------------------------------- | MARK A. ORR | | $CSD211 @ LSUVM.SNCC.LSU.EDU | | @ LSUVM.BITNET | ----------------------------------