(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.


  • 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?

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.

  • 1
    It would be great if you found some sources for the information in the last sentence of the third paragraph, and the second half of the fourth paragraph. There was little reason for them to update the system, but did they? And would it happen in any address range? – wizzwizz4 Sep 22 '16 at 10:34
  • @wizzwizz4 I find a lot of references to "don't do it" - But not a single one of what really happens in detail apart from "crash" or malfunction. My experience is: My Amiga 600 locks up if you do. Unfortunately, the answer needs to stay that way. – tofro Sep 23 '16 at 13:14
  • 1
    @wizzwizz4 If you end up in a concurrent write cycle between the CPU and Agnus (that's apparently what happens), the address actually written to is entirely random (both chips are driving the address lines and the result is "whoever supplies more force", i.e. random). You'd have to check the whole memory and I/O to find out where your write actually ended up. – tofro Jan 25 '17 at 18:58
  • 1
    BTST is not a replacement for TAS - it is not multi-processor safe. – LOIS 16192 Jan 26 '17 at 12:41
  • 2
    @LOIS16192 Which is pretty much irrelevant on all the Amigas I know. – tofro May 18 '17 at 9:12

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

  • Your answer is correct, but only half the story, I think. You're saying the TAS write is failing. With both CPU and Agnus accessing the bus at the same time, also an Agnus write-cycle can fail (or write into unexpected addresses because of address lines overridden by the CPU), which is probably far worse. – tofro Jan 25 '17 at 18:53
  • The CPU and Agnes Address/Data and control Lines were completely isolated by driver chips which were locked to half of the 4 clock cycle memory access operation by state machines, contained in the 2 PALs of the Amiga 1000. This ensured no bus-fights (the psuedo technical term for multiple drivers operating at the same time) or false writes. – LOIS 16192 Jan 26 '17 at 12:08
  • Isn't that exactly the provision that fails for the TAS instruction? – tofro May 18 '17 at 14:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.