Exact match. Not showing close matches.
PICList
Thread
'[PIC]: BCD question'
2001\04\19@053512
by
Vasile Surducan
2001\04\19@060553
by
Alexey Musin
Hello Vasile,
Thursday, April 19, 2001, 3:19:00 PM, you wrote:
VS> Could someone explain briefly what are diferences between unpacked and
VS> packed BCD ?
In packet format it need one byte (nibble + nibble) to store a BCD
number.
And in unpacket format it need two bytes (byte + byte) to store a BCD
number.
I hope You understood my English :).

Best regards,
Alexey Musin

http://www.piclist.com hint: The PICList is archived three different
ways. See http://www.piclist.com/#archives for details.
2001\04\19@061623
by
Vasile Surducan
Yes I understood.
Spasiva Alexei !
Vasile
On Thu, 19 Apr 2001, Alexey Musin wrote:
{Quote hidden}> Hello Vasile,
>
> Thursday, April 19, 2001, 3:19:00 PM, you wrote:
>
> VS> Could someone explain briefly what are diferences between unpacked and
> VS> packed BCD ?
>
> In packet format it need one byte (nibble + nibble) to store a BCD
> number.
> And in unpacket format it need two bytes (byte + byte) to store a BCD
> number.
>
> I hope You understood my English :).
>
> 
> Best regards,
> Alexey Musin
>
> 
>
http://www.piclist.com hint: The PICList is archived three different
> ways. See
http://www.piclist.com/#archives for details.
>
>

http://www.piclist.com hint: The PICList is archived three different
ways. See http://www.piclist.com/#archives for details.
2001\04\19@073719
by
Laszlo Kohegyi
Hi,
>Could someone explain briefly what are diferences between unpacked and
>packed BCD ?
>Thank's, Vasile
Let's say that you want to represent 3495 (decimal)
In packed format it will be: 0x34 0x95 (in C notation, hex, 2 bytes)
In nonpacked format: 0x03 0x04 0x09 0x05 (hex, four bytes)
Regards
Les

http://www.piclist.com hint: The PICList is archived three different
ways. See http://www.piclist.com/#archives for details.
2001\04\19@074350
by
Alan B. Pearce
VS> Could someone explain briefly what are diferences between unpacked and
VS> packed BCD ?
>In packet format it need one byte (nibble + nibble) to store a BCD
>number.
>And in unpacket format it need two bytes (byte + byte) to store a BCD
>number.
I would class this as "nearly correct". In unpacked BCD only the bottom
nybble represents a digit. The top nibble can be anything, and is most
commonly the ASCII high nibble of the number. Any arithmetic done on the
nibble needs to be careful to not change the upper nibble for this reason.
In packed BCD then two adjacent digits (e.g. from an ASCII string) will be
packed into one byte. When this is done it is necessary to be careful to
treat each byte properly when doing arithmetic as you cannot treat the
number as one 8 bit binary number. You have to detect the overflow from 9 to
A in the lower significant digit, and change it to 0 and increment the upper
significant digit. The order of packing will depend on the processor as
well, you cannot assume that the upper byte is the more significant digit.
When dealing with the packing and unpacking the swap nibble instruction is
very useful.
Note that it is known as BCD because the nibble representing the number is
constrained to the values 09, so any arithmetic that causes it to go
outside this range needs logic to deal with the resetting to 0 or 9 and
dealing with the adjacent digits correctly, which is extra logic compared to
ordinary binary arithmetic routines unless the processor has instructions
that deal with this for you. This is the reason that there is a "half carry"
flag that shows the state of the carry between bit 3 and bit 4 on arithmetic
operations (see the PIC flags definitions, it is there).

http://www.piclist.com hint: The PICList is archived three different
ways. See http://www.piclist.com/#archives for details.
2001\04\19@232001
by
Dmitry Kiryashov

Hi Alan.
What about case when you have number in range from 0 upto 99 (decimal)
stored
in one byte? For instance in add/sub operations if number is rolled over
100.
or borrow is generated than number is normalized again back to range
0...99
and carry/borrow operation is applied to next byte.
Is it some particular case of BCD arithmetic or something else?
WBR Dmitry.
"Alan B. Pearce" wrote:
>
> Note that it is known as BCD because the nibble representing the number is
> constrained to the values 09, so any arithmetic that causes it to go
> outside this range needs logic to deal with the resetting to 0 or 9 and
> dealing with the adjacent digits correctly, which is extra logic compared to
> ordinary binary arithmetic routines unless the processor has instructions
> that deal with this for you. This is the reason that there is a "half carry"
> flag that shows the state of the carry between bit 3 and bit 4 on arithmetic
> operations (see the PIC flags definitions, it is there).

