The Problems

The current state of software engineer is poor. Even now, I see so- called "experts" hacking kludges without care or attention. So think how bad it was 30 years ago! At least BASIC doesn't generally give you enough rope to hang yourself. But there are still annoyances I found. For example:

 

Implicit GOTO

 

For some reason, people think that:
IF X THEN 1000
reads better than
IF X THEN GOTO 1000
Ignoring the fact that GOTO is deemed evil, I had to write an explicit check for people using this shortened form. It's valid BASIC, for sure, but not on all platforms. (The Sinclair machines, most notably.) Which meant that anyone using it failed in their cross-platform amibtions.

 

Multi-statement Code (part 1)

 

The ZX81 was, allegedly, supported in BasiCode 2. Well, the functional spec for the library certainly allowed it. But only a very small number of published programs would work on the ZX81 because of excessive use of:
LET A=0 : LET B=0
I think the ZX81 was the machine produce to not permit multi-statement code, but I stand to be corrected.

 

Multi-statement Code (part 2)

 

If you have a long memory, you will know what this does:
IF X THEN GOSUB 1000 : PRINT "AND THIS?"
but without the implicit knowledge of BASIC interpreters (or its BNF or syntax diagrams), does the PRINT statement belong to the expression to be evaluated after the GOSUB? Or is the IF statement terminated by the colon, and PRINT will be executed all the time?

 

Implicit LET

 

GOTO Implicit GOTO It also failed on non-Sinclair machines, and a few others.

 

Screen Sizes

 

As previously noted, it is possible to detect the screen size. Therefore it is easy to write a method to text wrap your game instructions. It is also easy to ensure your text has no more than 32 characters on a line - the shortest line available on the general machines of the time. So guess who did it? That's right - no one! Most of the surviving software likes to presented a cropped version of its instructions!

 

Wither ye, ZX81

 

Thinking about it, BasiCode also allowed the use of ON ... GOTO and ON .. GOSUB, neither of which were supported.

Along with implicit LET.

 

The READ and DATA statements.

 

And other stuff.

 

I think that the machine had been forgotten, and BasiCode offers nothing more than lip service, as if the designers had only seen a ZX Spectrum, and thought the ZX81 was an equivalent BASIC, just without colour and sound. There's more to language than words; it's grammar and cultural references, too. So, I read all the source I could find to determine the specifics of library. For example, if you set the cursor outside of the screen area, does it clamp to the edge or not? The answer is that it clamps. Which makes it possible to detect the screen size by incrementing the cursor position, and noting when it doesn't change. To understand other elements of the language, I searched for the (Dutch) comments in the source code. Such as this:

 

http://www.opdam.net/frames/funstuf/Frame-MM-Basicode.html

 

You will also note that BasiCode uses a maximum of 2 letter variable names. This doesn't just help with really old machines (although I'm not convinced any were in use at this time) but to stop collision with 3+ letter built-in function names like SIN, COS, and so on. Since the range of functions couldn't be determined ahead of time, the designers must have just decided to limit variables to 2 letters. Just in case.

 

(That doesn't stop the case of AT, though.)

 

Detecting and evaluating nested arrays caused a problem. But I think I will be proved right by replacing (A(B(0)) - using the 2 character variable name limit - to replace the expression with ARRAY_GET(state,a,.*)