Path: utzoo!attcan!uunet!husc6!bbn!rochester!udel!wack
From: wack@udel.EDU (Andrew Wack)
Newsgroups: comp.sys.apple
Subject: Re: 12 MHz 65816
Message-ID: <3015@louie.udel.EDU>
Date: 14 Jun 88 23:50:30 GMT
Sender: usenet@udel.EDU
Reply-To: wack@udel.EDU (Andrew Wack)
Organization: University of Delaware
Lines: 37

Well after watching all the rumours fly by about the IIgs+ and now finally 
having time to respond, I thought I'd put in my two cents on why I think
the Greg Provost posts are just somebody's dreams.

The idea of a faster gs is something I am greatly interested in.  In
fact my interest is so great that I have been working on an accelerator
board for it for about the last 3 months.  When I started the project the
very first problem I found was memory speed.  In fact I quickly realized that
the only solution would be to implement a cache memory (a-la the zip chip or
main frame computers).  And this is where the biggest flaw (that I found)
shows up in the Greg Provost IIgs+ postings.  He states that the machine
runs at 7.6Mhz, and then goes on to say that 90ns DRAMS should be used
for the memory although 120ns may work.  A quick check of the data sheet
for the 65816 show that at 7.6Mhz the memory access time should be about 76ns
(this was extrapolated from the 8Mhz spec) which seems to indicate that 
neither rams would be up to the task.  In fact you have to slow down 6Mhz
before the memory acces time increases to 87ns!!  And no where in the detailed
posting of the IIgs+ features did I see mention of a cache (surely something
as sophisticated as this [for a micro] would be mentions), which leads me
to believe that all of this is idle dreaming.

An 8Mhz IIgs (even 10 or 12, but i haven't been able to get ANY information
from Western Design Center that anything above an 8Mhz part exists) is 
certainly possilbe, but not the way its been described in all these dream
postings.

(To all the more hardware inclined:  I realize there are many other ways
to deal with slow memory, such as putting in wait states etc, but all of
these decrease throughput to the point that you might as well run slower
(at the speed of the memory) and save youself some money by putting in
the slower processer.  I've tried as much as possible to keep this from
turning into a comp.arch posting, so if you want some more technical
info, I'd be happy to reply by email).

-------------------------------------------------------------------------------
ARPA:wack@udel.edu                       Gravity cannot be held responsible for
                                      people falling in love -- Albert Einstein