About a month ago I started working on KARL again using just vcc. I used a KARL interpreter. A simple program would be ‘W W’, ‘ B E’, ‘ G W, ‘E E’. The first letter in a line was the label. The second letter was W-Walk, B-if Blocked then goto, G-Goto, and E-End. The third letter was the target. This little KARL program would send the ‘>’ moving across the screen to the edge. It worked, but it was awkward and a little slow. I also had always be writing programs to test the command characters. I did use the system to write a KARL program to multiply two lengths together which worked. A week ago I started using basic routines for initialize, walk, turn, put down, pick up, and fix initial values. Walk, turn, put down, and pick up update B for blocked and M for marked. The user program looks something like 5000 gosub 5020, 5010 goto 100, 5020 gosub walk, 5030 if E then stop, 5050 goto 5020. That makes the ‘>’ run across the screen, stop at the edge and display the message ‘off screen’ ‘stop at 5030’. Adding 5040 if B then return makes the ‘>’ run across the screen, stop at the edge, and make a graceful exit back to the KARL command line. In addition to Q-Quit, S-Save, R-Run, W-Walk, T-Turn, D-put Down, and U-pick Up, there is C-Clear the robot line and F-Fix the initial values. At first I used Line-input to get the values to act on in the KARL command line. I had to always be pressing <enter>. I changed it to Inkey$. All at once I was cooking. When I wrote the multiply two lengths with this system, it was really fast.
I wanted to use Robert Gault’s COLORZAP-93 which I had bought, lost, bought again, and lost again. In the process of getting to buy it again I found it again. I decided that I would tell him all about it. At the end I mentioned this blog. I realized that I hadn’t been keeping it up to date at all. Well, Oct 11, 2022. About five months. Not as bad as I thought. Any way, I’ve put the user’s file in the regular basic’s space. There is Find to find a label, Var to find a name, Save to save a file and Load to load a file. Then, I wrote my world famous, haha, EARL program in the user’s file. It had its own editor and interpreter to run its program and save and load save and load its little program. I tried it out by running the original add and multiply lengths like my hero’s KARL back in the coco2 days of yore. Finally I did a digit multiply. It starts with __3_7, you can put any digits there. It ends in this case with __3_7_21. Quite a trick. Right? lol. Well I’ve done about as much with this system of programs as I want to. So, it’s off to new fields to conquer.
On another note I’m back to working on my project. Instead of making every character in every variable significant I’m just going to just keep the first 30 significant. Why you might ask. It makes the symbol table significantly smaller. I’m already using three k for the lower memory and three k for the higher memory which is going to share it’s eight k memory space with the symbol table. Using zero terminators and byte count bytes makes it two bytes overhead for each variable. I can use the same byte for the byte count and the variable terminator. With short variables that adds up. I’ve got the debug version of the screen showing the first 32 bytes of the symbol table.
The underlying code for my coco editor is done. The last piece was on expr go sub label list. It gave me fits. I kept dumping the stack and making on 2 go sub label list the same as on 1 go sub label which is handled by the basic rom. The trick was the top two words on the stack. I figured they were just there for the error control. Well, they are. The on 1 go to label and on 1 go sub label both had the same two words on the top of the stack. When I put them on the top of the stack for on expr go to label list and on expr go sub label list, my problems went away. I put an on expr go to label list into my sample program and it worked just fine. A word about my sample program. I call it EARL. Easy Assembler Robot Language. That just happens to be my name. Back when the coco 2 was great stuff and programs were saved on cassette tapes a professor out in California wrote a program he called KARL. He showed how one could add two distances to each other. He offered to send a copy of his whole program to anyone who showed how to multiply two distances together before the next issue of Rainbow magazine, bigger than Life or Look, devoted to the coco, came out. I caught fire. I wrote my first Earl program and developed my multiply program. I typed it up and sent it in. On of his students typed it into a coco. He made a couple of typos and it didn’t work. I fired off a letter explaining how I had written my Earl program to develop my multiply routine. I put them on a cassette tape and sent it in. The tape had a bad spot on it and it wouldn’t load. He replied to me that he didn’t believe anyone could develop the programs that fast. I should have copied it onto a new tape and sent it in. I kept trying to make it better. I wanted to make it print itself out onto a printer. I never got it good enough. It’s always festered in my mind. I’ve developed my coco editor similar to the program I had back then. Then I had only single letter labels, opcodes, and addresses. Now I have two letter labels and addresses. That way I don’t need line numbers. In my last attempt I had labels and variables with all their characters significant. But I didn’t have on expr go to and go sub label list. Now I’m going to put them together and have the whole enchilada.
If a label starts with a number the coco interpreter doesn’t throw an unknown label error like it does if it starts with a letter. When I made all characters significant before I didn’t address this issue. They could have said go to 1 and they would have been surprised by the results. I keep the number of screen lines for the logical file line in the number field, so there is probably a line with a 1 in the number field. It’s good that it has shown up here, so I can fix it properly. I’ve just come up with the ultimate solution. The coco screen has reverse digits available. I should check it, but I think that the basic interpreter will catch it. The process works. There’s a hook before the user enters a line. If I change the ‘0-‘9 to $60-$69 they show up as inverse ‘@-‘I in the normal basic listing. When the basic interpreter comes across them it sees them as zero and throws an unknown line exception. Of course I call it unknown label. There’s a hook for before a file line is put on the screen. So, I can change them to inverse ‘0-‘9 when I put them on the screen.
I’ve almost always had a message out routine. It started out as just a bare bones routine. Echoed characters till it found a zero. Just recently I started adding features to it. The first big one I made was making ] be the terminator. The advantage is that you can put the terminator in the character string and not have to add another line for the terminating zero. On the coco the ] character is shift-down-arrow. It never shows up in a basic program. I had replaced the zero with a [. Not good it broke the old code. Easily fixed. I made the zero be another terminator. Then I added ] as a carriage return terminator. On the coco it is shift-right-arrow. It also never shows up in a basic program. And now at last I made the ] just a carriage return. I don’t think that I’ll get much better than that.
I’ve been using to instead of go to trap runtime errors so I can use labels instead of line numbers. And then I remembered ‘for variable=expr to expr.’ I’ve decided to make a severe change. No one is going to use edit or list in a program, so I can use go edit for go to and go list for go sub. The runtime system checks after a go to see if it is a to or a sub. edit and list are neither so it will throw a syntax error. All I need to do is check if the run pointer is pointing at an edit or a list. If edit or list show up anywhere else the runtime system will throw a direct statement in program error. If the pointer is pointing at edit I know I have a go to. If it is pointing at list I know I have a go sub. Because it was a syntax error. Of course if I want to be sure I can check the token before the list or edit. If it is a go I can be positive. I felt a little bad about spending so much time figuring out the stack pointer. It needed doing. It was meant to be.
I was going to rush onward and work on ‘on expr go to label list.’ I was sure that I had the stack pointer figured out. I had fudged and got it to sort of work. I decided that I’d better get it right before I went on. I wrote a debug tool which used a parameter list after the debug call. That way it made only the minimum effect on the stack pointer. I’m having a great time and when I do get around to ‘on expr go to label list’ it won’t occasionally break for no apparent reason. I hope.
I have temporarily abandoned all characters in names significant. Labels are just normal names. One letter followed by a letter or digit. I’m working on program execution. Basic skips over initial names followed by a colon. Go to is replaced by to to. Any time basic expects a go and finds a to, it throws a syntax error. I catch the error and process the go to label. If there is a space between the characters of the label, the first character is not alpha, there is no label, or there is no line starting with that label followed by a colon I change the “sn error” to “ul error” and return to the error processing routine. Next I tackle on 0 go to label list.
First I made crunch work. I had an inc-pair routine that kept track of the current name pair at all times. It was complicated but direct. Of course it was easy to write the pair when it came time. Unfortunately when searching the symbol table, inc-pair was called each time that one went to the next symbol in the table. I changed it so that inc-pair just incremented the lsb until it reached zero then it started the lsb over again and incremented the msb. When the msb reached zero it printed a warning that there were only 35 name pairs left. Now when traversing the symbol table it usually only did one increment for each symbol looked at. Every 36th symbol it was only a little worse. The routine to write the name pair was less complicated than the original inc-pair routine and it only ran once for each name looked up. My other improvement was to add a byte count to each symbol table entry. Then when you first knew that the symbol didn’t match, two instructions, load b and add b to x, moved to the next symbol in the table. I’m satisfied that I won’t be able to make it much better. Another advantage is it was easier to check the code. A symbol could only be shorter or longer than the entry in the table. My code was defective but it was easy to fix. The lsb is A-Z, 0-9. By changing the starting values I was easily able to check the difficult changes. Z to 0 and then back 9 to A. I left the values in the code so I can use them in uncrunch which is next.