Differences between BASIC1/2 and BASIC4 in handling an EVAL?

Discuss all aspects of programming here. From 8-bit through to modern architectures.
alex_farlie
Posts: 35
Joined: Sun Jul 07, 2013 9:46 pm

Differences between BASIC1/2 and BASIC4 in handling an EVAL?

Postby alex_farlie » Thu Sep 28, 2017 4:50 pm

Hi,

I've found a program that works on a BBC B (BASIC 1/2) but not a MASTER (BASIC 4).

It's the Turtle Logo program that came with the Let's Compute Club pack...

On a BBC B you can do the LOAD "KNOT example instruction without issue.

On a MASTER (emulated) it fails with a MISSING FN/Proc error, nominally because there appears to be a spurious character in the string passed to an EVALed FN call....

Was something fixed in BASIC4 which the TurtleLogo program is relying on in BASIC 1/2? Hmm...

Would be interested in tracking this down... albiet it's an annoyance in an ancient program?

(I doubt that it's the emulation that's iffy.)

User avatar
MartinB
Posts: 4514
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity

Re: Differences between BASIC1/2 and BASIC4 in handling an EVAL?

Postby MartinB » Thu Sep 28, 2017 5:14 pm

Can you post a disc image so people can help...?

User avatar
jgharston
Posts: 2663
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield

Re: Differences between BASIC1/2 and BASIC4 in handling an EVAL?

Postby jgharston » Thu Sep 28, 2017 8:04 pm

alex_farlie wrote:I've found a program that works on a BBC B (BASIC 1/2) but not a MASTER (BASIC 4).

The only difference with EVAL is between BASIC I and later. On BASIC I the parameter string is incorrectly tokenised so that pseudovariables are tokenised as commands instead of functions, so, eg, EVAL"TIME" fails.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

alex_farlie
Posts: 35
Joined: Sun Jul 07, 2013 9:46 pm

Re: Differences between BASIC1/2 and BASIC4 in handling an EVAL?

Postby alex_farlie » Thu Sep 28, 2017 8:08 pm

Attached is a parred down disc image containing only the Turtle Logo code from the Let's Compute Tape 1 in the STH/Stardot archive.

The files
Turtle.zip
Zip file containing the Let's Compute Turtle Logo.
(6.65 KiB) Downloaded 6 times
contains the files TURTLE (instructions) , TURTLE2 ( core), KNOT (example LOGO text file)

The file which doesn't appear to work on the BeebEm emulated Master128 is TURTLE2. Try loading the example as indciated in the instructions and an error occurs.. Be nice to finally pin down why.

User avatar
jgharston
Posts: 2663
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield

Re: Differences between BASIC1/2 and BASIC4 in handling an EVAL?

Postby jgharston » Thu Sep 28, 2017 8:22 pm

Has it been typed in correctly? With a BBC I get Mistake at line 310 which is 310DEFPROCj(E%)X

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

alex_farlie
Posts: 35
Joined: Sun Jul 07, 2013 9:46 pm

Re: Differences between BASIC1/2 and BASIC4 in handling an EVAL?

Postby alex_farlie » Thu Sep 28, 2017 9:01 pm

jgharston wrote:Has it been typed in correctly? With a BBC I get Mistake at line 310 which is 310DEFPROCj(E%)X


That should have been directly from the Tape in the archive... The listing for this was not in the Magazine. So... I'm not sure what's gone wrong.

The original is on the tape here - http://www.stairwaytohell.com/bbc/archi ... tsCompute/

I hope this isn't an issue of bad transfer...

I'm attaching a re-transfer DIRECTLY from the tape to disc using *MOVE inside Beeb-em. If it's not an issue of bad transfer then any typos are there in the original.
Attachments
Turtle.zip
Attempt number 2
(6.69 KiB) Downloaded 4 times

User avatar
jgharston
Posts: 2663
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield

Re: Differences between BASIC1/2 and BASIC4 in handling an EVAL?

