Jump to content

Talk:Binary-coded decimal

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
This is an old revision of this page, as edited by 81.6.34.246 (talk) at 14:21, 31 July 2018 (BCD code B: new section). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.
WikiProject iconComputing Start‑class
WikiProject iconThis article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
StartThis article has been rated as Start-class on Wikipedia's content assessment scale.
???This article has not yet received a rating on the project's importance scale.
Note icon
This article has been automatically rated by a bot or other tool because one or more other projects use this class. Please ensure the assessment is correct before removing the |auto= parameter.
WikiProject iconElectronics Start‑class Low‑importance
WikiProject iconThis article is part of WikiProject Electronics, an attempt to provide a standard approach to writing articles about electronics on Wikipedia. If you would like to participate, you can choose to edit the article attached to this page, or visit the project page, where you can join the project and see a list of open tasks. Leave messages at the project talk page
StartThis article has been rated as Start-class on Wikipedia's content assessment scale.
LowThis article has been rated as Low-importance on the project's importance scale.


compressed vs uncompressed

If the number has an odd number of digits the compressed version will most likely need a leading 0 to byte-align. Thus an uncompressed number '1', 0x31 will be be 0x01 in compressed BCD, or the same size. On the other hand '32' (0x3332) will be 0x32, of half the size. I don't thing a categorical statement is possible regarding the size difference between compressed and uncompressed. This leaves the question of sign completely out. Peter Flass (talk) 03:20, 5 February 2015 (UTC)[reply]

Nope - as written the sentence specifies uncompressed "with the leading zero", implying an even number of digits, though without actually saying so, The statement was therefore correct, so I just changed "100 percent more" to "twice", which I think is clearer. Peter Flass (talk) 03:28, 5 February 2015 (UTC)[reply]
Thanks. That seems about the best that can be done. A description that correctly covers all conditions would be very complex. Consider that if only ONE digit is stored, then assuming we can't use just half a byte for packed decimal, they both take the same number of bytes! Jeh (talk) 03:39, 5 February 2015 (UTC)[reply]

Also, one usually has to store the sign somewhere. The usual packed decimal representations hold an odd number of digits, so the leading zero is on values with an even number of digits. Gah4 (talk) 21:36, 17 September 2015 (UTC)[reply]

Tension over tense

David Eppstein (talk · contribs · deleted contribs · logs · filter log · block user · block log) made these changes, converting some of the descriptions from present to past tense. Edit comment: "Undo. Using present tense loses part of the point of this material, that it is about systems that nowadays are obsolete."

I reverted, with edit comment "BCD is not a (computer) system. It is a method for representing numbers, and it is still used)".

Epp re-reverted to his own text: "BCD may still be used, but the sentences in question are about its implementations on specific no-longer-used computers"

First, this is a violation of WP:BRD. Once you have been reverted you are not supposed to edit the contested material again. You are supposed to take it to the talk page.

Second, this is contradicted by MOS:TENSE:

"By default, all articles are written in the present tense, including for those covering products or works that have been discontinued."
"Generally, do not use past tense except for deceased subjects, past events, and subjects that no longer meaningfully exist as such."
"The PDP-10 is a discontinued mainframe computer family." (given as example -jeh)

I'm just not seeing any wiggle room here. The fact that System/360 and VAX computers are no longer manufactured (though some are still used, regardless of being "obsolete") does not mean the designs or their principles of operation have ceased to exist. Granted there are several articles in the computer area that get this wrong, but that doesn't mean we should ignore MOS. Jeh (talk) 20:22, 29 April 2015 (UTC)[reply]

The MOS:TENSE argument is a strong one. If I had seen that one in your edit summaries I might have been more hesitant to revert. Your weird misinterpretation of WP:3RR has nothing to do with the content and is not worth discussing. —David Eppstein (talk) 20:26, 29 April 2015 (UTC)[reply]
It's not about 3RR per se. I am aware that WP:BRD is not policy, and the "bright line" is at three reverts within 24 hours. However WP:EW is policy, and it says "Once it is clear there is a dispute, avoid relying solely on edit summaries and discuss the matter on the article's talk page". It also refers to Wikipedia:Editing_policy#Talking_and_editing, which is also policy, and says "Discussion is, however, called for if [...] someone indicates disagreement with your edit (either by reverting your edit and/or raising an issue on the talk page)." And certainly someone indicated disagreement here. Jeh (talk) 20:37, 29 April 2015 (UTC)[reply]
Re MOS:TENSE, note that past events can and should still be related in, of course, past tense. So a design decision or process that occurred in the past (even for a present-day machine!) should be described in past tense. But the resulting designs still exist in the present (even if no machines are being built from them). Jeh (talk) 20:37, 29 April 2015 (UTC)[reply]
Anyway... all those lovely packed decimal instructions are still implemented in IBM System Z architecture, which is the present-day descendant of System/360. Jeh (talk) 20:41, 29 April 2015 (UTC)[reply]

