Category: CoCo

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.