Postby jgharston » Thu Sep 28, 2017 9:24 pm

It looks likes it's some problem happening with using $ao% as a parameter in various DEFPROCs and DEFFNs. That shouldn't be a problem, and I've tried moving ao% to point elsewhere and still get the same problems.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

alex_farlie
Posts: 35
Joined: Sun Jul 07, 2013 9:46 pm

Re: Differences between BASIC1/2 and BASIC4 in handling an EVAL?

Postby alex_farlie » Thu Sep 28, 2017 9:31 pm

jgharston wrote:It looks likes it's some problem happening with using $ao% as a parameter in various DEFPROCs and DEFFNs. That shouldn't be a problem, and I've tried moving ao% to point elsewhere and still get the same problems.


Hmm... Willing to add taking a look at this in a better analysis tool at a later date? Using pointers is not easy, and getting them right drove me nuts on a college course (and that was in Modula2 which is strongly typed, quite unlike the C=style pointers in BBC BASIC.)

What's suprising is that on a default BBC B with an old DFS it works, on a Master (where page is lower) it doesn't. Hmm..

Are there some key memory locations that are different between the machines and thus something is getting wrongly initialised, or assigned by a pointer?

I hope it's an issue with the original code and not the emulation.... :roll:

TO be honest , I was looking at this, with a view to seeing if it could be ported to BBC Basic for SDL. Probably quicker for someone to write a much better Turtle Logo directly for that though. :(

User avatar
jgharston
Posts: 2663
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield

Re: Differences between BASIC1/2 and BASIC4 in handling an EVAL?

Postby jgharston » Fri Sep 29, 2017 12:52 am

If you just want turtle logo in BASIC, try this:

Code: Select all

1MODE0:VDU28;31,6479;29,640;512;:PLOT69,0,0:REPEATINPUTLINE">"A$:FORX=1TOVALA$:B$=A$:REPEATC=ASCB$AND31:N=VALMID$(B$,2):IFC=3RUNELSEIFC=10ORC=28OSCLIB$:B$="":UNTILFALSEELSEPLOT4*-(C=8),0,0:P=PEOR-(C=16):A=(A-N*(C=18)+N*(C=12))MOD360:D=N*(C=2)-N*(C=6):PLOT1-P,D*SINRADA,D*COSRAD(A+.1):B$=MID$(B$,INSTR(B$+";",";")+1):UNTILB$=""ORC=24:NEXT:UNTILC=24

I'm sure the user instructions are obvious from the code :D :D :D

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

User avatar
Rich Talbot-Watkins
Posts: 1090
Joined: Thu Jan 13, 2005 5:20 pm
Location: Palma, Mallorca

Re: Differences between BASIC1/2 and BASIC4 in handling an EVAL?

Postby Rich Talbot-Watkins » Fri Sep 29, 2017 6:57 am

Seems to me that strange line:

Code: Select all

DEFPROCj(E%)X

is a deliberate way of causing an error, whose ID gets put into E%.

That's very peculiar - there's clearly a difference between how BASIC 2 and BASIC 4 is executing this program. I tried debugging it but it's just impenetrable... In BASIC 4, the "LOAD" keyword is being transformed to "eoA" (instead of simply "eo") by PROCcn. There's just no way I can make sense of what's going on down this stack of calls to PROCs and FNs with obscure names, so I'll have to leave that to someone braver than me. Good find though! Hope someone can solve the mystery.

User avatar
Rich Talbot-Watkins
Posts: 1090
Joined: Thu Jan 13, 2005 5:20 pm
Location: Palma, Mallorca

Re: Differences between BASIC1/2 and BASIC4 in handling an EVAL?

Postby Rich Talbot-Watkins » Fri Sep 29, 2017 7:10 am

Just to add, I doubt it's anything to do with memory usage in the two machines. The main program is being loaded with PAGE at &1400, and doesn't appear to be using any strange memory locations. I'm 100% sure that it's not an emulation issue (jsbeeb passes all the 6502 test programs), so that leaves differences in BASIC itself.

Like JGH, I think it's likely to be due to handling of $ao% as a PROC/FN parameter which has changed subtly between versions. Funnily enough, without fully reading your reply, I also tried changing ao% to point somewhere else (in case BASIC 4 uses page 7 differently) but had the same problems. So can anyone figure it out?

User avatar
jgharston
Posts: 2663
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield

Re: Differences between BASIC1/2 and BASIC4 in handling an EVAL?

Postby jgharston » Fri Sep 29, 2017 1:45 pm

That's the same symptoms I was getting, and the code is so crunched and re-uses re-used re-used memory that it's incredibly hard to follow and track values. I wonder if just bashing in a LEFT$(thing,2) would fix it.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

alex_farlie
Posts: 35
Joined: Sun Jul 07, 2013 9:46 pm

Re: Differences between BASIC1/2 and BASIC4 in handling an EVAL?

Postby alex_farlie » Fri Sep 29, 2017 2:04 pm

Rich Talbot-Watkins wrote:Just to add, I doubt it's anything to do with memory usage in the two machines. The main program is being loaded with PAGE at &1400, and doesn't appear to be using any strange memory locations. I'm 100% sure that it's not an emulation issue (jsbeeb passes all the 6502 test programs), so that leaves differences in BASIC itself.

Like JGH, I think it's likely to be due to handling of $ao% as a PROC/FN parameter which has changed subtly between versions. Funnily enough, without fully reading your reply, I also tried changing ao% to point somewhere else (in case BASIC 4 uses page 7 differently) but had the same problems. So can anyone figure it out?


BTW trying some modfied code in BB4W gave the windows equivalent of a segfault so... pointers must be wrong somewhere

alex_farlie
Posts: 35
Joined: Sun Jul 07, 2013 9:46 pm

Re: Differences between BASIC1/2 and BASIC4 in handling an EVAL?

Postby alex_farlie » Fri Sep 29, 2017 3:00 pm

jgharston wrote:That's the same symptoms I was getting, and the code is so crunched and re-uses re-used re-used memory that it's incredibly hard to follow and track values. I wonder if just bashing in a LEFT$(thing,2) would fix it.


Shame it's not straightforward to de-crunch it.. The M% handling seems to be a detection for a system other than a BBC Micro... Like BASIC V on RISC OS perhaps?

From the look of the initalisation code, $ao% seems to be being used to write indirectly to some kind of lookup-table, for the various functions, (including possible TO definitions later added by a user...). It maybe that somewhere on the MASTER this lookup table is being read ever so slightly differently between systems?... which would explain the spurious character...

I wonder, if this code doesn't work on BASIC V (i.e RISC OS) either... (On Windows it really really wasn't happy.)..

