Any fast floating point or fixed point math code available?

[scm2000]

to get back in to programming Atari 800s. i wrote a mandelbrot set plotter in basic. painfully slow. so i wrote it again in assembler but still using the ROM floating point routines. 

turned out to be about the same speed as the algorithm is mainly floating point math. 

 

online i get inklings theres faster floating point available but no searches turned up code, except for an implementation wozniac did that looks like its apple specific. 

 

before i do surgery on that id like to ask if there is atari friendly fast floating point available. or even fixed point. 

[reifsnyderb]

https://atariwiki.org/wiki/Wiki.jsp?page=FAST FLOATING POINT source code for the ATARI#section-FAST+FLOATING+POINT+source+code+for+the+ATARI-Picture

 

 

[Forrest]

I have a Newell Fastchip installed in my Atari 800!

[tebe]

MadPascal uses several, fixed-point (real Q24.8, shortreal Q8.8), single (IEEE754 32bit), float16 (IEEE754 16bit)

https://github.com/tebe6502/Mad-Pascal/tree/master/base/common

 

fractal samples

https://github.com/tebe6502/Mad-Pascal/tree/master/samples/a8/graph/fractal

[scm2000]

15 hours ago, reifsnyderb said:

https://atariwiki.org/wiki/Wiki.jsp?page=FAST FLOATING POINT source code for the ATARI#section-FAST+FLOATING+POINT+source+code+for+the+ATARI-Picture

 

 

Thanks!   I loaded up the .atr image, and since I am running on my 1200xl these days I used the ldfast program that copies the OS to extended ram and loads in the new FP routines.   Ok so I found that my code runs the exact same speed...   Looking in to things, based on looking at the code at D800, it appears the fastfp.obj code is identical to what I already have in ROM... it may be someone already upgraded the rom on my machine. 

 

A nice thing is though...    I hadn't thought about modifying the OS in this way... I may have some fun in the future modifying the OS myself.

[scm2000]

12 hours ago, tebe said:

MadPascal uses several, fixed-point (real Q24.8, shortreal Q8.8), single (IEEE754 32bit), float16 (IEEE754 16bit)

https://github.com/tebe6502/Mad-Pascal/tree/master/base/common

 

fractal samples

https://github.com/tebe6502/Mad-Pascal/tree/master/samples/a8/graph/fractal

I may be able to adapt that code for use, but it's going to be a job converting it to MAC65 code.

[reifsnyderb]

11 minutes ago, scm2000 said:

Thanks!   I loaded up the .atr image, and since I am running on my 1200xl these days I used the ldfast program that copies the OS to extended ram and loads in the new FP routines.   Ok so I found that my code runs the exact same speed...   Looking in to things, based on looking at the code at D800, it appears the fastfp.obj code is identical to what I already have in ROM... it may be someone already upgraded the rom on my machine. 

 

A nice thing is though...    I hadn't thought about modifying the OS in this way... I may have some fun in the future modifying the OS myself.

You may want to take a look at this thread regarding modifying the OS....

https://forums.atariage.com/topic/347696-compiling-a-new-atari-os/

 

 

[ivop]

4 hours ago, scm2000 said:

I may be able to adapt that code for use, but it's going to be a job converting it to MAC65 code.

If you don't want to use Pascal and stick to assembly only, this might be good resource for a fast Mandelbrot algorithm:

 

https://github.com/davidgiven/bogomandel

 

Be sure to read his blog entries (mentioned in the README.md on the github page).

[scm2000]

56 minutes ago, ivop said:

If you don't want to use Pascal and stick to assembly only, this might be good resource for a fast Mandelbrot algorithm:

 

https://github.com/davidgiven/bogomandel

 

Be sure to read his blog entries (mentioned in the README.md on the github page).

actually. i only chose mandlebrot as an example to get in to setting graphic modes and writing to display memory. also shaking off the rust on my 6502 assembly language. i used an optimized escape algorithm. 

but then it also got me going on floating point implementations. i can imagine needing floating point math in future programs

i would not rule out using pascal in the future so long as i can find a legit copy of pascal.  

right now im in assembly language, knowing all to well how compilers bloat code and produce inneficient code for the sake of abstraction 

[scm2000]

so today i took the code wozniac et al published in dr dobbs journal for 4 byte binary floating point. i converted it over to a MAC65 assembly language code. it uses the page zero area that the ROM floating point uses for its regusters etc. 

it assembles and im writing ascii to fp and fp to ascii routines which it lacks

 

