multi-core software

[Paul Wallich]

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