Klaus:

I too use the Kingswood A65 assembler, and have been following this thread. I am not ready to delve into VTL02 at this time, but would certainly appreciate not having to make syntax and/or general format changes to the code that you have already made. Thus, I would certainly like access to your source for VTL02.

Perhaps now would be a good time to discuss having a 6502.org GitHUB repository for code such as this. I can see the benefit of a generally accessible, but controlled, source code repository with version control built in. I found a 6502.org repo on GitHUB, but it was not fully populated with code from the various contributors on this site. It could simply be a centralized repo for forum members to share their code. A forum moderator could simply fork the repos from GitHUB accounts of forum members.

I certainly would like to access your 6502/65C02 test suite and VTL02 source in this manner.

_________________
Michael A.

Good thought: the area at
https://github.com/6502org/6502.org/tre ... lic/source
Corresponds directly to
http://6502.org/source/
And so on. Anyone could send a pull request, and then Mike could accept it (or reject it...)

For now I have made a version compatible to the Kowalski simulator and assembler so people can play with it. Besides changing I/O access to the simulator's requirements I also changed the editing keys from '_' to 8 (true backspace) and from '@' to 27 (true escape). Remember that this does not mean that you can use _ and @ as a variable. They are used internally in VTL02 as temporary storage.
After assembling the source in Kowalski start the debugger and click run. To test simply copy an example program from the Altair VTL manual and paste it to the I/O window in the Kowalski simulator. #=1 makes VTL run the code.

I will eventually load those sources on github if I ever find out how it works.

The AS65 source is here:

_________________
6502 sources on GitHub: https://github.com/Klaus2m5

Thanks once again for your kind (and accurate) critiques, and for your considerable effort to help make this neat little language more available to "the masses". I haven't tried to assemble your modifications yet, but it appears that your versions will still fit easily in 1K, which was my revised goal. It's certainly not for everyone, since error handling, string handling and floating point are almost non-existent, but I agree with you that it could find its niche, even in the 21st century.

Before I try the compiler idea, I'm going to implement it in 65c802 and m-824 (you guys don't know the m-824, because I haven't shared it with the rest of the world yet). A quick hint or two: arithmetic will be 24-bit, and I think that I can fit all of VTL-2 into 512 bytes or less.

Mike

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

Hey, good work. I was looking for something like that. Small and easy to use. I've read the manual that was posted at the beginning of this thread and came over one question. On page 14 is a sample program that prints out the factorial numbers from 1 to 8, having a line number 40 showing something like this:

I tested the code on the simulator and it works, but I want to understand why. I found no proper explanation for this in the manual. Maybe somebody can put me on the right path.
Mario.

_________________
How should I know what I think, until I hear what I've said.

Hi, Mario.

That line 40 is actually supposed to be:

40 ?="! = ";

