Jump to content
integer_basic

BASIC 2? Why not get BASIC 7?

Recommended Posts

18 hours ago, integer_basic said:

Why use BASIC 2?  It's horrible, without any commands for graphics, sound, or the joystick.  Was BASIC 7 more money to license?

Have you checked out the Commander X16 programmer's guide at https://github.com/commanderx16/x16-docs/blob/master/Commander X16 Programmer's Reference Guide.md?  They've added graphics, mouse, and joystick commands to the ahem, basics.

  • Like 1

Share this post


Link to post
Share on other sites
On 2/8/2021 at 9:15 PM, Sean said:

Have you checked out the Commander X16 programmer's guide at https://github.com/commanderx16/x16-docs/blob/master/Commander X16 Programmer's Reference Guide.md?  They've added graphics, mouse, and joystick commands to the ahem, basics.

It's still dreadful. The problem is not so much the shortage of the sort of command added, though that is relatively simple. The problems are the failings integrated into the structure (that carry through to BASIC 10) ; almost no program structures , no long identifier names, no local variables. These require significant reengineering to work at all, and are likely to be unstable.

Share this post


Link to post
Share on other sites

A little bit off-topic: the only Basic I actually liked was GFA-Basic which I used pretty often back on the Amiga.  To be honest, that was the third and last Basic I ever used (C64 Basic V2 -> AmigaBasic -> GFABasic).   I don't think I will ever use Basic on C64 and CommanderX16 but instead revert to assembly straight away (either directly or via cross compiling another programming language)

  • Like 1

Share this post


Link to post
Share on other sites
6 hours ago, paulscottrobson said:

It's still dreadful. The problem is not so much the shortage of the sort of command added, though that is relatively simple. The problems are the failings integrated into the structure (that carry through to BASIC 10) ; almost no program structures , no long identifier names, no local variables. These require significant reengineering to work at all, and are likely to be unstable.

If I had to use BASIC, something more along the lines of QBasic would definitely be preferable, if less retro.  Longer identifier names, structured instead of line numbers, and the TYPE statement to allow some degree of abstraction, all make trying to write something complex much easier and more maintainable.  I will likely stick to C or assembly for anything I write for the X16.  But I was specifically addressing integer_basic's points regarding graphics and joystick.

  • Like 1

Share this post


Link to post
Share on other sites
2 hours ago, Sean said:

If I had to use BASIC, something more along the lines of QBasic would definitely be preferable, if less retro. 

1. The X16 was founded on some objectives based on "good retro".

2. BASIC 7 and BASIC 10 are still "bad retro", like loading files from 5.25" diskettes on a 1541.  That is not what attracts me to the platform.  It gets old, very fast.

  • What a quaint old-skool feeling.  I'm back in 1985. 
  • How nostalgic!  NOW PLEASE GET ME OUT OF HERE.

I've come around to Paul's thinking. 

I'd like some sort of 16K S-BASIC interpreter.  Not transpiled.

I know, I know "You want it, you write it.  No one is stopping you."

 

Well sure.  I can try.  I'm a high-level programmer that knows C.  I can at least write a big fat binary and then think about how to optimize it.  Please wish me luck, because I'm going to need it.

 

Edited by rje
  • Like 2

Share this post


Link to post
Share on other sites
2 hours ago, Sean said:

If I had to use BASIC, something more along the lines of QBasic would definitely be preferable, if less retro.  Longer identifier names, structured instead of line numbers, and the TYPE statement to allow some degree of abstraction, all make trying to write something complex much easier and more maintainable.

That pretty much what the Color Maximite is doing, but that of course requires a lot more horsepower, and then BASIC becomes the main way of developing for it and the system itself becomes a black box that just speaks BASIC. And that's great, if that's what you want.

2 hours ago, Sean said:

I will likely stick to C or assembly for anything I write for the X16. 

Yep, and that's great too, and really gets down to the reason that the X16 exists. To have something simple enough that it is relatively easy to work at that level. That is the "dream" after all.

  • Like 5

Share this post


Link to post
Share on other sites

I used the BASIC that came with the C64 and C128 back in the day and while they can be used for various things, they quickly fall short and I abandoned them for Forth and assembly.

