Keep in mind that if you're on a IIIc, the Epson LCD driver is
SLLLLLOOOOOWWWWWW !!!!
You can saturate it easily, and that saturation occurs at only 1
megabyte/second.
So it actually pays to interleave other functionality while doing the
final copy to the screen.
Florent Pillet wrote:
>
> on 8/08/00 17:10, Tom Zerucha at [EMAIL PROTECTED] wrote:
>
> > Not true. The Dragonball has the ORIGINAL 68k core. The 68010 (which
> > wasn't in the Atari STs ever, and the original 520/1040 and the Megas
> > had 8 Mhz chips - but there was a 16mhz upgrade).
> >
> > The original 68k has NO cache.
>
> I'm not sure about this assumption. I think there was something like 16
> bytes of cache. Some copy-protection code on the Atari ST took advantage of
> it by self-modifiying code a few bytes after the current instruction, which
> would crash a debugger because of cache flushes but not the normally running
> program, for the same reason. Therefore, it seems that the 68k series has at
> least _some_ cache. Hmmm... I'll dive in the Motorola manuals to check this
> anyway, this may make a difference depending on the loop code size (I'm
> actually using a tower of move.w instructions, I'll try move.l and movems to
> see what difference it makes).
>
> Cheers,
> Florent.
>
> --
> Florent Pillet, Code Segment [EMAIL PROTECTED]
>
> BrainForest, outlines and action items for Palm OS handhelds
> -> Aportis Technologies Corp. http://www.aportis.com/
> PowerGlot, the premier localization tool for Mac OS software
> -> PowerGlot Software http://www.powerglot.com/
> Palm Buddy, MacOS active link companion for PalmOS handhelds
> -> ...and other tools... http://perso.wanadoo.fr/fpillet/
>
> --
> For information on using the Palm Developer Forums, or to unsubscribe, please see
>http://www.palmos.com/dev/tech/support/forums/
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/tech/support/forums/
