Am I crazy? Last night I had an idea in my head while thinking about how FP numbers work in my head -- you know, how the z80 even has a DAA instruction to shift to $00 to $99 decimal digits after an addition. However, think about this:
can a byte hold more than two decimal digits, when not coded in BCD format?
Think about this:
99 in non-BCD could be represented as 9*10+9, which is $63 in non-BCD. but, what about if each digit was just 10 (in decimal) apart in number? Let's say 99 is actually 9+10+9, which is in decimal only 28 -- but did you see what I think I did there? you see, every $0A increment you climb in the byte, you can store a whole digit! therefore, 678 is (6+20)+(7+10)+(8 ), which is 26+17+8, which is 51 in decimal normally, but in packed form can be 51! Now, unpacking it would be very tedious... and would probably be extremely hard to do without completely ruining the number we're after. It's very hard to think about and hurts my head because you have to think of things in both binary and decimal form at the exact same time for it to make any sense.
Maybe this makes no sense anyways I have, of course, never really looked into bit mangling... That could debunk this whole thing.
With that in mind, if this is as impossible as spontaneous generation, are there actual ways of fulfilling this, by packing a value more than 256 into a bit based byte?
can a byte hold more than two decimal digits, when not coded in BCD format?
Think about this:
99 in non-BCD could be represented as 9*10+9, which is $63 in non-BCD. but, what about if each digit was just 10 (in decimal) apart in number? Let's say 99 is actually 9+10+9, which is in decimal only 28 -- but did you see what I think I did there? you see, every $0A increment you climb in the byte, you can store a whole digit! therefore, 678 is (6+20)+(7+10)+(8 ), which is 26+17+8, which is 51 in decimal normally, but in packed form can be 51! Now, unpacking it would be very tedious... and would probably be extremely hard to do without completely ruining the number we're after. It's very hard to think about and hurts my head because you have to think of things in both binary and decimal form at the exact same time for it to make any sense.
Maybe this makes no sense anyways I have, of course, never really looked into bit mangling... That could debunk this whole thing.
With that in mind, if this is as impossible as spontaneous generation, are there actual ways of fulfilling this, by packing a value more than 256 into a bit based byte?