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.
Basic needs line numbers. Urbane uses the two bytes that basic uses for its line numbers for a zero byte and a screen lines in a file line count. The zero byte lets me look backwards in the file to the beginning of the previous line. The screen lines in the file line lets me see how far up in the screen I’m going. When I exit urbane I will renumber the file. When I enter urbane I’ll replace the line number bytes with my zero byte of nine for the screen lines in a file line. The maximum count is eight, so I’ll know I need to find the real count the first time I look at a line. I’ll store the count so I won’t have to do it again. Oh yeah. I discovered that Vcc has a break key. It’s <home>. Now I exit urbane when I press <home> and I delete the current line when I press shift-down-arrow. I used to use a shift-down-arrow to exit from the urbane editor. Letting the user edit the file in basic has the problem that he can edit the end of file line with disastrous results. He can also edit the symbol table which could be useful if he knew what he was doing. Changing a name in the symbol table would change it everywhere in the file. I need to give it more thought. Oh yeah. At my son’s suggestion I quit putting a phantom asterisk at the top of the file and I let the user see the end command and colon in addition to the asterisk at the end of file line. I think what I’m going to work on now is letting the user move up one screen line at a time instead of moving up one file line at a time and moving to the start of that line. I’m going to make it like the editor I use when developing urbane.
I am so happy. My son suggested that I should have the urbane editor screen and the coco basic listing look the same. I had been feeling good because I was working hard to make the urbane screen look almost alike. Just added a quote mark to the empty line or string of quote marks in the urbane editor before I put it in the coco basic file. Before that I had treated blank lines and single quote lines as special cases. Terrible. When I saw that putting everything in loops so I could handle blank lines and any string of just quote marks simplified the code I was happy. My first try after my son’s suggestion was to change blank lines to a quote mark before I let the user leave a line. That really simplified the code. Happier. My next improvement was to check when the user started to edit a line to see if it was just a quote mark. If so I would empty the buffer. The quote mark was already on the screen. Since it was no longer in the buffer, when the user pressed a key it would go right onto the start of the line where the phantom quote was. There was a bug. While I was trying to duplicate the error, I discovered that I had a blank line in the urbane editor screen. I figured that I should have a line with a quote mark. I returned to coco basic. The line listed and ran properly. I figured out what had happened. I had put a line in the urbane editor of just a space. No surprise that the urbane editor screen showed a blank line. The great surprise was that it solved the coco basic list function’s bug of repeating the last not blank line when it encountered a blank line. Apparently a space was all it needed. And of course one can’t see a space if it’s all by itself. Even better the program ran properly. I found that the end and shift-end in Vcc acted like a space in the urbane editor. If I can figure out how that works I may have the last key I need for delete-line-function. When I’m in coco basic on Vcc the end and shift-end act as break keys. That’s ascii 3. How that changed to a space I need to find out.
I’ve spent about a week working on my urbane project to get it to show empty lines in the editor. Coco Basic’s list command has a flaw. If there are blank lines in the file it repeats the last non blank line. If my user enters an empty line in the urbane editor I replace it with a quote mark in the basic file. That’s the comment signifier. So the program lists with quote marks and runs fine. My son suggested that I should let my user enter a quote mark by itself if he wants to. So I replace his quote mark with a pair in the basic file. My editor shows the user his single quote mark where he put it. My editor passes normal comment lines right through. The last problem I had was when I uncrunched a line from the basic file it showed the extra quote if any. I changed the line buffer and the line length count, but the extra quote mark was already on the screen. I fixed it with a kludge. I knew where the quote mark was on the screen so I poked the screen memory with the appropriate value to make it a space. Four instructions and it was fixed. What a kludge.