Jump to content
  • 0
geek504

BASIC: New Commands

Question

LOCATE (GW-BASIC) or HTAB and VTAB (Applesoft BASIC)

MOD (modulo)

ELSE (would be nice)

 

  • Like 1

Share this post


Link to post
Share on other sites

16 answers to this question

Recommended Posts

  • 0

Yes, I would really, really like to see LOCATE. 

ELSE isn't that hard... Commodore did it on the 128. ELSE has to be on the same line as the IF/THEN. So the parser just skips forward in the line when the IF is false and looks for an ELSE.

The problem is that this makes IF/THEN slower, since the parser has to work through the whole line when the condition is false. And it's very easy to reverse the IF condition and GOTO over a block of code, so I'm not sure ELSE is actually necessary or useful. 

But LOCATE and MOD are definitely useful. MOD makes certain type of math much faster (especially when doing byte conversions and base conversions), and LOCATE really should have been part of the command set since the beginning. 

 

Share this post


Link to post
Share on other sites
  • 0
Posted (edited)
3 hours ago, geek504 said:

LOCATE (GW-BASIC) or HTAB and VTAB (Applesoft BASIC)

MOD (modulo)

ELSE (would be nice)

 

Add these as feature requests, here:

https://github.com/commanderx16/x16-rom/issues

LOCATE is actually already on the list: https://github.com/commanderx16/x16-rom/issues/128

ELSE and MOD are not yet there, so adding those as suggestions might be nice.
Create a separate issue for each of the two commands and prefix the title with "Feature Request." So:

  • Feature Request: ELSE statement
  • Feature Request: MOD operator

 

Edited by TomXP411

Share this post


Link to post
Share on other sites
  • 0
Posted (edited)
4 hours ago, geek504 said:

LOCATE (GW-BASIC) or HTAB and VTAB (Applesoft BASIC)

MOD (modulo)

ELSE (would be nice)

 

ELSE could be a matter of someone integrating the 128 code into the current Basic and doing a pull request.

LOCATE ... AT-XY in Forth ... with just the first two parameters is just making a Kernel call available.The third option to turn off the cursor for "silent" placement of text graphics is also valuable, especially since that was done in the C64 with magic locations.

For GET-XY, CURSOR(0|1) where 0 is the X and 1 is the Y would work.

Note: ELSE is in the feature requests, just a lot further back.

Edited by BruceMcF

Share this post


Link to post
Share on other sites
  • 0

I agree, I do not see any reason for else.

You do not need to do anything it works out of the box like that:

Quote

 

10 A=0
20 IF A>0 THEN PRINT "SOMETHING":A=0:GOTO100
30 REM ELSE
40 PRINT "SOMETHING ELSE"
50 A=1
100 REM CONTINUE
110 PRINT "WE LEFT"

 

So we even have a ELSE with multiple lines already in it. Yes it is a little bit different to write but it is not an issue and easy to understand after you  worked with it. 

Share this post


Link to post
Share on other sites
  • 0
Posted (edited)
3 hours ago, SerErris said:

So we even have a ELSE with multiple lines already in it. Yes it is a little bit different to write but it is not an issue and easy to understand after you  worked with it.

Agreed. ELSE would be nice but not essential since it can be done using IF/THEN/GOTO. It's actually better not to have it for two reasons:

1. Use less ROM space; BUT if we have 128-512K ROM, why not?

2. Easier transition to assembly language programming which is really COMPARE/BRANCH/JUMP style.

I only suggested for the sole purpose of teaching kids how to program and ELSE would be nice to have! Two-character variable names is tough to teach with... I'm thinking for teaching just programming maybe GW-BASIC is better, but if I wanted to teach hardware too, moving from GW-BASIC to C64 BASIC would be quite "painful"!

Edited by geek504

Share this post


Link to post
Share on other sites
  • 0

Maybe it is good to start very basic and work your way up. The same is true for if then else. It is either else or goto, does not matter. Most languages do not have a goto instruction. The problem is that else is very slow the goto variant is also much faster which is most likely not a concern. Easier to read for someone not that familiar with a simple basic or even assembler dialect, so maybe it is good to implement and have options, however even the C128 implementation is very limited (one line if instruction)

Share this post


Link to post
Share on other sites
  • 0
1 hour ago, SerErris said:

Most languages do not have a goto instruction.

Quite the opposite is true... while modern, fad languages tend to leave it out (Python is a notable example), the keyword and operation is in most programming languages. C, C++, and C# all have it, for example, and Microsoft gives a pretty compelling use case in the c# documentation. 