http://www.piclist.com hint: The PICList is archived three different
ways. See http://www.piclist.com/#archives for details.
2001\04\20@003529
by
Douglas Wood
Dmitry,
You must perform a "decimal accumulator adjust" function after an add or
subtract of two packed BCD numbers. Most CPUs have a form of this function
in an instruction called "DAA". Note that the 17Cxxx and 18Cxxx parts have
this instruction; on this processors it's called "DAW" for decimal adjust
WREG Register.
The operation of DAW (or DAA) is as follows:
If (WREG<3:0> > 9) or (DC =1) then
WREG<3:0> + 6 > WREG<3:0>
else
WREG<3:0> > WREG<3:0>
If (WREG<7:4> > 9) or (C = 1) then
WREG<7:4> + 6 > WREG<7:4>
else
WREG<7:4> > WREG<7:4>
DAW performs the fixups so that the result of the computation remains in
packer BCD format.
Douglas Wood
Software Engineer
spam_OUTdbwoodTakeThisOuTkc.rr.com
Home of the EPICIS Development System for the PIC and SX
http://epicis.piclist.com
{Original Message removed}
2001\04\20@020341
by
dr. Imre Bartfai

It is worth to mention the IBM mainframe architecture has also a sign
nibble: the rightmost nibble contained (AFAIK) B, C, or D (hex) if
negative, and A or E if positive. Any other values were illegal,
similarly, if any of other nibbles contained a higher value than 0. Those
illegalities led to the famous "Data Exception" 0C7. They (IBMs) have a
decimal arithmetics such as AP, MP, DP, SP, ZAP, SPR, CP.
Regards,
Imre
On Thu, 19 Apr 2001, Laszlo Kohegyi wrote:
{Quote hidden}> Hi,
>
> >Could someone explain briefly what are diferences between unpacked and
> >packed BCD ?
> >Thank's, Vasile
>
> Let's say that you want to represent 3495 (decimal)
>
> In packed format it will be: 0x34 0x95 (in C notation, hex, 2 bytes)
>
> In nonpacked format: 0x03 0x04 0x09 0x05 (hex, four bytes)
>
>
>
> Regards
>
> Les
>
> 
>
http://www.piclist.com hint: The PICList is archived three different
> ways. See
http://www.piclist.com/#archives for details.
>
>
>
>

http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email .....listservKILLspam@spam@mitvma.mit.edu with SET PICList DIGEST in the body
2001\04\20@033839
by
Dmitry Kiryashov
Hi Douglas.
Very informative answer but I've
been asking about something else.
WBR Dmitry.
Wood wrote:
>
> Dmitry,
>
> You must perform a "decimal accumulator adjust" function after an add or
> subtract of two packed BCD numbers. Most CPUs have a form of this function
> in an instruction called "DAA". Note that the 17Cxxx and 18Cxxx parts have
> this instruction; on this processors it's called "DAW" for decimal adjust
> WREG Register.
>
> {Original Message removed}
2001\04\20@042022
by
Peter L. Peres
2001\04\20@043659
by
Alan B. Pearce
>What about case when you have number in range from 0 upto 99 (decimal)
>stored
>in one byte? For instance in add/sub operations if number is rolled over
>100.
>or borrow is generated than number is normalized again back to range
>0...99
>and carry/borrow operation is applied to next byte.
>Is it some particular case of BCD arithmetic or something else?
Well just like any variable you have to assign enough bytes to handle the
largest value. There is nothing to stop you having a 10 digit number as 5
bytes of packed BCD. Your routine just needs to be able to carry over to the
next digit in the next byte just as any binary routine would do when doing
multibyte arithmetic. The basic arithmetic carry logic does not change.
I used to do technical support and board repair to chip level for a machine
that had a 16 byte accumulator in memory, and the CPU microcode did BCD
arithmetic on this accumulator as unpacked BCD. When storing data to a file
it was possible to save it as packed BCD to save file space. Is anyone still
using a QANTEL machine out there?

http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email .....listservKILLspam.....mitvma.mit.edu with SET PICList DIGEST in the body
2001\04\20@072723
by
Roman Black

Dmitry Kiryashov wrote:
>
> Hi Alan.
>
> What about case when you have number in range from 0 upto 99 (decimal)
> stored
> in one byte? For instance in add/sub operations if number is rolled over
> 100.
> or borrow is generated than number is normalized again back to range
> 0...99
> and carry/borrow operation is applied to next byte.
>
> Is it some particular case of BCD arithmetic or something else?
Dmitry, it's easier to understand like this:
* BCD is a 4bit format (from 09 decimal)
the format is not related to bytes at all.
* it's easiest to just put ONE digit in a byte,
this makes math much easier between variables,
this is called "unpacked". Yes it wastes 4 bits.
Variables are easy to add, subtract, display etc.
* if memory is limited you can put TWO digits in
a byte. Each digit is separate and has 4 bits.
This is called "packed". This is much harder to
do math with and is best to avoid packed format
unless you have a reason to use it.
:o)
Roman

http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email EraseMElistservspam_OUTTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body
2001\04\20@104016
by
Scott Dattalo
On Fri, 20 Apr 2001, Roman Black wrote:
> Dmitry Kiryashov wrote:
> >
> > Hi Alan.
> >
> > What about case when you have number in range from 0 upto 99 (decimal)
> > stored
> > in one byte? For instance in add/sub operations if number is rolled over
> > 100.
> > or borrow is generated than number is normalized again back to range
> > 0...99
> > and carry/borrow operation is applied to next byte.
> >
> > Is it some particular case of BCD arithmetic or something else?
>
>
> Dmitry, it's easier to understand like this:
<snip>
Actually, Dmitry understands an explanation in code better:
www.piclist.com/techref/microchip/math/add/bcdp2.htm
http://www.piclist.com/techref/microchip/math/sub/bcdp2.htm
These routines are packed bcd add and subtract. They support carry propogation.
Scott

