| |
oziphantom
Registered: Oct 2014
Posts: 478 |
CIA SDR Race condition
Does the SDR on the CIA have a race condition?
If you write before it runs out, it will auto load the byte and send
If you write after it runs out, it will auto load the byte and send
If you write when it runs out, does this then stuff up? |
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11111 |
good question - test it :) |
| |
oziphantom
Registered: Oct 2014
Posts: 478 |
well I think I am ;)
I have one system like so
Wait till flag is set to say byte has arrived
Toggle Clock
store byte
loop
and another on the other end
Send Byte
wait for clock to toggle
loop
This works for 59 bytes, then first one is waiting for a byte to arrive which it never does, and the 2nd one is waiting for the clock to toggle after having sent the byte.
This is all in VICE BTW.
Which makes me think that the 2nd one wrote the byte but it didn't latch, so it doesn't send. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11111 |
uh, i wouldn't trust VICE at all for this stuff - since the shift register isnt used for anything (in the c64 emu) and it cant be tested easily (on a single machine) chances are that the emulation is simply broken :) |
| |
lft
Registered: Jul 2007
Posts: 369 |
When you say "store byte", does that also involve fetching the byte from the CIA? I'm thinking, what if the first party toggles the clock, but before fetching the byte, the second party has already had enough time to transmit a whole new byte, overwriting the first. When this second byte arrives, the flag is already set, and remains set. When the first party thinks it is reading the first byte, it is actually reading the second byte, and clearing the flag. It then waits for the flag to be set again, which never happens, because the second party is waiting for a second clock transition.
This could happen e.g. if the first party got delayed at the wrong time by an interrupt. |
| |
oziphantom
Registered: Oct 2014
Posts: 478 |
I think you have the right idea, but for the wrong reason.
Both sides have interupts disabled but. If one steps through in VICE you get this.
What you expect to happen
A 1Mhz vs B 2MZ
clock
clock
clock
clock
clock
clock
clock
clock
clock
What actually happens
A 1Mhz vs B 2MZ
clock
clock
clock
clock
clock
clock
clock
clock
clock
clock
clock
clock
clock
clock
clock
clock
clock
clock
clock
clock
clock
clock
clock
clock
clock
clock
clock
clock
clock
clock
clock
clcok
clock
clock
clock
clock
So it is entirely possible what you said happened. |
| |
Martin Piper
Registered: Nov 2007
Posts: 634 |
This pattern is very familiar when debugging drive code. |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Is this on C-64? Because the hardware clocking and handshaking has been broken from the start and only fixed with the C-128, hence the abysmally slow ROM loading using bitbanging and no fastloader on C-64 using hardware bitshifting.
Edit: Never mind, i guess you're not on the serial bus here but rather the user port. |
| |
oziphantom
Registered: Oct 2014
Posts: 478 |
128 + 1571 |
