Was the Atari 400/800 BCD or Radix 100?

Software
1

I have read in many places, to the point that it’s literally the only statement you will find, that the Atari systems used BCD for their math. But someone just posted a reply in a very old thread on SO that makes me wonder if that is entirely accurate.

The post was about the TI-99, which used Radix 100 for math. I had never heard this term before, and the brief bit I found about it seems to suggest that the difference is basically that the numbers are stored not as two digits of base 10, but in essence, a single byte-long value in base 100.

But I recall in a previous thread on the Atari that it too did everything in 100’s, but I did not (and still don’t) really understand these things, so I did not follow up on that.

So can those that do understand this: is the Atari really Radix 100 as well? And what, practically, is the difference?

1 Like
2

A manual might tell us, or failing that, a disassembly. Quick searches indicate that TI were the only ones to venture into Radix 100.

One possible benefit of Radix 100 is that it has room for a sign bit, if needed. A disadvantage is that exponents are powers of 100, so you lose a decimal digit’s worth of mantissa half the time. (I think IBM’s early floating point had a similar weakness, where exponents were powers of 16.)

A possible advantage of Radix 100… maybe performance? Certainly in a CPU without a BCD mode. And I’m not sure about multiplication, in the two cases of BCD and Radix 100 - they are both more tricky than shift-and-add which we usually use for binary.

But this is just me riffing - not a citation in sight!

3

I’m almost 100% sure that the Atari’s BASIC used BCD, rather than Radix-100. Exhibit A is ATR: chpt.11: Floating Point Package, which describes the floating point format as:

         Floating point number representation
     
     
               byte 0    xx   excess 64 exponent + sign
                         xx \
                         xx  \
                         xx   > 10 BCD digits
                         xx  /
               byte 7    xx /

It stores 10 BCD digits in five bytes. I’m not sure how it stores the bytes, but I’m going to assume it’s hex 00 to hex 99, with gaps at 0a…0f, 1a … 1f, etc.

Had it used Radix-100, it could still hold 10 digits in five bytes, but each byte would hold 00 … 99 (decimal) with no gaps.

I tried to mess about with Atari BASIC to see if I could print values stored in the FR0 and FR1 float buffers, but I was clearly doing something wrong, as they never changed. As I know 0 about Atari BASIC, I am unsurprised

4

Why is it labeled byte 0, byte 7 ? 8 bytes would give you 14 digits,

5

Looks to me like a typo in the original: should be byte 5, for a 6 byte float. Just possibly there was some capability for 8 byte floats, but the buffers are described as 6 bytes.

1 Like
6

I did a project where I worked heavily with the Atari’s floating-point routines, and I can say for sure they were BCD. Each floating-point number was encoded in 6 bytes. The first byte contained a kind of “metadata,” with sign info., and the exponent. I think the other 5 bytes just contained the float data. Each byte contained two digits from 0 to 9, each digit in a nibble. Ironically, the best way to view this data was in hexadecimal, because if you tried to view it in decimal, you wouldn’t see the decimal digits encoded in the bytes that clearly. The Atari’s float calculation routines used the 6502’s decimal mode. However, outside of that, the 6502 was used in its native binary mode for things like calculating addresses. If you programmed in Atari Basic, all numeric values (except for line numbers) were stored in BCD, since all numeric values were stored as floats. However, if you programmed in assembly, you typically used integers for numeric values, and in that case, you could work in radix 10. Though, hex was typical. You could work in BCD using the 6502’s decimal mode, but that was optional. There are languages on the Atari that work with integers, and in that case, it’s radix 10.

2 Likes
7

For greater clarity, The Atari BASIC SOURCE BOOK includes the BASIC ROM source code, and it’s SEDs à gogo.

F’rinstance, the IFP - Convert Integer to Floating Point routine sets decimal mode just after it has loaded the integer value into a temporary workspace.

As to how the data are stored, the possible values for simple BCD in a byte are:

00 01 02 03 04 05 06 07 08 09 __ __ __ __ __ __
10 11 12 13 14 15 16 17 18 19 __ __ __ __ __ __
20 21 22 23 24 25 26 27 28 29 __ __ __ __ __ __
30 31 32 33 34 35 36 37 38 39 __ __ __ __ __ __
40 41 42 43 44 45 46 47 48 49 __ __ __ __ __ __
50 51 52 53 54 55 56 57 58 59 __ __ __ __ __ __
60 61 62 63 64 65 66 67 68 69 __ __ __ __ __ __
70 71 72 73 74 75 76 77 78 79 __ __ __ __ __ __
80 81 82 83 84 85 86 87 88 89 __ __ __ __ __ __
90 91 92 93 94 95 96 97 98 99 __ __ __ __ __ __
__ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __
__ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __
__ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __
__ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __
__ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __
__ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __

while in Radix-100 they’d be:

00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f
30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f
40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f
50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f
60 61 62 63 __ __ __ __ __ __ __ __ __ __ __ __
__ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __
__ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __
__ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __
__ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __
__ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __
__ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __
__ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __
__ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __
__ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __

It turns out that there are many, many ways of encoding decimal in bytes and words, and entire careers at IBM have been dedicated to finding the most efficient ones. One of those careers belonged to Mike Cowlishaw (aka the Rexx guy), who documented the General Decimal Arithmetic website and came up with the Densely packed decimal (DPD) encoding.

1 Like
8

Great links, thanks! Speleotrove is a place I’ve landed on many a time.

For interest, I see MSX used BCD floats, either 6 digits or 14 digits of precision, in 4 or 8 bytes respectively.

1 Like