Reply by Nicholas O. Lindan●January 17, 20052005-01-17
<r_green@btinternet.com> wrote
> Sorted my problem the other day. So for anyone else who ever wants to
> know - facnrm appears to control how the math51.lib functions read a
> float from memory. When you have a IEEE754 constant in ROM like this...
>
> declare fp_ROM_273_15 (4) byte constant (033h, 093h, 088h,
> 043h); /* 273.15 kelvin */
>
> ...then you need to set facnrm true before referencing it, like this...
>
> facnrm = TRUE;
> call fp_link(call_fpsub, .fp_ROM_273_15); /* convert to celcius
> */
Oh, yes. It all comes back now, and if FACNRM is false then it grabs
the data from ram but at the rom address ... hence your divide by
zero, I imagine.
The interface I used was similar to an H/P calculator. The constant
part was in the name of the function call, a trailing 'C' indicating
a constant.
CALL FP_PUSH (.DEG_K);
CALL FP_SUBC (.K_273_15);
It didn't prevent
CALL FP_SUB (.K_273_15);
as PLM/51 didn't enforce strong typing on assignment to a pointer, only
dereferencing was typed.
--
Nicholas O. Lindan, Cleveland, Ohio
Consulting Engineer: Electronics; Informatics; Photonics.
Remove spaces etc. to reply: n o lindan at net com dot com
psst.. want to buy an f-stop timer? nolindan.com/da/fstop/
Reply by ●January 17, 20052005-01-17
Thanks Nicholas, I emailed them.
Sorted my problem the other day. So for anyone else who ever wants to
know - facnrm appears to control how the math51.lib functions read a
float from memory. When you have a IEEE754 constant in ROM like this...
declare fp_ROM_273_15 (4) byte constant (033h, 093h, 088h,
043h); /* 273.15 kelvin */
...then you need to set facnrm true before referencing it, like this...
facnrm = TRUE;
call fp_link(call_fpsub, .fp_ROM_273_15); /* convert to celcius
*/
But don't set facnrm before referencing an auxiliary.
--
Rich
Reply by Nicholas O. Lindan●January 13, 20052005-01-13
<r_green@btinternet.com> wrote
> I don't know who produced math51.lib. ...
> functions are called like this...
> call fp_link(call_ldfac, .fp_ROM_4812_8);
Sounds like (and I'll bet it is) FPAC51 from US Software.
US Software was sold to Lantronix who sold the technology
on to 'Micro Digital'.
The FPAC product line has been replaced by what appears
to be a semi-interpreted somewhat device-independent
system call Go-Fast.
--
Nicholas O. Lindan, Cleveland, Ohio
Consulting Engineer: Electronics; Informatics; Photonics.
Remove spaces etc. to reply: n o lindan at net com dot com
Reply by ●January 13, 20052005-01-13
Nicholas O. Lindan wrote:
> Do you know who produced your math51.lib? If you dump the .lib file
> as hex/ASCII does a copyright/company drop out?
I don't know who produced math51.lib.
I did dump it the other day - sadly no company name or (c) message in
there, though all the procedure names are readable...
CALL_BINBCD, CALL_FIX, CALL_FLOAT, CALL_FPABS, CALL_FPADD, CALL_FPASC,
CALL_FPCMP, CALL_FPDIV, CALL_FPEXP, CALL_FPLN... etc...
All operations are performed on a floating point accumulator. The
functions are called like this...
call fp_link(call_ldfac, .fp_ROM_4812_8);
which loads the floating point accumulator with an IEEE float stored at
address .FP_ROM_4812_8
Does this ring any bells?
Cheers,
--
Richard Green
Reply by Neil Kurzman●January 13, 20052005-01-13
Rich Green wrote:
> Hiya,
>
> Anybody still know anything about Intel PL/M-51?
>
> I have to modify some really old firmware written in PL/M that
> uses floating point procedures in library math51.lib. We have
> no documentation at all! I'm struggling with a tricky division
> by zero error.
>
> I reckon my problem might be caused by a rounding error.
>
> Can anyone tell me how to use the facrnm flag, which I think
> controls rounding mode.
>
> Any documentation on PL/M-51 and/or math51.lib would be greatly
> appreciated.
>
> ps. math51.lib is date 1992-03-05 size 9644 bytes.
>
> TIA,
> Rich
Try a post at www.8052.com you may have better luck.
Reply by Nicholas O. Lindan●January 12, 20052005-01-12
Rich Green" <r_green@btinternet.com> wrote
> I have to modify some really old firmware written in PL/M that
> uses floating point procedures in library math51.lib. We have
> no documentation at all! I'm struggling with a tricky division
> by zero error.
> I reckon my problem might be caused by a rounding error.
> Can anyone tell me how to use the facrnm flag, which I think
> controls rounding mode.
> ps. math51.lib is date 1992-03-05 size 9644 bytes.
PL/M-51 didn't support floating point. There were several
after-market add-on floating point libraries.
Do you know who produced your math51.lib? If you dump the .lib file
as hex/ASCII does a copyright/company drop out?
--
Nicholas O. Lindan, Cleveland, Ohio
Consulting Engineer: Electronics; Informatics; Photonics.
Remove spaces etc. to reply: n o lindan at net com dot com
psst.. want to buy an f-stop timer? nolindan.com/da/fstop/
Reply by Rich Green●January 12, 20052005-01-12
Hiya,
Anybody still know anything about Intel PL/M-51?
I have to modify some really old firmware written in PL/M that
uses floating point procedures in library math51.lib. We have
no documentation at all! I'm struggling with a tricky division
by zero error.
I reckon my problem might be caused by a rounding error.
Can anyone tell me how to use the facrnm flag, which I think
controls rounding mode.
Any documentation on PL/M-51 and/or math51.lib would be greatly
appreciated.
ps. math51.lib is date 1992-03-05 size 9644 bytes.
TIA,
Rich