BBC BASIC on Android
Steve Drain (222) 1620 posts |
I have had an interesting email from Richard Russell, who maintains BBC BASIC for Windows (BB4W), the gist of which is below: I wonder if I may seek your advice. As you probably know, I have recently developed an Android version of BBC BASIC and – if I say so myself – I’m rather pleased with it. To support it I’ve written (in BBC BASIC of course) a simple ‘touch-based’ program editor – with the usual features such as syntax colouring, automatic indentation and the ability to jump directly to a FN/PROC – which can be used quite successfully on a small touchscreen. I do not think I can offer direct help, but is there anyone to take up the challenge? I can see some immediate barriers, so my thought would be to help Richard translate his IA-32 assembler version into ARM assembler, but there might be a more straightforward way. Richard does look in on the forums, so he will see comments here, and he might welcome contact by email. |
David Boddie (1934) 222 posts |
Wouldn’t he have to produce different versions of the BASIC64 binary for different ARM architecture revisions? It sounds like it would be possible to work with ARM BASIC, though it depends on whether it relies on fancy assembler tricks to save space or run faster that might get in the way of just replacing SWIs with branches. I don’t do much ARM assembly these days. Perhaps it would be easier to start with Brandy or just port another existing interpreter to C. Maybe there’s even a reimplementation of BBC BASIC in Java already available. |
Richard Russell (1920) 95 posts |
Unless an Android application (i.e. a .apk file) contains multiple different ARM binaries – and as far as I know it doesn’t – I can only assume that the architecture is standardised for Android. Even if not, if an app coded in C can cope, I don’t see why there would be a fundamental problem with an app partly coded in assembler.
I’ve considered Brandy, but it’s so architecturally different from either BB4W or BASIC64 it could be difficult to interface with. And of course there’s no assembler, and to me BBC BASIC without an assembler isn’t really BBC BASIC! I’ve certainly never come across a Java implementation of BBC BASIC. |
Rick Murray (539) 13396 posts |
I am not an app coder so I reserve the right to be wrong – however… it is my understanding that an apk file contains a sort of bytecode version of the program (think Java) that is (partially? entirely?) translated to native code by the phone as part of the installation process. Early implementations used “Dalvik”, more recently something better though as I’m not an app coder I don’t know the specifics. This seemingly convoluted process means that a “one app fits all” approach can be used.
You can write in C or C++ using the NDK, however please note:
The Android NDK help says: Using native code on Android generally does not result in a noticeable performance improvement, but it always increases your app complexity. In general, you should only use the NDK if it is essential to your app — never because you simply prefer to program in C/C++.
There isn’t, a fair few video players use C/assembler for the decoding that isn’t directly supported by the hardware (for example 10 bit H.264 or HEVC (if I remembered the acronym correctly). However it requires either all the architecture binaries to be included in the apk (VLC) or a generic binary in the apk with downloadable platform specific additions (MXPlayer). If you want to bring BBC BASIC to Android, your best bet is probably going to be to implement it in Java and forget about supporting an assembler. You’ll be too tied up dealing with the numerous differences between a phone/tablet and a desktop computer. |
Jeffrey Lee (213) 6046 posts |
You can have libraries for multiple architectures, and even libraries for completely different CPUs, within the same APK. This page covers all the supported ABIs and where the shared objects should be placed in the APK for the automatic selection to work: https://developer.android.com/ndk/guides/abis.html If you only want to support some ABIs that’s fine, although I’m not sure off the top of my head exactly how that works (I think it might be an automatic part of the build process, or maybe you need to manually specify the supported architectures in the app manifest). |
Richard Russell (1920) 95 posts |
I think you may have misread Steve’s original post. I have already created an Android version of BBC BASIC, so there is no need to explain the process to me! Indeed the whole point is that having already got a working Android app (albeit only for Intel CPUs) the great majority of the work that would be needed to create an ARM version is done.
Again you’re ignoring what I have already achieved. I don’t “want” to bring BBC BASIC to Android, I already have! It would be crazy to ‘start from scratch’ and attempt to re-implement it in Java (even if I knew how to program in Java, which I don’t). I expect there are a few people reading this who already have a suitable Android device (i.e. one with an Intel CPU, such as a Tesco Hudl2 tablet or an Asus Zenfone smartphone) and if so they can download and run BBC BASIC now: |
Richard Russell (1920) 95 posts |
That seems to suggest that an app containing just an armeabi binary will run on any ARM Android device, in which case the issue of creating multiple binaries for different architectures does not arise. Needless to say my current Android app contains only an x86 (IA-32) binary. |
Richard Russell (1920) 95 posts |
Here’s a video of an early version of BBC BASIC for Android (before it gained an IDE) running on a Tesco Hudl2, just in case anybody thinks this product is a figment of my imagination! |
Rick Murray (539) 13396 posts |
Okay, my mistake – I thought you were starting from scratch. That said, if it had been written in java (assembler aside) there’d be no problem with what it is running on. :-P I wish you luck with this. A nice BASIC interpreter will be much more useful to the world than a load of crappy games with multudinous in-app purchases… |
David Boddie (1934) 222 posts |
Looking at the source code for ARM BASIC I don’t think this will be the short cut you’re looking for. Perhaps some prolific programmer can convert the SWI calls into C library calls but it looks like a lot of work. I know you dismissed Brandy, but have you seen J.G. Harston’s fork of Brandy called Banana? Is that any better to use? I’m intrigued by your BASIC interpreter. Is it written in x86 assembly language? Did you have to do anything special to assemble and run inline assembly language code on Android? |
Richard Russell (1920) 95 posts |
Could you outline why you believe it to be “a lot of work”? With my limited knowledge it seemed that SWI calls which pass up to four (32-bit) parameters and receive back at most one 32-bit result ought to be easily (almost trivially) convertible to subroutine calls. SWIs that pass five or more parameters and/or receive more than one result would be more work, because of having to spill the excess parameters and results to the stack, but not hugely challenging. So am I missing something in the above analysis?
I know nothing about it, but I’ve had no success contacting Jonathan recently so I would rather not use anything of his if he isn’t around to help. In any case as I’ve said before the assembler is for me an essential part of BBC BASIC.
All my BBC BASIC interpreters have been written entirely in assembly language, yes. Indeed you can trace the roots of the IA-32 version back to my original (1982) Z80 version, via the 16-bit MS-DOS version. Each has been developed from its predecessor with the minimum amount of effort, helped by the processors sharing a common Intel heritage. |
David Boddie (1934) 222 posts |
I only meant that there seem to be a lot of SWI calls. In theory it would merely be a case of auditing which ones are used and figuring out if anything special is needed to handle them. A quick skim through the files reveals about 90 different SWIs in use. Some of those appear to be using assembly time arithmetic operations to specify the SWI (e.g., OS_WriteI+"[" and OS_WriteI+29), but I imagine those are trivial to deal with. I’m not really familiar with the syntax used. Some system calls might need a bit of work to handle – you would effectively be writing a small RISC OS compatibility layer just for BASIC. I’m thinking, for example, of the MessageTrans and ResourceFS calls. Perhaps you can just write functions that do nothing but return suitable values in the cases where the calls don’t make sense outside of a RISC OS environment. Other calls like the Sound, OS and ColourTrans ones will have more obvious mappings to existing functions. Jonathan posted to the stardot forums on Wednesday. I don’t know if he’s very busy at the moment. |
Richard Russell (1920) 95 posts |
Indeed, and 90 different SWIs is rather a lot! It’s a shame that ARM BASIC is so intertwined with the OS; it’s almost as if Sophie didn’t anticipate there ever being ARM-based OSes other than RISC OS, a rather poor prediction as it turns out! My versions of BBC BASIC have retained the original simple OS interfaces of the 6502 version (OSRDCH, OSWRCH, OSBYTE, OSWORD, OSCLI etc.) because they have always been targeted to multiple platforms. This has helped make porting to x86 Android (and Linux and Mac OS) relatively straightforward: I did it in about two months late last year. The two processor families for which assembler implementations of BBC BASIC exist – ARM and x86 – happen to be those that run 99.9% of all computers. I’ve done my bit to port it to all the common x86-based platforms but there seems to have been little effort put into getting ARM BASIC running on anything other than RISC OS. This is something that I think needs addressing. This year marks the 35th anniversary of BBC BASIC (and the 15th anniversary of BBC BASIC for Windows) and I can’t think of a better celebration than porting it to ARM Android and ARM Linux. I don’t underestimate the effort that would be required, and it may well be that it is beyond what I could hope to achieve on my own. That’s precisely why I contacted Steve, who then posted here. I would still very much like to hear from somebody who would be prepared to collaborate with me on this project. |
David Boddie (1934) 222 posts |
If you like, I can send you a summary of what I’ve found. I can also ask on the stardot forums to see if there’s anyone who fancies a challenge. I think the first step would be to get the BASIC code running on ARM Linux, just because there’s less of an overhead in terms of developing and deploying software for that kind of system. Intriguingly, I don’t think BASIC was made available for RISC iX, though it would be interesting to hear otherwise. |
Richard Russell (1920) 95 posts |
That would be extremely kind of you, thanks. Based on what you’ve said about the number of SWIs I now think it would be more sensible to write the ‘RISC OS emulation layer’ in ARM assembler rather than in C. Being forced to comply with the C ABI – which for example limits the number of parameters passed in registers to four – just adds unnecessary complication. Writing it in assembler ought to mean that a simple substitution of each SWI with a BL would be possible. Those functions that are fairly self-contained, i.e. that don’t ultimately need to communicate with the native OS, could consist solely of assembler code. Those that end up performing genuine input-output would need to call into my C code, but none of my interfaces exceed what can be passed in registers. Of course I wouldn’t be able to write that assembler layer myself, since it would need a competent ARM programmer with a good understanding of RISC OS. So finding somebody to help becomes even more important.
What I haven’t clarified is that, in fact, my Android, Linux and (future) Mac OS versions all share the same code base because they are using SDL 2.0 as an ‘OS abstraction layer’. So any work on porting ARM BASIC would automatically contribute to a Linux version as well as an Android version. In practice, because I do currently have an ARM Linux device – a Raspberry Pi – but not any ARM Android devices, I would almost certainly be intending to do initial testing on that platform. But an Android version could follow almost immediately, it’s just a case of running the right build. |
David Boddie (1934) 222 posts |
Yes, I saw that in your APK file. Anyway, I’ll send you a mail as I promised. |