>=20
> >While I sympathize (somewhat, anyway) with highly tuned code
> >that has stopped working due to the differences between 628
> >and 628a, I gotta argue with your assumption there. Surely
> >downloading user graphics happens seldom enough that you can
> >blank the screen while they are being saved to EEPROM? I'm

  It didn't really stop working, the functionality just decreased a little:=
=20
The user now has to make sure the screen doesn't contain any user defined=
=20
graphics when they change them. And I can well imagine a user that would=20
want to continuously change user defined characters, so they can adapt the=
=20
graphics to each game level's environment. And I agree that is was a design=
=20
choice to maintain synchronisation at all cost, and that things would be=20
easier without it.

 >reminded of the timex-sinclair zx80 that would blank the
> >screen a lot while running the basic interpreter. It wasn't
> >great, but it was usable...

 Yes, it blanked the screen, but it kept some form of synchronisation (the=
=20
screen turned black, it didn't turn into noise). Of course, both the ZX80=
=20
and ZX81 did the synchronisation in external logic, rather than using the=
=20
Z80. It was a very clever setup.
=20
> The ZX81 had a "fast" mode that blanked the screen and sped up basic=20
> execution by orders of magnitude. The "slow" mode allowed display, but co=
uld=20
> only run the basic interpeter during horizontal retrace (IIRC).

 The slow mode operated whenever the external logic was handling the=20
synchronisations (both horizontal and vertical). This gave the CPU about 20=
%=20
time to do calculations. The ZX80 didn't have this slow mode.
 Greetings,
Maarten Hofman.
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist