The (old) datasheet specified that MLB was active (low) for the last 3 cycles of a RMW instruction. I have found experimentally that this is not the case, at least with the DEC zp opcode. MLB goes low on the dead cycle after the first data (read) cycle, stays low for the next cycle (write data), then goes high for the opcode fetch of the next cycle. That's a total of 2 cycles. According to the datasheet, MLB is supposed to go low when the instruction fetches the data to modify.

Can anyone confirm for me or clue me in?

_________________
Thanks for playing.
-- Lord Steve

Weird... but, could you use a DEC absolute to $00xx instead ?
(opcode $CE)

--Jorge.

I could do that, but it still wouldn't explain why DEC zp doesn't bring MLB down low when it fetches the data to modify.

Could someone confirm this on hardware?

_________________
Thanks for playing.
-- Lord Steve

Does a DEC absolute $00xx do the same ?

--Jorge.

It does not matter if DEC doesn't drop MLB during the fetch, because it already owns the bus during the fetch. When the CPU relinguishes the bus for its internal operations, then it drops MLB so that no other processor uses the otherwise idle cycle, thus preventing potential changes to the read location.

Good point.

>The (old) datasheet specified that MLB was active (low) for the last 3 >cycles of a RMW instruction. I have found experimentally that this is not >the case, at least with the DEC zp opcode. MLB goes low on the dead >cycle after the first data (read) cycle, stays low for the next cycle (write >data), then goes high for the opcode fetch of the next cycle. That's a >total of 2 cycles. According to the datasheet, MLB is supposed to go low >when the instruction fetches the data to modify.
Hi Everyone,

This doesn't seem right. MLB should go low during the first data-read.

Cheers,

Paul