Re: ROM Dump of Amiga Keyboard controller

From: Marko Mäkelä <>
Date: Wed, 2 Jul 2014 09:56:12 +0300
Message-ID: <20140702065612.GC2020@x60s>
On Wed, Jul 02, 2014 at 09:34:32AM +0300, Marko Mäkelä wrote:
>On Tue, Jul 01, 2014 at 06:13:59PM -0500, Jim Brain wrote:
>>   send_data(0x2C);
>>   send_data(0x24);
>>   send_data(0xEA);
>>   send_data(0xEA);
>>   send_data(0x78);
>>   send_data(0x78);
>>   send_data(0xA9);
>>   send_data(0x55);
>I do not think that this will synchronize. If the processor fetches 
>the 0x2c byte as an instruction (BIT $ea24), it will next execute 
>0xea78 as NOP, and 0x78a9 as SEI. After that, it will fetch 0x55, 
>which is not intended (you wanted LDA#$55).

Sorry, I realized that I am wrong. The 3-byte BIT (0x2c) is of course a 
4-cycle instruction, so it would be directly followed by the SEI 

The 2-byte BIT (0x24) is 3 cycles, so it would be followed by the SEI as 

The NOPs after the BITs should be unreachable, because this string of 
instructions was being preceded by enough padding to ensure that the 
processor will fetch and execute either the 0x2c or 0x24. So, you could 
replace the two 0xea with 0x02 and it should not make a difference.

It could make sense to use 0x78 (SEI) as the padding byte instead of 
NOP. In that way, we can be more sure that there is no IRQ that would 
interfere with our processing. (Does the chip contain an internal 
interrupt source?)


       Message was sent through the cbm-hackers mailing list
Received on 2014-07-02 07:00:33

Archive generated by hypermail 2.2.0.