The thing that you have to realize about VTL-2 is that it makes simplifying assumptions regarding the code's intent, and this typo just happened to be harmless. Frank's version and mine both peek just past the assignment operator (which, BTW, doesn't even have to be '=') and if it sees an initial quote, it simply treats the entire statement as a ?="... statement.

There is another factorial program further down that keeps going until it runs out of memory. The only problem is that it starts producing invalid results when it silently overflows ... I forget what the largest valid result is, but a VTL-2 program with 16k of array space will have enough room to happily spit out bunches of completely inaccurate results!

Here's a little quiz: what do the following statements do?

-----

.....

Both of these statements silently do something, but what?

In summary, VTL02 refuses to give up executing any non-null statement you give it. If it can't do what you tell it to do, it will not complain, but instead simply do something it can do. In fact, Frank's 6800 version didn't even give up if you gave it a null statement ... it forged ahead on buffer garbage, assuming that you meant to use null as a variable name! It is possible for my version to run past the end of a mal-formed statement as well, and even get caught in an endless (at),y loop, but it NEVER gives up until it sees what it interprets to be the end.

Take care,

Mike

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

That can really byte you when you use non printable characters. Even spaces at the end of the line can cause problems:You can't see them but they are evaluated.

Regarding Mikes' quiz: Obviously - and . are valid variables and - is even a valid operator, . is not. You have to know (or find in the code) that the operator defaults to test for greater than or equal to.

_________________
6502 sources on GitHub: https://github.com/Klaus2m5

As many of us as there are here who are addicted to code golf, I'm a little surprised no one else has brought it up yet, but it looks like you may be able to squeeze a little more blood -- er, bytes -- from the stone. I haven't actually tested these.

In OPER5, save 4 bytes with this:



At CVBIN2, save 2 bytes by using EOR #$30 CMP #10 BCC CVBIN3 before the PLA.

In ADD, save 1 byte with



You can do the same thing in SUB to save 1 byte, or you can save 5 bytes if you're willing to resort to self-modifying code. ADD and SUB become:



You would also replace the BNE OPER3 (after the CMP #'-' at OPER2) with a BEQ SUB. ADD and SUB were 28 bytes total before, and become 22 bytes total, with 1 byte of that being from the previous optimization of ADD. On systems (such as the Apple II) where $75A9 is not an I/O location, you can use the old trick of replacing the BNE with a .DB $2C to save 1 more byte. (Of course, by swapping the SUB and ADD lines and some additional rearrangment, you can make this work on systems where $F5A9 is not an I/O location.)

I bow to your superior 'crunchitizing' skills, Bruce! Thank you. I will incorporate your suggestions (except the self-modifiers) in my new revision, with credit to you. I was on a space-optimizing tear until I realized that it would be impossible for an amateur coder like me to get everything into 768-bytes like the 6800 version (those 16-bit ldx and stx instructions are the reason that it made it, IMO). So I concentrated more on the commenting, and patted myself on the back for actually 'finishing' a project.

I need to constantly remind myself to apply some of that focus to the myriad unfinished projects and ideas that I've accumulated over the years ... the 65m32 documentation and simulator are currently at the top of my to-do list, but I can feel it starting to slip from my grasp, despite the interest and kind words of Garth, ttlworks, teamtempest, DrJefyll, and others. Somebody slap me, please!

Mike

Sorry for warming up this old thread, but I think it's good to have all questions and answers in one place.
It took a while to find out how to list the current program, but this is solved now (just typing "0" plus <RETURN>.
But is there a possibility to directly read or write to a memory location? This would be a nice feature for using VTL for I/O programming.

Mario.

_________________
How should I know what I think, until I hear what I've said.

Hi, Mario. As Klaus mentioned earlier, VTL02 has a version of BASIC's deek and doke, but it doesn't use absolute addressing, but rather indexes from the end address of the stored program, held in system variable &.

So, if you want to read or write a single byte, you will need to write your own machine-language peek and poke using the system variables > and ". Set " to the address of your peek/poke handler, and call it with >= ... it will be up to you how to handle the exchange of data between VTL02 and your routine. I'll think about it, and post my version.

If you can accept the limitations of VTL02's array facility (16-bit unsigned R/W only), you could try the following sample code, that allegedly writes a 16-bit value in V to a two-byte location addressed by A.


If & needs to be adjusted at run-time (because A is even and & is odd, or vice-versa), your program will gain one garbage byte at the end every time you use this routine, possibly confusing the program listing feature, but it should otherwise be relatively harmless, as far as I know. [edit: added code to self-adjust & back down, making the previous sentence moot].

If you don't use the array facility or #= while accessing I/O, you can simply do the following (but possibly only for target addresses above the end of your program):

Mike B.

P.S. I'm going to post this code completely untested, then check it ... I like to live on the edge!

(I see that as recently as 2010 we have RVTL for linux, for ARM, for AMD64. There's even a single-floppy linux with RVTL! The language has become a bit bigger though - but note, there's a compiler, written in RVTL of course and compiling direct to x86 machine code. There's also a wiki written in RVTL. Pages may need translation.)

It seems that VTL/K had a simple peek and poke feature.
Poke: @(n)=<EXPRESSION>
Peek: A=@(n)

Maybe we can add this feature to our 65C02 VTL. It would also make handling arrays much easier.

Mario.

_________________
How should I know what I think, until I hear what I've said.

Mike
this is very interesting - and we've blown the 3-prom budget already, so a 1k version which goes a lot faster would be a big win! Did you have any further thoughts on it?

Ed

I was completely unaware of Jun Mizutani's extensive work on VTL when I ported the original 680b source to the SWTPC and 6502! I don't have enough spare time to work on a compiler, but I may be able to add the equivalents of peek and poke by adding a ;A) notation as an absolute-addressed 8-bit version of the program-end-relative 16-bit :A). Please don't hold your breath waiting for me to produce ... my schedule is rather hectic at the moment, and I'm sure that there are many others reading this who are capable of performing the modifications themselves, with my blessings of course. By my rough estimate, it should still fit inside 1KB, if done carefully.

Mike B.