VAL ("BIN") in 128 BASIC

[SabreWulf]

Example:
10 LET b$="10101010"
20 PRINT VAL ("BIN "+ b$)

In 48 basic, BIN is entered as a keyword. I can't see a way for 128 basic to recognise BIN within quotes as anything other than "B" + "I" + "N". The result in 128 basic is the equivalent of typing 'B', 'I', 'N' in 48 basic: variable not found; rather than evaluating BIN b$.

Unsurprisingly, typing the line in 128 basic and transferring that listing to 48 basic retains the 'B' 'I' 'N' as three separate characters - rather than BIN being tokenised. Writing it in 48 basic and loading it into 128 basic allows it to work correctly, line 20 appears on the 128 as:

20 PRINT VAL (" BIN " + b$)

The only visible difference is a space before BIN.

Is there a way of entering line 20 in 128 basic and it working as intended? The single character entry doesn't parse it as a keyword within quote marks.

An alternative that can be typed in 128 basic is:

20 PRINT VAL (CHR$ 196 + b$)

CHR$ 196 is the BIN keyword.

Is there any way to input BIN inside quotes in 128 basic?

[TMD2003]

The only way I can think of to do that would be to manually POKE it in, i.e. start with:

20 PRINT VAL ("*"+b$)

...then search through the memory, starting at the first byte of BASIC - the system variable PROG holds that, so PEEK 23635 and 23636 (it's a two-byte value) to find it. You're looking for the sequence 245,176,40,34,42...

This throwaway program line will do the business:

9999 LET q=PEEK 23635+256*PEEK 23636: FOR n=q TO 256+q: PRINT n,PEEK n: NEXT n

Note down the address where the 42 is contained (that's the *), and POKE that address with 196.

I tried your original program with the * modification above, found the * at address 23782, and the POKE worked. The BIN token appeared in the listing, and the program ran and gave the value 170 as you'd expect the result from the VAL to be. So, this is a very roundabout way of doing it, but it works.

Now that I think of it, a second method (which may be quicker!) is to write the line in 48 BASIC, save it to tape, and then MERGE it into the 128 BASIC listing. But where's the fun in that? Meddling directly with the program in memory and gaining knowledge of the system variables is much more satisfying. And now that I also think of it, poking the program directly is the only way to get 128 BASIC to display its unused error "p", which will cause a crash unless it's on an Investrónica 128+ (which will display the correct code "p PARAMETRO MAL", in Spanish as you'd expect, and in capitals, as are all the Investrónica 128+'s reports):

1 REM "1","2","3","4","5","6","7","8","9"

The REM must be manually poked to PLAY this way, as the editor won't accept the line if there are more than eight strings involved, and nine are needed to trigger error "p".

[Pobulous]

The only way I can think of to do that would be to manually POKE it in, i.e. start with:

20 PRINT VAL ("*"+b$)

...then search through the memory, starting at the first byte of BASIC - the system variable PROG holds that, so PEEK 23635 and 23636 (it's a two-byte value) to find it. You're looking for the sequence 245,176,40,34,42...

This throwaway program line will do the business:

9999 LET q=PEEK 23635+256*PEEK 23636: FOR n=q TO 256+q: PRINT n,PEEK n: NEXT n

Note down the address where the 42 is contained (that's the *), and POKE that address with 196.

I tried your original program with the * modification above, found the * at address 23782, and the POKE worked. The BIN token appeared in the listing, and the program ran and gave the value 170 as you'd expect the result from the VAL to be. So, this is a very roundabout way of doing it, but it works.

What happens if you stick the cursor on the line after doing this and hit Enter? Does it turn it back into B I N?

[TMD2003]

What happens if you stick the cursor on the line after doing this and hit Enter? Does it turn it back into B I N?

The line needs to be edited in some way to have any effect - say, delete the space between VAL and the bracket.

There's no change on screen, but I can confirm that it does change the token back into five characters (space, B, I, N, space). VAL ignores the space and tried to interpret BIN as a variable, and stops with 2 Variable not found.

[AndyC]

There used to be a sneaky technique for temporarily switching back to the 48K editor, though I've forgotten what it was. Or you could use CHR$() instead but that probably undoes whatever speed increase this was probably trying to accomplish.

[SabreWulf]

@TMD2003 thanks for the effort. I know how to search the BASIC in memory but I was hoping that there was a simple way to convince the 128 parser that the keyword within the quotes was intended as a keyword - and to do that with the same, or a similar level of ease as entering it in 48 BASIC.

@AndyC I included the CHR$() alternative. It wasn't a speed increase, I just wanted to use something that I'd use in 48 BASIC whilst entering BASIC with the 128 editor and the VAL "BIN... was a useful example.

Would it be safe to say that this is a limitation of the 128 BASIC parser and end it there?

[PeterJ]

@SabreWulf,

Just to let you know that if you type the @ symbol then start typing the username you should see a drop down. Select the username and they will then get a notification.

Best wishes

Peter

[SabreWulf]

@PeterJ thank you.