When I edit articles following MOS:TENSE I try to keep the event distinction in mind. But yes, the ideas and their descriptions still exist (present), even if no implementations exist (but most often, they do). Gah4 (talk) 21:43, 17 September 2015 (UTC)[reply]

Are hand calculators and CD players now obsolete? As far as I know, hand calculators do all arithmetic in BCD, and CDs still store the track number in BCD. (That is why 99 tracks maximum.) Gah4 (talk) 21:45, 17 September 2015 (UTC)[reply]

To keep this discussion going, note that the 8086, and still in descendants today, have BCD instructions. They just aren't as good as other machines. In 16 bit 8086, you can add and subtract binary numbers 16 bits at a time, but add and subtract BCD two decimal digits at at time, with the use of DAA and DAS. Multiply and divide one digit at a time with AAM and AAD. Also, x87 can load/store values in 18 digit BCD. Gah4 (talk) 03:11, 22 September 2016 (UTC)[reply]
(Marked claim that BCD is no longer implemented as Dubious.) Seems to me it is wrong, as I just noted. But even so, it is fairly rarely used. In years past, it was popular for COBOL compilers to use it, where little calculation was done between input and output. I don't know about COBOL compilers today. I believe it is implemented on enough machines to remove the claim. Gah4 (talk) 03:11, 22 September 2016 (UTC)[reply]

Is there an article about an algorithm that converts a binary value to BCD?

for example: convert the value 11111111 (binary) to 255 with each digit stored in separate bytes:

2 5 5
00000010 00000101 00000101

What I can do is: you simply divide by 10 repeatedly and each time, you use the remainder to place your digits, while the quotient (rounded down) is the next digit to be divided again. For example:

  1. 255/10 = Q:25 R:5 That is 5 would be placed in the ones place of the digit BCD storage (XX5).
  2. with the quotient in hand, divide by 10 again, which would be 25/10 = Q:2 R:5 store the remainder into the tens place (X55)
  3. again, with the new quotient in hand, divide by 10 again: 2/10 = Q:0 R:2 now write the remainder value in the hundreds place (255).

This only works with unsigned integers. For signed integers, simply flip the negative value to a positive (-5 turns into 5, for example), call the routine to write the digits in, and then place a minus sign before it (so 11111111 (255), XOR +1 would be 00000001, then BCD it, which spits out 1 in decimal, and place the minus sign to form -1). You can keep going based on how many digits you want to display.

I did this on Super Mario World ROM hacking when Akaginite developed the 32-bit/16-bit division. Joeleoj123 (talk) 21:49, 24 February 2018 (UTC)[reply]

Edit: Included how to convert. Joeleoj123 (talk) 00:38, 8 March 2018 (UTC)[reply]

I'm sorry... I thought I replied to this. I was certainly intending to. In general we don't include algorithms, particularly not if they're obvious or very well known. This one is widely covered in the literature, eg places like IBM's "Commercial Subroutine Package" (which dates from the 1960s) and, well, this one is obvious (or should be) to anyone in a first-year programming course and so has been "invented" countless times already. Jeh (talk) 03:12, 8 March 2018 (UTC)[reply]

BCD code B

I was reading MAX7219/MAX7221 datasheet, and they mention code B, https://datasheets.maximintegrated.com/en/ds/MAX7219-MAX7221.pdf page 7 and 8.

It goes 0-9, then '-', 'E', 'H', 'L', 'P', ' '. Instead of pure A B C D E F. This is because these letter and symbols are more useful in userfacing equipement, i.e. E error, H/L - high low, and '-' for a minus sign in front or between digits, and blank for spacing. P is probably standing for program, i.e. P001, and all 6 characters can be easily displayed on standard 7 segment display in upper case without problem. (B and D cannot be displayed without confusion with 8 and 0).

I do not know if this is industry standard. 81.6.34.246 (talk) 14:21, 31 July 2018 (UTC)[reply]