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

3 Answers 3


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
    Commented Sep 22, 2016 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
    Commented Sep 23, 2016 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
    Commented Jan 25, 2017 at 18:58
  • 1
    BTST is not a replacement for TAS - it is not multi-processor safe.
    – LOIS 16192
    Commented Jan 26, 2017 at 12:41
  • 2
    @LOIS16192 Which is pretty much irrelevant on all the Amigas I know.
    – tofro
    Commented May 18, 2017 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

  • 1
    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
    Commented Jan 25, 2017 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
    Commented Jan 26, 2017 at 12:08
  • Isn't that exactly the provision that fails for the TAS instruction?
    – tofro
    Commented May 18, 2017 at 14:18

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)

  • If Fast RAM is available, DOS loads the program's segments preferably into fast RAM. It can be forced to load stuff into Chip RAM via some flags on each Hunk, but that was seldom done and only to load stuff that certainly required Chip RAM (sounds, images). Yes I think the question still stands. For example in the A3000 and A4000 architecture Fast RAM should be pretty much directly connected to the processor I think?
    – user180940
    Commented Oct 28, 2019 at 13:18

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .