At 04:41 PM 04/03/1997 EST, you wrote:
>> From: John Dammeyer <johnd@ISLANDNET.COM>
>> [cut]
>> Here's one version of a binary-decimal conversion routine.
>> Call with r.hl having binary value; returns 4 digit packed BCD
>> in r.de -- I neglected the fifth digit  :-(  It can be
>> rewritten to preserve that extra digit.  To produce ASCII,
>> obviously you can append a code fragment to add '0' to each
>> unpacked digit.
>>
>> BinDec: LD B,16         ;7
>>         LD DE,0         ;10
>>
>> Loop:   ADD HL,HL       ;11
>>
>>         LD A,E          ;4
>>         ADC A,A         ;4
>>         DAA             ;4
>>         LD E,A          ;4
>>
>>         LD A,D          ;4
>>         ADC A,A         ;4
>>         DAA             ;4
>>         LD D,A          ;4
>>
>>         DJNZ Loop       ;13/8
>>
>>         RET             ;10
>> [cut]
>
>Hmmm... suspiciously like Z80 code, even down to the clock cycle
>counts, no?

Yup!
>
>
>> Finally I do welcome all input.  Especially if someone can improve on the
>> speed/space of this one.
>
>
>DAA is a bit tekno for this task.  My philosophy when it comes to
>binary to decimal decoding is that decimal is almost always used
>by humans (or printers) and hence speed is not an overriding concern.
>I would go for the most compact code.  Successive subtraction of
>powers of ten would be my first choice.  Actual division is
>certainly unnecessary.  Converting an unsigned 16-bit number to
>5-digit decimal requires a maximum of 27 2-byte subtractions,
>20 1-byte subtractions and 5 additions.

Please do post it.  ie: Put your opcodes down as evidence.

>
>Yes of course there are much smarter ways, but this is easy to
>understand and can be implemented fairly easily (even on a PIC).
>
>Now I realise there are always exceptions, but if you find yourself
>requiring more than a few decimal conversions per second, then rethink
>the application because no human can read that fast.

Well,  the 16C57 doesn't have interrupts.  I need to service I/O  quite
frequently.  I can't afford to spend a large amount of time in a subroutine
- including divide.  The above algo.  lends itself nicely to an iterative
approach.

ie: Using a flag, enter the routine, shift and calculate, leave the routine.
Do this 16 times and then set another flag that a different routine can use
as a conversion complete signal.  If tiem wasn't an object here or I was
using a PIC/8HC05 with interrupt support for time critical I'd stay with the
divide algo.  Short, simple, easy to follow as long as the 16 bit divide was
needed elsewhere.

Reagrds,

John


Pioneers are the ones, face down in the mud,
with arrows in their backs.
Automation Artisans Inc.      Ph. 1-250-544-4950
PO Box 20002                  Fax 1-250-544-4954
Sidney, BC CANADA V8L 5C9