🚀 go-pugleaf

From article <8805222049.AA02208@cory.Berkeley.EDU>, by dillon@CORY.BERKELEY.EDU (Matt Dillon):
> 
> :What I said was that the ST 68000 is usurped for video refresh - this
> :is of course incorrect. What I meant to say was that ths ST's 68000
> :is usurped to move information around on the screen (including any
> :text). I was aware of this all along, guess I slipped 'cos I was
> :a little peeved at the tone of the original message - my apologies
> :to all.
> 
> 	Correct me if I'm wrong, but my understanding was that in color
> mode video refresh does not take cycles from the 68000, but in monochrome 
> mode video refresh DOES.
> 
> 						-Matt

At no time ever does video refresh "directly" take time away from the
68000 on the ST.  However because the ST's cpu and the video refresh
system run at different clock rates they can get out of sync.  This
can happen in any mode, and causes an added wait state.  This is why
when cpu-only speeds of the ST and the Amiga are compared you don't
just say that the ST is 8/7.16 (?) percent faster; you have to give
a range (say 5-15% or so).

Also, monochrome mode on the ST is NOT "directly" slower; the amount
of memory that the video shifter has to access in monochrome mode can
"normally" be accessed in cycles where the cpu is off the bus, similar
to what happens in a color mode.  Where you might see a slowdown is:

    a. depending on the exact program being run, you might see the
       "out of sync" condition described above in the first paragraph
       more often.

    b. normally the ST has a not insignificant amount of code connected
       to the vertical blanking interrupt (and user programs can enable
       other video interrupts).  This code will get called more often
       in monochrome mode.

dgc