From: Spiro Trikaliotis (ml-cbmhackers_at_trikaliotis.net)
Date: 2005-10-05 12:09:19
Hello,
* On Tue, Oct 04, 2005 at 12:49:15AM +0200 silverdr@inet.com.pl wrote:
> On 2005-10-03, at 19:53, Spiro Trikaliotis wrote:
> >BTW: An unbuffered access to port A is available at $180F.
> >
>
> 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.
> >Now, the first EOR $1801 reads the last content AND clears the buffer
> >for the next value.
>
> Clears the "latch" you mean?
Yes. I had a short look into the 6522 data sheet(s) from Rockwell, MOS
and Synertek: It seems the VIA only latches if CA2 is actived (and if it
is actived in the corresponding register), thus, this description may
not be correct for your case.
> >This way, the next LDA $1801 clears A,
>
> ??
I don't know what I meant, either. ;)
> >but performs the handshake for
> >the C64 side to input the next data.
>
> The handshake seems to be done explicitly over the DATA line here,
> isn't it so?
Well, yes. Anyway, the 6526 and the 6522 can be put into modes such that
the C64 side actives CA2 on the floppy side for doing the above
handshake for the latch. I don't know if this is used in your code, this
depends upon how the 6522 and 6526 are initialized.
> >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.
Why can't the C64 be faster? Well, in the worst case, the BIT on the C64
side just got the changed value. Now, the BPL/BMI has to be executed (2
clocks as the branch is not being taken), before STA is performed (3
more cycles). On the other hand, the drive code executes the LDA only 3
cycles after writing the handshake, thus, it is 2 cycles before the
floppy side. Even with unsynchronized clocks (they do not run with
exactly the same speed), 2 cycles is enought to make sure to read the
old value.
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?
> Yes. The problem was twofold though. 1. I was expecting regular bytes
> here rather then EORed ones (after deeper digging I realised that I
> was looking at the wrong part of 64s code).
To be honest, I don't know why the programmer chose to use EOR. These take
exactly the same time and space as LDAs. I can only think of two
possibilities:
1. He found it to be "cool" to do it in a way one would not expect it.
2. This might be part of a copy protection scheme, and he did not want
the data sent over the parallel cable to be able to be analyzed to
easily with a digital analyzer.
Regards,
Spiro.
--
Spiro R. Trikaliotis
http://www.trikaliotis.net/
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.