Was the MC680x0's TAS instruction forbidden on Amiga systems only when operating in CHIP memory?

Question

(Note: a previous version of this question asked about the CAS instruction, that was added by Motorola from the MC68020; the original one is the TAS instruction).

TAS is the acronym for Test And Set, an instruction that is used to create multiprocessor-safe shared data structure. The MC680x0 instruction set reference describes its operation as:

Tests and sets the byte operand addressed by the effective address field. The instruction tests the current value of the operand and sets the N and Z condition bits appropriately. TAS also sets the high-order bit of the operand. The operation uses a locked or read-modify-write transfer sequence. This instruction supports use of a flag or semaphore to coordinate several processors.

The atomicity is realized via a special bus cycle that external peripherals must not break.

The official Amiga programming guidelines state that TAS must not be used on an Amiga as it can lock the machine. As far as I remember, the reason is that Agnus can't deal with this special cycle.

However:

• Was this later fixed in one of the latter Agnus revisions (Fat Agnus, Super Agnus) and/or AA's Alice?
• Is is really only Agnus (or Denise/Lisa and Paula too) the culprit or are the "glue logic" chips (Gary, Fat Gary, Gayle, Buster, Super Buster, Bridgette, Ramsey...) responsible for it too?
• Does it affect all of the 24 bit original address space or just Chip RAM access (e.g., does it work in "Slow Fast" RAM? Does it work in the Zorro II address space?)
• Is the address space above the 16MB marker free of the problem?

Answer 1

In order to detect whether the bus is "free" to access and it is safe to halt the CPU, take over the bus and access memory and peripherals, the Agnus and later DMA chips monitor the control bus for a CPU access. The first part of the TAS cycle "looks" to the Agnus like every normal memory read cycle, and once the read part of the cycle is done, Agnus will assume it can halt the CPU. This was an omission of this specific bus condition in the Agnus design.

In "normal" cycles, the 68k would then just stop and put its bus output into tri-state, effectively releasing the bus for access from external devices. While a TAS cycle is happening, it will, however not do that, but keep on running and driving the bus until its TAS write part of the cycle is finished, even if /HALT is asserted by Agnus. Now we have two devices driving the bus and basically everything from nothing (because Agnus doesn't "need" the bus at the moment) to bad (Agnus writing to memory concurrently with the CPU) to disaster (bus lock because of undefined control bus states) can happen.

Pretty much anything you can do with a TAS instruction on an Amiga (if you could) can also be achieved with a BTST.B instruction - TAS is partially redundant and easy to avoid. Thus, I don't think Agnus or its descendants have ever been updated.

Because the TAS issue is not in any way related to addresses, but rather bus sharing (Agnus thinks it owns the bus but doesn't), my guess is it would happen in any address range - For the problem to occur, it is actually totally irrelevant afaik what's on the address bus.

Answer 2

This is a quick answer. The TAS instruction is a Read Modify Write operation and the Write may not succeed because the TAS instruction is the only instruction 5 half-cycles long. All other operations are an even number of cycles.

Simplified the CPU is never halted, or grants the bus it is only delayed. Half the accesses (odd) to the Chipmemory are dedicated to the chipset and invisible to the CPU. The other half (even) are only available to the CPU if the chipset did not use them.

A TAS instruction attempts to write during the odd cycle and this is not permitted at the hardware level.

I can go into more detail if there is interest, or you can review the TAS timings at page 4-6 in the 68000 Users Manual at http://www.nxp.com/assets/documents/data/en/data-sheets/M68000UM.pdf

Answer 3

Interesting question. It would hinge on whether anything other than the CPU is able to interfere with Fast RAM, or attempt to interfere with the CPU whilst it's in the middle of a TAS cycle.

The problem with running it in Chip memory is that it's non-interruptible, and the Amiga architecture (as per that of many other contemporary 68000-based, shared video memory, single processor machines) hinges on being able to insert 2-clock video memory-access cycles in the "idle" parts of the usual 4-clock 68K memory access, using buffers in the chipset, and asserting waitstates on the processor to briefly halt it (for 1 to 3 clocks) if it happens to execute a longer-running instruction that means it attempts to start a memory access cycle outside of that usual 4-clock aligned rhythm (and, in certain video modes in the Amiga, for a clock or two at the end of each scanline, to keep it locked to the correct broadcast scan frequency). Obviously, a 5-cycle memory access instruction that is, by design, noninterruptible, and sends the processor into a seizure if it can't complete as intended, upsets that particular applecart somewhat.

Ideally, Fast RAM is dedicated entirely to the processor, and one of its main benefits is that there's no limits on how it's timed (even with the chipset using a video mode that would otherwise cause the CPU to be halted much more of the time than usual, there's no slowdown, and it can execute unaligned instructions to its heart's content without even the usual minor stuttering that would cause; and, of course, it can have faster and higher-end chips like the 68030 attached, which have shorter inherent memory cycles, and operate those at their native cycle alignment)... therefore it can do whatever the dickens it wants to within that realm, including executing TAS instructions. If that is indeed the case, then I don't see why it shouldn't be legal to do so... notwithstanding that it's intended (IIRC) as a method of ... message passing? checking for bus/process lock? in a multiprocessor system, so you'd have to be running an Amiga expanded with not only Fast RAM but an additional 68000 (or better) set up not as a system-overriding accelerator but a true parallel coprocessor. Which kinda limits its usefulness and the cases in which you'd want to code it into your program in the first place, because I don't know if I've ever heard of a multiprocessor Amiga before.

(Also you'd need be able to absolutely ensure that your program was running 100% in FastRAM and there was no possibility that the crucial parts of it executed from Chip ... I'm not expert enough about that to know whether it's difficult, but I do remember seeing utilities to force programs to prefer loading into FastRAM first if at all possible, so it's certainly not an automatic thing that the system does, and even that wouldn't seem to make it guaranteed)