assembly wrote:

Thank you very much for your reply. I'm now trying to revise all of what i've done.

The really problem for me is how to convert the string into hex. btw, will this way of input be the same even if it is specified that we'll be using single precision format or will it matter only on the operations? thanks. i'll try to post soon my latest copy. Cheers!

I'm not quite sure what you mean by "will this way of input be the same even if it is specified that we'll be using single precision format or will it matter only on the operations?"

Just remember, when you input a string, it is a string of ASCII characters that get stored to memory. If you use instruction number 2 in TRAP #15, and enter the string '123abc' which is a hexadecimal number, in memory you will have 49,50,51,97,98,99,0, which represents '123abc' in ASCII.

To convert to digits you can use, you can subtract 48 ( ASCII character zero 0 ) from a digit, and that will give you the correct answer if the digit was from zero to nine.

For the example I gave above "49,50,51,97,98,99", subtracting 48 from each digit gives "1,2,3,49,50,51" which is correct for the first three digits, but not for the last three.

To convert lower case ASCII letters a-f to numbers, you'll have to subtract a different number. For lower case, you'd subtract the ASCII code for 'a' and then add 10. In other words, subtract 87

For the example above, "97,98,99", become "10,11,12", which is the correct number for hexadecimal a,b and c digits. Also, upper case letters have a different ASCII code too, so you'll also have to take that into account.

Basically, just be aware that you'll have to treat ASCII characters 0 to 9 differently from letters a to b. But you may have known all this already. Sorry if I've been telling you things you already knew =X

Ignore everything from here onwards if you want. It's a bit technical, and might just confuse things and you don't really need to know it.

I notice you use the MULU instruction in the programme you posted. Which is fine. But there's a few limits with this command.

The first being, it will only multiply 16 bit numbers together, and give a 32 bit answer. You can't multiply 32 bit numbers together with it in the 68000 processor, because a 32 bit number multiplied by a 32 bit number could give a 64 bit answer, which wouldn't fit in the 68000s 32 bit registers.

The second problem with MULU is less important for an emulated 68000. But that problem is the MULU command is SLOOOW. On the real 68000, it takes something like 40-50 machine cycles to achieve a result, which is forever in assembly programming.

But, there's a cheat you can use to multiply faster, and using 32 bit numbers if you want. You use the command "LSL". Logically Shift Left. What this does, is shift all the bits to the left by a specified amount. For example

**Code:**

MOVE.B #%00010110,d0

LSL.B #1,d0

Command 1 puts the binary number %00010110 in the D0 register

Command 2 then shifts the bits left by the specified 1 place

So after than comand D0 contains %00101100

"Okay, so what?" you may be thinking. But we've just multiplied that number by 2

Don't believe me? Look. ( I'm assuming you know how to convert binary to decimal )

%00010110 = 22

%00101100 = 44

All without a mulu in sight. So how about we shift it again?

%01011000 = 88

and again?

%10110000 = 176. Which is double 88

Well, if you multiply something by 2 twice, that's the same as multiplying by 4. And if you multiply something by 2 three times, that's the same as multiplying by 8. And if you multiply something by 2 FOUR times, that's the same as multiplying by 16

So, if you shift all the bits in a number left by four places, you'll have multiplied it by 16.

So LSL.W #4,d0 gives the same result as MULU #16,d0

But LSL isn't limited to Word and Byte sizes. You can LSL.L #4,d0, which will multiply a 28 bit number by 16. With the left most bits falling off into nothing.

For example. %00001001101010010111000000010111 = 162099223 = $09A97017

Shifted 4 bits. %10011010100101110000000101110000 = 2593587568 = $9A970170

Which is correct, and something you couldn't do with just a single MULU command.

Anyway, if you didn't follow that last part, then nevermind. You can stick with MULU if you're happy using 16 bit numbers ( $0000 to $FFFF )

It's just a useful trick.