128 BASIC bug with <= <> >= - Sinclair

This is a discussion on 128 BASIC bug with <= <> >= - Sinclair ; In 128 BASIC, enter a line like this one: 10 PRINT " " The gets spaces around it, as if it were the keyword token, but they are disregarded when the PRINT statement actually runs. Is this glitch documented? I ...

+ Reply to Thread
Results 1 to 14 of 14

Thread: 128 BASIC bug with <= <> >=

  1. 128 BASIC bug with <= <> >=

    In 128 BASIC, enter a line like this one:

    10 PRINT "<>"

    The <> gets spaces around it, as if it were the keyword token, but
    they are disregarded when the PRINT statement actually runs.

    Is this glitch documented? I noticed it wasn't in Ian Collier's list
    of +3 oddities.

    Eq.



  2. Re: 128 BASIC bug with <= <> >=

    On Dec 23, 4:17*am, "Paul E Collins"
    wrote:
    > In 128 BASIC, enter a line like this one:
    >
    > 10 PRINT "<>"
    >
    > The <> gets spaces around it, as if it were the keyword token, but
    > they are disregarded when the PRINT statement actually runs.
    >
    > Is this glitch documented? I noticed it wasn't in Ian Collier's list
    > of +3 oddities.
    >
    > Eq.


    That's a new one. It seems to be present in all versions of the ROM
    except the original Spanish one.

  3. Re: 128 BASIC bug with <= <> >=

    On Dec 23, 4:17 am, "Paul E Collins"
    wrote:
    > In 128 BASIC, enter a line like this one:
    >
    > 10 PRINT "<>"
    >
    > The <> gets spaces around it, as if it were the keyword token, but
    > they are disregarded when the PRINT statement actually runs.
    >
    > Is this glitch documented? I noticed it wasn't in Ian Collier's list
    > of +3 oddities.


    Actually I think it might be...

    " 14AF: On the 48K spectrum, leading spaces are only printed for
    token
    codes >=197 starting with a letter. On the +3, all
    tokens have
    spaces before and after."

    That sounds like it fits - the spaces aren't genuinely in the BASIC
    line, they're
    just displayed by the 128 printing program. (You can confirm this by
    typing
    SPECTRUM to go into 48 mode.)

    Matthew

  4. Re: 128 BASIC bug with <= <> >=

    Yes, I think we had long debates about this one on Micronet in the late 80s.
    There was also something about a syntax error in the 128k editor that was
    not really an error as I recall, as some fiddling with spaces seemed to fix
    it.

    Long time ago now.

    Brian

    --
    Brian Gaff - briang1@blueyonder.co.uk
    Note:- In order to reduce spam, any email without 'Brian Gaff'
    in the display name may be lost.
    Blind user, so no pictures please!
    "Matthew Wilson" wrote in message
    news:dd9931ae-9282-49d0-a9a8-d80ce808f9fc@e23g2000prf.googlegroups.com...
    > On Dec 23, 4:17 am, "Paul E Collins"
    > wrote:
    >> In 128 BASIC, enter a line like this one:
    >>
    >> 10 PRINT "<>"
    >>
    >> The <> gets spaces around it, as if it were the keyword token, but
    >> they are disregarded when the PRINT statement actually runs.
    >>
    >> Is this glitch documented? I noticed it wasn't in Ian Collier's list
    >> of +3 oddities.

    >
    > Actually I think it might be...
    >
    > " 14AF: On the 48K spectrum, leading spaces are only printed for
    > token
    > codes >=197 starting with a letter. On the +3, all
    > tokens have
    > spaces before and after."
    >
    > That sounds like it fits - the spaces aren't genuinely in the BASIC
    > line, they're
    > just displayed by the 128 printing program. (You can confirm this by
    > typing
    > SPECTRUM to go into 48 mode.)
    >
    > Matthew




  5. Re: 128 BASIC bug with <= <> >=

    On Sun, 23 Dec 2007 01:20:10 -0800 (PST) da kidz on comp.sys.sinclair were rappin'
    to MC Matthew Wilson:

    > On Dec 23, 4:17 am, "Paul E Collins"
    > wrote:
    > > In 128 BASIC, enter a line like this one:
    > >
    > > 10 PRINT "<>"
    > >
    > > The <> gets spaces around it, as if it were the keyword token, but
    > > they are disregarded when the PRINT statement actually runs.
    > >
    > > Is this glitch documented? I noticed it wasn't in Ian Collier's list
    > > of +3 oddities.

    >
    > Actually I think it might be...
    >
    > " 14AF: On the 48K spectrum, leading spaces are only printed for
    > token
    > codes >=197 starting with a letter. On the +3, all
    > tokens have
    > spaces before and after."
    >
    > That sounds like it fits - the spaces aren't genuinely in the BASIC
    > line, they're
    > just displayed by the 128 printing program. (You can confirm this by
    > typing
    > SPECTRUM to go into 48 mode.)


    If that's the bug, then PRINT "PRINT" would also have spaces round the
    PRINT that is being PRINTed.

    The operators are a bit odd in the 128 editor, IF a ab<1 after parsing. If you add some spaces you can get it to accept
    it (this may be the bug Brian mentioned).

    Chris


    --
    +-------------------------------------------+
    | Unsatisfactory Software - "because it is" |
    | http://www.unsatisfactorysoftware.co.uk |
    | Your Sinclair: A Celebration |
    +- http://www.yoursinclair.co.uk -----------+

    DISCLAIMER: I may be making all this stuff up again.

  6. Re: 128 BASIC bug with <= <> >=

    On Dec 23, 11:31 am, "Chris Young"
    wrote:
    > On Sun, 23 Dec 2007 01:20:10 -0800 (PST) da kidz on comp.sys.sinclair were rappin'
    > to MC Matthew Wilson:
    >
    >
    >
    > > On Dec 23, 4:17 am, "Paul E Collins"
    > > wrote:
    > > > In 128 BASIC, enter a line like this one:

    >
    > > > 10 PRINT "<>"

    >
    > > > The <> gets spaces around it, as if it were the keyword token, but
    > > > they are disregarded when the PRINT statement actually runs.

    >
    > > > Is this glitch documented? I noticed it wasn't in Ian Collier's list
    > > > of +3 oddities.

    >
    > > Actually I think it might be...

    >
    > > " 14AF: On the 48K spectrum, leading spaces are only printed for
    > > token
    > > codes >=197 starting with a letter. On the +3, all
    > > tokens have
    > > spaces before and after."

    >
    > > That sounds like it fits - the spaces aren't genuinely in the BASIC
    > > line, they're
    > > just displayed by the 128 printing program. (You can confirm this by
    > > typing
    > > SPECTRUM to go into 48 mode.)

    >
    > If that's the bug, then PRINT "PRINT" would also have spaces round the
    > PRINT that is being PRINTed.


    I just tried this, and that's exactly what happens.

    Matthew

  7. Re: 128 BASIC bug with <= <> >=

    It's not the 'leading spaces' bug. The bug is that the tokenizer is
    tokenizing the stuff contained between the quotes. This bug is not
    present in the tokenizer in the Mk I ROM (but that tokenizer can't
    handle lower case).

  8. Re: 128 BASIC bug with <= <> >=

    Matthew Wilson wrote:
    >> If that's the bug, then PRINT "PRINT" would also have spaces round the
    >> PRINT that is being PRINTed.

    >
    > I just tried this, and that's exactly what happens.


    Right -- it's a tokenising bug and not a problem with listing (although
    128K BASIC's listing does behave differently). The real problem is that

    10 PRINT LEN(" <> ")

    prints 1 on the 128K, and LPRINT(" <> ") might not work.
    --
    Stuart Brady

  9. Re: 128 BASIC bug with <= <> >=

    On Dec 23, 4:39*pm, Stuart Brady
    wrote:
    > Matthew Wilson wrote:
    > >> If that's the bug, then PRINT "PRINT" would also have spaces round the
    > >> PRINT that is being PRINTed.

    >
    > > I just tried this, and that's exactly what happens.

    >
    > Right -- it's a tokenising bug and not a problem with listing (although
    > 128K BASIC's listing does behave differently). *The real problem is that
    >
    > 10 PRINT LEN(" <> ")
    >
    > prints 1 on the 128K, and LPRINT(" <> ") might not work.


    My advice then is to switch to using the English translation of the MK
    I ROM. Or ditch 128 BASIC completely (unless you use PLAY or the RAM
    disk) and use something like the Gosh Wonderful ROM which has a better
    tokenizer.

  10. Re: 128 BASIC bug with <= <> >=

    Stuart Brady wrote:
    : 10 PRINT LEN(" <> ")

    : prints 1 on the 128K, and LPRINT(" <> ") might not work.

    Workaround: 10 PRINT LEN (" <"+"> ")

    --
    --------------------------- ,@@.o ,@@. SPELL SUCCEEDS
    John Elliott | @@@@ @@@@ n \_O_
    CHAOS in a sig... | '||` '||` Hr \I `
    --------------------------- JL JL I\ /\\

  11. Re: 128 BASIC bug with <= <> >=

    On Dec 23, 5:10 pm, OwenBot wrote:
    > On Dec 23, 4:39 pm, Stuart Brady
    > wrote:
    >
    > > Matthew Wilson wrote:
    > > >> If that's the bug, then PRINT "PRINT" would also have spaces round the
    > > >> PRINT that is being PRINTed.

    >
    > > > I just tried this, and that's exactly what happens.

    >
    > > Right -- it's a tokenising bug and not a problem with listing (although
    > > 128K BASIC's listing does behave differently). The real problem is that


    Hmm. I think that there is a tokenizing bug AND a listing bug.

    The tokenizer turns the two characters "<", ">" in the string into a
    single token.

    The lister then incorrectly places spaces before and after the single
    token.

    > > 10 PRINT LEN(" <> ")

    >
    > > prints 1 on the 128K, and LPRINT(" <> ") might not work.


    Isn't LPRINT smart enough to do this kind of translation anywhere?
    I mean, it was always possible to do LPRINT ("<>") on a 48
    (where the string contains a single character).

    Matthew

  12. Re: 128 BASIC bug with <= <> >=

    Matthew Wilson wrote:
    > Isn't LPRINT smart enough to do this kind of translation anywhere?
    > I mean, it was always possible to do LPRINT ("<>") on a 48
    > (where the string contains a single character).


    Yeah, but it might not work with all printer interfaces. For instance,
    the DISCiPLE and +D seem to have a 'raw output' option. In most cases,
    it would probably work, but I did say 'might' and not 'will'. :-)

    Poking such a string into memory and then reading it with a program that
    doesn't support BASIC tokens would be a better example.
    --
    Stuart Brady

  13. Re: 128 BASIC bug with <= <> >=

    > Isn't LPRINT smart enough to do this kind of translation anywhere?

    All LPRINT does is send the contents of the string to the printer
    channel. LLIST sends a listing to the printer channel. The LIST or
    PRINT command detokenize the contents of the listing/string.

    Sending the a token to the printer will result in the token being
    detokenized unless you're using a different driver. Remember that in
    128 BASIC, the printer is the serial port, not the ZX Printer. In +3
    BASIC you have the option of the Centronics port or the serial port.
    If you wanted you could always write your own driver (for instance to
    handle colour output).

    The workaround is to use LPRINT "<"+">". Other solutions are to use an
    editor where the bug is not present like the Mk I 128 ROM, the 48 ROM,
    or use a PC based editor like BASIN.

  14. Re: 128 BASIC bug with <= <> >=

    On Dec 23, 4:39 pm, Stuart Brady
    wrote:
    > Matthew Wilson wrote:
    > >> If that's the bug, then PRINT "PRINT" would also have spaces round the
    > >> PRINT that is being PRINTed.

    >
    > > I just tried this, and that's exactly what happens.

    >
    > Right -- it's a tokenising bug and not a problem with listing (although
    > 128K BASIC's listing does behave differently).


    The code is at $3e2f in the 128 ROM, where there is special code for
    dealing with these characters - that is, it's not the same code as is
    used
    for tokenizing words like "PRINT".

    It looks like there are flag bits being used to determine whether the
    code is in the middle of a string or not (see $3e74), but these bits
    are not considered when tokenizing the inequality operators.

    Looking at the disassembly, "<>" will also be tokenized inside a
    REM statement, but that's unlikely to cause any harm.

    Matthew

+ Reply to Thread