NextBASIC features vs Sinclair BASIC compatibility

This is where most of us started. Classic Spectrum basic.

Moderator: Programming Moderators

User avatar
programandala.net
Posts: 45
Joined: Thu Nov 02, 2017 11:55 am
Location: Spain
Contact:

NextBASIC features vs Sinclair BASIC compatibility

Postby programandala.net » Fri May 22, 2020 2:10 pm

The more I try NextBASIC, the more a realise all of the hard work put on it.

The result is impressive, given the required compatibility with the akwkard, slow, uncomfortable, unusual and limited Sinclair BASIC. Certainly the compatibility prevented NextBASIC from going much further.

I wonder if, in theory, it had been easier to write a new BASIC, say similar to ZX Spectrum's Beta BASIC or even SAM Coupé's MasterBASIC, sacrificing the backwards compatibility.

Happily the machine and the operating system are mostly open, well documented, and much more powerful than the original models, making enhancements easier.
Marcos Cruz (programandala.net)

User avatar
varmfskii
Posts: 287
Joined: Fri Jun 23, 2017 1:13 pm
Location: Stone Mountain, GA USA

Re: NextBASIC features vs Sinclair BASIC compatibility

Postby varmfskii » Fri May 22, 2020 2:56 pm

To be fair, when compared to BASIC dialects of similar vintage, Sinclair BASIC was slow, and unusual, but I wouldn't use the term limited. If you want limited look at things like Microsoft BASIC on the C64.
Backer #2741 - TS2068, Byte, ZX Evolution

User avatar
programandala.net
Posts: 45
Joined: Thu Nov 02, 2017 11:55 am
Location: Spain
Contact:

Re: NextBASIC features vs Sinclair BASIC compatibility

Postby programandala.net » Sat May 23, 2020 1:46 pm

varmfskii wrote:
Fri May 22, 2020 2:56 pm
I wouldn't use the term limited. If you want limited look at things like Microsoft BASIC on the C64.
You are right, maybe "limited" is not accurate. But as you say, it depends on what you compare it with. Of course, there were BASIC dialects even more limited.

As for Sinclair BASIC I meant things like lack of control structures; no error trapping; one-character string, function and loop variables; fixed-length string arrays; no integers... But on the other hand it has good features, e.g. graphics.

Beside, its line editor and its keyword input method were a real pain, though that was solved in the 128K models. I always owned a 48K and I still wonder how I was able to write so many long BASIC programs under such conditions :)
Marcos Cruz (programandala.net)

User avatar
varmfskii
Posts: 287
Joined: Fri Jun 23, 2017 1:13 pm
Location: Stone Mountain, GA USA

Re: NextBASIC features vs Sinclair BASIC compatibility

Postby varmfskii » Sat May 23, 2020 9:49 pm

All true, of course those were very common limitations in contemporary 8-bit BASIC dialects. Control structures beyond FOR and GOTO (GOSUB) were almost unheard of, as was error trapping. Variable names were generally limited to two characters, so one for strings is more limited. Most had better string handling. Some had integers and some not (some were integer only). Overall, I personally would consider it a bit more powerful than average for the time.
Backer #2741 - TS2068, Byte, ZX Evolution

User avatar
programandala.net
Posts: 45
Joined: Thu Nov 02, 2017 11:55 am
Location: Spain
Contact:

Re: NextBASIC features vs Sinclair BASIC compatibility

Postby programandala.net » Tue May 26, 2020 10:27 am

varmfskii wrote:
Sat May 23, 2020 9:49 pm
those were very common limitations in contemporary 8-bit BASIC dialects. Control structures beyond FOR and GOTO (GOSUB) were almost unheard of, as was error trapping.
Yes, but see some examples:
  • TI Extended BASIC (1981) has `else`, `on break`, `on error`, `on gosub`, `on goto`, `on warning`, procedures and sprites.
  • Sord M5 BASIC-I (1982) has `else`.
  • BBC BASIC (1982) has procedures, `else`, `repeat until` and an inline assembler.
  • ORIC-1 BASIC (1983) has `repeat until`, `on goto` and `on gosub`.
  • MSX BASIC 1.0 (1983) has `on gosub`, `on goto`, `else`, error trapping, sprites and interrupts.
  • Amstrad CPC 464 Locomotive BASIC (1984) has `while wend` and interrupts (`after`, `every`).
Of course, those dialects lacked other features, but at least `on gosub`, `on goto` and `else` were not so uncommon, and I always wondered why they were not included in Sinclair BASIC.
varmfskii wrote:
Sat May 23, 2020 9:49 pm
Variable names were generally limited to two characters
Yes. I used also MSX-1 and MSX-2 BASIC in the 1980's, and that limitation was annoying.
Marcos Cruz (programandala.net)

User avatar
varmfskii
Posts: 287
Joined: Fri Jun 23, 2017 1:13 pm
Location: Stone Mountain, GA USA

Re: NextBASIC features vs Sinclair BASIC compatibility

Postby varmfskii » Tue May 26, 2020 12:02 pm

Most BASICs didn't allow expressions for the destination, only a literal constant. In Sinclair BASIC you can use goto or gosub expression to replace on expression goto/gosub. At worst you waste an array that you index into. Of course this causes problems when you renumber your program.
Backer #2741 - TS2068, Byte, ZX Evolution

User avatar
programandala.net
Posts: 45
Joined: Thu Nov 02, 2017 11:55 am
Location: Spain
Contact:

Re: NextBASIC features vs Sinclair BASIC compatibility

Postby programandala.net » Tue May 26, 2020 1:44 pm

varmfskii wrote:
Tue May 26, 2020 12:02 pm
In Sinclair BASIC you can use goto or gosub expression to replace on expression goto/gosub.
Good point, that was very useful to replace `ON GOTO` and `ON GOSUB`, provided you don't need to renumber a lot...

There's a similar great feature of Sinclar BASIC: expressions are allowed in `DATA`. I missed that in several modern BASIC interpreters.
Marcos Cruz (programandala.net)

Z80Man
Posts: 21
Joined: Wed Jul 08, 2020 5:53 am

Re: NextBASIC features vs Sinclair BASIC compatibility

Postby Z80Man » Fri Jul 10, 2020 10:12 am

What was limited was mostly the editor, especially on the 48K (but you could rely on machine code add-on tools to rename lines, for example).

Sinclair Basic by itself was rather quite powerful. VAL$ allowed to run the interpreter to evaluate any expression, for instance, somtething you don't find everywhere (you'd have to think about dBase III and Clipper at the time to be able to do this).

The maths functions were efficient (and could be called directly from machine code) and could do real floating point operations (what some other BASIC couldn't manage), though the lack of integer type numbers could adversely make them fell slow since all numeric were floating type, but we had our tricks to manipulate booleans faster, and the graphic functions were blazing fast, thanks to ultra efficient algorithms by Ian Logan. And you could add your own functions and commands by triggering remapping the hook codes managing syntax errors.

The real problems were bugs. They were everywhere : in the functions (FN), GOSUB (problems with the stack and corrupted registers when interrupted), and the maths functions were tricky to use from machine code because of bugs.

I think many corrected ROMs can be found hee and there, but you had to plan on a mean to switch with the original ROM as some games were using its contents and would crash if the ROM was different than expected.


Who is online

Users browsing this forum: No registered users and 3 guests