Your comment about sanitising what comes back from looking up stuff seems to be a good hint.

alex_farlie
Posts: 35
Joined: Sun Jul 07, 2013 9:46 pm

Re: Differences between BASIC1/2 and BASIC4 in handling an EVAL?

Postby alex_farlie » Fri Sep 29, 2017 3:13 pm

Rich Talbot-Watkins wrote:Just to add, I doubt it's anything to do with memory usage in the two machines. The main program is being loaded with PAGE at &1400, and doesn't appear to be using any strange memory locations. I'm 100% sure that it's not an emulation issue (jsbeeb passes all the 6502 test programs), so that leaves differences in BASIC itself.

Like JGH, I think it's likely to be due to handling of $ao% as a PROC/FN parameter which has changed subtly between versions. Funnily enough, without fully reading your reply, I also tried changing ao% to point somewhere else (in case BASIC 4 uses page 7 differently) but had the same problems. So can anyone figure it out?


Not entirely sure that having an indirection location as a formal paramter is a good idea generally anyway! On windows it really really wasn't happy.... Maybe I should ask the BB4W developer about this?

User avatar
Rich Talbot-Watkins
Posts: 1090
Joined: Thu Jan 13, 2005 5:20 pm
Location: Palma, Mallorca

Re: Differences between BASIC1/2 and BASIC4 in handling an EVAL?

