As in, “Go fix your null modem cable so you can upload it.”
The Diamond calculator is in working order with very few crashes. I really thought that I would get a few more blog entries posted before it was done. The unseen logic ended up being easier to create then the graphics.
I got in the groove and I just couldn't stop. You know the programming groove, that zen state where you become one with the computer; where you become some cyborgion entity, where the program flows from your fingertips to the keyboard faster then a 300 baud data transmission. Come on, we've all been there./?
Up until now I was doing a good job at keeping everything neat and tidy. Even putting REMark statements on almost ever line. Now, I'll never remember what I was thinking.
Early on I decided to use Reverse Polish Notation for entry procedures. This is were you input the first number, press enter to move it into the register(or stack), input the second number, and then press the key for the operation. Once I was able to get the two numbers into the computer it would have been a good place to stop for a blog entry....but I didn't.
Then it happened, the first operation (addition) got coded. The first truly meaningful number was on the screen. And it happened without REMark statements and the code started jumping from subroutine to subroutine like some C code gone mad. This would have been a good time to stop for a blog entry....but I didn't.
Then the subtraction, multiplication and division functions were in. What if you wanted to input a negative number? Programmed. What if you entered the wrong number? Programmed. What if you wanted to reset the registers to 0? Hit the enter key twice and forget about programming a clear key. This would have been a good time to stop for a blog entry....but I didn't.
Beta Testing – need I say more. There were a few problems, most got solved. Divide by 0 is a no-no. The number of charters in a string variable can't exceed its length and so on and so on. The only one I know that still exists is when the number is to large. I was going to SYSDRAW a message of “number to large – buy a calculator” but just decided to let the program crash. This would have been a good time to stop for a blog entry....but I didn't.
Speed was a problem and something had to be done. The calculator functions was not the hold up, it was the 44 seconds that it took to set up the screen. Early on the antic chip was turned off resulting in a 27 second wait. Maybe the Variable Name Table was over populated with unused variables. I removed all but 5 Diamond function definitions used in the program and LISTed it to disk, cleared memory, and then ENTERed the program back in. 22 seconds still seem like a long time. Removing most of the REM statements and turning off Antic at the earliest possible moment and moving the routine to populate the ICON$ string from DATA statements to the beginning of the program got me below 17 seconds(but not by much). This would have been a good time to stop for a blog entry...but I didn't.
I didn't want to admit that building the Icon bit map data from DATA statements into strings was the problem. I wanted to keep from using control characters that are hard to display and type in. Converting the numbers into control and inverse characters for the ICON$ was something to avoid, so I LISTed the data lines to a file and then ENTERed back after issuing a NEW command. Then a program was written to print the lines onto the screen, five lines at a time. Then pressing return on each line to add them to the program. 10 X=xx:Y==yy:ICON$=”fill in the string”:GOSUB “install the icon”. Once there was a line for each icon, those program lines were LISTed to disk, the dCalc program was LOADed and the new lines were ENTERed from the file. Got rid of the old DATA statements and its down to a reasonable 5 seconds. This would be a good time for a blog entry.....but maybe I should fix my null modem setup.