System09

in ALU is the original

when alu_lsr16 | alu_lsr8 => out_alu <= carry_in & left(15 downto 1); -- lsr

(carry_in is set to 0 whith alu_lsr16 and alu_lsr8)

it has to be (seperate 8 bit version)

when alu_lsr16 => out_alu <= '0' & left(15 downto 1); -- lsr when alu_lsr8 => out_alu <= left(15 downto 8) & '0' & left(7 downto 1); -- lsr

because bit 8 shifts into into bit 7 of the lower byte. according the datasheet the bit that shifts in should be a zero at all times.

Motorola: "LSR Logical Shift Right

Description: Shifts all bits of the ACCX or M one place to the right. Bit 7 is loaded with 0. The C bit is loaded from the least significant bit of ACCX or M."

By the way: the 6809 does not have a LSRD like the HC11

The same error is in the 16 bit version.

It appears that the same error is in the HC11 core

Thanks for the bug report.

This problem should only be evident on single operand instructions. When LSR8 is performed on ACCA or ACCB the left side of the ALU is used. The accumulators connect to the low 8 bits of the ALU left input and the high byte of the left ALU input is set to zero, so LSR8 will look like LSR16.

The problem arises when single operand 8 bit shifts are performed. The 8 bit data byte to be shifted is loaded into the low half of the MD register and the low byte is sign extended into the high byte. Under this condition, the MSB will not always be zero, but may be set to the sign (Bit7) of the LSB effectively performing an Arithmetic Shift Right (ASR8) rather than a Logical Shift Right (LSR8).

To overcome this problem I have moved LSR8 to the ASR8 and ROR8 when statement, which forces the high byte to zero. The carry_in will be the carry condition code for ROR8, it will be Bit(7) for ASR8 and will be zero for LSR8.

I have updated the code in the CVS to implement this correction. Thanks again for the bug report. I will look at the system11 code shortly althought it does not appear to be a problem as the MD register is not sign extended on the first byte fetch on CPU11.

Dilbert57.