48589 $BDCD LINPRT
OUTPUT a Number in ASCII Decimal Digits
This routine is used to output the line number for the routine above
(INPRT - 48576 $BDC0)
It converts the number whose high byte is in .A and whose low byte is in .X
to a floating point number. It also calls the routine below (FOUT - 48605
$BDDD), which converts the floating point number to an ASCII string.
So POKE 780, (high byte):REM A reg
POKE 781, (low byte):REM X reg
and SYS 48589
You'll have to convert from Binary to Hi and Lo bytes.
Jeremy
E> I want to output a 16 bit unsigned binary number
E> in decimal form.
E> Does anyone have a short 6502 routine to do this?
This is what I use:
; print a 16-bit integer
; lsb in x, msb in a
print16 subroutine
sta acc+1
stx acc
ldx #4
.nextdig jsr div
lda ext
sta .num,x
dex
bpl .nextdig
.firstdig inx
cpx #5
beq .print0
lda .num,x
beq .firstdig
.ptnxtdig clc
adc #"0"
jsr bsout
inx
cpx #5
beq .pt16done
lda .num,x
jmp .ptnxtdig
.pt16done rts
.print0 lda #"0"
jsr bsout
rts
.num dc.b 0,0,0,0,0
; 16/16-bit division, from the fridge
; acc/aux -> acc, remainder in ext
div subroutine
lda #0
sta ext+1
ldy #$10
.dloop asl acc
rol acc+1
rol
rol ext+1
pha
cmp aux
lda ext+1
sbc aux+1
bcc .div2
sta ext+1
pla
sbc aux
pha
inc acc
.div2 pla
dey
bne .dloop
sta ext
rts
acc dc.w 0
aux dc.w 10 ; constant
ext dc.w 0
--
___ . . . . . + . . o
_|___|_ + . + . + . Per Olofsson, arkadspelare
o-o . . . o + Mage...@cling.gu.se
- + + . http://www.cling.gu.se/~cl3polof/
That's a real nice routine. I believe the 16-bit divide is the one
Glen Bredon included with Merlin, is it not? I wrote something very
similar a couple years ago.
But what would you do if the size of the integer is unknown at
assembly time? For instance, what if the input could range from 8 bits
to 24 bits? Would you process it as a 24-bit number every time?
Just curious ;-)
MagerValp <Mage...@cling.gu.se> wrote in message news:<p14g02d...@panini.cling.gu.se>...
PD> That's a real nice routine. I believe the 16-bit divide is the one
PD> Glen Bredon included with Merlin, is it not? I wrote something
PD> very similar a couple years ago.
I honestly don't know -- I found it in Steve Judd's fridge. Oh wait,
it does say that it's from the Merlin 128 disk. I just set the divisor
to 10, added the loop that grabs the remainder, and prints out the
number without leading 0s.
PD> But what would you do if the size of the integer is unknown at
PD> assembly time? For instance, what if the input could range from 8
PD> bits to 24 bits? Would you process it as a 24-bit number every
PD> time?
I use this routine to print out 8 and 16-bit integers. Haven't used
any 24-bit integers, so I wouldn't know :)
>I want to output a 16 bit unsigned binary number
>in decimal form.
>
>Does anyone have a short 6502 routine to do this?
Rather than code, I'll give you an outline of the logic of a method I
published long ago. (I'm given to understand that this method was
independently developed by others, too)
1. Set up an output area to hold a BCD result (three bytes for
possible five digits in this case), and zero its contents.
2. Set decimal mode with SED.
3. Repeat for each bit of the binary number:
3a. Shift the whole binary number left by one bit. For a 16-bit
number, this involves ASL of the low-order, followed by ROL of the
high-order byte.
3b. WITHOUT DISTURBING THE CARRY from this last operation, add the
output area to itself. The usual stuff: load A with the low order
byte, add the low order to A, store the result in the low order, do it
all again for the next higher order byte, and so on.
4. When all 16 bits have been processed, clear decimal mode with
CLD.
5. Unless you want BCD, you now need to break the four-byte values
from the output area, and change them to ASCII with OR $30. You can
work in zero suppression while you're doing this, if you wish. The
general form is something like:
5a. load the BCD value into A
5b. push it to the stack with PHA
5c. shift it right four bits with four LSRs
5d. put in the ASCII zone bits with ORA $30
5e. store the resulting ASCII digit
5f. pull the original value back with PLA
5g. kill the four high bits with AND #$0F
5h. repeat 5d and 5e above.
Quick explanation: Adding a number to itself is normally the
equivalent of left-shifting the number one bit. If we hadn't set
decimal mode, the output would end up containing the original binary
number. With decimal mode set, however, the value is copied as a BCD
decimal-style number.
Caution: you must NOT meddle with the carry bit as you go from step 3a
to 3b. It's tempting to set up a loop-and-compare routine for these
steps (16 iterations); DEX and BNE or BMI is totally safe, since it
doesn't affect the carry flag, but if you use something like CPX, be
sure it doesn't get between those two steps.
--Jim
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
|Hiya MV,
|
|That's a real nice routine. I believe the 16-bit divide is the one
|Glen Bredon included with Merlin, is it not? I wrote something very
|similar a couple years ago.
|
|But what would you do if the size of the integer is unknown at
|assembly time? For instance, what if the input could range from 8 bits
|to 24 bits? Would you process it as a 24-bit number every time?
|
|Just curious ;-)
That is a lot of food for thought, especially as more people are
trying out the 65816. And as many people are champing at their bits
anticipating the CommodoreOne computer. Should we just go ahead
and assume 32 bit integers, even if that takes a little bit longer?
So it depends on the fact that ADC is affected by D-flag but the shift
commands aren't, right? Sweet and simple :)
Thank you
f...@pathcom.com (Jim Butterfield) wrote in message news:<3cab2564....@news.pathcom.com>...
> 5c. shift it right four bits with four LSRs
By the way, there isn't any (undocumented) op-code out there which
swaps the low and high nybble of the accumulator? I believe it could
have some usage and would save these rows of four shifts up and down
depending on the code.
--
Anders Carlsson
>So it depends on the fact that ADC is affected by D-flag but the shift
>commands aren't, right? Sweet and simple :)
Uses that fact in the suggested procedure, but doesn't depend on it.
You could alway switch in SED each time before you add .. since you
don't need to, this saves a few dozen microseconds.
--jim
Probably .. since it's compact and efficient, I tend to use it
whenever I need to do binary-to-Ascii.
There's only a little need for this in Supermon, of course; there's
not much decimal output. On the other hand, decimal input is
permitted almost anywhere (prefixed by a '+' symbol): addresses or
operand fields. So Ascii-to-binary is fairly commonplace in the code,
but it's accomplished in a relatively straightforward manner (multiply
previous binary value by ten, grab new digit, strip its zones and add
it in).
--j