silverdr_at_inet.com.pl
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
immediately...
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.