iOS edition of BBC BASIC announced

[Deleted User 9295]

A brand new iOS edition of BBC BASIC is now available for beta-testing. This is a 64-bit app (as is mandated by Apple) so will run only on devices with a 64-bit CPU. In practice this means those devices that can run iOS 11, i.e. the iPod 6th generation, iPhone 5S or later, iPad Air or later, or iPad mini 2 or later. Earlier iOS devices have only a 32-bit CPU and cannot run the app (nor be upgraded to iOS 11), sorry.

Because of Apple's restrictions on how apps may be distributed, if you would like to try out BBC BASIC you will need to tell me the UDID of your device so I can enable it in the 'Provisioning Profile'. To find the UDID connect your device to iTunes on a Mac or PC (as you would to sync it with iTunes); click on the device's icon, and then click on the Serial Number to reveal the UDID. On Windows, at least, you can copy the UDID to the clipboard by right-clicking.

Send the UDID to me by private email (or PM) and I will reply with instructions for installing BBC BASIC on your device. Functionally it is almost identical to the Android edition and is supplied with the identical set of example programs. The only major difference is that because iOS forbids 'arbitrary code execution' (this is completely outside my control) neither the assembler nor CALL and USR can be used.

Richard.

[Lardo Boffin]

Interesting!

I have found Apple a joy to work with when distributing our app at work...

Are you able to load and save programs? Import / export etc.?

[Deleted User 9295]

Are you able to load and save programs? Import / export etc.?

You can certainly load and save programs or data files from/to internal memory, but I'm not familiar enough with iOS to know how easy it is to access that memory from 'outside'. With Android you can generally connect the device to a PC using a USB lead, and it will simply appear as an external drive. This makes it trivially easy to transfer programs and other files, or even to edit a BBC BASIC program on the PC.

I'd like to think a similar facility is provided by iOS but I've not experimented with that and our shared experience of Apple may not be encouraging! If there is a comparable facility you can discover (for example) the path to BBC BASIC's @usr$ directory (usually a good choice of place to store a user program or data) simply by typing PRINT @usr$ in immediate mode.

