The custom syntax makes it harder to reuse the code in existing projects without a porting step. I was looking at this as a potential way to sidestep the parsing and formatting required for the woz floating point code.

In WDC assembly syntax a leading '<' in the operand (as in 'LDA <exp') forces zero/direct page and '>' forces absolute long in 65c816 mode.

Having '<exp' interpret as '#<exp' is rather weird. I don't think I've ever used a 6502 assembler that does that.

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs

Hello,
Three years ago I used fltpt65 for my calculator project ; I ported it to the ca65 assembler, fixed some bugs and added a few functions. The archive is named fltptC65 which implies it makes some use of the 65C02 instructions - but the "readme" file will tell you more :

"readme" file contents :
-------------------------------------------------------------------------------
fltptC65 - A slightly enhanced fltpt65 (original from C. R. Bond)
2017 - Marc Ferrer

INTRODUCTION :
A few years ago I built a 65C02-based RPN programmable calculator. I used C.R. Bond's floating-point package to which I added a few mathematical functions. (also fixed a few bugs, please see below)
The core arithmetic routines are reliable enough that they've allowed my calculator to perform flawlessly tens of billions of calculations during the last 3 years.
(multi-precision constants computations, pi, e ...)

IMPORTANT NOTES :
- Assembles with ca65 assembler.
- Uses 65C02 instructions.
- Provided as is, no warranty.
- There are surely many improvement paths I didn't look for.

ADDED FUNCTIONS :
pow2 ........ Squares the argument
isint ......... Checks if the argument is an integer
cubrt ........ Cubic root computation
p10ow ...... (10 ** argument) computation
fact .......... Factorial computation (range : 0 to 449)
ncr ........... Combinations computation
npr ........... Permutations computation
hr2hms ...... Decimal hour to Hour/Minute/Second conversion
hms2hr ...... Hour/Minute/Second to decimal hour conversion
p2r ........... Polar to rectangular coordinate conversion
r2p ........... Rectangular to polar coordinate conversion

NOTES :
The last 2 functions use extra F.P. registers (ST_X and ST_Y) which
are not part of the original fltpt65 environment !
Anyway you can easily tailor them to your own project.

The last 7 functions use a new w5 F.P. working register. It should
be possible to optimize them in order to avoid that.

FIXED BUGS :
1) Multiplication (mul) :
- Incorrect results when multiplying 2 numbers with
exponents having same absolute values but opposite signs.
- If w1 = 0 or w2 = 0, we got a result with a computed zero mantissa
but the exponent field isn't set to 0.
2) Arc tangent (atan) :
- Trapped in an endless loop if argument = 0.
3) Integer part (int) :
- If argument exponent = +010, the mantissa's 2nd digit is zeroed
instead of the 12th one.

KNOWN BUGS (to me) :
1) Logarithm (ln) :
- Gives wrong results with arguments of magnitude > 10^10.
-------------------------------------------------------------------------------
Last note not included in the readme file : the cycle counts I mentioned in some comments may be inaccurate. (I recently read about a new version of Michal Kowalski's simulator which has fixed that.)

Hoping it'll be of some use,
Marc

Thanks for posting.

I just finished a port to the Ophis assembler and introduced some 65c02 instructions, as well as macros to reduce the boiler plate code. I might work in your extra functions later.

I've been going over this code with a fine tooth comb to really understand it. I've noticed there's a lot of boiler plate loading up registers as arguments, calling a subroutine copy2w, and then using those registers for a byte move using indirect addressing mode. Here's a sample of those code in question.

There another subroutine which is almost the same, but copies to the r registers. This seems a bit convoluted as it takes nine bytes for the setup, and then seven instructions to store and return from the subroutine. In addition a indirect addressing takes a cycle time longer than absolute addressing. So I replaced all instances of this code with a macro invocation that expands to a copy loop as follows:

Unless I am missing something the expanded macro is only two bytes larger than the subroutine call, but is much faster because of the reduced overhead.

Update: This code has a dependency for the ra registers to be at $0400, and I am not sure why. I found one hard code magic number, but that didn't resolve the dependency. It's strange.

I think I've worked out all the magic number dependencies, as well as the requirement that certain variables be on the same page. I reworked the code to use macros which clarifies the code flow considerably, and started separating symbols into local scope versus external entry points.

Updated source is here: https://github.com/Martin-H1/Lisp65/blob/master/bcdmath.asm

It works pretty well, and BCD is a snap to print versus the binary format.

Looks as though the page went 404.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Looks like Martin has moved some code around. Have a look around
https://github.com/Martin-H1/Math65

That is 6 month old and most probably does not have the changes.

edit: Sorry, my bad. The post BDD was referring to is 6 month old. So it should be up to date.

_________________
6502 sources on GitHub: https://github.com/Klaus2m5

Yes, I moved it because it the code and the unit tests were adding confusing noise to my Lisp65 repo. I've also collected two different float packages, and started porting an IEEE version as well. So I decided to given all of them their own repo. I forgot to update the link here.

No problem - a bit of link rot is bound to happen, and almost always a little searching can fix it.

I'm getting a bit of repo sprawl, so I'm creating monorepos of all my code based upon the architecture (e.g. Arduino, 6502). It will be hierarchical, so all projects for 6502 will be in sub-directories under that repo. Math65 will be here:

https://github.com/Martin-H1/6502/tree/master/Math65

Ultimately I might want to create a common macros directory and link between projects rather than copying and pasting like I am currently.