Quote:
Originally Posted by Toni Wilen
Use of NOP is still technically wrong. Some fast RAM 68060 board can still fail (or some future board with overclocked CPU and/or very fast on board RAM, like ACA1260)
NOP only guarantees write has finished from CPU point of view, it won't guarantee following RTE can't finish before Paula notices the IPL change (1 extra CCK).
|
The MMU plays an important role dealing with cashmodes. Especially the data cache is the problem on the 68040/060. Normally the CUSTOM chip address space is marked as "cache inhibited, precise mode" which means that the write to the address $00DFF09c is not cached in the data cache and the sequence of read and write accesses to the page is guaranteed to match the sequence of the instruction order. This cache mode can be set via a translation table or by the DTTR0/DTTR1 registers.
Normally, if the store buffer on the 68060 is enabled, operand writes using this buffer, the operand execution pieline incurs no stalls. But in the "cache inhibited, precise mode" this buffer is bypassed and system bus cycles are generated directly for each pipeline operation. This means, that each write operation is stalled for a minimum of five cycles. This also leads to a delay writing the the INTREQ register and shows how important it is to use the nop command for a bus syncronisation.