OK, I've looked at the code a bit, and I see at least one thing, even without knowing the particular processor - I can work out what many of the mnemonics mean, but not all of them. I did find a chart of the opcodes
on a quick Google search
, which I'm using for reference, and so far most of them have meant what I expected them to mean. Another search
found some general information about the assembly language syntax, too. However, I'm not going to pretend to really know 68HC11 assembly, so I will probably misunderstand some things.
In the first loop, which apparently is meant to initialize the array, the intended initialization seem to be [0, 8] in ascending order. However, the array index increment 'ABX' is cumulative; you are adding the current
value of B to the previous
pointer, which will jump exponentially (addr + 0, then addr + 0 + 1, then addr + 0 + 1 + 2, then addr + 0 + 1 + 2 + 3, and so on). If the array size is nine, then the pointer will pass the end of the array in five iterations.
One way to fix this is to separate the memory index increment from the initializer increment; since they really are different operations, and can be done with one-cycle instructions, you don't lose anything by doing so.
LDX #array1 * first addr in the array
LDAA #ArraySize * the size of the array
CLRB * clear the array initializer
BRA Init_test * jump to the first test
STAB 0,X * init the currently indexed value
INX * increment the array index
INCB * increment the initializing value
CBA * Is B < ArraySize?
(Not tested code, just used as an example.)
You'll notice two things about this version. First, I used the A accumulator to hold the value of ArraySize, to avoid an extra memory reference; while it can be tricky on a very constrainted register set like this one, it is preferably to use registers for as many operations as possible, especially in loops, as memory references are time-consuming. Also, I changed the order of the branches around, so that it skips a test at the bottom instead of testing at the top and then doing an uncoditional branch from there. Done this way, you can avoid one branch per iteration, which generally speaking is a good thing. Also, it allows you to use a 'while' type condition rather than an 'until' type condition, which most programmers find more familiar.
Actually, given that you are using the same array each time in this version, it may make more sense just to hard-code the starting array values as rather than initializing them; this way you can also test it with data that isn't already ordered; for example,
array1 FCB 5, 2, 23, 42, 17, 69, 57, 13, 255
AFAICT, the value set using FCB doesn't actually need to remain constant during the program run; from what I gather, 'Form Constant Byte' just means that it is initialized
to a constant value. If I am mistaken in this, you could still use this sort of pre-initialized array as a source value, which in some ways would actually make the sorting easier (since you can sort to the second array without having to do changes in-place).
Alternately, and probably most desireably, you could get the values fro the user somehow. However, I don't know offhand much about the I/O capabilities of the SBC or simulator you are testing this on, so I can't give any examples.