BBC BASIC
« Search Results »

Welcome Guest. Please Login or Register.
Mar 29th, 2017, 11:02am


Cross-platform BBC BASIC (Win32, Linux x86, Android, Mac OS-X, Raspberry Pi)

Search Results

Total results: 10


 1   Raspberry Pi / Excellent work on the Raspberry Pi 3 BBCSDL !!  on: Yesterday at 12:54am
Started by michael | Post by michael
I just got the Raspberry pi 3 kit with keyboard and mouse and a Raspberry pie touch screen. BBCSDL works and so does my Buttonz tools. I am working on my text tools, as they work but need some modifications.

I will work on tools for controlling vehicle sensors and automated systems and post them here,

I am amazed at the power of this tiny unit. It can play Youtube and functions very much like a regular PC.. Awesome!
 
  Reply Quote Notify of replies

 2   BBC BASIC Language / Re: IF..THEN..ELSE Problem  on: Mar 27th, 2017, 10:17pm
Started by RNBW | Post by RNBW
Hi Richard

No, I just didn't see that I'd missed an ENDIF. Should have because of the alignment.

However, thank you for bringing the semi-colon issue to my notice. If I'd seen that at the time, the examples would have made it obvious to me.

Thanks for the help.

Ray

 
  Reply Quote Notify of replies

 3   BBC BASIC Language / Re: IF..THEN..ELSE Problem  on: Mar 27th, 2017, 9:36pm
Started by RNBW | Post by Richard Russell
on Mar 27th, 2017, 7:24pm, RNBW wrote:
Why do I get "Missing END IF" error at the first END IF in the following code

The unhelpful (but accurate) answer is because the ENDIF is missing! Apart from doing a simple count (there are two multi-line IF statements but only one matching ENDIF statement) it's evident from the indentation that the first ('outer') IF clause is never terminated.

But presumably that's not the answer you wanted since it's stating the obvious, so what is it that you really want to know? Is the question related to the recent Cascaded IF clauses and the semicolon thread?

Richard.

 
  Reply Quote Notify of replies

 4   BBC BASIC Language / IF..THEN..ELSE Problem  on: Mar 27th, 2017, 7:24pm
Started by RNBW | Post by RNBW
Why do I get "Missing END IF" error at the first END IF in the following code:

Code:
      z=0: a=0: c=0: rl=0: rr=0: vk=0
      rl = 10: rr = 15
      a = 10: c = 0
      z = 5

      IF z < a THEN
        vk = rl
      ELSE IF z > a + c THEN
          vk = -rr
        ELSE
          vk = 0
        ENDIF
  
        PRINT vk
 

 
  Reply Quote Notify of replies

 5   Interpreter & Run-Time Engine / Re: Bug alert  on: Mar 26th, 2017, 09:30am
Started by Richard Russell | Post by Richard Russell
on Feb 19th, 2017, 11:12am, Richard Russell wrote:
So please do as much testing of BBCSDL v0.16 as you possibly can. Particularly, test calling procedures (PROC) and functions (FN) in as many ways as you can think of, including passing a User Defined Function as a parameter.

I've not received any feedback, positive or negative, as yet.   I can only hope that this is because lots of people have been doing lots of testing, without any problems being identified, rather than that very few people have done very little testing!

I cannot emphasise too strongly how reliant I am, and hence how dependent the reliability of the next release of BB4W will be, on extensive third-party testing.  The nature of the modifications to workaround this bug/feature means that it is not appropriate for the programmer who made them to do the testing.  He (i.e. I) cannot be sufficiently objective, especially given the huge number of possible ways in which procedures and functions can be called in BBC BASIC.

So when the next version of BB4W is released it will be the diligence of your fellow users that you are relying on when it comes to having confidence in the product.

Richard.
 
  Reply Quote Notify of replies

 6   BBC BASIC Language / Re: Unexpected "No room" error  on: Mar 23rd, 2017, 12:21pm
Started by hellomike | Post by hellomike
Awesome answer. Think I get it now.

