(Continuing from VTL-2 Expressions, because some people want to know:)
As I understand it, Very Tiny Language essentially owes its existence to the
paucity of support from MITS for the Altair 680. RAM boards from the
manufacturer were not just expensive, but they were really hard to come by.
And even if you had the RAM, putting anything in the RAM was painful. No
floppies, no cassette tape, only the serial port, so you had to load BASIC or
the assembler or other tools from paper tape, and that took a long, noisy
several hours according to what I have heard. And without tools, it's hard to
develop tools in the first place.
So Gary Shannon and Frank McCoy at the famous Computer Store made this very tiny programming language that fit into three ROM sockets on a single ROM board. 760 bytes of fairly tight code. (When I say fairly tight, don't get me wrong. I might kibbitz their work, but they did a pretty good job.)
They took a bunch of short-cuts in the design of the language to keep it tight, which is something to keep in mind while we walk through using the language to write programs.
And it turned out to be useful enough that owners of the 8800 also wanted it, so they wrote a version for that. And then 3rd parties wrote versions for the 6502 and other processors.
Why?
Because it can turn your microcomputer into a programmable (integer)
calculator even with very little ROM and RAM. (And it's also an example of a
useful, minimal ad-hoc programming language.)
My post on expressions talked about using it without really programming in it. This post will be about programming in it.
Allocation variables!:
Before we can start putting VTL programs in memory, we have to make sure VTL knows where it can store the lines of program we feed it.
(Fasten your seat-belt and hang on, this detour-is-not-a-detour is a bit of a rough ride.)
We need to check the two allocation variables, the current allocation base -- & (ampersand) -- and the top of allocatable memory -- * (asterisk). (Yes, ampersand and asterisk are variables.)
?=&
will print the current allocation base. And
?=*
will print the top of allocatable memory -- except that they have to be
correctly set first.
Yes, these are variables, and yes, that's what they are named.
If you want to know the total amount of memory available for programming (and the array, more later), type
?=*-&
-- if they happen to be correctly set. Which is what I should explain now.
To understand the problem, consider that Gary Shannon and Frank McCoy at one time were making a little money off the VTL ROMs they sold. Not much, though. They really didn't want to have lots of different versions of the ROM in their inventory.
Other than the CPU decision, they just wanted the user to be able to plug the ROMs into a ROM board, set the board's address, and turn on power. So they didn't want to program a RAM limit into the ROMs that would not apply to a large number of their customers, even if the customer could fix the limit. Better to make customers aware of what those variables are and why, and ask the customers to set them themselves.
Maybe.
Anyway, if you have the original ROMs or the original source (including the version I started with in bringing VTL-2 up on EXORsim), these variables are not set when VTL-2 starts up.
And, until they are set, you can't start programming.
If you are running VTL-2 inside an emulator, the emulator may do you the convenience of clearing memory before loading the interpreter -- in which case it will be obvious that they are not set.
Or it may not.
And if you are running real hardware, the variables will probably have garbage in them on boot-up, which may be obvious, or which may look valid to the interpreter (and may cause crashes if you try to edit or look at program lines).
On the other hand, if you are working with one of the executable images made from source in which I moved the VTL variables out of the direct page (all the rest of the versions I have posted), I went ahead and put start-up code in the interpreter that sets them -- specifically because I moved those variables and the initial allocation base is no longer a simple question of 264 on a 68XX CPU.
Similarly, C being what C is, VTL-C sets them for you. And others have done
likewise, for similar reasons.
So, you need to take a look at them and figure out if they need to be set or not.
Top of allocatable RAM:
The top of allocatable RAM is fairly straightforward. Check it now:
?=*
It should be either equal to the amount of RAM you have (or have given it), if VTL resides (say, in a ROM) in an upper address range, or the amount of RAM minus 1K to 2K -- so that VTL and maybe system stuff like maybe stack can reside in RAM above the allocatable area.
Confusing? Maybe I should draw a map:
| 0000: | Possible system stuff |
| (low address): | VTL variables also, input buffer and usually VTL stack |
| (slightly higher address): |
& (allocation base is here.) VTL allocatable space -- for program (and maybe an array) * (top of allocatable area is here.) |
| (still higher address): | possible system stuff (including, possibly, the host stack) |
| (even higher address, may be top half of memory): |
VTL interpreter code image |
| (above that): | more system stuff (including, possibly, the host stack) |
Hard numbers?
The top of the allocatable area should be something around 30000 or more for 32K RAM systems, 14000 or more for 16K, 6000 or more for 8K, etc. If the interpreter is up in the upper 32K of address space, where ROM often is, top of RAM may be exact powers of two.
However, in some systems, the system stuff at the bottom of RAM is huge, and general purpose RAM itself may not start until something like 16384. And general purpose RAM may not come in simple powers of 2. So you may need to figure out the total RAM size and add it to the physical beginning of general purpose RAM.
(For the MC-10, for example, you probably want to play around with it with my
unedited sources in the XRoar emulator, then read the source and figure out
how to adapt it to your hardware, to use your RAM configuration
effectively. Your likely configurations are 4K, 8K, 20K, and ??, so top of allocatable space is likely to be 1 or 2 K less than one of those.)
(To be strictly accurate, in the MC-10 images and the CoCo images I've produced, I'm letting the VTL interpreter piggyback its stack on the stack the BASIC host uses. This is because the MC-10 interrupt routines, in particular, don't like the stack being somewhere else -- which means you really could eliminate the stack allocation in the source code, but I didn't want to pull too many rugs out from under things.
Without the necessity of maintaining BASIC's stuff, you would need less than 900 bytes at the top of RAM for the interpreter, not 2K. Top of RAM would be above 31000, 15000, 7000, etc.)
Allocation base:
If you are running an original ROM or an image from the original source, the initial value of the allocation base depends on the CPU:
- For the 6800, the allocation base at startup is 264, eight bytes above the stack area at the top of the direct page.
-
For the 8080, they moved the variables up to make space for the CPU
interrupt shims at the bottom of memory, and the initial allocation base is
320.
If you are running an image from my modified sources and have not altered the label ZERO or the ORG before where ZERO is declared, the allocation base depends on which source you are using. You can check the assembler listing for the value of the label PRGM.
(Cough. Let me correct myself.)
If you are assembling it yourself from whatever sources, you should check the assembler listing.
Go ahead and find the listing, or re-run the assembler and get it, and look for the label PRGM. If the interpreter is setting things for you, a little bit after the label COLD, or a little before START, you'll see something like
LDX #PRGM
STX AMPR
That's the allocation base. And you'll see the code setting the STAR variable shortly before the START label. That's the theoretical top of memory.
(If you're running a C language version, it will most likely be 264 on
startup. Or, if it's a 32-bit version, 528 or something. Maybe. Look for clues
in the C source. Or assume it's good unless it crashes.)
At the time I write this post,
- For my 6800 version with just the variables moved, the initial allocation base is hexadecimal $308, which is 776 in base ten.
- For my general 6801 enabled, slightly optimized version with the variables moved, it is the same.
- For the MC-10 using the general 6801 image, because there is a huge gap where nothing exists below video RAM and because VTL and its variables have to reside above video RAM and memory in use by interrupt routines and such, the initial allocation base is $4400, or 17408 in base ten.
-
For the Color Computer using the transliteration image, while we don't have
that gap of wasted memory map like on the MC-10, we do have memory
used by BASIC and interrupt routines, and by the video RAM, which have
to reside below the variables. The initial allocation base I'm using is
$1708, or 5896 in base ten.
Whew. End of detour-is-not-a-detour.
If the values of the allocation variables don't look reasonable on startup, figure out what they should be and set them before you continue. Otherwise, you will by typing in code and VTL won't be remembering it.
One more point before we return to our originally scheduled programming:
New command:
Now that you have noted and remembered the initial value of the allocation base, consider what happens if you have a program in memory and you type
&=264
or whatever the initial allocation base label was on your system (say, 5896 on
the Color Computer or 17408 on the MC-10).
Presto.
VTL has forgotten your program and is ready for a new one.
Programming a counted loop in VTL-2:
With the allocation variables properly set, we can now type program lines in
and list them.
In my bring-up process, I used several variations of a simple counting program because it was simple. We'll start by looking at that. If you've been through my expressions post, much of this will be familiar, and you'll be able to see some differences from BASIC.
10 A=0
20 A=A+1
30 ?="A=";
40 ?=A
50 ?=""
60 #=(A<10)*20
70 ?="BYE-BYE NOW"
Lines 10 and 20 look just like BASIC.
If you make a mistake, _ (the underscore key) allows you to back up one space,
but the terminal doesn't back up or erase it from the screen. If you have
trouble keeping track of what's happening this way, type @ (the at-each key)
and start the line over from scratch.
Line 30 has that print command that reminds one of the BASIC shortcut key, but isn't the same. It will just print the string
A=on the output device. And the semicolon will stop the VTL interpreter from putting a new-line after it.
Line 40 prints the value of A.
Line 50 doesn't have a trailing ; (semicolon), so printing the empty string
puts a new line on the output device.
Line 60:
You may remember from the expressions post that # is the current line number. And I mentioned that setting it forces a jump. But what is that weird business about multiplying a comparison by 20?
There is no line 0 in VTL. Trying to jump to line 0 is a no-op.
The value of the comparison is 0 (false) or 1 (true). Multiply that by 20 and you get either 0 or 20. If it is 0, there is no jump. If it is 20, setting the line number to 20 causes a jump to line 20.
Say what?
This is VTL's version of BASIC's IF -- GOTO statement.
VTL re-uses the assignment syntax -- and the semantics -- not just for jumps, but for conditional jumps, too.
Just for the record, the left-to-right parsing means that we don't really need
the parentheses on the condition. I put them in there to make them more
obvious. Whether you do or not is up to you. Remember that more complex
conditions will likely need the parentheses.
So, that's how this counted loop works. If you run it.
Can you guess how to run it?
That's right. Type
#=1
on a line by itself.
OK
#=1
A=1
A=2
A=3
A=4
A=5
A=6
A=7
A=8
A=9
A=10
BYE-BYE NOW
Huh? Why not #=10?
#=10 would also work, but VTL does you the convenience of looking for the next higher existing line number and starting there, so #=1 will run any program.
What about line 0? Try it if you haven't yet.
Nothing? Remember, VTL forbids line 0.
That means that, when you type 0 by itself on a line, it does not try to edit, save, or delete a line 0. And the authors took advantage of that.
OK
0
10 A=0
20 A=A+1
30 ?="A=";
40 ?=A
50 ?=""
60 #=(A<10)*20
70 ?="BYE-BYE NOW"
Typing a 0 by itself on a line gives you a listing, instead -- if the
allocation variables define memory to remember a program in, and if there is a
program in there.
Some versions of VTL use an L instead of a 0 as a listing command, just for the record.
Programming Factorials in VTL-2
This one is from the PDF manual, but I've modified it just a little bit for no particular reason.
Since VTL wants us to be frugal, we'll take the cumulative approach.
LIne 10, N will be the index number.
Line 20, F will be the cumulative factorial.
Line 30, we want to print N,
then, in line 40 print some text to show what it is,
and, in line 50, print F.
In line 60, we'll terminate the output line.
In line 70, we'll increment remember F in G.
In line 80, we'll increment N,
and in line 90, we'll use the new value of N and the old value of the factorial to obtain the factorial for the new N.
In line 100, we'll see if the new factorial is so large that it wraps around. This only works once, and we only know it works because we know it works. We might as well check to see if N is less than 9.
And, in fact, the first time through, it doesn't work. We don't have a less than or equal comparison, so we'll add a line for the equality at 95.
10 N=0
20 F=1
30 ?=N
40 ?="! = ";
50 ?=F
60 ?=""
70 G=F
80 N=N+1
90 F=F*N
95 #=(G=F)*30
100 #=(G<F)*30
and that prints out the factorials of 0 through 8.
Subroutines in VTL:
Print the value of the (system) variable ! (exclamation mark).
?=!
If you just ran the program above, it should give you 101.
VTL does a little more than just set the line number when it sets the line
number. (I told a little lie back there about the semantics. Or, at least, not
the whole truth. It's doing a little more than re-using the semantics of
assignment.)
Before VTL sets the # line number variable, it saves the current line number plus 1 in the ! (exclamation mark) variable.
So you get one level of call and return. Exclamation mark is the current
return line number.
Don't get too excited, it's just one level. If you want to further call subroutines, you have to save the current return value first, yourself, somewhere.
There are other system variables, but I will stop here.
This should be enough to help you decide whether or not you want to go looking for the PDF manual with the rest of the system variables listed and some example programs to try.
One place the PDF manual for the Altair 680 can be found (with some other retro stuff) is at http://www.altair680kit.com/ .
The manual includes more sample code.
One downside of VTL-2 on the MC-10 or Color Computer is that we don't have a way to load the programs in other than typing them. If we had a true monitor, we could save and load the program area. Or someone could extend VTL-2 on these two, to create cassette tape save and load functions, perhaps -- someone besides me. I think I need to get back to some other projects.
