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
[url]http://groups.google.com/group/comp.sys.sinclair/browse_thread/thread/6e897ff439e7cae0/a79d9cbd6d8e06f9?lnk=gst&q=boriel#a79d9cbd6d8e06f9[/url]).

Now I have another one on the same topic (This looks a bit like a geek
trivia contest :D) 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?

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" <boriel@gmail.com> wrote in message
news:0d14de6a-f906-4379-a02c-2df1739c8a86@c19g2000prf.googlegroups.com...[color=blue]
> Hi,
>
> It' me again. :^P
>
> First of all, thanks a lot (again) for the previous answer to my dark
> FP-ROM question (see
> [url]http://groups.google.com/group/comp.sys.sinclair/browse_thread/thread/6e897ff439e7cae0/a79d9cbd6d8e06f9?lnk=gst&q=boriel#a79d9cbd6d8e06f9[/url]).
>
> Now I have another one on the same topic (This looks a bit like a geek
> trivia contest :D) 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?
>
>
>[/color]

On Apr 10, 3:24*pm, Boriel <bor...@gmail.com> wrote:[color=blue]
> 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 :D) 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?[/color]

Looking at the Complete Spectrum ROM Disassembly at
[url]ftp://ftp.worldofspectrum.org/pub/sinclair/books/CompleteSpectrumROMDisassemblyThe.pdf[/url]
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"<STR$ 0 .1 yields the logical value
"true"; once again "" is used instead of "50"."

So it looks like a known bug.

Matthew

On 10 abr, 19:11, Matthew Wilson <matt...@mjwilson.demon.co.uk> wrote:[color=blue]
>
> "See PRINT-FP for an explanation of the 'PRINT "A"+STR$ 0.1' error."[/color]
[...][color=blue]
> So it looks like a known bug.
>
> Matthew[/color]

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.