In fact, out of the current languages labeled as most popular, 7 of them have explicit GOTO statements. And as you go back in time, it gets difficult to find a language without an unconditional branch statement before Java. (There was one, "BLISS", but I don't think anyone has heard of it outside of academic circles.)

 

Share this post


Link to post
Share on other sites
  • 0
On 8/28/2020 at 7:58 PM, SerErris said:

I agree, I do not see any reason for else.

You do not need to do anything it works out of the box like that:

So we even have a ELSE with multiple lines already in it. Yes it is a little bit different to write but it is not an issue and easy to understand after you  worked with it. 

Really, all Control Structures except counted loops are semantic sugar for GOTO and IF <condition> THEN GOTO. Where ELSE is needed is not in the ROM Basic, but as a reserved and reusable structured label in the EditorBasic, which allows working with labels and the editor basic sorts out line number behind the scenes.
TASK5: IF X5>0
THEN: DOTHIS
  DOMORE
  DOMORE
ELSE: DOTHAT
  DOMORE
  DOMORE
ENDIF

Becomes:
450 IF X5>0 THEN GOTO 460
455 GOTO 490
460 DOTHIS :
470 DOMORE
480 DOMORE:GOTO 520
490 DOTHAT
500 DOMORE
510 DOMORE
520 ...

Commodore 128 Basic V7 ELSE is just a modest space saver:

450 IF X>0 THEN GOTO 460:ELSE GOTO 490
460 DOTHIS
470 DOMORE
480 DOMORE:GOTO 520
490 DOTHAT
500 DOMORE
510 DOMORE
520 ...

But I am confident that all of the classic structured program structures can be done with IF/THEN and GOTO, because I am in the middle of implementing a Forth ... and while Forth has all of the classic structured programming structures, the underlying primitives are just BRANCH and ?BRANCH. IF/THEN/ELSE/ENDIF, REPEAT/UNTIL and BEGIN/WHILE/AGAIN are all straightforward to implement with GOTO and IF/THEN alone.

However, unless ELSE is implemented for speed, with the content after the ELSE token linked into the line number list, then the second is slower than the first, but I presume that the actual V7 implementation does it the slow way.

Share this post


Link to post
Share on other sites
  • 0

Having recently gotten into SmileBASIC4, I've found they've added quite a few things that I'm trying to recreate myself using the commands currently available. I did not know that there were Kernal level functions that are otherwise hidden (PLOT, for example.)

Kernal functions can be found in this reference: https://www.c64-wiki.com/wiki/Kernal

For sure - anything on that list is desirable in a more useful command (I've noticed the issues list. Keep it growing!) I'm still new and finding my way around (as well as catching up with status of ongoing development), but I'm definitely trying to move as much BASIC as I can from SB4 to equivalent bits using the VERA-based X16 and C64 BASIC.

For inspiration and comparison, here's a link to the SmileBASIC reference. http://smilebasic.com/en/reference/

Example: I've noticed SB4's LOCATE is similar to C64's PLOT, but PLOT is accessed via SYS $FFF0, and with some preparation.

While I can understand obvious technological and design differences between the platforms that run these two - I'm of the mind that anything that could make anything easier and more direct is worth doing at some point (priorities upheld, ofc).

Share this post


Link to post
Share on other sites
  • 0
On 9/3/2020 at 12:24 AM, SerErris said:

Maybe you want to have a look at this: https://github.com/commanderx16/x16-docs/blob/master/Commander X16 Programmer's Reference Guide.md

X16 has already a much broader BASIC dialect than C64. Some borrowed from new Commodores ..

For you .. PSET and LINE are interesting in the context above, but there are others like COLOR or SCREEN ... 

This feature request is about the text display mode, not about the graphics screen. The graphics commands export GEOS BIOS functions to Basic, LOCATE would export the ALREADY EXISTING Kernel PLOT call to Basic.

I don't mean to rain on your RTFM parade, but RTFR is also a thing.

Edited by BruceMcF

Share this post


Link to post
Share on other sites
  • 0

Back when I used to program an 8-bit home machine, I would use the following for MOD: a mod b === a - int(a/b) * b

Example:

10 A = 111

20 B = 4

30 M = A - INT(A/B) * B

40 PRINT M

This will print a value of 3.

Share this post


Link to post
Share on other sites
  • 0
18 minutes ago, pastblast said:

Back when I used to program an 8-bit home machine, I would use the following for MOD: a mod b === a - int(a/b) * b

Example:

10 A = 111

20 B = 4

30 M = A - INT(A/B) * B

40 PRINT M

This will print a value of 3.

If you're modulo-ing by a power of 2, it can be done much faster with an AND:

10 A = 111

20 REM MODULO 4 IS JUST THE LOWEST TWO BITS

30 M = A AND 3

40 PRINT M

Share this post


Link to post
Share on other sites
  • 0
18 hours ago, SlithyMatt said:

If you're modulo-ing by a power of 2, it can be done much faster with an AND:

10 A = 111

20 REM MODULO 4 IS JUST THE LOWEST TWO BITS

30 M = A AND 3

40 PRINT M

Absolutely. I was just showing the generic way to do MOD when not having the operator available. I totally agree to using AND whenever possible. Thanks for highlighting that.

I have always enjoyed doing bit-fiddling stuff, so I truly get into the AND, OR, NOT, XOR, etc. side of things. I once wrote the entire windowing system for a touch-screen based printer. After writing all of the window operations and window message handling in C++, including per-pixel transparency of overlapping windows, I decided that it was just too slow. So I rewrote the "blitter" operations in ARM assembly language, and (WOW) what a difference in speed!

Edited by pastblast
  • Like 1

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
Answer this question...

×   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