 |
| Swtpc6800 en:User:Swtpc6800 Michael Holley, Public domain, via Wikimedia Commons |
In my previous post on VTL-2, I described how I got Very Tiny Language running on Joe H. Allen's EXORsim simulator. I noted in that post that the use it makes of the entire direct page address space would likely cause conflicts with many run-time operating environments.
I'm not sure how much of a problem on 6800 systems this will be, but I know it will be a problem on any 6801 system that doesn't map the built-in peripherals completely out of the memory map.
So, preparatory to working through the code to optimize it to the 6801, and in an effort to understand some things that will be necessary in transliterating the code for the 6809, I worked out how to move the variables out of the direct page. It was actually quite a bit easier than it could have been.
To make it easier to take a diff to see what I have done, I'll include links to the previous two paste buffers:
-
Adding semicolons to make it easier to assemble accurately:
https://osdn.net/users/reiisi/pastebin/8440 -
Modifications for EXORsim (and EXORciser):
https://osdn.net/users/reiisi/pastebin/8441
And this is the version with the variables moved out of the direct page:
https://osdn.net/users/reiisi/pastebin/8474
[Work in progress here, left live to help integrate with paste buffer.]
A brief rundown of the changes (if not how I figured them out) --
The original uses a number of magic numbers -- 72, $87, and several implicit zeroes (NULL vectors). I added definitions to the code that clarified what those magic numbers mean and made it easier to redefine them.
The most important of those was ZERO, which, in this version, is no longer $0000.
The next most important was BUFOFF, which is $88. This allows the code to be
explicit about what it is doing with the index register at several important
points, particularly where ZERO was implicitly $0000.
One of the problems I had getting the original version running was the problem of initializing two variables that are necessary for the program to know where it can store VTL program code for editing and running:
- & (AMPR in the assembler) to 264 and
- * (STAR in the assembler) to something like the end of your RAM.
Running the original, the user was required to set those by hand because the assumption was that you would get a ROM and plug it into your single-board computer or system, and the ROM code would not be able to know how much RAM it could use and where it would end.
The assumptions change here. Now we assume that you will assemble this to run on whatever you want to run it on. So the source code can set AMPR for you, and can probe to set STAR for you.
Comment that code out, or simply jump to START instead of COLD if you don't want to do that. And remember to set those yourself.
More details:
At line 33, set the source code to start at address $200 instead of address 0. This address can be moved, but be aware that, in order to keep the code simple, the code assumes that the lower byte of this address is 0. In other words, wherever you move it, it must be to an address evenly divisible by $100.
(In case you are unfamiliar with Motorola assemblers, $prefix makes it hexadecimal base: $100 is 100sixteen, or 256ten.)
At line 81, SAVOFF was something I decided I didn't want to do. It's commented out, ignore it.
From line 84, I mentioned the magic numbers for LINBUF and BUFOFF above, read the comments for details. Note that BUFOFF is actually $88, but it is used every as BUFOFF-1. No biggy.
From line 88, I moved the stack. No big deal. Remember that the bottom of the allocation area is the limit of the stack, and the stack pointer gets initialized to the top.
In particular, and this is important, note that on the 6800 and 6801 the stack pointer is always pointing to the next available byte, not to the last byte pushed. In other words, the CPU stores a byte where S is pointing, then decrements, ready for the next byte. And it increments before popping (PULing) the most recently pushed byte.
Note especially that this is different from the 6809, which always points to the last byte pushed, or to one beyond the stack.
(POP vs. PUL. Motorola used a different jargon from the most visible literature. In the most visible literature, PULL is associated with queues -- first in, first out. POP is for stacks, last-in/first-out. In Motorola 8-bit assemblers, however, POP is PUL. Think about it. The most common metaphor was a stack of trays at the lunchroom. You don't POP a tray off the stack, you PULL it off, whether at the top or the bottom. Confused? Study stacks and queues. It will all become clear -- eventually. Someday, I'm going to write a runtime library that will help clarify this. Sometime before I die, God willing.)
Line 91 sets up the beginning of the area where VTL stores lines of code (and leaves its single array allocated, if you use that).
Line 99 is where the code starts, I mentioned COLD vs. START above.
Line 232 is just a place where the extra code size required because the variables are no longer in the direct page moved a branch target out of range. On the 6800/6801 there is no long branch, so we invert the test and follow with a JMP to the target, instead. Not a meaningful change.
Note its proximity to the machine language stuff, which did not require changes, somewhat to my surprise.
Well, basically, if you put some machine language stuff in there, you're going to need the monitor to support you through the way it handles SWI. My changes should not affect that.
Line 439 is more branch target out of range, but there's no condition, so it's just changing a BSR to a JSR.
From line 452 is the key change, very dependent on making ZERO explicit. (See also lines 591, 595, and 597.) Read the comments in the code, note that I commented out the most obvious code and used instead the math mentioned above that depends on ZERO being declared at an even 256-byte boundary. (I'm trying to avoid pushing the capabilities of your assembler of choice too far. Also procrastinating about making my assembler more conformant to current assemblers.)
The comments on 591, 595, and 597 explain again why I got rid of the magic numbers and used explicit labels.
Note the puzzle at line 541. I'm not the one who said, What? I'll explain more carefully in my post of the optimization for the 6801.
And that should cover this step in the project.
Well, actually, it's tempting to back up here and post another version, bringing in the progress from the 6801 version: in other words,
- without the CPX trick at line 541, using an explicit branch around instead,
- using a non-stack-blast method of inserting and deleting lines,
- and giving the temporary SAVEnn variables meaningful names.
But I'll postpone that, with a few comments:
If you want to do an automatic (or mechanical manual) conversion of 6800 source code to 6809 source code, at a minimum, the CPX trick must be replaced with an explicit branch around, as I have done in the 6801 optimizations. Moving the variables out of the direct page, as I've done here, should help, since the implicit linkage becomes explicit. I'm not sure whether the stack blast will survive the conversion, so you might want to bring that in from the 6801 optimizations.
[I may be able to come back to finish this up, or I may not. I do think the 6800 version needs more work.]
[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]
[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]
No comments:
Post a Comment