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.
I hadn’t done a backup on my ed2.bas file for a while. The .basic files usually don’t change much. I now initialize the entry addresses by bouncing back and forth between the basic and machine language portions. I got very intense redoing the basic part. When I got it to work I backed it up this time. When I load my urbane program I will do a new-program routine in machine language, open the file and read lines in basic, crunch lines and put them in the urbane file in machine language, check for eof and eventually close the file in basic. I was doing the new-program routine when I started having problems. First the assembler reported an i/o error. I.wasn’t too worried yet. It does that now and then. I was still very intense. In machine language I have to switch the rom in and out to access rom routines. All at once Vcc started crashing. It never happens. I loaded the last version that worked. It still worked. The version that worked seemed to access a rom routine when the rom wasn’t switched in. It’s 1:00. I usually go to bed at 10. Maybe I should go to bed. Hmm.
When I’m jumping back into the old coco basic file I have to count the characters from the start to where I want to copy the line from the user’s urbane basic file. I used to think that I needed to start where there was a colon in the old file. When I listed the old line there would be the colon followed by the new line. I miscounted this time and copied the old line start right on top of the colon. It still worked and when I listed there was the new line right there at the start of the right after the old basic’s line number. meant to be.
I use the old basic to open the sequential file t.dat. I call a machine language routine to list the user’s file to console out. Then I use the old basic to close the file. I listed the old basic file a few times before I got the message that I needed to do that in a machine language routine. Loading the user file is going to be a harder. Console out is very strait forward. Not so console in. I plan to use a machine language routine to erase the current user file and set up the entry address for the next machine language routine. I plan to use the old basic to open the sequential file for input. Then for i=0 to -1 step 0: line input #1, l$: usr(l$) – (to pass the line to the machine language routine which will crunch it and put it at the end of the user file) : i=eof(1):next:close(1):end (which returns to direct basic. I’ve done each part separately. I just need to put them together. Sometimes easier said than done. Once I have that done I plan to show it to the world here. As though anyone will see it. lol.
Now I can take all the project files off the hard drive virtual image and put them back in. Extract.bat to get them off worked right off. Insert only worked with .bas files and then only if one used the -a option for ascii. So I copied each name.asm file to a temp.bas file. Then I inserted the temp.bas file with the original name.asm as the destination name in the floppy image. Of course I put it all into an insert.bat file. I already had the zzUbane.bat file that I had stored in the WINDOWS\system32\ folder that changed from that directory where the administrator command line starts to the \src directory where the .git files are stored. The only thing left is the readme.txt file. There were lots of programs that worked with .txt files on cocos in the old days. I suppose that I could look one up now. Better, maybe I’ll write one. lol.
Toolshed worked just fine to extract files from the floppy image. Inserting them was a different thing. .txt and .asm files caused various errors. I finally worked around it by by copying the individual files to a temporary .bas file, then inserting the temporary file into the floppy image with the old name. I managed to get around the problem of the administrator command prompt starting in a weird place where I could hardly do anything. I finally managed to copy a batch file to that place. It just changes directories to the directory I’m working in. Problem solved. Now to get back the the project itself.