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 (0x7878). The 2-byte BIT (0x24) is 3 cycles, so it would be followed by the SEI as well. 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?) Marko Message was sent through the cbm-hackers mailing listReceived on 2014-07-02 07:00:33
Archive generated by hypermail 2.2.0.