pw at panix.com
Mon Jun 8 16:33:36 CEST 2009
rossberg at mpi-sws.org wrote:
> On Jun 8, 6:28 am, "Ken T." <nowh... at home.com> wrote:
>>> Let's not forget Elite for the 6502 exploiting predictable performance
>>> in order to switch graphics modes partway down the vsync!
>> That actually didn't require predictable timing. You could tell the
>> video chip to send you an interrupt when it got to a given scan line. I
>> used this myself.
> I don't know what Elite did, but I know for sure that it was a common
> trick on the Atari ST to switch color palettes or graphics mode at a
> fixed point *in each single scan line* to get more colors, or display
> graphics on the screen borders. That required "synchronous
> programming", i.e. counting clock cycles of machine instructions such
> that for every point in the program you knew exactly where the
> electron ray would be.
> The Atari ST had an M68000 with exactly 8 MHz, which made this
> possible. There were no caches in those times, and clock cycles were
> entirely predictable.
The usual trick for these machines was an exact multiple of the NTSC
"color clock", which was approx 3.58 MHz. The 8-bit atari video games
and home computers all used this technique, as did the C-64/128.
68000-based machines (such as the ST and the Amiga) could not only
exploit that synchrony, they could also (this was the days before memory
wall) exploit the fact that a 680x0 typically accessed memory only once
every 4 clock cycles to do DMA from the same memory when the CPU wasn't
using it. High display resolutions would lock the processor out of RAM
except during blanking intervals. (Talk about contention and hot spots.)
Figuring out how to reuse resources most effectively was pretty much the
same as the register-allocation problem for compilers, and was sometimes
solved using the same kinds of graph-coloring algorithms...
More information about the Python-list