hello,
I am working with Motorola 68000.
I have to make a program wich
will add the BCD number NUM1=22875362 saved in memory $400400-400403,
the BCD number NUM2=635213 saved in memory $400404-400407 and it will stores the sum in memory $400400-400403. Next it will removes from the sum stored in memory $400400-400403 the BCD number NUM3=17195312 stored in memory $400408-$40040B and the result will be stored at memory
RESLT= $40040C-$40040F. At the end of the program the memory address $400400-400403 must have the sum of the first 2 BCD numbers.

I've done the program but when i use the assembler 68k i take sum = 5315263 and the pointer X=1
When i use the assembler Easy68k i take sum = 6315263 wich is the correct number. Any idea?

I've attached the code below so u can use

Mike

 

Mike,
When you add the BCD numbers 22875362 and 00635213, you should get 23510575. Then when you subtract the BCD number 17195312 from the sum of the first two, you should get 6315263, which is what you reported that you got.

It looks to me like your assembly code got the correct value for the sum of NUM1 and NUM2, otherwise you wouldn't have gotten the correct value for NUM3.

I'll take a closer look at your code in a few hours so I can see what's going on.

I don't understand what you said toward the end:
"when i use the assembler 68k i take sum = 5315263 and the pointer X=1"

What do you mean by "pointer X=1"?
Also, are you saying that you ran the code on a M68000 chip using an assembler, and also ran the code on some other machine using the Easy68k emulation software, and that you got different results?
Mark

 

I don't understand what you said toward the end:
"when i use the assembler 68k i take sum = 5315263 and the pointer X=1"

I have 2 programs for assembling the txt file.The first is called 68000sim running in dos and the other called Easy68k in windows mode.
In the Status Register, the user byte contains the flags X,N,V,Z,C from byte d4-d0.These flags called Condition Codes.

C Carry
V Overflow
Z Zero
N Negative
X Extent

When i use ABCD -(A1),-(A0) the machine add A1 into A0 + The EXtension flag.
First the sum it's correct, runned with the 2 programs ok!
But the Substraction gives as result

with Easy68k >> 6315263 (X=1 , C=0 , V=0 , Z=0 , N=0) Correct
with 68000Sim >> 5315263 (X=1 , C=0 , V=0 , Z=0 , N=0) Wrong

I can't understand why this digit difference

Mike

 

Mike,
Since you're running the same code through both emulators and getting different results, and since the result you're getting on Easy68k is the correct answer, it looks to me like there's a bug in 68000Sim.

BTW, some of your comments are wrong. Since they're comments, they don't affect how your code runs, but they could mislead a reader.

ADDBCD  LEA     NUM1+4,A0	//A0 points the 4th byte of num1

A0 actually points to the 5th byte after the start of NUM1, which is just beyond NUM1. You have three other comments that are almost the same.
It works this way:
As addresses used in LEA,
NUM1 is the first byte of NUM1
NUM1 + 1 is the second byte of NUM1
NUM1 + 2 is the third byte of NUM1
NUM1 + 3 is the fourth byte of NUM1
So NUM1 + 4 is the fifth byte

The reason you're loading the address of NUM1 + 4, which is one byte beyond the last byte of NUM1, is that in your ABCD instruction, the first thing that happens is the decrement of both address registers, A0 and A1, then the BCD addition happens. The decrements cause both address registers to point to the last byte in each of A0 and A1. The last (fourth for longwords) is the LSB, so the first time through your loop you're adding 62 and 13, getting 75, and this is what should show up in the byte at the address that A0+3 points to. There's no carry, so I think this means that X is still 0.

The same thing happens each time through your first loop, producing another BCD-coded byte that goes in the current byte that A0 points to. The second pass through this loop you have a carry, so I think X in the CCR gets set to 1, which will get added in the third pass through the loop.

Does that make sense?
Mark

 

I've run your code and don't see any problems with it. I'm getting the same results you're getting with EASy68K, and those results are consistent with calculations done by hand.

The only thing worth additional comment is when you reset the CCR condition codes using

MOVE #$EF,CCR

Since all you wanted to do was clear the X condition code, you could have done this:

ANDI.B #$0F,CCR

It might be that you haven't learned this instruction yet, but it's very useful when you want to clear (make equal to 0) certain bits. With the ANDI instruction in the example above, the upper 4 bits of the CCR are cleared (made equal to 0), and the lower four bits stay whatever they were. It doesn't matter that I cleared bits 5, 6, and 7, since they aren't available in user-mode programming. If you use MOVE to copy a value into the CCR, you overwrite whatever is there, running the risk of wiping out information that you didn't mean to change. There's also an AND instruction.

There's another instruction, ORI, that can be used to to turn on selected bits. There's another version that works about the same way, named OR.

Mark

 

Mark i understand what u said, I'm gonna do some excercise with the SR register and how to change the condition codes.

mike