I recall someone asking what the use of BCD (Binary Coded Decimal) was. I have here a 99-byte program that uses it to print out a number stored in the memory in decimal, with a maximum of more than 10^500 digits, Within 5 seconds :). What's the use ?? Well, you can impress your friends by calculating the answer to the chessboard-problem ( 2^64 - 1 or 0xFFFFFFFFFFFFFFFF ) within 0.06 of a second. Oh, and the maximum is pretty easy to overcome, with a slight code change, if anyone needs numbers greater than, oh, 509 digits. :)
* = $1000
SNUM = $1100
BUFF = $1200
PRINT = $FFD2
SNUMPTR = $FB
SNUMBF = $FC
BUFFEND = $FD
LDA #0
TAX
CLRBUFF STA BUFF,X
INX
BNE CLRBUFF
SED
STA BUFFPTR
LDY #210
STY SNUMPTR
BYTELOOP LDA SNUM,Y
STA SNUMBF
LDY #8
BITLOOP ASL SNUMBF
LDX #0
ADDLOOP LDA BUFF,X
ADC BUFF,X
STA BUFF,X
INX
BCS ADDLOOP
CPX BUFFEND
BCC ADDLOOP
STX BUFFEND
DEY
BNE BITLOOP
DEC SNUMPTR
LDY SNUMPTR
CPY #$FF
BNE BYTELOOP
CLD
LDA #13
JSR PRINT
DEX
LDA BUFF,X
AND #$F0
BEQ LOWNYB
PRINTLOOP LDA BUFF,X
LSR
LSR
LSR
LSR
CLC
ADC #48
JSR PRINT
LOWNYB LDA BUFF,X
AND #$0F
CLC
ADC #48
JSR PRINT
DEX
CPX #$FF
BNE PRINTLOOP
print 23.13 - 22.87 hit RETURN
Do you get .260000005?
The resulting thread after this question was posed started to lean in the direction of attacking the arithmetic units of BASIC in the Commodore 8-bit machines. Then an eloquent post from Alan Jones started to set the record straight. We can't express it any better than Alan:
Recently, the C64/128 floating point arithmetic has been maligned here. The C64/128 has good floating point math. It uses 5 byte reals with a 4 byte (32 bit) mantissa. There are no bugs in the basic FP arithmetic. The reals ARE limited in range and precision. They are more useful than computers using 32 bit reals, but not up to IEEE standard arithmetic. IEEE FP arithmetic (double and extended precision...) would be much slower than our existing FP routines. Of course it might be possible to interface a hardware FPU to the new Super64/128CPU (65816).The other C64/128 FP routines, such as SIN, EXP, and functions that use them are not accurate to full 32 bit FP precision. When used with care, they are often accurate enough for engineering work.
The most annoying inaccuracy may be the conversion between binary FP and decimal for I/O. BASIC only prints 9 decimal digits of a FP number, but our binary FP number has about 9.6 decimal digits of precision. What you see is not what you have! Of course there are some simple tricks that you can use to print the FP number with more decimal precision, and you could do I/O using HEX notation. If you save intermediate results for later use, make sure you write the FP values as binary rather than ASCII (converted to decimal).
If you do accounting type stuff with dollars and cents, using binary FP with its limited precision and rounding can be annoying. If your results are off one penny, all of your work will be suspect. Our 6502 family of CPU's also has decimal arithmetic. It can do decimal arithmetic exactly, although you may have to program it yourself. I think the Paperclip Word Processor will do simple calculations with up to 40 decimal digits of precision.
If you are using 64+ bit FP you can compute some things in a fast and sloppy manner. Some programs that work OK on an IBM PC or workstation need more careful attention when coded for a C64/128.
Some numbers can not be represented exactly in binary FP formats of any precision. If you want to calculate:
a:=(1/3)*(1/5)*(1/7)*(1/11)You should code it as:
a:=1/(3*5*7*11)Aside from being faster, it is more accurate.
There are many tips for preserving numerical accuracy in computations. There are often interesting tradeoffs between computation speed, memory usage, and accuracy and stability. There are even some C64/128 specific tips. (e.g. We usually store a real value in 5 bytes of memory but push it onto a stack as 6 bytes when we want to use it.)
This is not intended to be a Commodore FP tutorial. It is reminder that the C64/128 can be used for "heavy math", and there are no bugs in the Commodore +, -, *, /, Floating Point arithmetic routines. It uses 32 binary bit mantisa FP reals with proper rounding. Simple examples can always be contrived to demonstrate a perceived FP bug by computer illiterates(?).
Alan got his dig in at the end there. That post, and others like it, pretty much squelched the arithmetic discussion. But, as is usually the case, we all learned a neat trick along the way. Peter Karlsson shared his easy way of determining whether his programs are running on a C64 or C128 by issuing the following statement:
C=64+64*INT(.1+.9)
Since the 64 and 128 differ ever so slightly in their arithmetic routines, the above line gives 64 on a C64 and 128 on a C128.
Well, that brought out some friendly debate, to state the obvious. Part of the group posted words of encouragement, noting that we need to support those programming for the environment. The other half of the camp echoed the words of Patrick Leung, who expressed concern that there are many programmers in the arena that are doing the same thing separately. He encouraged programmers to consolidate features and code bases to arrive at robust full-featured programs instead of fragile bare- bones applications that single programmers can't support. ACE, Craig Bruce's UNIX-like OS detailed in earlier C=Hacking issues, was brought up by some, who asked that programmers heed Leung's advice and build modules for the already supported ACE environment.
Perhaps J. Shell has the best idea, as he is planning to set up an interactive WWW site to allows programmers to work with him to build COMMIX System II (CX2). The site will allow programmers to bring new ideas to the table and have them rapidly incorported into the design. We'll see if Mr. Shell can deliver on this neat idea.
Going full circle, Benjamin Moos responded to some of the posts, saying that the OS work was going to be placed on the shelf for now, as many had expressed interest in the C++ like compiler. However, he did say that work would begin again at a later date, but no decision was made as to how he will proceed.
As with all things, there is a downside in that 19,200 becomes the next lower bps rate. 38,400 is gone forever. Craig speculated that perhaps a switch could be installed, but wasn't sure of the effects.
When someone keeps an old car around, babies it, works on it, adds to it, drives it around in style, no one says "Look at this dummy driving an out-dated gas guzzler that can't even do 80, and gets atrocious gas mileage. The frame is archaic. The windows aren't electric. Why doesn't he upgrade?". Nah... they are "enthusiasts of classic automobiles."
Well, ... we are "enthusiasts of a classic computer."