I don't think I really had this much spare time, but there was a question in the 6809/6309, 6800 programming language Facebook group about getting or building a version of VTL-2 (Very Tiny Language) for the 6809.
There were a couple of guys working on this. You can check David Wiens post and John W. Linville's post for the progress they've made so far.
This kind of thing piques my curiosity (... killed the cat, as they say).
So, for the past several weeks, part of what little spare time I have has disappeared down this rabbit hole, and I'm now bringing back some results. Nothing for the 6809, just yet, but some results.
First thing I did, since the assembly language sources they have for the 6809
came from someone working with a very perverse syntax assembler, and since I
don't like the way other people write 6809 code, etc., was go looking for a
base line source, something that runs with known results.
A little history:
As near as I can tell (from copyright dates on manuals and in source code,
etc., and from the manuals themselves), the original VTL and VTL-2 came to
life on the 6800-based MITS ALTAIR 680, motivated (as I understand it) in no
small part by the lack of manufacturer options for the 680.
VTL was a minimal programmable calculator-style language that would run from a very small ROM on a 680 with minimal memory expansion.
After making VTL-2 available for the 680, responding to interest from the larger, more established market for the 8080-based ALTAIR 8800, the authors, Gary Shannon and Frank McCoy from The Computer Store, re-implemented it for the 8800.
Thus, there are two base versions of the source code and manual for VTL-2, one for the 680 and the other for the 8800.
After that, versions for the 6502 and some other CPUs, and, ultimately,
versions in C, were produced by others. If you go looking for source code now,
the easiest to find is for the 6502.
I suppose I should leave links to everything I found, but I was tired after work and not keeping records. I think deramp.com and altairclone.com were among the places I visited.
But where I finally started getting traction was
T. Nakagawa's page on VTL. Down the page a ways is a link to a zip file containing a C language
implementation of VTL that is straightforward to compile on *nix (and some
other platforms). (Yes, his pages are mostly Japanese. Use Google Translate if
you need to.)
Now I had something running to test my understanding of the manuals I had
found elsewhere. (There is a searchable PDF version of the manual for the
ALTAIR 680 down towards the bottom of his page, too. Easier to read and more
complete than what I had been reading for the 680.)
He also has a table of memory usage for the VTL variables in his implementation, which is useful (though not definitive) in understanding how the microprocessor versions work. And the C source code is also useful in decrypting things under the hood in VTL.
And he has a link to Jun Mizutani's Return of Very Tiny Language page, which has a link to his very useful history and comparison of major versions table, where I finally rediscovered the command to list out the program you're typing in. On the 6800 versions, it's generally a zero typed by itself on the command line. Yes.
0
LOL.
And somehow (I don't remember how), I found the sbc6800 page on switch-science.com. Inside the software for the sbc6800, there is clean source for VTL-2 that almost works with my tools.
Almost. My assembler allows whitespace in operand expressions, which means you really need a leader character for comments to make sure that in lines like
VAR CMPB #'$ OR STRING
don't end up trying to use the OR of the character $ and the label string as the operand.
I need to fix that sometime, put in a switch to shut off whitespace in operand
expressions. Another project for the back burners.
Switch Science has a sbc6809, as well, but there is no VTL in the software for that. Maybe we can fix that.
Okay, so I used semicolon for the comment leaders and inserted them by hand. Good thing VTL is really tiny. Took me less than a half hour, I don't remember how much less. (Paste buffer on my OSDN pages.)
But I don't have an sbc6800. I should probably get one, but not yet. I do have Joe H. Allen's EXORsim simulator for Motorola's EXORciser running, however. And the fun begins.
First I had to move the code for the VTL interpreter down from $FC00, where it
was set up to assemble in the source code, to some place that doesn't conflict
with the EXORciser monitor and system object code. I moved it to $7800.
Then I patched the I/O calls and had to figure out why I wasn't getting any output from EXORsim.
For some reason, it turns out that I have to hit the output port about thirty
times before things start showing up. I should ask Joe about that sometime. I
added code to do that in an initialization routine. (Paste buffer.) Not a lot of changes yet, use diff if you're interested in seeing what I
added. Oh. I think there were also a couple of branches that were no longer in
range, which I changed to appropriate jumps.
I was expecting there were going to be problems with using all of the direct page for VTL's variables and stack. There will be conflicts if I try to assemble a version that works under a disk operating system.
But with the I/O patched and the code moved down, it worked as a simple calculator. Trying to enter a program, however, did not produce happy results. Crashing, freezing.
After spinning my wheels for a couple more days, I began to become sure that
it was just something about VTL itself that I was missing. Specifically,
looking in the code, there are two system variables that I didn't see getting
set any place in the code -- program base & and end * address. So I went
back and worked my way through the manual with both VTL-2 on EXORsim and and
VTL-C, and there it was, towards the end of the manual --
The microprocessor versions of VTL require one more step of initialization after you get the interpreter running and before you start typing in programs.
The variables in question are & and *, the program space base and the end.
264 should work for the base, per the manual. I used 300 to be safe. Look for the PRGM label in the source code to see what's going on. (Really, there should be no problem setting that automatically in the code, but I guess the authors were saving every byte they could for the user program space.)
The end depends on how much RAM you have installed and where you assemble the interpreter. It ought to work as large as 30719 ($77FF), but I used 8192 to be sure. (This could be probed and set, but it would take probably ten to twenty bytes to do a simple probe. Or you could just hard code it so you don't forget, and remember to reassemble if your memory layout changes.)
So, to get it running in EXORsim, copy the code from the paste buffer, save
and assemble it, open the S1/S9 object in the source.x file in a text
editor. Something like
asm68c -l1 vtl_6800_exorciser.asm > vtl_6800_exorciser.list
gedit vtl_6800_exorciser.list vtl_6800_exorciser.x
Run exorsim in a terminal session, something like
./exor --mon
You should have a starting message and a reminder you can type help, and the % prompt, at which you give the load command:
Hit Ctrl-C for simulator command line. Starting simulation...Don't forget to hit return after the load command. (The load command is the lone "l" you type in after the % prompt on the last line I just showed.)
> 0 A=00 B=00 X=0000 SP=FF8A ------ OSLOAD E800: 8E FF 8A LDS #$FF8A Load OS
Type 'help'
% l
It will wait for you to feed it S-record object code, so go to the object file in the text editor and select and copy the whole of the S1/S9 object as text:
S1090000000000000000F6Paste it into the exorsim session. It'll just paste in like the above. Hit the return key once at the end and it should say
S113000600000000000000000000000000000000E6
S113001600000000000000000000000000000000D6
S113002600000000000000000000000000000000C6
S11100360000000000000000000000000000B8
S113004400000000000000000000000000000000A8
S11300540000000000000000000000000000000098
S11300640000000000000000000000000000000088
...
S10C7AF8C60D8D02C60A7E7B1B3B
S1087B010D0A4F4B00CA
S10C7B06C628BDF0215A26FA3903
S1087B0FF6FCF45739F7
S10A7B1436BDF012163239F0
S10A7B1B3617BDF0183239E2
S903780084
PC set to 7800
Now hit CTL-C to get out of load mode, and at the % prompt type
% c 7800
or just "c" (continue), since it should have set the PC to 7800 for you
anyway. And hit return. It should give you some empty lines and then the OK
prompt.
OK
at which you need to set the base and end. Type
at the OK prompt. (Woops, not 300, see edit below.) Or you should be able to get away with&=300
*=8192
OK
&=264
OK
*=16*1024
OK
And it should run and allow you to type in programs.
[JMR202208092108: add]
After some study, it appears that the program area base variable needs to
equal the assembler PRGM label for listing and program editing to work. In
other words, the 6800 versions need to write
&=264
[JMR202208092108: add end]
[JMR202209231810: add]
I have written up a post on VTL expressions, here: https://joels-programming-fun.blogspot.com/2022/09/short-description-vtl-2-expressions-very-tiny-language-p1.html , which will help in testing and otherwise making use of the language. I should also shortly have a post up introducing programming in VTL-2.
JMR202209231810: add end]
My next step is probably to move the interpreter variables out of the
direct page ...
[JMR202208131113: add]
I've got this done, see part 2 here:
https://joels-programming-fun.blogspot.com/2022/08/vtl-2-part-2-moving-variables-out-of-direct-page.html
[JMR202208131113: add end]
... so I can optimize it for the 6801 (which usually has I/O at the bottom of the memory map)
[JMR202208140202: add]
And this is now done, see part 3 here:
https://joels-programming-fun.blogspot.com/2022/08/vtl-2-part-3-optimizing-for-6801.html
[JMR202208140202: add end]
... and then assemble it to run on the MC-10.
After that, if Dave and John haven't made any more progress, I'll see if I can make a quick transliteration to 6809.
[JMR202210011737: add]
I now have my work on VTL-2 up in a private repository:
There is a downloadable version of VTL-2 for the Tandy MC-10 (6801) in the stock 4K RAM configuration in there, with source, executable as a .c10 file, and assembly listing for reference. Look for it in the directory mc10:
[JMR202210011737: add end]
This comment has been removed by a blog administrator.
ReplyDelete