When last we visited I was going to jump on comments. Well, the kind of comment that doesn’t work is the single quote followed by the comment ‘this is a comment. The rem keyword works just fine. rem this is a comment. Problem solved. So I went back to my add two distances routine. I wrote what I thought should work. It didn’t. I couldn’t tell what was happening so I added a step mode into the urbane interpreter. The problem was obvious. Gosub returned to itself instead of the instruction after itself. Problem solved. As for moving the copy buffer back to the highlight buffer, I think that I will just use the highlight buffer for the read data buffer. Problem solved.
A while back I had trouble when I used a mid mem buffer to copy lines from high mem so the rom interpreter could work on them. Strings messed up. I solved it by copying them to linbuf in low mem. It solved that problem but when I tried to input from a file the input routine wrote on top of the line I had copied into linbuf. I took a couple of weeks off trying to figure out how I wanted to go. Finally I remembered something I had read in the Tandy user’s manual. It was talking about trying to put strings into low mem where variables live from mid mem where user’s machine language programs live. It dawned on me that’s what I was doing when my urbane program in high mem said a$=”sam” and I put it into mid mem where user’s programs live. It suggested that I say a$=””+”sam” to put “sam” into regular string memory. I tried it. It worked.
I plunged back in. When I tried to read into linbuf from a file I got the same error. My son has me using git-hub. Unfortunately I forgot a step. To get the change into my test area. I have to kill Vcc, save my change in notepad++, insert the changes into the floppy image, wake Vcc up, copy the files from the floppy image into the hard drive image, load the assembler, and assemble the file that has been changed. When I got the same error I checked to see if the file had been changed on the Vcc hard drive image. It had. I finally realized I hadn’t loaded the assembler and assembled the file. When I did it worked like a charm.
When I tried to run my Earl program I had a line of garbage on the bottom of the screen. I thought it might be because I had used the buffer I use when I’m highlighting the keywords. I changed it. Gave it a dedicated buffer. Same result. Then I realized that it was the scale line that I fixed up at the beginning of the program. The old a$=”sam” problem. I said a$=””+”sam”. Presto it worked. I wondered if I should go to all the trouble to switch it back the highlight buffer. Sometimes I wonder if it’s worth it. 256 bytes. I remember when the thought of wasting that much memory would drive me up a wall. My whole program will probably be less tan 4k when I’m done. That’s 1/16 of my program. Maybe it is worth it. Oh well. Another day. I tried to put a comment in my urbane program. It didn’t work. I guess you tell how few comments I make. I guess that’s something that’s I should do next. Maybe I can manage to switch the copy buffer back to the highlight buffer somewhere in there.
I have the urbane editor and interpreter written. Unfortunately It takes fifteen seconds to load. It seems like forever. Of course it’s not like when I started studying computers. One run a day. There’s a much more serious problem. I copy the next line to execute into the direct line buffer. That buffer is called the line input buffer for a reason. When I try to do input the input clobbers my commands. I was thinking of sharing the buffer. Write my commands into the far end of the buffer. The problem is that once in a while the input would overtake the commands. And there remains the problem of a buffer to handle reading data from the data statements in the program. I was thinking of dedicating a medium resolution graphics page for my two buffers. Six data pages. What a waste. Then I recalled low resolution pages. Two data pages per graphics page. Perfect. I never use low resolution buffers. I won’t mind. Who am I kidding. No one else is going to use urbane anyway. lol.
Remember how I left out an at sign and got strange results? This time I left out the &. It was sure I meant print at h80. That is what I told it. Of course I had never told it what value h80 had, so it assumed I meant zero. There it was what I wanted to print printing at the top of the screen. I assumed urbane was flawed. While it was just doing what I told it to do.
As my father used to say there’s the easy way, there’s the hard was, and then there’s Earl’s way that makes the hard way look easy. When I was editing an urbane line, every once in a while something would show up at the end of the line. I looked at my code and discovered that every time I refreshed the screen, I set up an inverse video cursor line then changed it back to normal before putting it on the screen. I fixed it by leaving the whole screen with reverse video keywords until I started editing a line. Then I did a straight forward uncrunch without making it inverse first. I haven’t tried it out very much, but I have great hopes.
Well, I have a program that marches a greater sign one way across the screen and then turns it around and marches it back as a less than sign. I always said that when I got it so that it would do that that I would expose my project to the light of day. Soo I guess that I will. Fortunately I have a computer savvy son who will help me with that. I hope.
I’ve been using github for a while. Everytime I did a commit It gave this error message in a big window. CRLF instead o f LF line endings. I just endured it. Finally I mentioned it to my son. He spent a while on it. Now no more error messages. Everytime I do a commit and it just does it I get a warm feeling all over. That’s the good.
I have behavior health issues. I’m willing to accept creepy ideas as real when they aren’t necessarily so. I have my IMUrbane project working well enough that I can write programs in Urbane basic that actually do things. I wrote a meaningful program which gave me some strange results. Instead of assuming my project was working and my Urbane program was faulty. I spent several hours trying to pin down how my project was flawed. Coco basic and Urbane basic which is just an extension of it both have this feature that if you say print@n it will print at a spot specified by n. Finally I thought maybe I should look at my Urbane program. I tried likely commands on the command line. Finally I discovered that I had left out the @ sign. It made some really strange results. It printed n at the current spot on the screen. Oh well. All’s well that ends well.
My dad sometimes said that there’s the easy way, there’s the hard way, and then there’s Earl’s way that makes the hard way look easy. I bounced back and forth between the original coco basic and machine language to find the beginning addresses of original coco basic snippets for load urbane, save urbane, and execute a line. I copied each urbane line into the original coco basic file when it came time to execute it. Often it didn’t work. A line that would work on the command line sometimes wouldn’t work when I tried to execute it in the urbane file. I changed one address in my program so that the lines would be copied into the command line and then be executed there. Almost everything worked.
Goto commands would work by themselves but not in if then else commands. I immediately set out to rewrite the if then else command interpreter. After sleeping on it I decided to use the error trap routine that I already had. It took awhile but I would have probably still been at it and it probably wouldn’t have worked if I hadn’t changed. It was just too complicated. Now when the rom interpreter finds a letter from a label instead of a line number it says he must have meant line zero. There is no line zero so it says ?ul error (undefined line). At which point I take over and take him to the desired label. If he doesn’t have it I let the original coco basic give him the ?ul error.
The coco assembler I use starts at line zero. Notepad++ where I make my changes starts at line one. I tried to get my son to adjust the batch files that move the files back and forth between the Vcc coco emulator and notepad++ to take care of it. He balked. He showed me how I could do it. I tried a little. Then I tried it without the fix. When I got assembly errors the lines were one off. For a while I would type in n1,1 into the assembler. Then it too would start at line one. In the old days I would assemble my files by typing aed /we/nl/ns. Assemble ed /wait-for-errors/no-listing/no-symbol-table. Since I am editing in notepad++ instead of Vcc I can now just type aed /we. It lists everything as it goes along. When it finds an error it waits. I fix the mistake in notepad++ then press a key in Vcc. When it finds another error I repeat the process. Eventually I figured out that I could just add one to the line Vcc said the error was on. I’m having a great time.
Right now basic keywords show up in inverse video on the screen except for the one that is being edited. There’s an asterisk at the top and bottom of the file. Goto’s work in if-then-else commands. The stack pointer stays the same. I’m so proud. I’m going to start writing urbane programs to test the editor and interpreter. Wish me luck.
I have inverse keywords done and committed to my github repository. Once more I started to use urbane. I almost immediately discovered that sam$=”sam”:print sam$ resulted in ‘am’ when I ran it. It worked fine from the command line. I’ve decided to plunge ahead and see if I can figure out what is going on. Maybe tomorrow.
Urbane was usable so I was trying it out. I was having trouble recognizing basic keywords. My variables that started with a keyword messed up. I decided to make the basic keywords inverse. My first step was to make lines consisting of just a single keyword inverse. When I’m debugging my asm programs I often put something on the screen then pause. I forgot I’d done that. I was tearing my hair out until I remembered. Now lines consisting of a single keyword show up inverse. Whew.
When urbane is in debug mode the lines above the cursor are tokenized basic. Tokens are are graphic rectangles. $8f is a solid green rectangle. The screen is green. That token is restore. I was trying to use restore and read. They didn’t work. When the restore token was invisible I was a little shook. When I realized the problem I took a little time to change it on the screen to $ff. A bright orange rectangle. Restore and read still don’t work, but I can see the restore token now. The problem is the user program is in high memory behind the rom. I copy a line down at a time to execute. I’m going to have to rewrite restore and read. Oh well. At least I got the restore token to show up when urbane in debug mode.
My son added to his bash tool. Now it includes what I was doing in coco basic. It still takes a few seconds to extract the project files from the floppy image and put them into the proper drives in the Vcc hard drive image. It’s only a few seconds now though. I don’t think that we’ll get it any better. Notepad++ starts at line zero. Ascii coco basic and edtasm6309 that I use on Vcc start at line zero. I wanted to take a blank line away and add one going the other way, so the lines would all be the same. He balked at that. He showed me how I could do the kind of thing that he had done. I went to town on it. When I had my c code finished I called him to discuss it. He was busy. Thank goodness. I went back to developing my urbane project using the tools he had finished. The only time the line numbers matter is when I have asm errors which almost never happens. He showed me how I could type n1,1 in the assembler and presto lines started at one with an increment of one. Just like notepad++. I tried doing part of the development on Vcc again. I just got confused. Now I am determined to make all changes in the git src folder with notepad++. Notepad++ is so much better than the edtasm6309 editor. It’s a world better than the editor that came with the coco out of the box. But notepad++ is much better still. Surprise suprise. It’s only been thirty years. My urbane project hopefully will make the coco work much more like notepad++.