Re: drive-side routine - mystery solved...
Date: 2005-10-06 20:09:52

Seems that one short session on the real hardware, where I was able  
to promptly check everything, cleared the remaining doubts  

On 2005-10-05, at 12:09, Spiro Trikaliotis wrote:

>> That's another interesting thing. You mean the status of the port
>> bits on $1801 is a kind of "latched" one and the same bits are real-
>> time accessible at $180f?
> Yes, exactly. It does not have to be latched, you can enable or  
> disable
> it.
> I only noticed (was bitten) this once when I had a problem with the DC
> ($1C01) where the first byte was always wrong. I found out that LDA
> $1C01; LDA $1C01 immediately one after the other fixed that.

This is a very important hint!


>>> While the floppy perform the BVC *,
>>> the C64 has enough time to put the next value into the port which is
>>> read by the 1541 via the EOR $1801 again.
>> The weak point for me here is the LDA $1801. It happens immediately
>> after sending the handshake, for which the 64 waits. What is then
>> being read? Since 1541 is faster than the 64, chances are that the
>> port is being read before 64 puts the next value on the port, am I
>> right? Race condition comes to mind...
> Well, the C64 cannot react that fast. This is impossible, as both
> 6502/6510 run at almost the same speed, and the C64 is waiting in a
> loop. Thus, you read the old value.

Seems correct - and important.

> Why did the programmer add the LDA? I don't know. Perhaps, he wanted a
> delay of 3 cycles? Perhaps, he wanted to confuse others?

It seems for clearing the "latch". When I replaced EOR:LDA with  
LDA:LDA (on both sides) everything worked as properly. But when I  
removed the LDA immediately after the handshake, leaving only one as  
I would normally do - it no longer worked reliably. My current best  
guess is that it has to do with what has once bitten you.

> To be honest, I don't know why the programmer chose to use EOR.  
> These take
> exactly the same time and space as LDAs.

Once I got the above working, I rechecked the whole flow again and  
found out that he does a primitive checksumming with those EORs and  
then "verifies" the checksums if that option is enabled, which I  
didn't use earlier. Now I set it as default for further actions.

Thanks to all of you guys, Spiro being the first in line as without  
those few hints I would certainly have spent more time trying to  
figure those out.

Arise, Sir Plenty of Bugs, Sir Mega of Lomaniac,
Sir Screen of Blue, Sir Embrace of Extend,
Sir 640 of K....

       Message was sent through the cbm-hackers mailing list

Archive generated by hypermail pre-2.1.8.