Postby Rich Talbot-Watkins » Fri Sep 29, 2017 3:33 pm

BBC BASIC happily accepts both word and string indirectors as PROC/FN parameters, as you can see if you try this:

Code: Select all

10DIM A% 255
20$A%="HELLO"
30PROCP("BYE")
40PRINT $A%
50END
60:
70DEF PROCP($A%)
80PRINT $A%
90ENDPROC

>RUN
BYE
HELLO


There's a bug which means that trying to do it with the byte indirector (?A%) will corrupt your program!

Regarding the Windows version, I wonder if the issue is the hardcoded address for one of the string buffers: $&700. There should probably be some changes to make sure that M% gets set the same as for RISC OS if running on Windows.

User avatar
jgharston
Posts: 2663
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield

Re: Differences between BASIC1/2 and BASIC4 in handling an EVAL?

Postby jgharston » Fri Sep 29, 2017 4:09 pm

Rich Talbot-Watkins wrote:Regarding the Windows version, I wonder if the issue is the hardcoded address for one of the string buffers: $&700. There should probably be some changes to make sure that M% gets set the same as for RISC OS if running on Windows.

Yes, the logic in that line is wrong. Instead of saying "if I'm running on two specific large-memory systems then use the large memory else use a small-memory system" it should say "if I'm running on *any* large-memory system then use the large memory else use a small-memory system"

It should be: MODE 4:M%=(HIMEM-LOMEM>some_amount):IF M% ELSE a=HIMEM:HIMEM=TOP+&1400
ie, M%=lots_of_memory_available and not M%=crash_on_90%_of_systems_with_lots_of_memory

This is a general programming point. ****ALWAYS**** test for facilities, ****NOT**** for platforms.

If your program has to have some behavior dependant on the amount of memory available, then TEST FOR THE AMOUNT OF MEMORY AVAILABLE!!!!!!!!!!!!!!!!!!!!!

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

alex_farlie
Posts: 35
Joined: Sun Jul 07, 2013 9:46 pm

Re: Differences between BASIC1/2 and BASIC4 in handling an EVAL?

Postby alex_farlie » Fri Sep 29, 2017 4:13 pm

jgharston wrote:
Rich Talbot-Watkins wrote:Regarding the Windows version, I wonder if the issue is the hardcoded address for one of the string buffers: $&700. There should probably be some changes to make sure that M% gets set the same as for RISC OS if running on Windows.

Yes, the logic in that line is wrong. Instead of saying "if I'm running on two specific large-memory systems then use the large memory else use a small-memory system" it should say "if I'm running on *any* large-memory system then use the large memory else use a small-memory system"

It should be: MODE 4:M%=(HIMEM-LOMEM>some_amount):IF M% ELSE a=HIMEM:HIMEM=TOP+&1400
ie, M%=lots_of_memory_available and not M%=crash_on_90%_of_systems_with_lots_of_memory

This is a general programming point. ****ALWAYS**** test for facilities, ****NOT**** for platforms.

If your program has to have some behavior dependant on the amount of memory available, then TEST FOR THE AMOUNT OF MEMORY AVAILABLE!!!!!!!!!!!!!!!!!!!!!


Still segfaults on Windows... even when the memory check line at the start is changed,I wonder if on BB4W doing the string indrection as a paramater isn't possible.. Seems BB4W has longer strings, and that what's happening is that a termination isn't being found, due to possibly uninitialised memory. hmm...
Last edited by alex_farlie on Fri Sep 29, 2017 6:38 pm, edited 1 time in total.

alex_farlie
Posts: 35
Joined: Sun Jul 07, 2013 9:46 pm

