silverdr_at_inet.com.pl
Date: 2005-10-06 01:31:01
On 2005-10-05, at 12:09, Spiro Trikaliotis wrote:
>
> 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.
Could you send me the MOS version in a spare second if you don't mind
me being lazy on google? I found the strange WDC one as for now (true
- didn't spend too much time googling on that ;-)
[...]
>
>
> 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.
I see. No, I didn't notice any "strange" inits to the VIA.
>
>
>>> 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?
Yeah - that looks like a possibility I am one of those who fell for
that ;-)
> 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.
I slowly start tending to believe in this while I still don't really
understand how it works. I think that I'll try to rewrite it myself
and see if it still works after that... Just need to get back to the
real hardware as my VICE has some problems with this code.
>
> 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.
Less probable I guess. It's a part of one of the 15sec copy versions,
which doesn't have much to do with copy protections, but of course
the routines might have originally been written for other purpose.
--
Staring into a computer screen is like staring into an eclipse. It's
brilliant and you don't realize the damage until its too late
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.