Re: 20MHz 65C816 (IIGS CPU) in production: used in C= accelerator

[doug.cotton@the-spa.com (Doug Cotton)]

WARNING: Somewhat technical content to follow...

In article <19961214193500.OAA01702@ladder01.news.aol.com>,
rubywand@aol.com wrote:

> In article <nugundamE2DyJ1.2H6@netcom.com>, nugundam@netcom.com (Joseph
> Lee) writes:
> 
> >....
> >I think the problem is it doesn't matter without the i/o bottleneck on
> the
> >GS, the difference between using the 14mhz part and the 20mhz part is
> >negeliable.
> 
> 
>      True enough. The cure is not especially complicated. What we need is
> a 20MHz New GS plug-in "accelerator card" which includes 32MB of main RAM
> and 4MB of FlashRAM 'System ROM'. It could have top-of-card connectors for
> a bus to control additional cards (such as boards for advanced Sound and
> Video).
> 
>      New GS would be able to use the current GS setup as a kind of 'front
> end'. It would be able to run old II and IIgs wares as well as wares
> designed for the new board.
>    
> 
> Rubywand

Not being in the Apple ][ market, I'm not about to comment on what you may
or may not 'need'. But I think we've tackled similar situations in our
market, so I'll share a little of that with you.

First, forget Flash memory... slow, expensive, and it has a limit on the
number of writes it can handle before it goes south. Our solution to
maintaining a fast 'system ROM' was to use a ROM... but to download that to
Fast Static RAM which mimics the ROM when the unit is powered on. This is
what the Wintelites call ROM shadowing, and it's both fast and inexpensive.

Next, a little warning is in order when you start considering placing a lot
of RAM on a 20 MHz processor. You see, the only RAM made _TODAY_ that can
keep up with a 20 MHz 65816 is Fast Static RAM. This is because the address
bus of the 65816 is multiplexed, so you need additional time to
de-multiplex addresses -- which gives you less time to deal with RAS
signals for Dynamic RAM (DRAM). In our accelerator design, the setup time
available from the point when the address has been decoded to the time when
valid data must be read or written is between 20 and 25 ns. Typically, even
fast DRAM requires 50 ns when moving to a new row, and even some of the
more esoteric new RAM types like EDRAM require 30 ns -- at a cost hike.

Now, you could say, "Then why not use Fast Static RAM throughout?" Two
problems. The cost factor is high on Static RAM, and the densities are low
(which means you probably couldn't put that much Static RAM on the bus and
still get it to work). The only workable solution is to allow for some
performance hits, but to design around that happening as much as possible.

While our unit for the Commodore will soon have a RAM expansion board
available which can hold up to 16 MB of RAM, the route we're taking is to
make a relatively complex interleaved DRAM memory controller which assumes
that the processor will request the next sequencial address. This
assumption leads us to pre-charge the expected address, and if it proves
true, the access happens in a single cycle. However, if the next memory
access is not sequencial, or if it crosses into a new row, we incur a delay
-- or in our case, a clock streatch -- of up to four 20 MHz cycles. Given
the way most code is written, our assumption will be correct about 75
percent of the time; but when this isn't the case, we regroup and take a
performance hit. 

Of course, accessing slow peripheral chips also causes performance hits (we
minimize this by using a one-byte cache for some write-throughs to system
memory), but you're probably already experiencing that with present
accelerators in your market. Depending on how your present accelerators
operate, and what type of RAM and RAM controllers they use, you may already
be taking some performance losses with RAM access as well. Bottom line is
that to determine if a 20 MHz accelerator will do much for you, you'll need
to analyze how your present accelerators operate first, and then determine
whether the methods required to increase that performance can be done at a
reasonable cost.


Doug Cotton
E-mail: doug.cotton@the-spa.com


=====================================================================
|    Creative Micro Designs, Inc.   |    Orders:  (800) 6383-CMD    |
|    P.O. Box 646                   |    Support: (413) 525-0023    |
|    East Longmeadow, MA 01028      |    Fax:     (413) 525-0147    |
---------------------------------------------------------------------
|        Visit our WWW Site at: http://www.the-spa.com/cmd/         |
=====================================================================