Date   
Re: 64 bit MAC software.

Richard Russell
 

On Mon, Feb 26, 2018 at 01:59 am, Paul Marshall wrote:
in my view it is time to create a new product optimised for 64 bit but compatible where possible. Call it say BB64 with a new logo and new filetype to emphasise it is not compatible
Created by whom?   To date I've not managed to interest anybody in taking over BBC BASIC from me, not even to maintain and support the existing versions let alone to develop a completely new one.  Isn't this completely pie in the sky?

Even when 32bit support ceases the machines themselves will be around for a very
> long time and the 32bit and 64bit versions can and should co-exist

The machines may be around, but if they've been updated to the latest version of the OS (and often this happens automatically) they may no longer be able to run 32-bit apps.  For example I have a Mac Mini on which I can currently install and run BBC BASIC but within the next couple of years it will receive an OS update from Apple which will prevent it from doing so.

Only by disconnecting a machine from the internet and quarantining it can you ensure continued ability to install and run 32-bit apps, but who is going to do that these days with the need to update virus databases, patch security holes, etc.?  It may be OK for a museum, but not much else.

I am not a Mac user so for totally selfish reasons I prefer you to focus on windows and SDL

Some slight confusion there I think, the Mac OS version of BBC BASIC is BBCSDL!   I have two current BBC BASIC products: BBC BASIC for Windows which runs on Windows only and BBC BASIC for SDL 2.0 (32 bits) which runs on Windows, Linux (x86), Mac OSX, Android and Raspberry Pi.  I am, from time to time, experimenting with a 64-bit BBC BASIC for SDL 2.0, the Windows edition of which I have already made available for download (although the full compatibility implications are not apparent because Windows preferentially allocates user memory in the bottom 2 Gbytes so 32-bit addresses are still sufficient).

Richard.

Re: 64 bit MAC software.

Richard Russell
 

On Mon, Feb 26, 2018 at 01:59 am, J.G.Harston wrote:
losing features risks killing the usability of 35 years of carefully accumulated libraries of code.
Nobody (I hope) is suggesting "losing" features, but of changes being required to support a 64-bits platform, which introduce incompatibilities.  Here's a more practical example, indeed a change which I have found myself making over and over again in the last couple of days:

      DIM mem% size%
      OSCLI "LOAD " + file$ + " " + STR$~mem% + " +" + STR$~size%

When run on a 64-bit platform this reports 'Number too big' because the address of the memory reserved by DIM cannot be stored in the 32-bit integer mem%, so the first change required is this:

      DIM mem%% size%
      OSCLI "LOAD " + file$ + " " + STR$~mem%% + " +" + STR$~size%

The 'Number too big' error no longer occurs, but now an 'Address out of range' error is reported because STR$~ cannot convert the address to a long enough hexadecimal number.  This requires another change:

      *HEX 64
      DIM mem%% size%

      OSCLI "LOAD " + file$ + " " + STR$~mem%% + " +" + STR$~size%
      *HEX 32


Now the code runs again, and fortunately it's still compatible with 32-bit BASIC (with the extra *HEX 32, anyway).

This is typical of the sort of change that is going to be required, and that requirement is going to be very widespread.

Richard.

Re: Should I bundle Rubik.bbc with the Android edition? #poll

dai_m_leeds
 

Hi Richard,

I looked at the BBCSDL download page,where it says the download is 7.3 MB, and I looked at your comment that it was about 6MB of data (plus presumably the program itself). Obviously if that compresses quite substantially then that changes the calculation a bit!

Best wishes,

D

Re: Should I bundle Rubik.bbc with the Android edition? #poll

Richard Russell
 

On Tue, Feb 27, 2018 at 01:09 am, dai_m_leeds wrote:
I looked at the BBCSDL download page,where it says the download is 7.3 MB,
That page is out of date; you will find that I state in my release announcement that the size is 8.1 Mbytes (as a rule it increases at each new release).

> Obviously if that compresses quite substantially

I stated in the poll question "
there are 6 Mbytes of data tables (less when zipped)" and I'm sure you know that it is not uncommon for Zip to halve the length of a file.  As it turns out that's almost exactly what it achieves in this case.  So the 34% increase should be about right.