With the X16 I will not even bother to try the BASIC, I will go to C and assembly instead. I wish it could boot into Forth and I could choose to play in that environment, or just load (C or assembly) software, then I would be very happy.

Another alternative would be Scheme, I am not sure how feasible that is? My little 8-bit Lisp machine.. 😉

  • Like 1

Share this post


Link to post
Share on other sites
1 hour ago, hth313 said:

With the X16 I will not even bother to try the BASIC, I will go to C and assembly instead. I wish it could boot into Forth and I could choose to play in that environment, or just load (C or assembly) software, then I would be very happy.

What would be the obstacle to booting into Forth?

Share this post


Link to post
Share on other sites
9 minutes ago, BruceMcF said:

What would be the obstacle to booting into Forth?

I don't think there's any plan on including it in ROM or having it be a configurable boot option -- or having configurable boot options at all. Most likely, it will have to be started from the BASIC prompt by loading it off an SD card. So, not a huge process, but not the same as booting to Forth immediately.

  • Like 1

Share this post


Link to post
Share on other sites
1 hour ago, SlithyMatt said:

I don't think there's any plan on including it in ROM or having it be a configurable boot option -- or having configurable boot options at all. Most likely, it will have to be started from the BASIC prompt by loading it off an SD card. So, not a huge process, but not the same as booting to Forth immediately.

I may have missed, but I hadn't heard any change to the plan to have a saved setting in the RTC storage whether you want an autostart program to run. Any autostart capability at all combined with a Forth with a savesys option is a configurable Forth boot up.

Share this post


Link to post
Share on other sites
2 minutes ago, BruceMcF said:

a saved setting in the RTC storage whether you want an autostart program to run

I must have missed that. If that is part of the final design, then sure, you can boot to whatever.

Share this post


Link to post
Share on other sites
12 minutes ago, SlithyMatt said:

I must have missed that. If that is part of the final design, then sure, you can boot to whatever.

I've only seen it described in FB discussions (which of course means it would be SO easy to track down!), but since the RTC has not been nailed down, I've always considered it to be just penciled in until/unless it makes the FAQ and/or emulator.

Share this post


Link to post
Share on other sites
On 2/8/2021 at 5:09 AM, integer_basic said:

Why use BASIC 2?  It's horrible, without any commands for graphics, sound, or the joystick.  Was BASIC 7 more money to license?

It was not a question of money. X16 hardware is based on VIC-20, and BASIC V2 is designed to run on this hardware. BASIC 7 was designed to run on different hardware, and to run BASIC 7 on X16 would mean to rewrite a lot of source code of BASIC 7. On the other hand BASIC 2 runs on X16 with minimal source code changes.

So to save time and resources X16 team decided to start with using BASIC 2, planning to add new commands later (which they already partially did). Depending on the user demand, BASIC functionality might grow to the one similar in version 7 or version 10 or whatever.

BASIC V2 allowed X16 to have a fast project start and stable run, allowing team to concentrate on other more important features.

  • Like 2

Share this post


Link to post
Share on other sites
15 hours ago, rje said:

Well sure.  I can try.  I'm a high-level programmer that knows C.  I can at least write a big fat binary and then think about how to optimize it.  Please wish me luck, because I'm going to need it.

 

Oh, don't worry about that. I've written a few to varying stages of completion, i.e. running programs. I never really finished most of them off because I didn't see the point, it's just writing tokenisation/detokenisation code.  The last one was designed to be modular so you could add and drop whole chunks of it (no floats ? no strings ? etc.) pretty much at will.

It's probably easier than working with the Microsoft/Commodore code. It's engineered better for a start, well engineered at all, and bits are where they're supposed to be.

The other problem with them is, whilst I don't doubt your ability to do it, you won't make it fast enough and resemble BASIC. I've got two interpreted languages which are about the same speed (about 5x faster than X16/MS Basic) one of which is a sort of FORTH you can edit on the fly like BASIC, and the other one resembles the old HP9xxx calculator language, HPL which sacrifices everything for speed. I have looked into tricks like DAI Basic, semi compiled stuff, storing references in the tokenised code (so if you access a variable you don't have to use lists/hash tables etc, same for procedure calls) and it just can't be speeded up that much. 16/32 bit integer maths, fp maths eats up CPU cycles. I did get a workable 8 bit only language going once but that was for a machine with only 2k RAM :)

