Want to port BASIC to Uniflex

Software
1

Looking for C code bases to start from. I know of TinyBASIC, any others ?

Be nice to add some keywords to support graphics too.

2

I ported an older version of Brandy Basic (v1.0.13) a few years ago back when it was still easy to port to run in text-only mode. I think it may be less portable now it has a lot more graphics support added, but that may not be a problem for you since you want graphics anyway. It’s a clone of BBC Basic, implemented in C. RISC OS Software
There is also this project: GitHub - rtrussell/BBCSDL: BBC BASIC for SDL 2.0: for Windows, Linux (86), MacOS, Raspberry Pi, Android and iOS.
There are lots of Basics in C to be found if you look: Repository search results ¡ GitHub

1 Like
3

I was just looking into BBCSDL - there’s a console mode build. I suspect it’s not very small though, and for Uniflex I suppose we’re looking at 64k address space? (The amusing thing about BBCSDL sources is that they started life as the x86 implementation, so the C variables have names like eax.)

There’s a 6809 port of BBC Basic - not in C of course - it’s mostly translated from the 6502. You’d need to adjust all OS calls, but those should be quite separable and probably not too much work.

Most amusingly, a recent competition entry implements a Basic in Basic - just possibly that 10 lines of source could be demangled and converted to C.

I found a list of free Basic interpreters - you’d want something open source and relatively portable, so it might not suit.

I see in this article a mention of Small Basic which has a console mode.

I found yabasic which is portable and open source, but is it small?

And finally I found bas which is unixy and open source and meant for nuttx, which is for small embedded systems.

4

Reading above, I haven’t thought thru what I want! Doh.

I guess I want:

  • variables,
  • string manipulation
  • input
  • loops
  • gosub
  • ability to load/save

Uniflex is running on 68000 and uses virtual memory - so I do want it small, but memory is prob not the issue.

Its probably simpler to just write it from scratch…

5

In case, you were building from scratch, I seriously recommend the caching scheme of the Grundy NewBrain’s BASIC, which I’m fascinated of, since I learned about it.

In brief, there’s the problem of two opposing goals: faithful listings of the original input on the one hand and performance on the other hand. The former requires repeated interpretation of the source text, e.g., for any literal constants, contributing much to the slowness of BASIC, while the latter may convert and tokenize all input early (as early as on input) for once, but will lose the original meaning as conveyed by the source text. (Is it “1000” or “+1E3”?)

What the Grundy BASIC does, is preserving the source text as-is, but, once a line is encountered, its interpreted version is cached (e.g., on a kind of heap) and a link to the cached version is attached to the source line for further use. Should the system run short on memory, parts of the cache can be purged easily, with no further penalty than the need to reinterpret and cache a line yet again. (A visit counter for the cached lines may help in deciding which cached lines to purge. Even a single 1-bit “seen again” flag may be of help.)
I think, this is a very elegant solution to this problem, especially, if there are no tight memory constraints.

4 Likes
6

If you’re writing your own, you should read P. J. Brown’s “Writing interactive compilers and interpreters” first. (If you look around hard you may find a pdf of that on the net somewhere. I have a paper copy though.)

1 Like
7

It looks like nuttx have appropriated Michael Haardt’s Bas - BASIC interpreter. Uniflex may not have an up-to-date C compiler for it, though. bas is the BASIC interpreter I use most.

There’s a chance that the Bywater BASIC Interpreter (bwBASIC) is more portable. It’s been around for a long time. One set of features I didn’t know it had was the ability to set language dialect compatibility using OPTION VERSION. Dartmouth, PDP-11, System/370 and MBASIC are among the options. This might also be of interest to @MauryMarkowitz …

1 Like
8

Some ~15 years back I wrote my own Basic. It runs under Linux and uses SDL (SDL 1.3 not SDL 2), or on a bare metal Pi v1. I doubt it would port easily to Uniflex - although maybe, but there are many others out there that might be easier.

However - given the above - I decided to tokenise everything. It’s a sort of one-pass compiler with the program ‘executable’ being built in a separate part of RAM to the program text which is then thrown away. It’s a sort of virtual machine at that point - so as variables and constants are encountered at tokenisation time a “symbol” is created for them and the text in the program line is replaced by a token that says “this is entry N in the symbol table”.

It works a charm - run-time speed is good as we’re not parsing numbers, etc. and long variable names have no impact, etc.

It was a PITA for LIST though. As above, is it 1000 or +1E3… Although it was fine when I tested it until I started doing some things with floating point where the number in the program text could not be represented exactly by printing the value in the symbol table. Since I had plenty of RAM I expanded the symbol table entry to include the fragment of program text.

And I thought I was being clever - looks like there is still nothing new…

A lot of these issues sort of went away when I added in a screen editor and made line numbers optional - the system was fast enough on a Pi v1 to be barely noticeable when a program was loaded from the editor into the run-time system.

-Gordon

2 Likes
9

And now I do too! (Not entirely sure why)

1 Like
10

I grabbed a copy too :grin:

1 Like
11

Sorry, just saw this thread.

Adam, the machine in question seems quite hefty compared to the machines BASIC originally ran on, so I suspect my version will work fine. It’s 100% C, flex and bison with no external dependancies other than stdlib. So if you have access to those for the platform you should be good to go.

You can get the source in zip from the Releases area on the right side of this page:

1 Like
12

Another contender - Elk with homebrew 68000 second processor - stardot.org.uk I ported this version of BASIC to my hardware fairly painlessly. It was written in 68000 assembly, so not quite what you asked for but it is fast!

1 Like
13

Oof, might be a bit of a battle - if nothing else just i/o calls.

However, been distracted from this by trying to finish up gcc floating point support port…