Jump to content
  • 0
Wertzui

What's wrong with this line here?

Question

I'm was looking to see if my usual BASIC program I try on everything would work on the X16 emulator too.

error.png.9a864a206a9e088a734f46c90c6dbc1a.png

(I was thinking the <> operator is at fault here)

Share this post


Link to post
Share on other sites

11 answers to this question

Recommended Posts

  • 0

I don't think string variables can be larger that 2 letters before the $. Change it to DA$ and that will probably fix it.

Share this post


Link to post
Share on other sites
  • 0

Never mind, renaming DASH$ to D4SH$ did the trick.

But what is DA$ used for by the system?

Share this post


Link to post
Share on other sites
  • 0

@SlithyMatt

String variables can be larger than 2 letters, just the letters above the first 2 won't make a difference. I usually write then out to know what they're about.

Share this post


Link to post
Share on other sites
  • 0

It's a hold-over from the C-64 BASIC that they started with.  With all the C= 8-bit BASICs, while variable names could be longer than 2 characters, they were only unique for the first two characters of the variable name, so if you tried to set up variables BOB, BOTTLE, & BOING, they'd all be (internally to BASIC) "BO".  There are a few reserved variables for system use.  TIme, TIme$, STatus, and now with the X-16, DAte$

10 BOB=10
20 BOTTLE=20
30 BOING=30
40 PRINT BOB,BOTTLE,BOING
RUN
 30        30        30

In any case, yeah, our variable namespace has shrunk by one with the X-16 from what we had on the C-64.

Share this post


Link to post
Share on other sites
  • 0

Coming from QBASIC, I consider the 2-letter variable name space (and no numbers in the first spot, remember) to be a pretty harsh limitation. In some cases even it conflicts when the variable name resebles a BASIC keyword.

Share this post


Link to post
Share on other sites
  • 0
29 minutes ago, Wertzui said:

Coming from QBASIC, I consider the 2-letter variable name space (and no numbers in the first spot, remember) to be a pretty harsh limitation. In some cases even it conflicts when the variable name resembles a BASIC keyword.

You're right on both counts.

  1. It's harsh
  2. It can conflict with BASIC, in which case a syntax error is generated
  3. It can conflict with reserved variables, similarly to #2.

Share this post


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

Coming from QBASIC, I consider the 2-letter variable name space (and no numbers in the first spot, remember) to be a pretty harsh limitation. In some cases even it conflicts when the variable name resebles a BASIC keyword.

It probably has to do with the way variable names are stored. I haven't dug into MS BASIC, but I can make some guesses. 

Let's start with how variables work: the interpreter has to associate a letter/number sequence (A, B3, NAME) with a location in memory. So somewhere in memory, the interpreter needs to create a name table and have a quick way to search that table. 

Let's start with the simplest name table: single character names. Names like "A" and "F" can simply be stored in a single list. So the variable "A" would be index 0 on the list, and "F" would be index 5. This is super easy to look up, as all the interpreter needs to do is subtract 65 from the variable name, then look at that position on the list. 

But now we add two letter variables to the mix, and we need a way to associate the names with the location in memory. We also need a quick way to look them up. So let's look at how MS BASIC does so:

I created a simple BASIC program that sets A=1, B=2, and AB=3

On the Commodore 64, variables are stored at (VARTAB), where each variable uses 7 bytes of memory. Let's take a quick look in there:

image.png.941b8ec03591bb98e26913755fc26a02.png

VARTAB is located at 2D on the Commodore 64, and it is a pointer, which points to $081C. 

image.png.5437a24d1b2738afd1339009bf3cb95e.png

If we break this down 7 bytes at a time, we get:

41 00 81 00 00 00 00
42 00 82 00 00 00 00
41 42 82 40 00 00 00

So we see that the first two bytes of each variable block are the name. $41 is ASCII A. $42 is ASCII B. And obviously $41 42 is AB. I won't go into the binary float representation of the values, other than pointing out that the 5 bytes after the variable name are the value. (And those do match up with the floating point values for 1, 2, and 3.)

When a variable has a sigil ($ or %), that is stored by adding $80 to the first byte of the name for integers (%) and the second byte for strings ($).

So how does BASIC look these variables up? You'd think the interpreter uses something fancy, like a binary sorted list, or maybe a hash table. 

Nope. 

Consider this:

image.png.667a5cc264489d94fa34261566f27ff5.png

The variables are not sorted and are not in name order. So it's likely that the BASIC interpreter just does a linear search to locate a variable name. 

So BASIC 2 is really not capable of longer variable names, nor is it particularly efficient when the list of variables gets longer. 

My current solution is to keep a table of variable names, based on a simple rule set:

  1. Use the first to letter: Hello > HE
  2. Use the first letter and the last letter: Helicopter > HR
  3. Use the first letter and one in the sequence (0-9,A-Z) : Hammer > H1, Horse > H2

I have actually written a simple code editor and converter that takes BASIC-like code and re-writes variable names and line numbers. I'm currently working on adding abstractions like functions and WHILE loops... and it will hopefully eventually be self-hosted, so you can run the entire thing directly on the Commander. 

Edited by TomXP411

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