rossb...@mpi-sws.org wrote:
On Jun 8, 6:28 am, "Ken T." <nowh...@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...
--
http://mail.python.org/mailman/listinfo/python-list
