[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: New GS/new accelerator




On Sat, 12 Feb 2000, Frank Carney wrote:

> Date: Sat, 12 Feb 2000 22:56:25 -0700
> From: Frank Carney <frankcTAKETHISOUT@ANDTHISALSOsrv.net>
> Newsgroups: comp.sys.apple2
> Subject: Re: New GS/new accelerator
> 
> Wayne Stewart wrote:
> > 
> > I'd agree with Supertimer that a 7mhz to 15mhz speed increase isn't by
> > any means a small increase. I'd tend to think the effectiveness of higher
> > speeds(100mhz) is going to be largely dependent on what the computers
> > doing.For example viewing or converting a jpeg. Of course it'd help a lot
> > almost everywhere if the accelerator has a good size cache.
> > It would complicate things but I always thought a neat way to do it would
> > be to have a cable running from the accellerator to the memory expansion
> > slot, That way most of your memory'd be on the accellerator and be
> > accessable at higher speeds.
> > 
> > Supertimer wrote:
> > 
> > > bobryan9@my-deja.com wrote:
> > >
> > > >Apple II accelerator (TWGS)
> > > >can run at 16 Mhz if you're lucky
> > > >boosting speed from 2.8 to 7Mhz seems like a big increase when you run
> > > >programs
> > > >boosting speed from 7Mhz to 15Mhz seems like a very small increase when
> > > >you run programs
> > >
> > > Not entirely true.  Boosting speed from 2.8Mhz to 7Mhz
> > > actually seems to have a very modest effect.  Boosting speed
> > > from 7Mhz to 10Mhz will make things seem much smoother.
> > > I have a 12.5Mhz TWGS and I can tell you that 12.5Mhz
> > > seems to smooth things out A LOT compared to 10Mhz.
> > > Only at 12.5Mhz do things actually seem snappy.
> > >
> > > Given the speed curve I've seen with increasing Mhz of the
> > > CPU, I think that the 25Mhz is probably when you will
> > > stop seeing much of an increase due to the bus (although
> > > cached code will continue to increase in speed).
> 
> Here is a serious question:
> What does cache got to do with it?
> Are we talking from experience in designing accelerators or is this just
> an observation that existing accelerators go faster with a larger
> cache?  I do not mean to be inflamatory, but I was hoping someone who
> knows could explain the technical reasons behind a large cache. 
> Besides, I just watched a rerun of "Whose Line Is It Anyway?".  It makes
> me exagerate my true state of mind.

The biggest problem with existing accelerators in the apple realm is their
dependancy on the original machine's memory for its own use.  The superCPU
for the c64 (relentlessly mentioned by me cause it's a good construct) uses
its own local ram for CPU usage, and only needs to slow down when it tries
to access memory on board the machine that's hosting it.  This memoty
comprises I/O devices, of course, as well as any data involving video. 
Audio would have to be included on the IIgs, since the DOC has its own 64k
of ram. =) The c64 only has its lowly (but beloved) sid chip.

The SuperCPU, by default mirrors the entire 64k memory bank (bank 0) to the
host machine 60 times/sec at 1byte/clock speed.  Of course, the 65816 cant
operate at the same time, so this causes delays.  Savvy programs can change
this optimisation.  My favorite, for simple basic utilites anyway, is the
"BASIC" optimisation, which only mirrors the 1k text page 60times/sec. 
This, obviously causes 1/64th the delay.

The zipGSx also has caches, which were questioned above.  The accelerator
design for the SuperCPU has a very simple cache, which consists of a 1-byte
write buffer that allows the 65816's code to make one write to the c64's I/O
devices without a 1microsecond wait between I/O's.   There are a few delays
in other memory locations due to slowness in some chips, but that's the rule
overall.  Reading of course is uncached, so you always get a delay there.

I believe that the current prices on ram (relative to the time when the
existing accelerators were released) makes it quite feasible to make a
complete self-contained machine which uses the IIgs for an I/O device. 
Since it's convenient to reach the IIGS's 65816 socket from expansion slots
3 or 4, I'd use that for bus control when the IIgs must be accessed.  The
C64 doesnt have such a luxury, so our accelerator simply locks DMA mode
permenantly once it starts up, and all devices must plug into its
passthrough port (which emulates the DMA capacity of the c64 perfectly). 
It's funky, but it works perfectly (the most popular DMA device is a 512k
memory expander which transfers chunks of memory in/out via DMA).

Enough drivel =)  Just remember these recommendations:

1> use LOCAL, self-contained ram, and make sure it's plenty fast. 

2> use a (small) write cache for I/O devices so writing doesnt cause
unnecessary delays

3> when possible, use "localbus" I/O devices (a-la a ultra-speed scsi card
on board or connected via a secondary highspeed bus [ribbon cable across the
top?]).

4> have fun, and keep it make-able =)

-Jonas