So because in theory the 2nd parameter could be something like this (couldn't think of a more simple example):
Code:
      B$="ABC"
      PRINT RIGHT$(B$,FNappend)
      END

      DEF FNappend
      B$+="DEF"
      =1 

Correctly the output is 'C'.
If it wouldn't create the temporary string the wrong output would be 'F'.

And because RIGHT$(<string>) doesn't have the 2nd parameter, there is no need for the temporary string.

Quote:
If that means a 'No room' error that the programmer does not immediately understand that's just how it has to be!

Which also isn't a problem because Richard always gladly explains!

Thanks again.

Mike

 
  Reply Quote Notify of replies

 7   BBC BASIC Language / Re: Unexpected "No room" error  on: Mar 23rd, 2017, 10:27am
Started by hellomike | Post by Richard Russell
on Mar 23rd, 2017, 09:31am, hellomike wrote:
Why would the statement in line 110 need to create a temporary string equal in length to $$Mem% (which indeed wouldn't have the space for)?

You are looking at things as a human would, rather than as the interpreter does! A human looks at these two statements and concludes that they are equivalent, so would be expected to behave identically:

Code:
      PRINT RIGHT$($$Mem%)
      PRINT RIGHT$($$Mem%,1) 

But the human is doing two things that the interpreter doesn't. Firstly he is 'looking ahead': in deciding what to do with the first parameter he considers the second parameter. Secondly he distinguishes between a constant value and an expression: because the second parameter is a constant he concludes that it is not necessary to create a temporary string.

The BBC BASIC interpreter does neither of these things. It parses the RIGHT$() function strictly left-to-right, so before the second parameter is even evaluated it has to decide what to do with the first parameter, and it makes no distinction between the second parameter being a constant and an expression.

So because the second parameter might be an expression rather than a constant, and because that expression might have the side-effect of modifying the first parameter, the interpreter has no choice but to make a temporary copy of the first parameter just in case!

This is one of the differences between a compiled language and an interpreted language. A compiler can 'look ahead': it can make decisions and perform optimisations based on the program as a whole. But an interpreter just plods through the program one element at a time, without knowing what comes next, and therefore must behave 'defensively'.

Only in a tiny minority of programs will evaluating the second parameter of the RIGHT$() function have the side-effect of modifying the first parameter. But it makes no difference how rare that circumstance is, to ensure that the correct result is returned the interpreter must assume it will happen and therefore makes a copy of the first parameter.

This sort of thing is going on all the time in BBC BASIC! For example I sometimes get asked why a simple statement like this can fail with a 'No room' error:

Code:
      array() = 1, 2 

The reason is basically the same as in your example. Before the interpreter even gets around to evaluating the expression to the right of the equals sign it has to assume that the result might be dependent on the original contents of the array. So, just in case, it copies the entire array into free memory, assigns the value of the right-hand-side to that copy, and then transfers the copy back into the original array.

That is quite an overhead, in both time and temporary memory usage, but if it didn't do that this statement would fail and produce the wrong result:

Code:
      array() = 1, array(0) 

Once again the circumstances in which this sort of problem occurs will be extremely rare, but it's not acceptable for BBC BASIC for make a mistake however rare they may be. So it behaves in such a way that the answer will always be correct.

If that means a 'No room' error that the programmer does not immediately understand that's just how it has to be!

Richard.


 
  Reply Quote Notify of replies

 8   BBC BASIC Language / Re: Unexpected "No room" error  on: Mar 23rd, 2017, 09:31am
Started by hellomike | Post by hellomike
Thanks Richard.

However I don't get it. What temporary string is created?
Line 100 doesn't, as it works. Why would the statement in line 110 need to create a temporary string equal in length to $$Mem% (which indeed wouldn't have the space for)?

Thanks

Mike
 
  Reply Quote Notify of replies

 9   BBC BASIC Language / Re: Unexpected "No room" error  on: Mar 22nd, 2017, 4:07pm
Started by hellomike | Post by Richard Russell
on Mar 22nd, 2017, 1:26pm, hellomike wrote:
Is this a know issue or am I doing something wrong?

By default BB4W provides 2 Mbytes of memory for your program, heap and stack (it's configurable). You are using up approximately half of that in the DIM statement, and then you are creating a temporary string of a similar length for use by the RIGHT$() function. That's all your free memory gone!

So the 'No room' error is neither "unexpected" nor an "issue", and you aren't doing anything "wrong" as such. It's simply that the default amount of available memory is insufficient for the program that you have listed.

In such a case I wouldn't spend any time analysing where the memory has gone, I would simply allocate more memory and not worry about it! For example making 10 megabytes available (which is still not a lot by modern standards) the program runs fine:

Code:
      HIMEM = PAGE + 10000000

      Size%=1050000:REM Works with 1040000
      DIM Mem% Size%
      REM Fill block with non-&00 chars
      FOR I%=0 TO Size%-1 STEP 4
        Mem%!I%=&41414141
      NEXT
      Mem%?Size%=0:REM Terminating &00 so I can use $$Mem%

      PRINT Size%, LEN$$Mem%, HIMEM-END-1024*1024
      PRINT RIGHT$($$Mem%)
      PRINT RIGHT$($$Mem%,1):REM Works without this line
      PRINT "Hello"
      END 

Richard.

 
  Reply Quote Notify of replies

 10   BBC BASIC Language / Unexpected "No room" error  on: Mar 22nd, 2017, 1:26pm
Started by hellomike | Post by hellomike
Hi,

Running on BB4W 6.02a, using a string function involving a numeric and less than 1MB free memory,
results in a "No room" error.
See below code which illustrates this.
Code:
   10 Size%=1050000:REM Works with 1040000
   20 DIM Mem% Size%
   30 REM Fill block with non-&00 chars
   40 FOR I%=0 TO Size%-1 STEP 4
   50   Mem%!I%=&41414141
   60 NEXT
   70 Mem%?Size%=0:REM Terminating &00 so I can use $$Mem%
   80 
   90 PRINT Size%, LEN$$Mem%, HIMEM-END-1024*1024
  100 PRINT RIGHT$($$Mem%)
  110 PRINT RIGHT$($$Mem%,1):REM Works without this line
  120 PRINT "Hello"
  130 END 


The output is:
Code:
   1050000   1050000     -1763
A

No room at line 110
>
 

Note that "A" is printed so the function 'RIGHT$($$Mem%)' works.

As far as I tested, the issue happens:
  1. when there is less than 1MB free space
  2. with string functions like LEFT$/RIGHT$/MID$(<string>,<numeric>) are involved

Is this a know issue or am I doing something wrong?
For what I need it for, I have a suitable workaround so it isn't urgent.

Thanks

Mike
 
  Reply Quote Notify of replies


Donate $6.99 for 50,000 Ad-Free Pageviews!


This forum powered for FREE by Conforums ©
Sign up for your own Free Message Board today!
Terms of Service | Privacy Policy | Conforums Support | Parental Controls