Re: ROM Dump of Amiga Keyboard controller

From: Gerrit Heitsch <>
Date: Fri, 18 Jul 2014 21:33:56 +0200
Message-ID: <>
On 07/18/2014 09:11 PM, wrote:
> Yes, this part was clear. Still thanks for such a well-presented explanation here once more. If you don't mind, I would use parts of it? It was the part about the clock phase, which was not so clear.

Feel free to.

>> The other thing I remember was that the 6500/1 does divide the
>> externally supplied clock by two. But the longer I think about it, the
>> less I see that as a problem as long as you feed the bytes at the right
>> speed (meaning half the clockspeed), the clock phase is of no
>> consequence as long as the data read by the CPU is stable the moment
>> it's sampled.
> How I understood it, is that this internal clock, which is the one actually dictating the CPU's actions (fetching opcodes/data), might be oddly phased in regards to the supplied one. This could theoretically lead to a situation when we /think/ we supply the data to the port using the correct timing but in reality it happens to be improperly timed, like too late for example.. ?

Lets see...

                      1    2     3     4     5
                     __    __    __    __    __
External clock:  __|  |__|  |__|  |__|  |__|  |__

                     _____       _____       _____
CPU clock     :  __|     |_____|     |_____|     |

You only know the external clock, but not the phase difference to the 
internal one. So when do you supply a new byte? At 1, 3, 5 or at 2 and 
4? Rising edge, falling edge or the middle of the stable period? The 
divider is probably just a simple flipflop so the phase shift should be 

As long as you do it in a way that the date is stable when the CPU 
samples it (falling edge of its clock/PHI2 if I remember right), 
everything will work and the exact timing is not relevant as long as the 
time between command bytes is 2 periods of the external clock. So safe 
points are rising and falling edge of 1, 3, 5 and falling edge of 2 and 
4. The rising edge of 2 and 4 would be the problematic part where the 
data might not be stable. The safest way would be in the middle of the 
HIGH or LOW portion of the external clock, that should always work. 
Together with the rather slow clockspeed supplied (250 KHz external 
clock?), it should be stable at the sampling moment.

Does that make sense to you?


       Message was sent through the cbm-hackers mailing list
Received on 2014-07-18 20:01:03

Archive generated by hypermail 2.2.0.