if it works and is faster than the fast fp rom version i’ll post the code

[reifsnyderb]

15 minutes ago, scm2000 said:

so today i took the code wozniac et al published in dr dobbs journal for 4 byte binary floating point. i converted it over to a MAC65 assembly language code. it uses the page zero area that the ROM floating point uses for its regusters etc. 

it assembles and im writing ascii to fp and fp to ascii routines which it lacks

 

if it works and is faster than the fast fp rom version i’ll post the code

I suspect one issue, with the Atari FP code, is that it all had to be stuffed into 2k.

[scm2000]

34 minutes ago, reifsnyderb said:

I suspect one issue, with the Atari FP code, is that it all had to be stuffed into 2k.

Well I think it was number of other things... The outfit that wrote it, and Atari BASIC was not necessarily expert.   The person who wrote floating point had never written floating point routines before.  also they chose BCD, they say to avoid representation errors you typically have when using a binary mantissa, but BCD math is inherently slower than binary math, even though the 6502 has support for BCD math.

 

as for size... the Dr Dobbs code, is only 450 lines of assembly code, my assembly listing says it's only about 700 bytes long...   now it only supports these functions:

0100 ;        NATURAL LOG
0110 ;        COMMON LOG
0120 ;        EXPONENTIAL (E**X)
0130 ;        FLOAT      FIX
0140 ;        FADD       FSUB
0150 ;        FMUL       FDIV
 

so the Atari ROM FP adds, polynomials, and ASCII to FP and FP to ASCII, but I'd say there'd be no problem extending the DR Dobbs code and fiting it into 2k...or even 1k     The problem with the Dr Dobbs code is it can't be a drop in replacement for floating point in rom because the representation is different and external programs depend on the BCD representation.

 

In my case I'm only interested in having floating point math capability -- I can afford a 1k for that.

[pcrow]

I always did like that Atari floating point didn't have weird rounding issues like you get with modern (binary) floating point, even if it's a less efficient representation.  The instructions take the same time in BCD.  Is it necessarily true that you'll need more instructions for BCD floating point, or is it just that Atari's implementation was poor (which is well documented)?

[phaeron]

14 minutes ago, pcrow said:

I always did like that Atari floating point didn't have weird rounding issues like you get with modern (binary) floating point, even if it's a less efficient representation.  The instructions take the same time in BCD.  Is it necessarily true that you'll need more instructions for BCD floating point, or is it just that Atari's implementation was poor (which is well documented)?