There's a very good example in the archive, a chap wrote a very nice BASIC version of a Boulderdash-type game, and he's stretched it about as far as it could go.

  • Like 1

Share this post


Link to post
Share on other sites

 

On 2/8/2021 at 11:22 PM, integer_basic said:

Aha!  Very nice!  Very nice indeed!

Just to let you know that X16's BASIC V2 is kinda like a hybrid of C64 BASIC V2 and C128 BASIC V7. 

Share this post


Link to post
Share on other sites

Converting variables from two significant to variable width could be tricky, but changing the number of significant characters from two to four would be a substantial increase in ease of use and likely to be less challenging.

But the number one community pull improvement to the current CX16 Basic would to be upgrade the garbage collector from the C64 version to the C128 version, which is much faster when there is an appreciable number of string variables to collect garbage for.

  • Like 1

Share this post


Link to post
Share on other sites
12 hours ago, paulscottrobson said:

...you won't make it fast enough and resemble BASIC.

Ah, yes, that's right, you have mentioned that more than once.  And, well, it is what it is. 

Share this post


Link to post
Share on other sites

I would like to have longer variable names as well. But 26 one-character and 26*36 (minus a few) two-character variable names, one set for floating point numbers, one set for integers, and one set for strings... that's actually a pretty big variable namespace.

Share this post


Link to post
Share on other sites

I had completely forgotten how terrible limiting two-character variables are.

It is SO EASY to lose track of them with programs larger than 4K.  By the time you get to 16K, you'd better have accompanying documentation kept up in good order... I think there must be a mental load function, here.

L(x) = (x / 4096) ^ 2

L(x) is the mental load incurred by a typical Commodore BASIC program of byte length x.

Its value is the probability that you'll forget a variable each time you add to the code.  A probability of 1 means you'll forget one variable.  A probability of 4 means you're going to forget four of them.

LOL

 

Edited by rje
  • Like 1
  • Haha 1

Share this post


Link to post
Share on other sites

So, here's the features of the BASIC transpiler that I'm using:

  1. Labels, not line numbers.
    • And the labels can have a dot in them, so as to look like prototype-y subroutines.
  2. Long variable names.
  3. Multiple files.

It doesn't have while loops, and it doesn't have true procedure calls.

Just labels and long variables are a HUGE leap forward.  It makes programming 24K+ BASIC programs possible without the need for reference documents.

 

Current discipline uses files as modules, and I build labels with a module name as a prefix.  This adds even more readability / traceability to the source code.

 

Edited by rje

Share this post


Link to post
Share on other sites
14 hours ago, rje said:

So, here's the features of the BASIC transpiler that I'm using:

  1. Labels, not line numbers.
    • And the labels can have a dot in them, so as to look like prototype-y subroutines.
  2. Long variable names.
  3. Multiple files.

It doesn't have while loops, and it doesn't have true procedure calls.

Just labels and long variables are a HUGE leap forward.  It makes programming 24K+ BASIC programs possible without the need for reference documents.

 

Current discipline uses files as modules, and I build labels with a module name as a prefix.  This adds even more readability / traceability to the source code.

 

Even if you can just write GOSUB update.display or something it improves readability of GOSUB 7730 so much it beggars belief.

Share this post


Link to post
Share on other sites
19 hours ago, BruceMcF said:

Converting variables from two significant to variable width could be tricky, but changing the number of significant characters from two to four would be a substantial increase in ease of use and likely to be less challenging.

But the number one community pull improvement to the current CX16 Basic would to be upgrade the garbage collector from the C64 version to the C128 version, which is much faster when there is an appreciable number of string variables to collect garbage for.

It really depends how they've done it. Theoretically it shouldn't be too hard. The risks of introducing a near-impossible-to-track bug is very high thought, as it's terribly unmodular. In theory all the variable code could go in one independent module, the only complexity being DIM and that's just called whenever you encounter a variable and it returns a reference and type. In practice ..... compared to patching the command vector table  and calling eval it'd be a mess

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...

Important Information

Please review our Terms of Use