In article <NETBSDList.1nnm@arcticus.burner.com> isthesin@TechFak.Uni-Bielefeld.DE (Stephan Thesing) writes:
> As far as I recall it from the introduction to the RKM Manuals the reason
> why one can not use TAS instructions is with the hardware:
> The AMIGA shares the memory bus between many components (CPU, blitter,..)
> There is a fixed scheme, which cycles can be used by whom.
> Especially the CPU is denied access to the bus whenever display or
> blitter access has to be done.
> It would be impossible to keep the CPU from accessing the bus with
> an undividable RWM cycle of the TAS instruction.

  As I recall, the CPU takes a lower priority on the chipram bus than almost
everything (display DMA, sprite DMA, sound DMA, floppy DMA, blitter drawing).
So, the CPU could get preempted from the bus in the middle of one of these
TAS instructions.

  However, as I recall, this only happens on the chipram bus. Any Amigas
that are capable of running NetBSD are 020+ and have Fast ram. As I recall,
NetBSD will not put any code in chipram, only using it for the display.

  A TAS instruction could only get interrupted if either the code or the
data operand were in chipram. Your code will never be in chipram, and as
long as you don't use TAS to set semaphores in chip ram it should run fine.

  Though...
  Could be a cool debugging technique to use pixels onscreen as your
semaphores, you'd always be able to see what was going on. Kinda like having
the ol' bus LEDs from an Altair or IMSAI or (something older than I am)... ;)

> Just my $0.04 (tax incl.)
> 	Stephan

  Well, somebody correct me if I'm wrong, but I suspect this would work. Maybe
someone could hunt up one of the old C= hardware guys (D. Haynie or Chris
Green would both probably know for certain) on one of the c.s.amiga.* groups.

Chris - Xenon
-- 
 Chris Hanson | Xenon@arcticus.burner.com | I've got friends in low latitudes!
 "There is no Truth. There is only Perception. To Perceive is to Exist." - Xen