[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Trouble with freeMinT 1.15.0



> What exists is the M68000PM/AD (M68000 family programmer's manual). The
> M68040/M68060 data books contain the additional parts (on movec special
> registers, cache/PMMU etc.).
> 
> All those manuals are available from Motorola in electronic form (PDF) or on
> paper - for free if you order them via the web.

Hm, good. Thanks.
 
> > I would suspect, that switching the cache off for the time of MiNT
> > initializations (i.e. for installing handlers, initializing memory,
> > filesystems etc) would solve the problem. Especially if, as I understood,
> > problems occur only at bootup, i.e. if MiNT finally starts, it works OK. 
> 
> Probably - although you still need to be a bit careful: the '040 has a write
> pipeline which can *not* be turned off. After modifying a trap vector, you
> need a NOP to flush the pipeline if one of the next instructions can cause
> the trap:

Well, my first guess was that there are pipeline problems and I of course
know the function of NOP (it flushes the *read* pipeline on 68030).

However, Frank told me about something that I consider strange, thus would
be glad to verify that. Namely, the GEMDOS timer handler routine is
supposed to make problems if it is ended by:

	move.l	_old_timer,a0
	jmp	(a0)

and the whole thing works better if it is ended by:

	move.l	_old_timer,-(sp)
	rts

I must admit that I hardly understand it. Considering the jump, both
fragments of code do exactly the same, but different way. The first
version does one read memory cycle, then jump, while the latter does
read-write-read. Could it matter? 

Of course, both work fine here, I'd prefer the first because it is a
little bit faster.

And, is documentation right when saying that GEMDOS timer routine doesn't
need to preserve registers?

> It is quite probable that modifications somewhere else in the code can cause
> cache-related problems to show up. I had multiple cases like this on Milan -
> and the MiNT crash on startup with enabled caches only showed on some
> machines, and with certain TOS versions.

Thus again, perhaps it might be useful to switch caches off for the time
of initialization and add NOPs somewhere to keep pipelines happy.

--
Konrad M.Kokoszkiewicz
|mail: draco@mi.com.pl                  | Atari Falcon030/TT030/65XE |
|http://www.orient.uw.edu.pl/~conradus/

** Ea natura multitudinis est,
** aut servit humiliter, aut superbe dominatur (Liv. XXIV,25)
*************************************************************
** U pospolstwa normalne jest, ze albo sluzy ono unizenie,
** albo bezczelnie sie panoszy.