TSB and TRB are atomic if correctly used. Also, the 65C02 does tell you when atomic access to RAM is needed during a R-M-W instruction. Your glue logic should be able to handle that.

That said, I surmise your problem has nothing to do with the atomicity of R-M-W instructions and everything to do with proper task-switching timing. Task-switching timing is going to take careful analysis and programming—for example, if a task is about to set a semaphore you have to inhibit task switching for the duration of the operation so conflict doesn't arise. You'd also need to account for what could happen if the semaphore was already being manipulated when your task tries to manipulate it. That can get tricky and result in deadlock if not carefully handled.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Yes, via the ML pin, and the glue logic that relates to that is what I'm trying to figure out.



I... don't really see how. There isn't any task-switching. There are two separate processors that have access to a shared RAM, but each processors is single-threaded and running constantly, so there's no task-switcing per se. Just two tasks running in parallel. The beautiful thing about Test-and-Set as a semaphore primitive is that, provided the instruction itself is atomic, it guarentees mutual exclusion for two competing processes.

CPU A and CPU B both execute on the same semaphore memory location; CPU A arbitrarily gets in a fraction sooner and the bus arbiter holds CPU B. CPU A reads a zero, so Z is set, then it writes back a '1', all within one atomic instruction. It has acquired the lock and can proceed on its merry way. Now, CPU B is released by the bus arbiter. It reads the '1' left behind by the previous instruction, so Z=false. It also writes a '1', but that's not a problem because that's what it was already. The TSB instruction is followed by a BNE spinlock, so it just keeps looping back and trying to do that TSB over and over until CPU A clears the byte, so it reads a zero, acquires the lock, etc.

The key thing is that only works if TSB is guarenteed to be atomic, i.e. that CPU B won't be able to read a '0' out of the semaphore before CPU A has had a chance to change it to a '1'. Therefore to make this scheme work, I need to use ML to guarentee the atomicity of TSB (and by extension all R-M-W instructions). I guess what I'm getting at is I'm fully aware that higher level software will require semaphores to synchronise access to shared RAM. My intended solution is the Test-and-Set, which requires the TSB instruction itself be guarenteed atomic, so I need to make it atomic at the hardware level - software semaphores won't work because bus arbitration happens on a cycle-by-cycle basis, not instruction-by-instruction, so there's no way for the software to "know" in time.



Incidentally, perhaps a moderator would be kind enough to split this topic? It has now significantly diverged and the topic title is therefore misleading.

_________________
Want to design a PCB for your project? I strongly recommend KiCad. Its free, its multiplatform, and its easy to learn!
Also, I maintain KiCad libraries of Retro Computing and Arduino components you might find useful.

How about this circuit?

Note that the two controlled buffers are not "part of the circuit", they're just there because logisim cannot directly emulate open-drain pins. Also note that Busy to X input and ML inputs are inverted (that is, active HIGH) on this diagram; hence that inverter is also not a part of the circuit.

Anyway, what happens is normally ~BUSY is passed to RDY unchanged. ~BUSY is normally asserted by the bus arbiter if both processors try to access the same RAM location at the same time. However, if ~BUSY and ~ML are asserted simultaniously, then that gets saved into the D Flip Flop, causing RDY to continue to be held low - even though ~BUSY would normally be released during PHI2 low because of the way the bus arbiter works. RDY will not be released until ~ML is released, which based on the infamous Table 5-7 in the 65C816 datasheet, should not happen until the part of the R-M-W instruction that needs to remain atomic has completed.

Thoughts?

_________________
Want to design a PCB for your project? I strongly recommend KiCad. Its free, its multiplatform, and its easy to learn!
Also, I maintain KiCad libraries of Retro Computing and Arduino components you might find useful.

Here's the same circuit again, but with the signals active low as they are in the real deal, and annotated to show how it might be built out of actual glue logic.

_________________
Want to design a PCB for your project? I strongly recommend KiCad. Its free, its multiplatform, and its easy to learn!
Also, I maintain KiCad libraries of Retro Computing and Arduino components you might find useful.

If you TSB an individual bit (1 for up to 8 CPUs) and then CMP that semaphore byte it should work. If the CMP doesn't match some other CPU did the same, so you should TRB then wait a while (ideally this delay should vary) and then retry.

Somehow a similar strategy was chosen when ethernet busses where really busses (not switched point to point connections). When the bus seems free they issued their packet, detect the collision and retry with individual delays. It worked

Of course, your HW solution is faster.


my 1/2 cent

UTP networks using hubs experience frequent collisions and hence require the random delay. It's still part of the Ethernet specification, although in practice collisions are not likely to occur on modern switched networks.

I recall a client (a busy insurance office) using a 3Com hub that had a collision detection indicator on it. That indicator was on most of the time. I finally convinced him to invest in an Ethernet switch, at a time when a switch was a costly piece of hardware. He was skeptical that the investment was worth it but quickly changed his tune when he saw a significant performance increase on his network.

Back in the days when I wrote software for the Xetec Lt. Kernal hard drive subsystem I used the random delay technique to arbitrate file and record locking. I got the idea from Ethernet.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Just complete to the discussion, I figured out that you need a diode, pointing left on the diagram above, with pull-ups on both sides, otherwise there is a rare circumstance involving WAI where the system could become deadlocked.

Your TSB/CMP solution is interesting, though I prefer the speed of the hardware solution. I'd probably have to use the TSB/CMP method if more than two devices were sharing the same RAM, luckily the architecture I have is each slave has its own shared RAM - so slaves are not aware of eachother, only the master.

_________________
Want to design a PCB for your project? I strongly recommend KiCad. Its free, its multiplatform, and its easy to learn!
Also, I maintain KiCad libraries of Retro Computing and Arduino components you might find useful.