Here's a christmas present for you!

edited December 2002 in Sinclair Basic
SE Basic is no longer being developed.
Post edited by chev on

Comments

  • edited December 2002
    This is the only present I've got so far, but it's a good one!

    Thanks!!
  • edited December 2002
    On 2002-12-25 12:28, aowen wrote:
    note that in order to generate the STOP token from an INPUT a$ command, you just have to press cursor down.

    Why not just type "STOP" (all four letters) in an INPUT a, and step out of the quotes and type "STOP" (again, one letter at a time) in an INPUT a$? That's how BASIC used to do it, IIRC. If your tokeniser takes any edit line, it should tokenise the stop properly?

    D.
  • edited December 2002
    There was a similar thread on CSS about this way back (about 2 years ago, IIRC) when I started coding SPIN - it was going to be a simple BASIC interpreter back then.

    The main sticking point was RND, PI etc - if we disallow those as vars, you can't really justify allowing STOP. This tokenisation lark can really get annoying, and you start to run into the problems that the 128k BASIC editor had to get around.

    Mind you, I find your implementation to be fascinating - SPINlite uses the 48.rom an performs all (de)tokenisation and keyboard support outside the emulation, whereas yours is a tailored ROM. Rather cool - but I suspect that you and I are going after rather different goals...

    D.
  • edited December 2002
    On 2002-12-26 01:44, Dunny wrote:
    The main sticking point was RND, PI etc - if we disallow those as vars, you can't really justify allowing STOP.

    Now I'm not into interpreters coding, but:

    RND, or PI are EXPRESSIONS, and as such using them as "left hand values" might cause ambiguity. On the other hand, STOP is a COMMAND, and there is therefore no ambiguity in allowing it to be a "left hand value" (first argument of an assignment: a variable).

    While this is one way to reason, another is:

    RND, PI or STOP are all reserved keywords, and as such they cannot be the name of a variable. It's a matter of taste.
  • edited December 2002
    On 2002-12-26 03:52, aowen wrote:
    There was a similar thread on CSS
    No discussion of INPUT A though. Can SPIN handle tokens in an INPUT A command? like PI etc.

    No, but it was a similar problem with the "how do we determine what this is - keyword or variable?" sort of thing.
    I'm not sure what your goal is with SPINlite. Are you planning to extend Basic to support the host hardware or is it just meant to run Spectrum Basic programs fast and make it easier to enter them?

    I'm not certain myself - I'm just playing around. I've removed the timings (TSTates per instruction) and just taken the interrupt from the PC's timer, so it'll run BASIC as fast as it can, whilst still maintaining HALT timing and FLASH stuff. PAUSE 1 is now a handy "wait vbl". Rather than modifying the ROM, I'm trapping and tokenising that way, and the keyboard is handled by setting sysvars rather than allowing the emulated speccy to read from #FE.

    So far, it's quite fun - I'm trapping load and save commands to go to the PC's HDD. It's been written primarily so that I have a "toy" language to play with on my 486-50mhz - I don't think it will be anything useful to the speccy community, although loading BASIC from a .sna or .z80 is possible. It wouldn't really make sense to save to those - you'd not get it running properly on a spec.

    When I get a better idea, I'll let you know :)

    D.
  • edited December 2002
    On 2002-12-26 03:52, aowen wrote:
    No discussion of INPUT A though. Can SPIN handle tokens in an INPUT A command? like PI etc.

    Oops, forgot about that - yes, it can. I trap the editor loop, so whenever a line is fetched from memory or the edit loop detects the Enter key, tokenisation and detokenisation occurs. This works perfectly for INPUT a, and with INPUT a$, anything in quotes is left alone, so tokens outside are tokenised. Useful if the user types "Hello"(2 TO 3) etc. I've not tried INPUT LINE a$ - I suspect that everything would be tokenised, whereas it should not be, as the quotes are implied, just not present. :)

    D.

  • edited December 2002
    Perhaps restoring a partial extended mode might be the best choice. That way you can have keys assigned to those unique (math) tokens that could possibly used for INPUT could be in the extended mode key map. You could also have STOP in this list. Since it's extended mode, it's a special thing that must be entered for such circumstances, otherwise typing the token in manually would still be the norm for BASIC code entry. You could also use the new extended mode for macro handling by defining macros to specific keys as well in addition to the defined tokens.

    Besides, coding such as the solution would take up far less source code.

Sign In or Register to comment.