Re: Slow GS video thanks to: Apple sucks

[dempson@actrix.gen.nz (David Empson)]

Eric Jacobs <jabox@geocities.com> wrote:

> No voodoo here. The reason slow RAM banks $E0-$E1 are "slow" is because
> of the video refresh. The GS timing for video is actually precisely the
> same as the timing in all other Apple II's. The original Apple II
> generated RAM timing signals for -all- memory at twice the processor
> speed. Thus the address bus alternated 6502, video, 6502, video, etc.
> This was an easy and economical solution to avoid dual-ported video RAM.

More importantly, it resulted in a major simplification of the memory
circuitry - there are no refresh cycles needed, because the video
accesses have the side effect of refreshing all the RAM!

> In the GS the story didn't change much. Banks $E0 and $E1 acted just
> like main and auxillary memory in the IIe (cpu, video, cpu, ...),
> and were dubbed "slow" ram. All other banks were "fast" ram and were
> allowed processor access on every cycle however. So when if the GS
> accesses slow ram on a designated "cpu" cycle, nothing's wrong. But
> when the GS accesses slow ram on a "video" cycle, the 65816 gets
> wait-stated.

Well, it isn't quite as simple as that - if the IIgs access banks $E0 or
$E1 (or a slow I/O location via bank $00 or $01) then the FPI chip
forces the processor to wait until it is synchronized with the next 1
MHz cycle.  There is no decision about whether there is a conflict with
video accesses - it always happens.

> 16-bit memory writes get the most penalty because one of the two 8-bit
> writes are bound to be on a "video" cycle. This is true even for 
> shadow memory in bank $01. (Shadowing only increases performance when
> video memory is read by the processor.)

A 16-bit access to bank $E0 or $E1 will always result in two consecutive
1 MHz cycles, with a delay before the first cycle which depends on the
relative timing of the CPU clock (normally 2.8 MHz) and the 1 MHz clock.

> An adequate solution that would have easy to implement without much
> timing pattern changing would be to make the slow RAM "fast" during
> vertical retrace. Since most CPU video access occurs during vertical
> blanking for games and animation programs, this might have provided
> a small gain.

It would have broken the refresh mechanism, and the precise timing
emulation.

-- 
David Empson
dempson@actrix.gen.nz
Snail mail: P.O. Box 27-103, Wellington, New Zealand