Both the new Calculator DA code (in fixed branch) and the new Eyes DA make use of the Applesoft ROM floating point routines. The calculator has a bunch of helper routines that switch in ROM, make the call, and switch back in the LC, preserving P: (4 3 + 5 1 ops = 17 bytes, including RTS). (The un-fixed calculator had buggy spaghetti logic for keeping ROM banked in most of the time and banked it out for MGTK calls.) The Eyes DA makes use of macros for the calls, but relies on the caller to bracket usage with the appropriate bank-switching.
It might be more elegant to have a library that does this with an MLI-style calling interface (jsr entry / db call / dw ptr), which is only 6 bytes per call.
Code density isn't a huge deal for the DAs, but the repetition is icky. Also, the ROM calls have inconsistent register usage/ordering, and we could sanitize that.
This might make future work (e.g. a scientific calculator, or other future DAs) easier to write.
Both the new Calculator DA code (in
fixed
branch) and the new Eyes DA make use of the Applesoft ROM floating point routines. The calculator has a bunch of helper routines that switch in ROM, make the call, and switch back in the LC, preserving P: (4 3 + 5 1 ops = 17 bytes, including RTS). (The un-fixed calculator had buggy spaghetti logic for keeping ROM banked in most of the time and banked it out for MGTK calls.) The Eyes DA makes use of macros for the calls, but relies on the caller to bracket usage with the appropriate bank-switching.It might be more elegant to have a library that does this with an MLI-style calling interface (
jsr entry / db call / dw ptr
), which is only 6 bytes per call.Code density isn't a huge deal for the DAs, but the repetition is icky. Also, the ROM calls have inconsistent register usage/ordering, and we could sanitize that.
This might make future work (e.g. a scientific calculator, or other future DAs) easier to write.