http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body
2001\04\20@113124
by
Jason Harper

Dmitry Kiryashov <@spam@nzewsKILLspamMAIL.RU> wrote:
> What about case when you have number in range from 0 upto 99 (decimal)
> stored
> in one byte? For instance in add/sub operations if number is rolled over
> 100.
> or borrow is generated than number is normalized again back to range
> 0...99
> and carry/borrow operation is applied to next byte.
>
> Is it some particular case of BCD arithmetic or something else?
Texas Instruments called that "Rad100" (radix 100) in their processors that
supported it directly. I find it very convenient to use: it's easier to
convert to decimal than plain binary numbers, and easier to calculate with
than BCD (if your processor doesn't directly support BCD). Another
advantage over BCD is that you have one completely unused bit per byte,
which can be used to indicate a decimal point, or the end of a
variablelength number.
Jason Harper

http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email KILLspamlistservKILLspammitvma.mit.edu with SET PICList DIGEST in the body
2001\04\20@120405
by
Alan B. Pearce
>Another advantage over BCD is that you have one completely
>unused bit per byte, which can be used to indicate a decimal
>point, or the end of a variablelength number.
Well only if you restrict yourself to 127 char ASCII. If you are using
packed BCD then all bits are used. :)

http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body
2001\04\21@005710
by
Dmitry Kiryashov
Hi Roman.
I do understand what packed and unpacked BCD's are ;)
The question was related to some particular unclassified yet
(for me at least ;) case for numbers in range of 0..99. that
is represented in pure binary form and is taken 7 bits to be
stored and carry/borrow operation is propagated to next such
a "number". Looks more like packed 100's number actually ;)
WBR Dmitry.
Black wrote:
> Dmitry, it's easier to understand like this:
>
> * BCD is a 4bit format (from 09 decimal)
> the format is not related to bytes at all.

http://www.piclist.com hint: To leave the PICList
spamBeGonepiclistunsubscriberequestspamBeGonemitvma.mit.edu
2001\04\21@005920
by
Dmitry Kiryashov
Perfect! ;) Thank you Jason.
I found it very useful as well for the same reasons you have listed.
WBR Dmitry.
> Texas Instruments called that "Rad100" (radix 100) in their processors that
> supported it directly. I find it very convenient to use: it's easier to
> convert to decimal than plain binary numbers, and easier to calculate with
> than BCD (if your processor doesn't directly support BCD). Another
> advantage over BCD is that you have one completely unused bit per byte,
> which can be used to indicate a decimal point, or the end of a
> variablelength number.
> Jason Harper

http://www.piclist.com hint: To leave the PICList
TakeThisOuTpiclistunsubscriberequestEraseMEspam_OUTmitvma.mit.edu
2001\04\21@010751
by
Dmitry Kiryashov
Hi Alan.
Brief track into it.
You have a byte with lowest 7 bits occupied and MSB bit that is "free".
In lowest 7 bits number in range of 0..99. (decimal) is stored.
Carry(above 99.)/borrow(below 0) is propagated to next "number"
and then current number is normalized back to range 0..99.
MSB is always free and can be used for whatever you want.
It is not BCD actually, Jason said right name for it. It is Rad100.
WBR Dmitry.
"Alan B. Pearce" wrote:
>
> >Another advantage over BCD is that you have one completely
> >unused bit per byte, which can be used to indicate a decimal
> >point, or the end of a variablelength number.
>
> Well only if you restrict yourself to 127 char ASCII. If you are using
> packed BCD then all bits are used. :)

http://www.piclist.com hint: To leave the PICList
RemoveMEpiclistunsubscriberequestTakeThisOuTmitvma.mit.edu
2001\04\22@140457
by
Alan B. Pearce
>You have a byte with lowest 7 bits occupied and MSB bit that is "free".
>In lowest 7 bits number in range of 0..99. (decimal) is stored.
>Carry(above 99.)/borrow(below 0) is propagated to next "number"
>and then current number is normalized back to range 0..99.
>MSB is always free and can be used for whatever you want.
I take it from this and some other emails that you are talking of 7 bit
binary, which is NOT BCD. BCD uses the numbers 09 only in 4 bits, where a 7
bit binary is 0127, and then you are crunching it separately to 099.
I think you are really confusing a thread which is talking about BCD. I only
realised that you were talking about 7 bit binary (what someone else called
rad100) after reading this block of messages from you, of which I have
quoted from the one you specifically addressed to me.

http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: >uP ONLY! [EE]:,[OT]: >Other [BUY]:,[AD]: >Ads
More... (looser matching)
 Last day of these posts
 In 2001
, 2002 only
 Today
 New search...