Digit at a time algorithms tend to be slower due to the larger radix. Also, some tricks that work in binary don't work in 6502 decimal mode. You can't INC or DEC in decimal, or do a reverse subtract (EOR #$FF / SEC / ADC).

[Rybags]

Not all in 2K - lesser used + trig stuff contained in the Basic Rom.

 

It'd be interesting to port over a faster binary based FP to see how fast it compares - though of course that would create big compatibility issues with some software.

[scm2000]

14 hours ago, pcrow said:

I always did like that Atari floating point didn't have weird rounding issues like you get with modern (binary) floating point, even if it's a less efficient representation.  The instructions take the same time in BCD.  Is it necessarily true that you'll need more instructions for BCD floating point, or is it just that Atari's implementation was poor (which is well documented)?

Yes, there are some peculiarities with binary floating point representations... as you said.. some decimal numbers can't be represented exactly in binary floating point.  But also theres considerations when checking for exact equality between two floating point numbers...    So for instance if you calculate A, and want to know if it equals zero... it might just be within a small epsilon of zero, even though the ideal math would have it exactly zero...   So when comparing two numbers A and B for equality -- you basically do a subtract and check for zero, but again, it might be slightly away from zero, even though the two numbers should really be equal.   Knowing this I avoid checks for exact equality..    You wouldn't have that complication with BCD floats.

[ivop]

16 hours ago, pcrow said:

I always did like that Atari floating point didn't have weird rounding issues like you get with modern (binary) floating point, even if it's a less efficient representation.

You always have rounding issues, no matter which base you choose. For example, try this in Atari Basic:

 

A=1/6

? A

0.1666666666

? 6*A

0.9999999999

 

[tebe]

Mad Pascal

shortreal (fixed-point Q8.8)  A = 1/6 = 0.1679    A * 6 = 1.0078
real      (fixed-point Q24.8) A = 1/6 = 0.1679    A * 6 = 1.0078
float16   (IEEE754 16bit)     A = 1/6 = 0.166747  A * 6 = 1.000000
single    (IEEE754 32bit)     A = 1/6 = 0.166663  A * 6 = 1.000000

 

[ClausB]

 

I did a fast BCD multiplier a while ago:

 

 

[thorfdbg]

On 6/1/2024 at 5:56 PM, scm2000 said:

But also theres considerations when checking for exact equality between two floating point numbers...    So for instance if you calculate A, and want to know if it equals zero... it might just be within a small epsilon of zero, even though the ideal math would have it exactly zero...   So when comparing two numbers A and B for equality -- you basically do a subtract and check for zero, but again, it might be slightly away from zero, even though the two numbers should really be equal.   Knowing this I avoid checks for exact equality..    You wouldn't have that complication with BCD floats.

These issues exist regardless of the representation - floating point is never precise. However, you can compute how much you loose by rounding, and the issue is that the larger the basis, the larger the round-off error. BCD math is thus necessarily less precise than binary, and Atari FP even more so as it does not even use 10 as basis, but 100. From a mathematical perspective, a very bad choice.

The only advantage is that you do not loose precision when converting from and to a human-readable representation.

[thorfdbg]

On 6/1/2024 at 3:48 AM, pcrow said:

I always did like that Atari floating point didn't have weird rounding issues like you get with modern (binary) floating point, even if it's a less efficient representation. 

That is exactly not true. It has considerably larger rounding issues than a binary representation. In fact, binary has the *least* rounding issue from all numerical bases. The smaller the basis, the smaller the issue. The base-100 (yes, really!) representation is really a very bad choice, numerically.

[pcrow]

1 hour ago, thorfdbg said:

That is exactly not true. It has considerably larger rounding issues than a binary representation. In fact, binary has the *least* rounding issue from all numerical bases. The smaller the basis, the smaller the issue. The base-100 (yes, really!) representation is really a very bad choice, numerically.

Yes, I get the mathematics here.  But from a user perspective, the Atari floating point routines gave out the same answers you would see with a calculator, while other floating point routines often have a long string of 9s at the end (with the last digit or two getting some other value).  So for someone looking at this in 1979, the Atari math routines would feel more right.

[thorfdbg]

It would be great if this would be the case, but that's not true. Try to compute 2^3 with Rev.A of Atari Basic. That does not give you 8. It gives you 7.9999, also due to the lousy (sorry) implementation of floating point, and the naive implementation of the power function in the Basic cartridge (of which the mathpack is actually a part of, historically). Rev.B added some sort of "workaround" without actually improving the algorithm. Basic++ includes a smarter and numerically more stable code for it. Atari (or actually SMI) really botched the math - but that's also due to the rather tight timeline within which Basic had to be developed.

[tebe]

certainly not the fastest but interesting (only add, sub)

 

https://github.com/CrashAndSideburns/6502ieee754

Edited June 6 by tebe

[XL Freak]

SPEED COMPARISONS

 

I've been playing around with my Antonia mod and different rom's. I stumbled across the XLOS816 16-bit XL rom by @drac030, and it works great  but slow math package  So I got in touch with him to attempt to 'persuade' him to add a fast math package, since his website notes say that is a low priority. I think he already had it done, because he responded with this...

 

xlos816f.rom

 

This rom uses the Marlett's FastFP package (is this a good one?). (Pls note this rom is for Antonia or Rapidus upgrades only, as it is written for the 16-bit 65C816 processor. More info on this 16-bit OS can be found here.)

 

Ok, here are a few speed comparisons:

Ticks  Math Package
-----  ------------
1080   Stock Atari Basic Rev C
1010   Altirra Basic
1010   Fast Basic integraged math package
 663   XLOS816F with Marlett's FastFP, stock Atari Basic Rev C
 373   Turbo Basic XL (yes, Frank was a genius!)
  93   Fast Basic Integer mode (for reference only), but the results were incorrect

 

This is the test I used. I just tried to get as many calculations as I could possibly fit on a single logical line without any errors.

1 POKE 19,0:POKE 20,0:A=1
4 FOR I=1 TO 100
5 A=A+I+(I+A)-(I+A)*(I+A)/(I+A)+(I-A+1)-(I-A+2)*(I-A+3)/(I-A+4)+(I*A)-(I*A)*(I*A)/(I*A)+(I/A)-(I/A)*(I/A)/(I/A)
6 NEXT I
7 ? I,A,PEEK(19)*256+PEEK(20)

Note that all references to the A variable in Fast Basic were changed to A% to force floating point.

 

 

 

Edited July 23 by XL Freak
Removed a stupid question lol