Introduction to BBC BASIC

[RichardRussell]

I have released version 1.06a of BBC BASIC for SDL 2.0, the cross-platform programming language for Windows, MacOS, Linux, Raspbian, Android and iOS. The changes in this version are as follows:

1. BASIC Interpreter / Run Time Engine
   
   Added support for antialiased 2D graphics (extending SDL2_gfx).
   
   Increased the maximum number of float parameters that can be passed by SYS from 6 to 8.
   
   Fixed a bug in the PRINT statement whereby a comma didn't unset 'hex' mode (64-bit and ARM editions).
   
   Modified the ARM and x86-64 assemblers so that the 'Jump out of range' error is not reported on the first pass if the destination label has been made LOCAL.
   
   Modified the ARM assembler so that numeric values may be used as aliases for register names (this improves compatibility with Acorn's assembler).
   
   
2. Libraries
   
   Added 'aagfxlib.bbc' to support antialiased 2D graphics. This is functionally very similar to the GDIPLIB library supplied with BBC BASIC for Windows.
   
   
3. Example Programs
   
   Added 'aagfxdem.bbc' (in the examples/graphics folder) to demonstrate antialiased graphics.
   
   Added 'knots.bbc' (in the examples/graphics folder), a Celtic Knot program by David Marples which also makes good use of antialiased graphics.
   
   Added 'BBSterm.bbc' (in the examples/general folder; desktop editions only) which is a terminal program for Bulletin Board Services accessed by 'telnet'.

This new version may be downloaded, for all the supported platforms, from the usual location. The GitHub repository has been updated (used to build the MacOS, Raspbian, iOS and 64-bit Linux editions, currently).

[RichardRussell]

Here's what the supplied example program aagfxdem.bbc produces, on all the supported platforms:

[RichardRussell]

Version 1.07a of BBC BASIC for SDL 2.0 - the cross-platform programming language for Windows, MacOS, Linux, Raspbian, Android and iOS - has been released. The changes in this version are as follows:

1. BASIC Interpreter / Run Time Engine
   
   User-defined characters may be used even if *FONT is active (improving compatibility with BBC BASIC for Windows).
   
   Removed a workaround (for Linux only) which was supposed to fix a bug in SDL2, but didn't (and hopefully SDL will be fixed one day).
   
   Fixed a couple of minor bugs in the antialiased 2D graphics extension.
   
   
2. IDEs and Utilities
   
   Modified the Cross Reference utility to make use of the updated Treeview library.
   
   The speed with which the mouse wheel scrolls SDLIDE's editing pane is controllable by adding e.g. 'wheelspeed=3' to sdlide.ini. If you prefer Mac-style 'backwards' scrolling you can specify a negative value (listboxes are unaffected however).
   
   The Help Topics and Tutorial menu selections in SDLIDE link to BBCSDL-specific pages at the website, allowing customisation if required.
   
   
3. Libraries
   
   Modified 'dlglib.bbc' so listboxes can be scrolled by dragging the list (as well as using the scrollbar).
   
   Svein's Treeview library has been updated to support a vertical scroll bar.
   
   Modified 'aagfxlib.bbc' to support dotted and dashed (straight) lines.
   
   
4. Example Programs
   
   Added 'SkyBaby.bbc' (in the examples/general folder) which is a simple Planetarium program showing positions of stars, planets etc. in the sky. Loosely based on an old BBC Micro program.
   
   Modified 'aagfxdem.bbc' to demonstrate a dot-dashed straight line.
   
   Modified 'lemmings.bbc' and 'tower.bbc' to protect against a potential (but unlikely) sound-effect crash.

This new version may be downloaded, for all the supported platforms, from the usual location. The GitHub repository has been updated (used to build the MacOS, Raspbian, iOS and 64-bit Linux editions, currently).

Please remember that if you use the Android Application Generator you should download a new APK template to ensure that any updates to the run-time engine are incorporated in your own apps.

[RichardRussell]

Some screenshots from the 'planetarium' program featured in the recent release:

skybaby1_small.png (123.45 KiB) Viewed 2171 times

skybaby2_small.png (169.35 KiB) Viewed 2171 times

skybaby3.png (250.4 KiB) Viewed 2171 times

[John_Spikowski]

Pretty slick!

You should check out Heater's new programming challenge. I see a relationship.

[Heater]

John_Spikowski,

That is an interesting thought you have there. It could spice up the challenge with a bit of real world applicability.

Where does one get a catalog of all named or otherwise identified stars and their directions in an easily digestible format?

Astronomy is not my thing but a quick google turns up the Smithsonian Astrophysical Observatory Star Catalog in binary:
http://tdc-www.harvard.edu/catalogs/sao.html

Seems the original human readable ASCII format is not openly available:
ftp://legacy.gsfc.nasa.gov/heasarc/dbas ... ao.tdat.gz

Then there seems to be hundreds of other star catalog...

Where does that BBC BASIC get it's planetarium data from?

[RichardRussell]

Where does that BBC BASIC get it's planetarium data from?

I've included web links in the source code, preceding the blocks of DATA statements at the end of the program. No guarantees that they are the 'best' sources nor that they are the most accurate, just ones that Google found.

As I mentioned, the program is based on an old BBC Micro program of the same name, but I've been able to take advantage of the greatly increased memory and features of later BBC BASICs, like the array dot-product, to improve it.

In particular the rotation of the 'celestial sphere' (a set of 9,000 or so 3D star coordinates) into the correct frame-of-reference for the orientation of the earth, the observer's latitude and longitude, and the telescope's pan and tilt, is achieved with this code:

Code: Select all

        REM Rotate around x-axis by camera/telescope tilt (zero towards horizon):
        rot() = 1, 0, 0, 0, COSRAD(tilt), SINRAD(tilt), 0, -SINRAD(tilt), COSRAD(tilt)

        REM Rotate around z-axis by camera/telescope pan (zero towards North):
        tmp() = COSRAD(pan), -SINRAD(pan), 0, SINRAD(pan), COSRAD(pan), 0, 0, 0, 1
        rot() = rot() . tmp()

        REM Rotete around x-axis by observer's co-latitude:
        tmp() = 1, 0, 0, 0, SINRAD(LAT), COSRAD(LAT), 0, -COSRAD(LAT), SINRAD(LAT)
        rot() = rot() . tmp()

        REM Rotate around z-axis by observer's sidereal time:
        tmp() = COSRAD(LST*15), SINRAD(LST*15), 0, -SINRAD(LST*15), COSRAD(LST*15), 0, 0, 0, 1
        rot() = rot() . tmp()

        REM Apply composite rotation matrix to celestial sphere:
        xyz() = rot() . XYZ()

I venture to suggest that this would be a lot less elegant in most other languages.

[Heater]

Well there is this https://github.com/astronexus/HYG-Database, nice CSV forma but only 100, 000 odd stars in it.

Nah, I want the real stuff The USNO UCAC4 star catalog with 113 millions stars to magnitude 16 !
600 mega bytes just for the equatorial region.
https://www.ap-i.net/skychart/pt/news/ucac4_catalog
http://casdc.china-vo.org/mirror/UCAC/UCAC4/

That is binary gunk though, needs a program to read it: u4conv. The source code to which seems to have disappeared.

edit: Ah but there is example C and Fortran code to pull data out of those binary files here: ftp://cdsarc.u-strasbg.fr/cats/I/322A/UCAC4/access/

[RichardRussell]

Nah, I want the real stuff The USNO UCAC4 star catalog with 113 millions stars to magnitude 16 !

It depends on what you consider the audience for the program to be. Most 'hobby' astronomers aren't going to be interested in that, or have a telescope capable of imaging most of those stars, anyway (to see a magnitude-16 object with the eye would need something like a 18" aperture reflector!).

In any case, if the purpose of the program is to assist with pointing a telescope at the right part of the sky, the stars it needs to have in its database are the bright ones likely to be used as 'guide stars', not necessarily the faint ones that the amateur astronomer wants to study. Most stars are pretty boring anyway!

[Heater]

Yes indeed.

Unless someone is paying, the audience for any program I write is precisely one, me. I'm always flattered and surprised if I find somebody else has actually found a use for it. It has happened on rare occasions.

I know pretty much nothing about astronomy. The last time I looked at anything through an actual astronomical telescope was 1977 when I joined a friend of mine at the university astronomy society's observatory one night. A kind of rotating wooden shed out the back of campus. I recall being fascinated by the jerry rigged clockwork and wooden mechanism that kept the telescope pointing at the right thing during long exposures as he took pictures. All in all far too cold out to take up as a hobby!

I know enough then to guess why an astronomer might want such a program and database.

Me. I just want a source of interesting random but not random numbers, if you see what I mean.

And now I have the challenge of getting the code that decodes all that UCAC4 binary gunk working.

I might need to pick your brains as to what those fields in there actually mean

[John_Spikowski]

To win the challenge you need to discover where heaven is.

Asking clergy is against the rules.

Anacortes WA is as close as I have been able to get.

[RichardRussell]

Unless someone is paying, the audience for any program I write is precisely one, me.

I can't believe that's true. You surely sometimes write 'informative' programs, e.g. a program designed to illustrate the capabilities of a language or a coding tecnnique, without expecting to be paid? That's what the majority of my programs are: they are example programs, supplied with my various programming language products, which are designed to show what the language is capable of and how it can be achieved. As such the audience is potentially quite large, and making the program attractive and/or functional is important in encouraging the user to take an interest.

[Heater]

RichardRussell,

Well, it does happen from time to time that after spending hours fighting with a problem I have some minimal example working code. Which ends up getting put up on Github. https://github.com/ZiCog?tab=repositories

Mostly for my own convenience. I'm somewhat amazed to find that sometimes people find that, put stars on it and even fork it for themselves. Even more amazed when they offer improvements via pull requests.

It makes me happy that sometimes, somebody, somewhere finds a use for my efforts. But still, none of it happens with an audience in mind. My hobby activities only happen for my amusement.

Unlike you I don't have a major thing going on, like a whole language system. I just tinker with this and that as my fancy takes me.

[Gavinmc42]

I noticed Fuze in the latest Wireframe Mag and thought why is there not a Basic based Baremetal OS solution yet.
Then realised I have not even installed any Basic on any of my Pi's.

Now Fuze is even on Nintendo Switches
Basic has my attention again.

Can you guys bring me up to speed, what works and does not work Basic wise on Pi?
I had a look at Gentoo's list and found Mono-Basic.

Is there a aarch64 version of BBC Basic?
Ok, found the source on github but no instruction on how to make?
Nice GNAT clock screensaver, port to OpenVG on Pi's?

[RichardRussell]

Is there a aarch64 version of BBC Basic?

The iOS edition of BBC BASIC is aarch64 (as mandated by Apple) but with so few RPis running a 64-bits OS I've not bothered to support that configuration.

Ok, found the source on github but no instruction on how to make?

The makefile is in the bin/raspi directory. I had some difficulty working out a project structure to support all the platforms, and although it may not be best practice to put a makefile in 'bin' it's the best solution I could come up with.

Nice GNAT clock screensaver, port to OpenVG on Pi's?

I can't say I'm into vector graphics myself. My background in broadcasting (having worked for BBC R&D for 33 years!) means I'm thoroughly indoctrinated with 2D pixel-based graphics, because that's how TV works!

[scruss]

I noticed Fuze in the latest Wireframe Mag and thought why is there not a Basic based Baremetal OS solution yet.

There are a couple: MMBASIC, and more in the emulation side, BMC64. Both have nothing to do with BBC BASIC, though, so are best kept out of this thread.

[Gavinmc42]

The makefile is in the bin/raspi directory. I had some difficulty working out a project structure to support all the platforms, and although it may not be best practice to put a makefile in 'bin' it's the best solution I could come up with.

cmake/make/qmake is all pretty new to me and while I use C for embedded micro I don't normally use C for Pi's.
But that source looked clean and because it ports to so many machines it could be easy to get running on Gentoo64.

OpenVG will work on VC4, but not the VC6 Pi4's, this limits a GNAT clock 64bit port to Pi3's.
But should be fun to try first in 32bit/VC4 Pi's.

Could BBC basic be made into a baremetal version?
Something to look at on the weekend.
Will read all the back posts to get up to speed.

[Gavinmc42]

I ended up here after looking for a RTOS on VPU.
https://www.raspberrypi.org/forums/view ... ?p=1558169
There was a link to PiTubeDirect which is a Pi emulating a 274MHz 6502 that was running BBC Basic.
274MHz Basic that's faster than the 2MHz I started with.

Just been reading all the older posts here.
It was the Ocean Shader demo that has me hooked.
I am not a Retro guy, I prefer moving forwards and OpenGL and Shaders are the direction I want to go.
At least until Vulkan arrives on Pi's

The language speed is not important if the GPU is doing the graphics,
I have to agree with RichardR there for the sort of non Fibonacci stuff I do.
Accelerated Graphics please.

So does the Ocean Shader demo work on Pi's?

[Gavinmc42]

Seascape.bbc works on Windows, once I figured out BBFW is not BBCSDL
yafl to mess about with OpenGL/shaders with the advantage is no compile time.

Seascape.bbc is OpenGL and OpenGLES, so will work on Pi3 and Pi4?
Time to go home and try.

[RichardRussell]

Could BBC basic be made into a baremetal version?

In principle, certainly. Right from the very start (i.e. on the BBC Micro in 1981) a clear distinction was made, and a well-defined interface established, between the 'language' and the 'operating system'. This was rare in the 8-bit home computer days and contributed to the ease with which BBC BASIC could be ported to other platforms.

Today that distinction can still be seen in the source files comprising BBC BASIC for SDL 2.0: the platform-independent part (the 'language interpreter') consists of the files bbmain.c, bbexec.c and bbeval.c (you can if you like consider the embedded assembler bbasmb_xxx.c as part of the interpreter - traditionally it is - but of course that's CPU-dependent). The platform-dependent part (which basically supports I/O and access to the OS) consists of the files bbcmos.c, bbccli.c and bbcvdu.c (also bbcvtx.c which is the MODE 7 emulator if you need it).

So to create a baremetal version you would be looking to keep bbmain, bbexec and bbeval substantially (if not exactly) the same, but significantly rewriting bbcmos, bbccli and bbcvdu (depending on the similarity between what your low-level drivers support and the higher-level interface provided by the CRT and SDL).

So does the Ocean Shader demo work on Pi's?

Yes, seascape.bbc runs on all the supported platforms (Windows, MacOS, Linux, Android and iOS); it's a bit slow on the RPi compared with the other platforms, but that's hardly surprising given the limited capabilities of the GPU. I've not tried it on an RPi4 but hopefully it's a little better. It does of course rely on the backend being OpenGL (or OpenGLES) which fortunately remains available on all those platforms. If and when support for OpenGL is dropped in favour of Vulkan or Metal the shader demos would need rewriting.

[Gavinmc42]

Seascape is not slow on the Pi4 in Buster 32bit:D
Probably not 60fps but not annoyingly slow.
Alexander Alekseev really knows his shaders and the Pi4 is pretty good too
.

It will probably be faster in Gentoo64 based on my experience with other OpenGL code in Gentoo64.
Will be interesting to make a game with Shader graphics.

Had to remember how to code Basic, too many decades of C comment methods.

Thanks for identifying which parts do what.
Baremetal does need a Basic version, a text one would be nice start.
Graphics is harder without the Linux/mesa libs and very PI specific.

Going to need a way to measure fps to so OpenGL/Shader code can be tweaked for the slower Pi's
I really like the IDEs being "selfhosted", most compiled languages don't have that.

One day with BBC Basic and I'm impressed, got three versions working on two types of computers.
Now for a fourth on Gentoo64?

[Gavinmc42]

Got this warning on main, exec, eval, smb_asm, but every other c file compiled individually on Gentoo64.
Someone who knows what to do should be able to get it going.
I'm no Linux or C expert, if make files work I can follow build instruction.

Code: Select all

gcc -Wall -c "bbmain.c" (in directory: /home/demouser/BBCSDL/src)
In file included from bbmain.c:12:
BBC.h:294:23: warning: call-clobbered register used for global register variable
  294 | register signed char *esi asm ("r10") ; // Program pointer
      |                       ^~~
BBC.h:295:19: warning: call-clobbered register used for global register variable
  295 | register heapptr *esp asm ("r11") ; // Stack pointer
      |                   ^~~
Compilation finished successfully.

[RichardRussell]

Got this warning on main, exec, eval, smb_asm, but every other c file compiled individually on Gentoo64.

That's likely to be due to this code in bbc.h:

Code: Select all

// Register globals:
#ifdef __llvm__
extern signed char *esi ;		// Program pointer
extern heapptr *esp ;			// Stack pointer
#else
#ifdef __i386__
register signed char *esi asm ("esi") ;	// Program pointer
register heapptr *esp asm ("edi") ;	// Stack pointer
#endif
#ifdef __arm__
register signed char *esi asm ("r10") ;	// Program pointer
register heapptr *esp asm ("r11") ;	// Stack pointer
#endif
#ifdef __x86_64__
register signed char *esi asm ("r12") ;	// Program pointer
register heapptr *esp asm ("r13") ;	// Stack pointer
#endif
#ifdef __aarch64__
register signed char *esi asm ("r10") ;	// Program pointer
register heapptr *esp asm ("r11") ;	// Stack pointer
#endif
#endif

The global variables 'esi' and 'esp' (you can see the assembly language origins of the code there!) are assigned to registers r10 and r11 respectively on ARM. From the warning you are getting these aren't suitable registers for that purpose with your system's ABI; try changing them to different registers.

Incidentally 'register variables' of this kind are rarely used these days because the assumption is that the compiler's own register allocation will be able to do just as good a job. However they are documented as being particularly suitable for language interpreters so I use them! If you'd prefer not to, you can enable the code listed for __llvm__ (Clang doesn't support global register variables).

[Gavinmc42]

Thanks Richard, clang compiled those without warning.
Now down to a fabsl fabs warning in bbceval.c
Looks like long double instead of long, but that's for fixing tmr.

[RichardRussell]

Now down to a fabsl fabs warning in bbceval.c
Looks like long double instead of long, but that's for fixing tmr.

I don't think I get any warnings when compiling for iOS (which is Clang/aarch64), at least none that Xcode draws to my attention. The redefining of fabsl to fabs (and others similar) is because the ARM FPU doesn't support 'long double' as meaning the 80-bit (padded to 128-bit) type that the x86 FPU supports.