BBC BASIC for SDL 2.0 version 1.08a released

[hellomike]

[quote]In your position I'd worry about the BIOS update failing though; what actually happens?[/quote]

Don't worry Richard. I really don't care as the laptop isn't really used. Just wondered if it would upgrade to Win10.
It did but for the rest I only use it sometimes to install or test software that I don't want to pollute my desktop machine.

Regards,

Mike

[RichardRussell]

This is happening to me on my windows machine 1 out of 3 times, on average.

I've no idea whether this might help, since I don't understand what the cause is, but (assuming you're launching BBCSDL from a desktop shortcut) try changing the 'target' of the shortcut so that it explicitly runs bbcsdl.bbc rather than doing so implicitly. So after the change your shortcut's properties should look something like this:

shortcut.png

[Leo]

I usually run BBCSDL on a Win 7 machine and it shows none of the problems being discussed here.

However, I have very recently obtained a new Win 10 laptop and on that I can see the 'clicking' problems and the non-starting IDE.
I agree that the click issue seems to be related to click press/release speed.
I think I'm a relatively slow clicker and if I speed up all seems well.

RE: the IDE startup issues - I run BBCSDL.exe by direct click, I've had a poke about and I note the following...

1. I see the 'console' window instead of IDE in about 1 in 6 starts but only if I have selected 'Don't ask me' about which IDE to use.
When I select IDE every time, it never fails (for me).

2. It doesn't matter which IDE is selected - the console appears instead of SDLIDE and BBCEDIT.

3. By using PRINT commands in the spurious console window, I see...
@usr$ = "c:\users\Leo\Appdata\Roaming\BBCBASIC\"
@lib$ = "c:\Program Files (x86)\BBC BASIC SDL\lib\"
@dir$ = "c:\Program Files (x86)\BBC BASIC SDL\"

I find @dir$ surprising - I would have expected "../examples/tools/" on the end.

Unfortunately I have no explanations for any of this yet.

[svein]

>try changing the 'target' of the shortcut so that it explicitly runs bbcsdl.bbc rather than doing so implicitly<

I tried this and a lot of other ways to try to figure out what the problem is.
Including programs like 'process explorer' and using 'event viewer' and such.
Via google i found some posts about 'file not found' in other languages, but it did not seem relevant.

You will not be happy by this, but i gave up and removed bbcsdl from my windows machine.
BB4W works perfect in windows and BBCSDL works perfect in linux.
I'm happy with this.

Svein

[RichardRussell]

I think I'm a relatively slow clicker and if I speed up all seems well.

In the next release I will be increasing the 'time window' for a click from 150 ms to about 500 ms so that should be long enough for even the slowest clicker!

Code: Select all

    @dir$ = "c:\Program Files (x86)\BBC BASIC SDL\"

I find @dir$ surprising - I would have expected "../examples/tools/" on the end.

It's not really surprising. The behaviour exhibited is (as far as I can ascertain) exactly the same as if the bbcsdl.bbc file was missing - you can try renaming it to see the effect. In that case @dir$ will inevitably be initialised to the directory containing bbcsdl.exe itself: that's the only place it knows anything about. Only when the Choose IDE selector is run does examples/tools come into play.

Can you please try the suggestion I made of specifying bbcsdl.bbc explicitly in the target of your shortcut (or indeed simply typing bbcsdl bbcsdl.bbc at a command prompt, which amounts to the same thing). By explicitly specifying the program to be run you are bypassing the section of code which is most likely to be responsible for the intermittent behaviour in Windows.

[RichardRussell]

You will not be happy by this, but i gave up and removed bbcsdl from my windows machine.

That's your prerogative. It does reduce the likelihood of the cause ever being found, because I am reliant on the support of those few people who experience the problem often enough to do some testing. There are other tests that I would have asked you to do had you not abandoned it.

The 'fault' happens so infrequently here that it's barely even an inconvenience, but if you feel that it makes the Windows edition of BBCSDL unusable I will discontinue it. The Windows edition has always been the 'odd one out' (not being based on Linux like the others) and compatibility does suffer somewhat as a result.

[Leo]

I tested the "bbcsdl bbcsdl.bbc
After 36 repeats there were no failures.
Thereafter, I tried without the specific param and it failed on the second attempt.

I became interested in the bit of code that changes @dir$ (since I got an unexpected @dir$ value) but haven't done anything with it yet.
Is there anything I could try for you?

[RichardRussell]

I tested the "bbcsdl bbcsdl.bbc
After 36 repeats there were no failures.

That's interesting, not least because Svein found that it made no difference (I think he changed the shortcut properties rather than issuing the command, but they should be equivalent). I can't explain that.

If you don't specify it on the command line, BBCSDL looks for a .bbc file with the same name as the .exe (so bbcsdl.exe looks for bbcsdl.bbc). This is a common mechanism used by run-time engines (Liberty BASIC works the same way for example) because it means you can make an 'executable' version of a BASIC program just by renaming the run-time-engine.

The code which does that is as follows:

Code: Select all

	if ((argc == 1) || (*argv[1] == '-'))
	{
		char *q ;
		strcpy (szAutoRun, SDL_GetBasePath()) ;
		p = strrchr (argv[0], '/') ;
		if (p == NULL) p = strrchr (argv[0], '\\') ;
		if (p)
			strcat (szAutoRun, p + 1) ;
		else
			strcat (szAutoRun, argv[0]) ;
		q = strrchr (szAutoRun, '.') ;
		if (q > p) *q = '\0' ;
		strcat (szAutoRun, ".bbc") ;
	}

What this does (or is supposed to do) is to concatenate the string returned by SDL_GetBasePath() with the name of the executable (which is in argv[0] as is standard for C), and then to change the extension to .bbc. Assuming this is what is failing, despite it apparently working perfectly in Linux and MacOS, then either SDL_GetBasePath or argv[0] must be returning something unexpected (unless that is there's a bug in my code which I can't see).

Is there anything I could try for you?

If you can get it to fail, you could try typing this into the immediate-mode window that's displayed:

Code: Select all

SYS "SDL_GetBasePath" TO p%
PRINT $$p%

That should tell us whether that component is correct, at least. There's no way, that I know of, of discovering what argv[0] contains without me modifying the code.

Of course all this might be be a red-herring, and the fact that it didn't fail for you in 36 attempts just luck. That's what Svein's result would suggest.

[KenDown]

I presume that the "fail" which is being discussed is what has just happened to me. I double-clicked on bbcsdl.exe and a window opened with a copyright message but nothing else. I entered the SYS command you specified and PRINT $$p% gave
C:\Program Files (x86)\BBC SDL\

I closed that window, double-clicked on bbcscl.exe again and this time up came the box offering the choice of BBCEdit or SDLIDE.

[Leo]

After 5 successful startups I got the command window and the SYS and PRINT gave fundamentally the same as Ken, ie :
C:\Program Files (x86)\BBC BASIC SDL\