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++.
I make my changes in the project’s files with notepad++ in the git src folder now. When I’m ready to test my new changes I run a windows batch file made by my son to insert the project files from the git src folder into a coco virtual floppy image. It is very fast. Then I wake Vcc up and run a coco batch basic file to extract the project files and put them into the Vcc virtual drives where I try out my changes. I wrote that. It is very slow. If there are assembly errors I make the changes in notepad++ and repeat the process. It’s slower than just working in Vcc, but the advantage is I can look back at my changes. I remember when I first started studying computers we used punch cards and fan fold line printer output. We got one run a day. Like then I’m much more careful before I try my changes out. Today I put a phantom top asterisk on the screen. It isn’t actually in the file so I only needed to change the one screen routine to achieve it. I also took away the restriction on double blank lines. I noticed that the load routine crashed now. I fixed it. Then I noticed that the load routine added a blank line at the top of the fle. That gave me the most trouble. I realized I hadn’t eaten for seven hours. I ate an orange and I solved the problem in no time. I’m waiting for my cell phone to charge so I can unplug it and go to bed. It finished so that’s it for tonight.
I finally finished my urbane program. The last part was the save routine. Now I’ll debug it by using it to write my earl program. Back when the coco 2 was new this professor wrote a karl program for it. This little symbol moved around the screen picking things up and putting them down. He wrote an article about it in the Rainbow magazine. A magazine devoted to cocos. He showed how to add two distances. He said if anyone could multiply them before the next issue came out he’d give them a copy of his program. It was very fancy. That was back in the days when you saved and loaded your programs on audio cassette players. I wrote a bare bones version and figured out how to multiply distances. I typed up what karl needed to do to multiply distances. One of his assistants typed it in and made a couple of typos. Of course it didn’t work. I sent a tape in to prove that it worked. He couldn’t load it because the tape had a flaw on it. I never did send it in again. Ever since then I have been writing earl programs (karl). Easy Assembler Robot Language. Of course my name is Earl. Now you know what I’m going to be doing for a while.