Re: Differences between BASIC1/2 and BASIC4 in handling an EVAL?

Postby alex_farlie » Fri Sep 29, 2017 4:56 pm

Rich Talbot-Watkins wrote:BBC BASIC happily accepts both word and string indirectors as PROC/FN parameters, as you can see if you try this:

Code: Select all

10DIM A% 255
20$A%="HELLO"
30PROCP("BYE")
40PRINT $A%
50END
60:
70DEF PROCP($A%)
80PRINT $A%
90ENDPROC

>RUN
BYE
HELLO


There's a bug which means that trying to do it with the byte indirector (?A%) will corrupt your program!

Regarding the Windows version, I wonder if the issue is the hardcoded address for one of the string buffers: $&700. There should probably be some changes to make sure that M% gets set the same as for RISC OS if running on Windows.


The following segfaults on BB4W 6.11a:

10 DIM A% 255
20 READ A$
30 PROCP(A$)
40 PRINT $A%
50 END
60 :
70 DEF PROCP($A%)
80 PRINT $A%
90 ENDPROC
:
DATA "BYE"

which is essentially the technique used in the Turtle program.. Not a bug, but BB4W definitely NOT liking a 'too-clever' technique. (Sigh).

BASIC 1/2 prints BYE once..

BASIC 4 prints :
BYE
B

so... I hope this helps figure out different behviours

Richard Russell
Posts: 163
Joined: Sun Feb 27, 2011 10:35 am

Re: Differences between BASIC1/2 and BASIC4 in handling an EVAL?

Postby Richard Russell » Fri Sep 29, 2017 5:45 pm

alex_farlie wrote:The following segfaults on BB4W 6.11a

The reason is much simpler than you think! Remember that 'formal parameters' are automatically LOCAL, so the first thing that happens on calling a PROC/FN is that the existing value of each formal parameter is stored on the stack so that it can be restored on exit. Now, in the case of your program, the 'existing' value of $A% is not defined because you have never stored a CR-terminator in the buffer - this is why BB4W is crashing. It is scanning through memory for the CR terminator and not finding it.

The cure is simply to ensure that $A% is properly defined before PROCP is called:

Code: Select all

   10 DIM A% 255
   15 $A% = ""
   20 READ A$
   30 PROCP(A$)
   40 PRINT $A%
   50 END
   60 :
   70 DEF PROCP($A%)
   80 PRINT $A%
   90 ENDPROC
  100 :
  110 DATA "BYE"

The only reason the code isn't crashing in earlier BASICs is that the maximum string length is in any case only 255 characters so it gives up looking for the terminator before it gets past the end of the buffer you have allocated.

BB4W definitely NOT liking a 'too-clever' technique. (Sigh)

Not at all. BB4W is entirely happy to have an indirected string as a formal parameter, so long as that string is defined beforehand so that there is something 'sensible' to store on the stack. I would argue that it's a bug in your code, pure and simple.

Richard.

alex_farlie
Posts: 35
Joined: Sun Jul 07, 2013 9:46 pm

Re: Differences between BASIC1/2 and BASIC4 in handling an EVAL?

Postby alex_farlie » Fri Sep 29, 2017 5:54 pm

Richard Russell wrote:
alex_farlie wrote:The only reason the code isn't crashing in earlier BASICs is that the maximum string length is in any case only 255 characters so it gives up looking for the terminator before it gets past the end of the buffer you have allocated.

BB4W definitely NOT liking a 'too-clever' technique. (Sigh)

Not at all. BB4W is entirely happy to have an indirected string as a formal parameter, so long as that string is defined beforehand so that there is something 'sensible' to store on the stack. I would argue that it's a bug in your code, pure and simple.

Richard.


Thanks for a prompt turnaround. Should have considered that given that storing &OD at PAGE is one of the first thing BASIC's intialistion does .... Sorry.


Return to “programming”

Who is online

Users browsing this forum: No registered users and 1 guest