Richard.

Re: BBC BASIC for iOS?

Richard Russell
 

On Tue, Dec 19, 2017 at 08:41 am, Richard Russell wrote:
So there are many issues to resolve before an iOS edition could be contemplated, and there may not be solutions for all of them. 
I've 'acquired' a hand-me-down iPhone (5S) from SWMBO, which has prompted me to take an interest in this topic again.  One thing I've definitely established is that iOS does not allow arbitrary code execution (it's not an App Store limitation, iOS itself prevents it) which of course means that neither BBC BASIC's assembler (not that we have one for 64-bit ARM!) nor the CALL statement and USR function, would be usable.  Considering how important the ability to run machine code is to BBC BASIC (for example some of the libraries depend on it, notably SOCKLIB and SORTLIB in BBCSDL) this is problematical.

The issue of SORTLIB is the more easily worked around, because it is of course possible to implement the same functionality in BASIC code.  It would only run at a fraction of the speed, but it might be good enough for some applications.  There is also the possibility, in principle, of adding a native SORT keyword to BBC BASIC (many BASICs do have that capability).

I don't know of any workaround for SOCKLIB however.  SDL_net, unfortunately (and stupidly in my opinion) provides no non-blocking 'read from network' capability, which is frequently a requirement - to be able to get on with other things, or monitor for an abort, while waiting for data to arrive.  I solve that at present by performing the 'blocking' read in another thread, but of course the only way to create a new thread in BBC BASIC is to use assembler code.

So, given all that, what is the consensus of opinion on whether developing an iOS edition of BBCSDL would be worthwhile or not?  I've always argued that BBC BASIC without an assembler isn't truly BBC BASIC, but you can't fight Apple!

Richard.

dlgdemo with keypad

Ian_Wade_G3NRW
 

Richard

I have decided that your Android dlgdemo example program will act as a helpful starting point for some simple apps that I want to write. I wonder if you have incorporated the keypad into dlgdemo, so that it becomes possible to enter text into some of the dldgdemo dialog boxes.

Or is this simple task left as an exercise for the reader?

--
Ian

Re: dlgdemo with keypad

Richard Russell
 

On Wed, Feb 28, 2018 at 06:22 am, Ian_Wade_G3NRW wrote:
Or is this simple task left as an exercise for the reader?
I don't think it is a "simple" task, because it would involve modifying the library (and you definitely don't want to do that, because I'm making changes to that library on an almost daily basis as I try to make things 64-bit compatible - it's an enormous pain)!

As I said before, dialogue boxes are largely foreign to Android; I don't think I've seen a single Android app with what could be described as a conventional dialogue box as part of its UI.  For that reason it would probably have been better if I had omitted dlgdemo.bbc from the Android edition; it's there because it's included with all the 'desktop' editions and I forgot to remove it, for want of a better explanation.

Are you writing a cross-platform app, i.e. one that is intended to run both on Android and on some or all of the desktop platforms?  In that case I could perhaps be persuaded that a dialogue box is a sensible choice.  But if it's an Android-specific app I would have thought something more tailored to a touchscreen interface, and more typical of other Android apps, would be better.

Richard.

Re: BBC BASIC for iOS?

Richard Russell
 

