Another ROM FP-CALC strange question - Sinclair

This is a discussion on Another ROM FP-CALC strange question - Sinclair ; Hi, It' me again. :^P First of all, thanks a lot (again) for the previous answer to my dark FP-ROM question (see http://groups.google.com/group/comp....9d9cbd6d8e06f9 ). Now I have another one on the same topic (This looks a bit like a geek ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: Another ROM FP-CALC strange question

  1. Another ROM FP-CALC strange question

    Hi,

    It' me again. :^P

    First of all, thanks a lot (again) for the previous answer to my dark
    FP-ROM question (see
    http://groups.google.com/group/comp....9d9cbd6d8e06f9).

    Now I have another one on the same topic (This looks a bit like a geek
    trivia contest ) regarding to FP-ROM. This time is related to the STR
    $ calculator function; The following ASM sequence converts a FP number
    to its strings representation (I need it to print FP numbers, for
    example):

    --- 8< --- --- 8< --- --- 8< --- (snip)
    RST #28h
    DEFB 2Eh ; STR$
    DEFB 38h ; END CALC

    call STK_POP ; Recovers parameters from the stack
    --- 8< --- --- 8< --- --- 8< --- (snip)

    This sequence works as expected. The string parameters are retrieved
    in DE (string start) and BC (string length) of the FP number. The
    strange thing is that, if the FP number is < 1 (e.g. 0.1), the
    calculator stack seems to have an extra FP ZERO (00 00 00 00 00).
    Thus, each time I execute the above sequence, I end up with a *memory
    leak * of 5 bytes. :-( if the number < 1.0

    Any clue about this? Why doing this leave 5 ZERO bytes on top of the
    calculator stack?




  2. Re: Another ROM FP-CALC strange question

    Could be wrong here but it sounds a bit like how the ZX81 pushes a zero to
    first print the leading zero before printing the decimal fraction part.

    Andy

    "Boriel" wrote in message
    news:0d14de6a-f906-4379-a02c-2df1739c8a86@c19g2000prf.googlegroups.com...
    > Hi,
    >
    > It' me again. :^P
    >
    > First of all, thanks a lot (again) for the previous answer to my dark
    > FP-ROM question (see
    > http://groups.google.com/group/comp....9d9cbd6d8e06f9).
    >
    > Now I have another one on the same topic (This looks a bit like a geek
    > trivia contest ) regarding to FP-ROM. This time is related to the STR
    > $ calculator function; The following ASM sequence converts a FP number
    > to its strings representation (I need it to print FP numbers, for
    > example):
    >
    > --- 8< --- --- 8< --- --- 8< --- (snip)
    > RST #28h
    > DEFB 2Eh ; STR$
    > DEFB 38h ; END CALC
    >
    > call STK_POP ; Recovers parameters from the stack
    > --- 8< --- --- 8< --- --- 8< --- (snip)
    >
    > This sequence works as expected. The string parameters are retrieved
    > in DE (string start) and BC (string length) of the FP number. The
    > strange thing is that, if the FP number is < 1 (e.g. 0.1), the
    > calculator stack seems to have an extra FP ZERO (00 00 00 00 00).
    > Thus, each time I execute the above sequence, I end up with a *memory
    > leak * of 5 bytes. :-( if the number < 1.0
    >
    > Any clue about this? Why doing this leave 5 ZERO bytes on top of the
    > calculator stack?
    >
    >
    >




  3. Re: Another ROM FP-CALC strange question

    On Apr 10, 3:24*pm, Boriel wrote:
    > Hi,
    >
    > It' me again. :^P
    >
    > First of all, thanks a lot (again) for the previous answer to my dark
    > FP-ROM question (seehttp://groups.google.com/group/comp.sys.sinclair/browse_thread/thread...).
    >
    > Now I have another one on the same topic (This looks a bit like a geek
    > trivia contest ) regarding to FP-ROM. This time is related to the STR
    > $ calculator function; The following ASM sequence converts a FP number
    > to its strings representation (I need it to print FP numbers, for
    > example):
    >
    > --- 8< --- --- 8< --- --- 8< --- (snip)
    > RST #28h
    > DEFB 2Eh ; STR$
    > DEFB 38h ; END CALC
    >
    > call STK_POP ; Recovers parameters from the stack
    > --- 8< --- --- 8< --- --- 8< --- (snip)
    >
    > This sequence works as expected. The string parameters are retrieved
    > in DE (string start) and BC (string length) of the FP number. The
    > strange thing is that, if the FP number is < 1 (e.g. 0.1), the
    > calculator stack seems to have an extra FP ZERO (00 00 00 00 00).
    > Thus, each time I execute the above sequence, I end up with a *memory
    > leak * of 5 bytes. :-( if the number < 1.0
    >
    > Any clue about this? Why doing this leave 5 ZERO bytes on top of the
    > calculator stack?


    Looking at the Complete Spectrum ROM Disassembly at
    ftp://ftp.worldofspectrum.org/pub/si...ssemblyThe.pdf
    the str$ routine at 361f is followed by the comment

    "See PRINT-FP for an explanation of the 'PRINT "A"+STR$ 0.1' error."

    After 2e24 there is the comment
    "Note that the stack is now unbalanced. An extra byte 'DEFB +02,
    delete' is needed at 2E25, immediately after the RST 0028. Now an
    expression like "2" +STR$ 0.5 is evaluated incorrectly as 0.5; the
    zero left on the stack displaces the "2" and is treated as a null
    string.
    Similarly all the string comparisons can yield incorrect values if the
    second string takes the form STR$ x where x is numerically less
    than 1; e.g. the expression "50" "true"; once again "" is used instead of "50"."

    So it looks like a known bug.

    Matthew

  4. Re: Another ROM FP-CALC strange question

    On 10 abr, 19:11, Matthew Wilson wrote:
    >
    > "See PRINT-FP for an explanation of the 'PRINT "A"+STR$ 0.1' error."

    [...]
    > So it looks like a known bug.
    >
    > Matthew


    Wow! O_O It was that!! Well, at less this time it was a ROM bug, not
    mine. :-P
    Andy, Matthew, thanks a lot. I would like to credit you for your
    valuable help in the compiler credits, if you don't mind.

    Regards,
    J.

+ Reply to Thread