Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!ncar!noao!asuvax!behemoth!mph
From: mph@behemoth.phx.mcd.mot.com (Mark Huth)
Newsgroups: comp.sys.amiga.tech
Subject: Re: CHIP mem mystery code
Message-ID: <10851@behemoth.phx.mcd.mot.com>
Date: 5 May 89 01:06:44 GMT
References: <17545@cup.portal.com> <5482@cs.Buffalo.EDU>
Reply-To: mph@behemoth.UUCP (Mark Huth)
Organization: Motorola Microcomputer Division, Tempe, Az.
Lines: 27

In article <5482@cs.Buffalo.EDU> ugkamins@sunybcs.UUCP (John Kaminski) writes:
>
>As I undestand it, ANY of the 680x0 instructions that expect to be in full
>control are in serious trouble, and if I recall (from long ago) correctly,
>"btst" is one such instruction.  Very simply, the 680x0 is NOT guaranteed
>RAM access at any time.  Therefore, when working in CHIP memory, all sorts
>of DMA can be performed which the 680x0 did not expect.  Also, is it really
>necessary to be waiting in such a tight loop?  Cannot the process sleep
>while waiting for whatever?

On the 68000/68010/68012/68HC000 only the TAS instruction uses the
Read-Modify-Write cycle.  They do this cycle by holding ~AS asserted
for both memory cycles.

On the 68020/68030/68040? in addition to TAS, there are CAS and CAS2
instructions which do read-modify-write operations.  However, they do
it by holding a signal called ~RMC asserted and toggling ~AS normally.
Additionally, the 68851 PMMU chip can perform RMCs during certain
page descriptor updates.

An examination of the 2620 schematic makes me reasonably sure that
RMCs to the onboard memory cause no problems.  However, not having the
PAL equations, I cannot tell for sure what happens off board.  I'll
examine the other schematics tonight to figure out what really happens
with the chip memory when RMCs are performed to that address space.

Mark Huth