Other possible ways of transferring programs would, I presume, be by copying-and-pasting from a website or an email via the clipboard (again I'm ignorant about iOS but presumably it has one?) . BBC BASIC can access the internet directly (try the supplied 'ceefax.bbc' demo for an example) so it could fetch programs that way, although it's not something I've incorporated as a built-in feature.

I've never been an Apple enthusiast so you can probably tell me far more than I can tell you about these things.

Richard.

[1024MAK]

I was of the understanding that any external 'code' (not contained in the app) is unacceptable to Apple. However, it's fine to write programs using the app, then save these as files. It's also acceptable to reload these files. It maybe that these saved files may not be accessible externally.

Mark

[Deleted User 9295]

I was of the understanding that any external 'code' (not contained in the app) is unacceptable to Apple.

That's not so much the issue that is relevant to BBC BASIC. What matters is that you cannot allocate 'executable' memory (technically, if you specify the PROT_EXEC flag to mmap it is ignored) so any attempt to execute code stored in RAM - in BBC BASIC that means the CALL statement or the USR function - results in an immediate and fatal access exception. The app is sandboxed, so no harm should come to the device or other apps, but of course BBC BASIC must be restarted to resume operation.

Richard.

[1024MAK]

By code, I mean any and all code. This may include BASIC commands and functions as a program, but it may be the case that plain text is okay. I am basing my information on the reasons given by a ZX81 emulator author in this thread.

Mark

[Deleted User 9295]

By code, I mean any and all code. This may include BASIC commands and functions as a program

You are apparently talking not about technical restrictions that affect BBC BASIC (such as the inability to execute code in memory that I discussed) but rather administrative rules that determine whether an app may be made available from the iTunes App Store.

As far as the latter are concerned, it is certainly true that Apple imposes quite significant constraints on the ability of 'programming language' apps to download and execute code, but this applies only to apps available from iTunes. Apps like BBC BASIC which are distributed via the 'ad hoc' mechanism are not affected by these constraints at all.

It is entirely possible that BBC BASIC could never be made available for download from the App Store, but that is not a reason not to develop it and make it available via the ad-hoc delivery process. Admittedly I may need to issue periodic updates simply to keep the app 'live' but this is very little effort.

Richard.

[1024MAK]

Ahh, that explains why we were talking at cross purposes...

I was assuming that at some stage you were going to release it as an app on the App Store.

Please do carry on and sorry for the distraction

Mark

[Deleted User 9295]

I was assuming that at some stage you were going to release it as an app on the App Store.

No more so than it being my intention to release the Android edition on the Google Play store! If it was easy then of course doing so would be a no-brainer, but knowing just how determined both Google and Apple are to ensure that App Store downloads are 'safe', a general-purpose programming language that gives access to OS API functions, allows memory peeks and pokes, and connects to the internet is never going to qualify!

It's a pity that iOS's ad-hoc distribution mechanism is so much more restrictive than Android's. With the latter the responsibility is placed firmly where it belongs, with the end user; it's his decision whether or not to trust the supplier and the software. Apple, as always, adopt a Big Brother 'we know best' attitude and will only allow ad-hoc downloads to individually-registered devices, and even then the app only lasts for a limited time.

But it seems to me that the potential value of having BBC BASIC on a mobile device is too great not to support it, especially given that - being based on SDL - it was relatively straightforward to achieve. In the case of Android I have developed a software tool which creates a self-contained Android app (APK file) from a BBC BASIC program, and there's no reason to think that an app developed that way could not meet the App Store requirements.

If, and at this stage it's an unknown quantity, a similar tool could be created for making a self-contained iOS app from a BBC BASIC program (it would surely have to run on a Mac, sadly) together they would provide one of the easiest ways of creating your own mobile apps, which could even be sold if good enough. BBC BASIC programmers everywhere should be excited by that prospect!

Richard.

[Lardo Boffin]

It is certainly possible to create frameworks that allow the creation of iOS apps for the app store - we use one at work. We basically develop using their tools (a Visual Studio extension) and create an app via their server - using a ‘build in the cloud’ option.
How many hoops thay have to jump through however I don’t know.

[Lardo Boffin]

Are you able to load and save programs? Import / export etc.?

If there is a comparable facility you can discover (for example) the path to BBC BASIC's @usr$ directory (usually a good choice of place to store a user program or data) simply by typing PRINT @usr$ in immediate mode.


Richard.

Installed and running and thought I would see where it placed files:-

I have not tried it from my Mac yet but pretty sure it is not accessible. From memory you can basically only see the images folder.

I have tried a few of the sample programs / games and they work well. Some very smooth animation and games. Buggy works very well with the accelerometer.

[Lardo Boffin]

Just wrote

10 print “hello”
20 goto 10

in notepad, copied it and pasted it into a new code file:-

You can copy / paste but I suspect there may be some tokenising confusion?

Edit:-

Just tried a program from one of the tutorials and it works fine:-

FOR Count%=-10 TO 10
PRINT Count%
NEXT Count%

[Lardo Boffin]

This code pastes as

and runs as:-

[Deleted User 9295]

You can copy / paste but I suspect there may be some tokenising confusion?

You can't (successfully) paste a tokenised program, any more than you can in Windows! Transferring BASIC code via the clipboard assumes that it is in plain text format (or at least UTF-8).

Edit: Looking more carefully, the issue is that your 'quotation marks' (") around "Hello world" aren't the regular ASCII character 0x22 but a pair of non-identical Unicode characters (probably U+201C 'Left Double Quotation Mark' and U+201D 'Right Double Quotation Mark'). When pasted into BBC BASIC the UTF-8 codes for those characters were interpreted as tokens. It may be that you typed the program into a 'smart editor' which automatically replaced the quotation marks with more 'typographically correct' symbols, but that's not helpful for BASIC code!

Richard.

[Deleted User 9295]

I have not tried it from my Mac yet but pretty sure it is not accessible. From memory you can basically only see the images folder.

Some research suggests that I need to enable 'file sharing' in my BBC BASIC app before its files can be seen by iTunes (or a file manager app like iMazing). I'll experiment with that and report back.

Richard.

[Deleted User 9295]

I need to enable 'file sharing' in my BBC BASIC app

Right, getting there! I've now enabled file sharing in my app, and I can see the Documents folder both from BBC BASIC and from outside via a USB link (in my case using iMazing). This is allowing me to copy programs in and out, but it's a bit inconvenient because to navigate to the Documents folder from BBC BASIC I have to tap on @usr$ then .. four times (tap to the right of the back button).

What would make more sense is if, having now enabled file sharing, I reconfigure BBC BASIC so that @usr$ points directly to the Documents folder; this would greatly reduce the hassle factor. I just need to work out how to do that. But at least there is now a way to transfer files from a Mac or PC into or out of a shared directory that BBC BASIC can see.

Richard.

[richardtoohey]

If, and at this stage it's an unknown quantity, a similar tool could be created for making a self-contained iOS app from a BBC BASIC program (it would surely have to run on a Mac, sadly) together they would provide one of the easiest ways of creating your own mobile apps, which could even be sold if good enough. BBC BASIC programmers everywhere should be excited by that prospect!

Definitely!

I've briefly tried TechBASIC before but it's not the same!

http://www.byteworks.us/Byte_Works/techBASIC.html

It seems to have gone a bit quiet.

[jonb]

I wonder if you could implement LOAD / SAVE to play a program as an audio file to the earphone, then read it back via the microphone? You might be able to store these as audio files in the iTunes folder.

You can create apps on an iOS device using Codea, as their "Cargo Bot" game demonstrates. (Codea is a Lua based IDE that runs on the device, no Mac needed.) In other words, if Codea can do it, why can't BBC BASIC?

[Deleted User 9295]

if Codea can do it, why can't BBC BASIC?

According to what I can find at their website, Codea can't create an app on the iOS device, it can only prototype it. The final app is built in Xcode on a Mac in the normal way.

I don't think it would be too difficult to do the same for BBC BASIC, but it would mean that you need a Mac and an Apple Developer Account and the necessary Certificate(s) and Provisioning Profile(s), just as you do when creating an iOS app conventionally. That's not as convenient as my BBC2APK tool, which anybody can run on a PC and convert their BBC BASIC program to a self-contained Android app in five minutes!

But I think it's highly likely that nothing similar is possible for iOS, because it's too tied down by Apple. So if the Mac-based route to creating an iOS app from a BBC BASIC program would be of interest (and setting yourself up as a developer isn't that difficult really, so long as you don't mind paying Apple $99 annually) I can investigate it.

[Pablos544]

I like this line from the App Store Codea entry
https://itunes.apple.com/gb/app/codea/id439571171?mt=8

"features..
Generate retro-game sound effects...."
sounds like we need to immediately rush out the door and buy one

[Deleted User 9295]

reconfigure BBC BASIC so that @usr$ points directly to the Documents folder

OK, I've made that change. I've used a slightly risky approach to locating the Documents folder but hopefully it will be OK. Now, @usr$ is the 'shared' folder, so you can easily copy files into or out of BBC BASIC using iTunes or a file manager like iMazing. Indeed I believe iTunes will automatically backup any programs you store in @usr$.

To update to this latest version simply re-visit the original download link. I've not changed the displayed version number (0.20i) but the build number has increased.

[Lardo Boffin]

Took me a while to figure out how but got there!

I took a wrong turn by creating a sub folder (lardo) in the usr folder - it won’t let me interact with files in the folder. Leaving files in the root of the usr folder works fine. I can drag and drop files (e.g. boffin.bbc) between my PC and phone seamlessly!

Now, how do I import and run a program I have written in BBC BASIC (using BeebEm as my beebs are in storage)...

[Deleted User 9295]

how do I import and run a program I have written in BBC BASIC using BeebEm

Is this program in Acorn tokenised format? If so you'll need to convert it to a .bbc file, most easily by loading and re-saving in BB4W (the trial version is fine for this). There's not enough demand for importing Acorn-format files these days to bother supporting them in BBCSDL.

Bear in mind that the iOS edition of BBC BASIC is not a BBC Micro emulator; it may be wise to try your program in a desktop edition of BBCSDL (e.g. Windows or Mac OS) first just to check that it's compatible.

Richard.

[richardtoohey]

I don't think it would be too difficult to do the same for BBC BASIC, but it would mean that you need a Mac and an Apple Developer Account and the necessary Certificate(s) and Provisioning Profile(s), just as you do when creating an iOS app conventionally. That's not as convenient as my BBC2APK tool, which anybody can run on a PC and convert their BBC BASIC program to a self-contained Android app in five minutes!

I like Apple stuff, but yes, sometimes they are

So if the Mac-based route to creating an iOS app from a BBC BASIC program would be of interest (and setting yourself up as a developer isn't that difficult really, so long as you don't mind paying Apple $99 annually) I can investigate it.

Definitely interested, and would like to have a play with BBC BASIC on iOS to see what I can do. I set up an Apple account to play with Swift but didn't get much further than "Hello World". But can't promise I'll do anything remotely useful or profitable, just definitely interested.

[Deleted User 9295]

Now, how do I import and run a program I have written in BBC BASIC (using BeebEm)

Something else to consider are the implications of BBC BASIC for iOS being '64-bit'. For example a simple program like this will work perfectly:

Code: Select all

   10 DIM p 4
   20 !p = 123456
   30 PRINT !p

but if you use p% instead of p:

Code: Select all

   10 DIM p% 4
   20 !p% = 123456
   30 PRINT !p%

it will fail with a 'Number too big at line 10' error. This is because the memory allocated by DIM resides at a 64-bit address that won't fit in the 32-bit variable p%. It's 'obvious', but with all versions of BBC BASIC having previously used 32-bit addresses, at most, the issue hasn't arisen until now.

Richard.

[crj]

Woah!

What precision are the floating-point numbers? Is there any evidence that they'll span the address space at byte resolution? And doesn't that make a mockery of attempts to write portable code?

I can see three alternatives, any of which feel preferable to using floating point numbers to hold addresses:

• Confine iOS BBC BASIC to 4Gbytes and consistently apply an offset to addresses if necessary.
• Make integers be 64-bit on iOS BBC BASIC
• Tag every %-value as either a 32-bit integer or an address. Propagate the tag through arithmetic operations according to rules similar to those for address arithmetic in C, only dynamically instead of statically.[/code]

[Deleted User 9295]

What precision are the floating-point numbers?

Limited by the ARM CPU to 64-bit 'doubles'; on x86 versions it's 80-bits ('long double').

And doesn't that make a mockery of attempts to write portable code?

'Portable' code is not an issue: anything that will run in a 64-bit environment should run in a 32-bit environment! But not the reverse.

Confine iOS BBC BASIC to 4Gbytes and consistently apply an offset to addresses if necessary.

You could do that if there was no SYS statement, but of course a crucial feature of BBC BASIC is its ability to interface with the OS, which means it must deal in true 'machine addresses' not 'virtual addresses'.

Make integers be 64-bit on iOS BBC BASIC

That would impact far more severely on compatibility.

Tag every %-value as either a 32-bit integer or an address. Propagate the tag through arithmetic operations according to rules similar to those for address arithmetic in C, only dynamically instead of statically.

Drifting off into realms of fantasy there! Let's just ditch 37 years of history and experience, and rewrite the language so that variables work ike they do in C....

When a 64-bit version was first mooted, some months ago, all these options (well, not the last one!) were discussed at length at the discussion group. Adapting a 32-bit language to work in a 64-bit environment is always painful, but I'm confident that the solution we adopted is the one with the fewest compatibility implications.

At present it's only the iOS edition which has to be 64-bits, but the other platforms are going the same way. Android will be 64-bits only within 18 months or so, Mac OS within a year or so. Linux still supports 32-bit apps, but only by the user choosing to install 'multiarch' and many people don't like to do that. So this is something that we have to tackle if BBC BASIC is to have a future.

Richard.

[Deleted User 9295]

Is there any evidence that they'll span the address space at byte resolution?

I didn't specifically address this question in my earlier reply, but I think it's well known that BBC BASIC (unlike some other BASICs) has always had the property that floating-point numbers have at least as much precision as integers. So in the early versions (6502 up to and including the MS-DOS version) integers were 32-bits and floats were 40-bits (32-bit mantissa plus 8-bit exponent). In recent editions (BBC BASIC for Windows and BBC BASIC for SDL 2.0) integers are internally 64-bits and floats are 80-bits (64-bit mantissa plus 16-bit exponent). So you can guarantee that an 'integer' can be stored in a 'float' with no loss of precision.

You may well ask: what about the ARM editions that have only 64-bit floats, not 80-bits? Fortunately it makes no difference, because it's the C compiler that automatically substitutes 64-bit arithmetic operations for the 80-bit ones; the amount of memory allocated remains the same so a 64-bit integer can still be represented precisely even though the mantissa is only 52-bits. This is one of the benefits of 'my' versions of BBC BASIC (right back to the Z80 version of 1983 vintage or thereabouts) using variants, not floats.

It wouldn't actually matter anyway, because currently a '64-bit' CPU has in practice no more than a 48-bit-or-so addressing capability so even the 52-bit mantissa is sufficient. But with variants being able to contain a true 64-bit integer it's belt-and-braces safe.

Richard.

[crj]

Tag every %-value as either a 32-bit integer or an address. Propagate the tag through arithmetic operations according to rules similar to those for address arithmetic in C, only dynamically instead of statically.

Drifting off into realms of fantasy there! Let's just ditch 37 years of history and experience, and rewrite the language so that variables work ike they do in C

That's not remotely fantasy. Language runtime implementation is not one of my more major CV items, but I have spent a few years doing it, one way or another.

The trick is to make %-values be 65-bit, the 65th bit denoting whether they're a 32-bit integer (I-values) or a 64-bit address (A-values). Then, when numbers (integer or floating-point) and addresses are composed:

• Numeric literals are N
• DIM and various OS-specific language extensions return A
• N+N => N; N+A => A; A+N => A; A+A => Error
• N-N => N; A-A => N; A-N => A; N-A => Error
• N*N => N; A*_ => Error; _*A => Error
• ...and so on.

When a value is N, it is dynamically integer or floating point according to the current rules of BBC BASIC.

That behaves 100% compatibly in every circumstance except those in which a 64-bit address has been acquired and then used in an integer context. In those circumstances, expressions behave semantically correctly on a dynamic basis. There is only a problem if someone writes bizarre code like:

Code: Select all

DIM M% 100
A% = 2-M%

This is strictly a subset of the ways in which the current 64-bit implementation can break when fed code intended for a 32-bit implementation. And when it does break, it gives an error rather than incorrect computation.

As you say, addresses on current 64-bit platforms do not actually use all 64 bits in address. This scheme can work within 64-bit values provided even 1 bit is spare in addresses - and that can be any 1 bit, not just a high-order bit.

Indeed, it can actually work provided 4Mbytes of (aligned) address space are free anywhere. You can use even one "impossible" signature value for the top 32 bits of addresses to denote integers.

If there isn't inherently such an address, with a 64-bit address you can afford to make one: just mmap 4Gbytes of /dev/zero .

(If even that can't be done, I know some even more devious tricks...)

[Deleted User 9295]

That's not remotely fantasy. Language runtime implementation is not one of my more major CV items, but I have spent a few years doing it, one way or another.

The "fantasy" to which I was referring was that anybody would have the time, inclination and knowledge to re-write (then test and debug) the BBC BASIC interpreter with the variables and arithmetic handled in such a different way. Nobody is going to do that (unless you're offering to do it yourself!).

That behaves 100% compatibly in every circumstance except...

It can't behave "100% compatibly" because you still need to allocate more than 4 bytes of memory to hold your 'integer' variable. That's going to break some assumptions, for example that the memory address of B% is always four greater than the memory address of A% (you may argue that programs should not rely on that, but some do). The static integer variables are both a blessing and a curse!

It's important to remember that over the last 37 years or so BBC BASIC has evolved. At every stage in that evolution some degree of incompatibility has been introduced, requiring some programs to be modified in order to continue working. Additionally, the 'Russell' strand of BBC BASIC has never been 100% compatible with the 'Wilson' strand. So there's nothing new or unexpected about incompatibilities being introduced at this latest evolution from 32-bits to 64-bits.

Different people will have different opinions on what degrees of incompatibility are acceptable and what are unacceptable. My judgement is, of course, that the few incompatibilities in the 64-bit iOS edition are acceptable. In the specific case of allocating memory with DIM and then accessing it using indirection, why is anybody doing that in 2018 anyway?

Richard.