Re: Slow GS video thanks to: Apple sucks

[Eric Jacobs <jabox@geocities.com>]

Nathan Mates wrote:
> 
>    Bzzzzt! Thank you for playing, but you lost. The GS's super hires
> screen is writable only at 1Mhz, true, but most of the rest of ram
> (non-I/O space, also all of banks E0/E1) is accessible at the system
> speed (1Mhz or 2.5Mhz depending on what it's set to). Since the SHR
> screen is in bank E1, it's accessible at the slow speed. Blame Apple
> for cheapskating on the RAM and using part of slow ram for that screen
> rather than doing it properly and used fast ram or a dedicated bank of
> ram.
> 
>    The SHR 'shadow' screen in bank 01 can be read at the full 2.5Mhz,
> but writes to it drop the system speed to 1Mhz while it updates the
> memory location in both banks. Even so, there is still some serious
> hardware voodoo going on-- PEI slamthrus of the screen from 01 to E1
> work better with a NOP every 13 PEIs simply to get the dualspeed bus
> time to recover better.

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.
In the original Apple II, this made sense, because the 6502 was only
available at 1 MHz anyway, so they might as well.

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.

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.)

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.

Obviously, the best solution would have been to redo the system bus
architecture entirely, and I don't think this would have hurt the GS
at all. Compared to other NTSC-output video chips of the time,
(such as the Nintendo), the GS really looked bad. The RGB output was
acceptable, but a 400-line screen would have really been nice. Make it
switchable interlaced/noninterlaced so that we can upgrade to VGA
monitors as they became more available.

The GS's architecture preserves 'scope-level characteristics of the
Apple II family, and that really wasn't neccessary or beneficial to
the GS at all.

-ej