13 replies to this topic

[idavis]

So I was sitting here with an emulator running and no disk loaded in and decided to just boot to basic. Then I decided since the Atari was just idling I would have a little fun. So I typed in this program and hit run.



I turned on the turbo and let it go, actually forgetting about it for a day or so. So far it's about here (12 million).



So anyone know offhand what the largest number Atari Basic can count to? I am sure it might be somewhere in the Basic manual but I don't have any of that handy at the moment and google isn't coming up with an answer. Anyone else finding a goofy way to let their emulator waste time?

Edited by idavis, Fri Mar 15, 2013 12:03 PM.

[atari8warez]

to save you some dollars on your hydro bill: -9.99999999E97 to 9.99999999E97

Edited by atari8warez, Fri Mar 15, 2013 12:15 PM.

[idavis]

Thanks. That's the funny thing here. It was just sitting there idling anyway so I though why not have it do something off the wall.

[rdea6]

[Magic Knight]

Pity it didnt stop until it runs out of memory space - Perhaps if a program could be done that just adds a nought every 100 cycles (displaying and not trying to accumulate) there would be more numbers possible (until it runs out of memory with display history being the main usage of memory) .

[atari8warez]

Thanks. That's the funny thing here. It was just sitting there idling anyway so I though why not have it do something off the wall.

That number is valid when the floating point package is enabled in the OS, for BASIC to work, you need the FP package enabled so that is not an issue. However outside BASIC if you need to go beyond +65535 and integer arithmetic you need the FP enabled, devices that use PBI for example can not use FP as the FP code area of the Atari ROM is mapped to PBI for I/O purposes. if it sounds like cramming too many things in the limited space of the Atari it really is

Edited by atari8warez, Fri Mar 15, 2013 1:32 PM.

[idavis]

Pity it didnt stop until it runs out of memory space - Perhaps if a program could be done that just adds a nought every 100 cycles (displaying and not trying to accumulate) there would be more numbers possible (until it runs out of memory with display history being the main usage of memory) .

Looks like it won't run out of memory space in my lifetime. I know that my kids do goofy things like turn on the stopwatch on their phones and see who can run theirs the longest. One son said he had it running for over a year. So that's where I got the idea. Just start up the Atari and let it count. I am cheating by turning on turbo and might fire up an instance and let it run true speed. Just for giggles.

[bfollett]

I modified your program to see where Atari basic would switch to scientific notation to display the number, and I came across something odd The odd behavior begins if you set A= 9999999990 (10 digits). If you make the last digit any number higher... 1 to 9, and then list your program, the last digit will be changed back to a zero. If you run the program, you find that A will continually display a value of 9999999990 when its value moves from 9999999990 to 9999999999. It then will display scientific notation, but I don't know how accurate that is because you just get a long stream of 1E+10 displayed. This was observed in Altari

Bob

[russg]

to save you some dollars on your hydro bill: -9.99999999E97 to 9.99999999E97

Can do the ranges you mention, but only nine significant digits. Anything beyond the 9 digits gets dropped off up to 10. so 999,999,999 is the largest number that you can add one to and get the next higher number.
Essentially your program will get to 1 billion then just drop off to the tenth digit. So one billion is the highest number. After that it goes 1,000,000,000 ten times then goes to 1,000,000,010 ten times then 1,000,000,020 etc.

Edited by russg, Fri Mar 15, 2013 3:18 PM.

[Joey Z]

to save you some dollars on your hydro bill: -9.99999999E97 to 9.99999999E97

First off, the biggest and smallest numbers in atari basic using the FP routines are 1.00000000E-128 and 9.999999999E127. the FP roms can express numbers in between those, their negative equivalents, and 0. BUT, as far as what you can COUNT to, that is a different case. the atari only has 10 digits of precision, 9 in some cases because of the way FP numbers are encoded (I think even powers are 9 digits of precision) so once you get to 9,999,999,999 (or 99.99999999x100^4 in the FP format) you hit 10,000,000,000. everything is completely fine at this point, the number is expressed as 01.00000000x100^5. as soon as you go to 10,000,000,001 though, you have a problem. in the FP format that would need to be 01.0000000001x100^5. this all looks fine and dandy, but count the digits, there are 12 in the mantissa (the part before the x) which is too many, the atari FP routine only allows 10 digits in the mantissa, so it rounds down to 01.00000000x100^5 which puts you back at 10,000,000,000. So, Atari basic can count by ones until 10 billion, after that you get stuck at 10 billion and can't go further.

Well, that's all assuming I did my math right anyway...

Edited by Joey Z, Fri Mar 15, 2013 3:33 PM.

[bfollett]

Here's a little program to show Atari Basic getting in trouble past 9999999999

10 A = 9999999990
20 Print A+9 - A
30 Print A+10 - A

Line 20 will correctly print 9. Line 30 prints 100

[ProWizard]

The FP routines in the atari 8bit is probably the only thing I do not like in these fabulous machines. If there was one thing I could redesign in the machine... it would be the FP routines.

[thorfdbg]

So I was sitting here with an emulator running and no disk loaded in and decided to just boot to basic. Then I decided since the Atari was just idling I would have a little fun. So I typed in this program and hit run.

There is actually no need to speculate. The mathpack routines store numbers with 10 significant digits (exactly), in five bytes, plus one byte for exponent and sign. Thus, numbers up to 10000000000 can be represented exactly. Beyond that point, any attempt to add one will yield nothing because the math pack add routine has, as its first step, to align the exponents of the two numbers. However, by that the "one" you add will be completely normalized away, i.e. will become a zero. Actually, the Os++ math pack detects this first, and simply does nothing on the add then - not sure about the original, but the consequence is the same.

[thorfdbg]

The FP routines in the atari 8bit is probably the only thing I do not like in these fabulous machines. If there was one thing I could redesign in the machine... it would be the FP routines.

Well, the routines are only part of the problem. The problem is manyfold: A) there is no jump-in table into the math pack, which makes replacing them pretty hard. B) the number format is not chosen wisely, which implies that there is at least no efficient algorithm available to divide to BCD numbers through each other (multiplication could be speed up a bit, though), and C) the implementation is surprisingly naive.

As already stated, Os++ fixes this partially - the routines implement now at least a consistent rounding mode, are a bit less naive (numerically), but due to size constraints, are only a bit, but not much faster than the original. Specifically, multiplication is slower than it really had to, but there is not enough ROM space left to implement it in a smarter way.