Playing with the iPhone (I realise it's rather like communing with the Devil!) has at least answered one question: what to do about the absence of the Android 'back' button.  Other apps which require that functionality, including Apple's own 'Settings' app, seem to have established a convention of providing a back button in the top-left corner (sometimes bottom-left, such as in Safari) consisting of a simple 'chevron' or less-than symbol.  It shouldn't be difficult for BBC BASIC to overlay a similar button; there will be occasions when it obscures something important but experimentally rotating the device from portrait to landscape usually moves it out of the way.

Richard.

Re: Testers wanted

Richard Russell
 

The deadline has now passed, and disappointingly there have been very few responses from the testers.  Indeed most of the people who requested a beta copy didn't even bother to acknowledge receipt.  I know I shouldn't be surprised, or allow it to upset me, but it always does.  :-(

The small number of reports received have, on the whole, been negative.  It seems that people have had much more difficulty getting the utility to work for them than I hoped.   The users concerned may (or may not!) wish to post their own reasons for not being enthusiastic.

The concept of a tool which would automatically convert a BBC BASIC program to a self-contained Android app seemed initially very exciting, but like so many of my 'grand ideas' it hasn't worked out.  Sorry.

Richard.

Re: Testers wanted

dai_m_leeds
 

Hi Richard,

I know it took a bit of headscratching to work out why I was struggling, but once we'd realised the program needs to sit in a directory path with no spaces, it was pretty straightforward after that. Now that I have my keystore and template working, presumably making more will be striaghtforward.

I am enthusiastic- please don't despair/give up: I think the prize is well worth the hassle..

Best wishes,

D

Re: Testers wanted

Paul Marshall
 

On Wed, Feb 28, 2018 at 03:35 pm, Richard Russell wrote:
Sorry.

Richard, you have nothing to be sorry about. As one of those who has been in communication with you let me state publicly that you've have created a superbly useful tool.
Yes  there were some difficulties, all centred around filenames. If these snags appeared to be negative it wasnt meant too, I regret that one simple error creates a chain of emails!

Now that we know the following it is not an issue any longer:

  • filenames must not start with a dot
  • filenames must not contain spaces
  • filenames are case sensitive

Some problems with  the package name have been resolved. It might put some people off if they think they need to have a website but it doesnt appear to matter what the company name is.

I have turned two programs into Android apps really without any other real problems. Admittedly they were old Acorn programs with nothing particularly clever and no Windows api calls, but it's good experience for the future. And - although you will criticise me for this - I didnt even test my latest program on the Android first. Such is the ease of compiling that I prefer to make changes in Windows SDL compile, install and test on the tablet. Thats because although TouchIDE is useful I am a dyed-in-the-wool Windows user and find it much easier.

I assume the 'string too long' is still an issue but if it works on the majority of devices and only fails on one or two I would beg you not to deny it to the rest of us.

Re: dlgdemo with keypad

Paul Marshall
 

I really like the simplicity of the Android touch interface. To build a Windows program with a nice UI that used menus, dialogue boxes etc was massively complicated even with the library functions. (parachute on, ready to be shot down)  With Android all that is needed is MOUSEX%,Y%,B%  kind of thing, compare where on the screen the user has clicked and you are on your way!

Re: Testers wanted

Richard Russell
 

The facts here are that two of the most experienced and most knowledgeable BBC BASIC users struggled so badly to get my utility working that they were both unable to without extensive help from me.  I can confidently say that most people would find it more difficult, not less, than they did.

I assume the 'string too long' is still an issue

I've left the 'workaround' code in place, so it should no longer affect the operation of the loader program (autorun.bbc) but it could still of course affect the operation of users' own programs if they are also using the $addr kind of 'fixed string'.

> I would beg you not to deny it to the rest of us.

I'll do a deal with you: if - despite the deadline having passed - I receive encouraging feedback from some of the others who offered to test it, but have not yet responded, I will reconsider my decision not to release it.  However given the lack of response and general apathy I do wonder whether the "rest of us" actually amounts to 'nobody'.

Please ensure that you have downloaded the latest version (0.32) which has some changes that should ameliorate a few of the problems encountered.

Richard.

Re: Testers wanted

Richard Russell
 

On Thu, Mar 1, 2018 at 01:48 am, Paul Marshall wrote:
it doesnt appear to matter what the company name is.
Of course it matters!  Did you not read the supplied help file, which I recommended that everybody study before trying to use the utility?  The package name must be 'globally unique'; if you don't have a domain and just 'make up' the name there is every likelihood the somebody else might have chosen the same name.  In that case if an end-user, who had previously installed the 'other' app, installed yours it would wipe out the original!

You can't even argue that you can change the name should such a situation come to light, since once allocated you can never change the package name(because it will break the 'app update' process whereby a newer version automatically replaces the older one).

If you haven't got a domain I strongly recommend that you obtain one; they are very cheap.  But even if you don't, you still have the option of (hopefully) guaranteeing uniqueness by using a 'reversed' email address as the initial part of the package name.

Releasing Android apps to the 'wide world' requires that you adopt a professional approach, just as releasing 'compiled' BB4W executables does.  Since all such EXEs and apps made using BBC2APK contain details that allow them to be traced back to me, it could reflect badly on me if you don't.

Re: Testers wanted

Paul Marshall
 

On Thu, Mar 1, 2018 at 02:05 am, Richard Russell wrote:
The facts here are that two of the most experienced and most knowledgeable BBC BASIC users struggled so badly to get my utility working that they were both unable to without extensive help from me.
Surely the idea of having feedback from testers was to iron out those difficulties so that others do not get stuck. Maybe two is enough.  We now know about filename restrictions - and you did tell us about leading dots, and case sensitivity was a silly error - but wont be an issue in future. A few things you have ameliorated in the latest version so it should be easier for any new adopters..
It is indeed very bad that so few have bothered to try it. So come on guys I dont want to lose this tool just because you cant be bothered!   

Re: Testers wanted

Richard Russell
 

On Thu, Mar 1, 2018 at 04:29 pm, Paul Marshall wrote:
I dont want to lose this tool just because you cant be bothered!   
I don't understand how you can "lose" what you've already got.  It's not as though the version currently available for download is a time-limited trial version, or restricted in some other way; it's fully functional and there's nothing to stop you continuing to use it.

Richard.

Re: BBC BASIC for iOS?

Richard Russell
 

On Tue, Feb 27, 2018 at 04:33 am, Richard Russell wrote:
I don't know of any workaround for SOCKLIB however.
This is proving to be less of a problem than I feared.  I've today experimented with allowing the 'read from network' function to block, and so long as I read relatively small packets - and have a relatively fast internet connection - the effect on the performance of 'banner.bbc' and 'Ceefax.bbc' is not too serious compared with the version of socklib using assembler code.

Richard.

Re: Testers wanted

mclout@...
 

I will be installing and working on this this weekend.  Just did not have time to get to it.  I too think this is a very valuable project and tool for the community. 

Re: dlgdemo with keypad

Ian_Wade_G3NRW
 

Richard

I had a hunch you might say something like this. It's coming home to me that my mindset for writing Android apps is quite inappropriate. Trouble is, I have spent a lot of time over the last 4-5 years getting to know BB4W well, and along the way learning a lot about the Windows API. And enjoying it.

I'm now realising that I need to approach the Android world quite differently, and it's time to go back to basics -- after all, my 11-year old grandson can stand his Android on its head with some very impressive apps! He must get the same kind of buzz that I used to experience when persuading machine code to work on very simple process control systems way back in the 1960s.

--
Ian

On 28/02/2018 14:42, Richard Russell wrote:
As I said before, dialogue boxes are largely foreign to Android; I don't think I've seen a single Android app with what could be described as a conventional dialogue box as part of its UI.  For that reason it would probably have been better if I had omitted dlgdemo.bbc from the Android edition; it's there because it's included with all the 'desktop' editions and I forgot to remove it, for want of a better explanation.
Are you writing a cross-platform app, i.e. one that is intended to run both on Android and on some or all of the desktop platforms?  In that case I could perhaps be persuaded that a dialogue box is a sensible choice.  But if it's an Android-specific app I would have thought something more tailored to a touchscreen interface, and more typical of other Android apps, would be better.
Richard.

Re: Testers wanted

Richard Russell
 

On Thu, Mar 1, 2018 at 04:29 pm, Paul Marshall wrote:
Surely the idea of having feedback from testers was to iron out those difficulties so that others do not get stuck
Of course that's true to a degree, and to be fair I think the problems you had have largely been ameliorated by adding warnings to the program.  But the other person who provided feedback had much more difficulty than you did, even to the extent of not understanding how the Embedded Files feature works (despite it working in an identical fashion to BB4W, and even presenting an identical UI).  I really worry that if somebody so experienced struggled with it, releasing it to the 'wide world' would be unwise.

Perhaps (and of course I'm joking, but it's tempting!!) the program, when first run, should present the user with a multiple-choice questionnaire to assess his level of knowledge.  It could ask questions like 'What does the REM!Fast compiler directive do, and when mustn't you use it?".  That would sort the wheat from the chaff!  :-)

Richard.