On Thu, Aug 10, 2000 at 03:57:13PM +0200, 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).
That is NOT how it was done on the ST. What usually happened is that
someone placed something ABOVE the stack with interrupts disabled.
Since the debugger used trap instructions, it would overwrite that
code with the trap stack frame.
No cache. None. Nada. I still have the original 286 v.s. 68000
architectual comparison and they would have trumpeted it back then if
it had it (they did everything else - If only IBM chose the 68K for
the original PC...). I also have (and you can get) the instruction
timings - which vary slightly but not anything with cache (the 68010,
and CPU32 cores note this in the appropriate sections, and the
680[2346]0 series gives guidelines but explains the cache makes
determinism nearly impossible.
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/tech/support/forums/
