FP-CALC floating point number comparison BUGGY in ZX Spectrum? - Sinclair

This is a discussion on FP-CALC floating point number comparison BUGGY in ZX Spectrum? - Sinclair ; Hi, I'm new to this group. Great there are some people there still with the Speccy and other Sinclair related products! :-) I'm almost finishing a Basic cross compiler for the ZX Spectrum (you write a FreeBasic-like program and it ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: FP-CALC floating point number comparison BUGGY in ZX Spectrum?

  1. FP-CALC floating point number comparison BUGGY in ZX Spectrum?

    Hi,

    I'm new to this group. Great there are some people there still with
    the Speccy and other Sinclair related products! :-)

    I'm almost finishing a Basic cross compiler for the ZX Spectrum (you
    write a FreeBasic-like program and it will produce a TZX or .BIN
    file).

    However, when dealing with Floating Point arithmetic, I decided to use
    ZX ROM FP-Calculator (I have spend almost 3 weeks to learn how to use
    it correctly, due to lack of documentation). Anyway, I now have FP
    arithmetic, but when dealing with number comparisons, I notice that
    some FP CALC comparison operators (see http://www.wearmouth.demon.co.uk/zx82.htm#L353B)
    didn't work as expected, or didn't work at all (I test them in an 2
    different emulators, anyway).

    For example:

    To test if 10 == 9, I could do:

    org 40000
    ;
    LD A,10
    call 2d28h ; STACK_A
    Ld a,9
    call 2d28h ; STACK_A

    rst 28h ; FP CALC
    defb 0Eh ; NUM == NUM
    defb 38h ; END CALC

    call 2314h ; STK_TO_A ; 0 == FALSE, 1 == True
    ret

    Which effectively works (returns 0 in A). But changing defb 0Eh line
    by defB 0Ch (GREATER THAN) seems to return always false (?).

    Anybody knows why the above is failing?

    I managed to do a Greater Than comparison by subtracting, anyway. But,
    unless I'm missing something, this looks more likely a bug in ROM
    calculator. :-/

    Regards,
    Jose

    PS: BTW, I hope this is the right place to ask for this. If not,
    sorry, and ignore this msg.
    ---
    http://www.boriel.com

  2. Re: FP-CALC floating point number comparison BUGGY in ZX Spectrum?

    Boriel wrote:
    > Which effectively works (returns 0 in A). But changing defb 0Eh line
    > by defB 0Ch (GREATER THAN) seems to return always false (?).
    >
    > Anybody knows why the above is failing?
    >
    > I managed to do a Greater Than comparison by subtracting, anyway. But,
    > unless I'm missing something, this looks more likely a bug in ROM
    > calculator. :-/


    Surely not a bug in the calculator as such but in how it is called? e.g.
    the following BASIC program:
    10 PRINT "10=9:";10=9
    20 PRINT "10>9:";10>9
    30 PRINT "10<9:";10<9

    produces these results as expected:
    0
    1
    0

    Can you look at what is given to the calculator in the above cases?

    Fred

  3. Re: FP-CALC floating point number comparison BUGGY in ZX Spectrum?

    On Mar 23, 10:58*pm, Fred wrote:
    > Boriel wrote:
    > > Which effectively works (returns 0 in A). But changing defb 0Eh line
    > > by defB 0Ch (GREATER THAN) seems to return always false (?).

    >
    > > Anybody knows why the above is failing?

    >
    > > I managed to do a Greater Than comparison by subtracting, anyway. But,
    > > unless I'm missing something, this looks more likely a bug in ROM
    > > calculator. :-/

    >
    > Surely not a bug in the calculator as such but in how it is called? e.g.
    > the following BASIC program:
    > 10 PRINT "10=9:";10=9
    > 20 PRINT "10>9:";10>9
    > 30 PRINT "10<9:";10<9
    >
    > produces these results as expected:
    > 0
    > 1
    > 0


    According to Toni Baker in ZX Computing, Sep 1986, various opcodes
    require that the B register is also set to the value of the
    instruction opcode.

    So for 0C GREATER THAN, B must equal 0C.

    See ftp://ftp.worldofspectrum.org/pub/si...g860900057.jpg

    Does that fix the p[roblem?

    Matthew


  4. Re: FP-CALC floating point number comparison BUGGY in ZX Spectrum?

    On Mar 23, 11:58 pm, Matthew Wilson
    wrote:
    [...]

    > So for 0C GREATER THAN, B must equal 0C.
    >
    > Seeftp://ftp.worldofspectrum.org/pub/sinclair/magazines/ZXComputing/Issu...

    First of all, thank for this info. It was exactly what I was looking
    for. :-) (it would have saved me a lot of work :P)
    >
    > Does that fix the p[roblem?

    It does!!

    Analyzing again the ROM listing (see http://www.wearmouth.demon.co.uk/zx82.htm#L335B
    )
    first line reads:

    LD A, B

    which means the operaton must be in the Z80 B register, not in the
    Calculator "B REGISTER" (BREG system variable at 23655). ARRGHHH! :-D
    One of the many test I tried was:

    LD A, 0Ch ; GTR-THAN
    LD (23655), A ; Loads 0C in Calculator B REGISTER
    RST 28h
    ...

    which, also failed, as expected.
    It is simply LD B, 0Ch which is simpler and faster.

    Thanks a lot!

    Regards,
    Jose

    BTW: I think my ZXBasic compiler will be ready this month. I will made
    it public at WOS if anybody is interested (It is not exactly ZX BASIC,
    but another dialect, and of course, much faster, since it's translated
    into ASM).

  5. Re: FP-CALC floating point number comparison BUGGY in ZX Spectrum?

    On Mar 24, 11:55*am, Boriel wrote:
    > On Mar 23, 11:58 pm, Matthew Wilson
    > wrote:
    > [...]
    >
    > > So for 0C GREATER THAN, B must equal 0C.

    >
    > > Seeftp://ftp.worldofspectrum.org/pub/sinclair/magazines/ZXComputing/Issu....

    >
    > First of all, thank for this info. It was exactly what I was looking
    > for. :-) (it would have saved me a lot of work :P)
    >
    > > Does that fix the p[roblem?

    >
    > It does!!


    It's a very informative set of articles (as is typical for Toni
    Baker). 5 parts, I think.

    Matthew

+ Reply to Thread