Welcome to another exciting installment of text word wrapping in Color BASIC! This time, I will share another word wrap submission, then compare all four versions in speed and code size.

Be sure to check out part 1, part 2, and part 3.

I originally shared some BASIC code I was writing to do word wrapping of text. My program needed to run on 32, 40 or 80 columns on the CoCo, and I did not want to hard code versions of every screen for each screen width.

CoCo/MC-10 BASIC wiz Jim Gerrie passed along his three-line version, and now CoCoSDC designer Darren Atkinson shares some more tweaks. He writes:

Hi Allen,

Here is a submission for your Word Wrap article. It’s not my own design. I just took the liberty of making a couple changes to Jim Gerrie’s code:

1. It will now use the last column in a line.
2. It runs a bit faster.

By focusing on speed, the trade-off is somewhat larger code size and the allocation of a few more variables.

– Darren

His update looks like this:

0 CLEAR200:DIMCC,VP,C1,LN,SP:GOTO10
1 C1=1:CC=WD+2:VP=VARPTR(M$):VP=PEEK(VP+2)*256+PEEK(VP+3)-1:LN=LEN(M$)-1:SP=32
2 CC=CC-1:IFCC<LN ANDPEEK(VP+CC)<>SP ANDCC>C1 THEN2ELSEC2=CC-C1:IFCC=C1 THENC2=WD:CC=C1+WD-1
3 PRINTMID$(M$,C1,C2);:C1=CC+1:CC=C1+WD:IFC2<>WD ORLN+1<WD THENPRINT
4 IFC1<LN THEN2ELSERETURN
10 CLS
30 INPUT"SCREEN WIDTH [32]";WD
40 IF WD=0 THEN WD=32
50 INPUT"UPPERCASE ([0]=NO, 1=YES)";UC
60 TIMER=0:TM=TIMER
70 PRINT "SHORT STRING:"
80 M$="This should not need to wrap.":GOSUB 1
90 PRINT "LONG STRING:"
100 M$="This is a string we want to word wrap. I wonder if I can make something that will wrap like I think it should?":GOSUB 1
110 PRINT "WORD > WIDTH:"
120 M$="123456789012345678901234567890123 THAT WAS TOO LONG TO FIT BUT THIS IS EVEN LONGER ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890ABCDEFGHIJKLMNOPQRSTUVWXYZ1234 SO THERE.":GOSUB 1
130 PRINT"TIME TAKEN:"TIMER-TM
140 END

Hi version is four lines of actual code (1-4) and uses a few more variables. He is using a technique I had not seen before. Rather than check characters using MID$(), he gets the address of the string using VARPTR() and then PEEKs memory. I will have to benchmark this and see the time differences. His version clocks in with a count of 192.

Let’s see how all four versions stack up, from fastest to slowest.

1. My version 2 (LEFT$/RIGHT$): 107
2. My version 1 (MID$): 114
3. Darren Atkinson’s four line version: 192
4. Jim Gerrie’s three line 3rd version: 248

That takes care of speed, but what about memory usage? In order to do a true apples-to-apples comparison, I need to alter my versions so they use the same starting line number at Jim’s and Darren’s. Jim moves subroutines to the start of the program so they are found quicker. He also numbered by 1 as a space-spacing step (GOSUB1 takes three bytes less than GOSUB1000). Since my versions are too long to fit before the start of the test code at line 10, I am going to make the test code start at 100, and GOSUB to line 1 for the word wrap routine. The new test program will look like this:

100 CLS
110 INPUT"SCREEN WIDTH [32]";WD
120 IF WD=0 THEN WD=32
130 INPUT"UPPERCASE ([0]=NO, 1=YES)";UC
140 TIMER=0:TM=TIMER
150 PRINT "SHORT STRING:"
160 A$="THIS SHOULD NOT NEED TO WRAP.":GOSUB 1
170 PRINT "LONG STRING:"
180 A$="This is a string we want to word wrap. I wonder if I can make something that will wrap like I think it should?":GOSUB 1
190 PRINT "WORD > WIDTH:"
200 A$="123456789012345678901234567890123 THAT WAS TOO LONG TO FIT BUT THIS IS EVEN LONGER ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890ABCDEFGHIJKLMNOPQRSTUVWXYZ1234 SO THERE.":GOSUB 1
210 PRINT"TIME TAKEN:"TIMER-TM
220 END

Line 0 will have any needed CLEAR command (for extra string space), and could use DIM to pre-declare any variables used later. Then it should GOTO 100 to start the test routine. The word wrap routine will start at line 1.

Jim provided me with an existing routine he had, so he altered the test program to use M$ for the message to wrap. In order to keep all cases the same, I have changed Jim’s (and Darren’s) test programs to use A$. Now all four word wrap routines will be as similar as possible.

I also removed the DIMs for now, since I wanted everything in the .BAS file to be the same except for the word wrap routine.

My version 1 (LEFT$/RIGHT$):

1 REM WORD WRAP V1
2 '
3 'IN : A$=MESSAGE
4 ' UC=1 UPPERCASE
5 ' WD=SCREEN WIDTH
6 'OUT: LN=LINES PRINTED
7 'MOD: ZS, ZE, ZC
8 '
9 LN=1
10 IF A$="" THEN PRINT:RETURN ELSE ZS=1
11 IF UC>0 THEN FOR ZC=1 TO LEN(A$):ZC=ASC(MID$(A$,ZC,1)):IF ZC<96 THEN NEXT ELSE MID$(A$,ZC,1)=CHR$(ZC-32):NEXT
12 ZE=LEN(A$)
13 IF ZE-ZS+1<=WD THEN PRINT MID$(A$,ZS,ZE-ZS+1);:IF ZE-ZS+1<WD THEN PRINT:RETURN
14 FOR ZE=ZS+WD TO ZS STEP-1:IF MID$(A$,ZE,1)<>" " THEN NEXT:ZC=0 ELSE ZE=ZE-1:ZC=1
15 IF ZE<ZS THEN ZE=ZS+WD-1
16 PRINT MID$(A$,ZS,ZE-ZS+1);
17 IF ZE-ZS+1<WD THEN PRINT
18 LN=LN+1
19 ZS=ZE+1+ZC
20 GOTO 12

My version 2 (MID$):

1 REM WORD WRAP V2
2 '
3 'IN : A$=MESSAGE
4 ' UC=1 UPPERCASE
5 ' WD=SCREEN WIDTH
6 'OUT: LN=LINES PRINTED
7 'MOD: ZC, ZE, ZS
8 '
9 LN=1
10 IF A$="" THEN PRINT:RETURN
11 IF UC>0 THEN FOR ZS=1 TO LEN(A$):ZC=ASC(MID$(A$,ZS,1)):IF ZC<96 THEN NEXT ELSE MID$(A$,ZS,1)=CHR$(ZC-32):NEXT
12 ZE=LEN(A$)
13 IF ZE<=WD THEN PRINT A$;:IF ZE<WD THEN PRINT:RETURN
14 FOR ZE=WD+1 TO 1 STEP-1:IF MID$(A$,ZE,1)<>" " THEN NEXT:ZP=0 ELSE ZE=ZE-1:ZP=1
15 IF ZE=0 THEN ZE=WD
16 PRINT LEFT$(A$,ZE);
17 IF ZE<WD THEN PRINT
18 LN=LN+1
19 A$=RIGHT$(A$,LEN(A$)-ZE-ZP)
20 GOTO 12

Jim Gerrie’s three line version:

1 C1=1:CC=WD+1
2 CC=CC-1:ON-(MID$(A$,CC,1)<>""ANDMID$(A$,CC,1)<>" "ANDCC>C1)GOTO2:C2=CC-C1:IFCC=C1 THENC2=31:CC=C1+WD-2
3 PRINTMID$(A$,C1,C2):C1=CC+1:CC=C1+WD:ON-(C1<=LEN(A$))GOTO2:RETURN

Darren Atkinson’s four line version:

1 C1=1:CC=WD+2:VP=VARPTR(A$):VP=PEEK(VP+2)*256+PEEK(VP+3)-1:LN=LEN(A$)-1:SP=32
2 CC=CC-1:IFCC<LN ANDPEEK(VP+CC)<>SP ANDCC>C1 THEN2ELSEC2=CC-C1:IFCC=C1 THENC2=WD:CC=C1+WD-1
3 PRINTMID$(A$,C1,C2);:C1=CC+1:CC=C1+WD:IFC2<>WD ORLN+1<WD THENPRINT
4 IFC1<LN THEN2ELSERETURN

To determine program size, I will PRINT MEM before loading,and then load the full test program and delete line 0 (the CLEAR/GOTO) and anything past 100 (the test program). I will print MEM again and subtract.

Here they are again, from smallest code size to largest:

1. Jim Gerrie’s three line version: 176 bytes
2. Darren Atkinson’s four line version:  236 bytes
3. My version 2 (LEFT$/RIGHT$): 500 bytes
4. My version 1 (MID$): 542 bytes

Now the order is nearly reversed, with Jim’s and Darren’s versions substantially smaller than my versions. But, my version has those big REM statements and plenty of spaces and lines that could be combined. Mine also returns the number of lines printed (LN) and has the code for uppercase conversion and a check at the start to make sure we aren’t passed an empty string. If an empty string is passed to Jim’s, it gives “?FC ERROR IN 2”. Darren’s just returns. I will have to inspect his code and see if that was intentional. I should probably add an empty string to the test case.

I will remove the uppercase (UC) and line count (LN) code from mine, and try to pack things together. I want to keep the empty string check since error checking is good and since it seems Darren’s does this.

My optimized version 1 (MID$) now looks like this:

1 IFA$=""THENPRINT:RETURNELSEZS=1
2 ZE=LEN(A$):IFZE-ZS+1<=WD THENPRINTMID$(A$,ZS,ZE-ZS+1);:IFZE-ZS+1<WD THENPRINT:RETURN
3 FORZE=ZS+WD TOZS STEP-1:IFMID$(A$,ZE,1)<>" "THENNEXT:ZC=0ELSEZE=ZE-1:ZC=1
4 IFZE<ZS THENZE=ZS+WD-1
5 PRINTMID$(A$,ZS,ZE-ZS+1);:IFZE-ZS+1<WD THENPRINT
6 ZS=ZE+1+ZC:GOTO2

My optimized version 2 (LEFT$/RIGHT$) now looks like this:

1 IFA$=""THENPRINT:RETURN
2 ZE=LEN(A$):IFZE<=WD THENPRINTA$;:IFZE<WD THENPRINT:RETURN
3 FORZE=WD+1TO1STEP-1:IFMID$(A$,ZE,1)<>" "THENNEXT:ZP=0ELSEZE=ZE-1:ZP=1
4 IFZE=0THENZE=WD
5 PRINTLEFT$(A$,ZE);:IF ZE<WD THENPRINT
6 A$=RIGHT$(A$,LEN(A$)-ZE-ZP):GOTO2

Now let’s see how things stack up.

• My version 1 (MID$): size 240 bytes / speed 107
• My version 2 (LEFT$/RIGHT$): size 199 bytes / speed 99

Wow. By removing extra functionality, REMs, removing spaces, and packing lines together, I went from 542 to 240 for version 1, and from 500 to 199 in the second version. For speed, version went from 114 to 107, and version 2 went from 107 to 99.

…but I should point out that, with the default 200 bytes reserved to variables in BASIC, my second version crashed with an “?OS ERROR” (out of string space). I had to CLEAR255 to make it work. The actual number has to be large enough to hold the biggest string being passed in, plus the overhead for the string manipulation using LEFT$/RIGHT$. To really know how much memory a BASIC program takes up, we really do need to consider its variable usage.

And now the new rankings for code size (smallest to largest):

1. Jim Gerrie’s three line 3rd version: 176 bytes
2. My version 2 (LEFT$/RIGHT$): 199* bytes (see note below)
3. Darren Atkinson’s four line version: 236 bytes
4. My version 1 (MID$): 240 bytes

…and for speed:

1. My version 2 (LEFT$/RIGHT$): 99 (was 107)
2. My version 1 (MID$): 107 (was 114)
3. Darren Atkinson’s four line version: 192
4. Jim Gerrie’s three line 3rd version: 248

NOTE: Since my version 2 required me to do a CLEAR255 for it to run, that means it actually took up 254 bytes (code, plus the extra 55 bytes allocated past the default 200 for variables).

It is tricky to calculate variable usage since the sizes of strings passed in will be a factor, and maybe it would have ran with CLEAR 210 or CLEAR 220 to save a bit more. To crash-proof a program, you need to ensure CLEAR is done to cover the maximum size of string usage in the worst case. Here, we’re not that concerned.

In conclusion, right now if ever byte of program space matters (such as Jim’s case when programming in 4K), his is best. For overall speed, my version 2 is best (but it uses the most memory between code and variable storage). Even my version 1 (with no extra string space required is still faster than the next fastest.

Can we do better? Can you do better? Let’s find out.

I will make a .DSK image (that works in the XRoar emulator, and should be loadable via CoCoSDC on a real CoCo) as soon as I figure out how to post one in WordPress.

To be continued… Probably…

1. 2015/1/5 Update: Jim’s v3 code has been fixed.

In the “CoCo Community”, Jim Gerrie is well-known for his prolific BASIC programs. He and his son have cranked out an endless assortment of games over the years for both the Radio Shack Color Computer and the MC-10. Since the MC-10 also started out as a 4K computer, he has long been since writing programs to fit in such little memory. He is the first one to submit programs to the 1980 4K CoCo Programming Challenge I am hosting.

After he saw my word wrap article and its follow-up with updated code, he was kind enough to share a simple word wrap routine that he uses. His looks like this:

...
1 C1=1:CC=WD
2 FORCC=CC TOC1+2STEP-1:IFMID$(M$,CC,1)<>""ANDMID$(M$,CC,1)<>" "THENNEXT
3 PRINTMID$(M$,C1,CC-C1):C1=CC+1:CC=C1+(WD-1):IFC1<=LEN(M$)THEN2
4 RETURN
...

FOUR lines compressed of code. Since he works with low-memory BASIC so often, he demonstrates plenty of the optimizing techniques I mentioned earlier and some I didn’t mention. Not only does he number his program by 1s, he also places the subroutine at the start of the program. Every time you GOTO or GOSUB, Color BASIC will either search forward (if the line number you are going to is higher than the one you are currently on), or start at the TOP of your program and search forward. This means if you had something like this:

100 REM A REALLY BIG PROGRAM
...
150 GOSUB 1000
...
995 END
1000 REM MY SUBROUTINE
1010 PRINT "HELLO!"
1020 RETURN

…when you called “GOSUB 1000” from line 150, BASIC would then have to scan forward until it finds line 1000. If you have hundreds of lines of BASIC code, this is a big waste of CPU time.

However, if you placed that routine at the start of the program (and had a line at the beginning to jump past it), every time you called the routine it would find it much quicker:

19 GOTO 100
20 REM MY SUBROUTINE
30 PRINT "HELLO!"
40 RETURN
100 REM A REALLY BIG PROGRAM
...
150 GOSUB 20
...
995 END

Keep in mind, there are always tradeoffs. GOTO works the same way, and ant complex BASIC program is usually full of GOTOs. Every GOTO has to do the same scanning (forward, or starting at the top) to find the routine. This means each GOTO to an earlier line number now has to scan past all your subroutine lines every time you GOTO. For the fastest code, you need to take in to consideration what happens more often — GOSUBing to functions, or GOTOs to higher line numbers.

As to how significant the time savings can be, I plan to write another article in the near future with some simple benchmarks.

Here is Jim’s complete program, which uses my WRAPTEST code to process the same strings:

0 CLEAR200:DIMC1,CC,M$:GOTO10
1 C1=1:CC=WD
2 FORCC=CC TOC1+2STEP-1:IFMID$(M$,CC,1)<>""ANDMID$(M$,CC,1)<>" "THENNEXT
3 PRINTMID$(M$,C1,CC-C1):C1=CC+1:CC=C1+(WD-1):IFC1<=LEN(M$)THEN2
4 RETURN
10 CLS
30 INPUT"SCREEN WIDTH [32]";WD
40 IF WD=0 THEN WD=32
50 INPUT"UPPERCASE ([0]=NO, 1=YES)";UC
60 TIMER=0:TM=TIMER
70 PRINT "SHORT STRING:"
80 M$="This should not need to wrap.":GOSUB 1
90 PRINT "LONG STRING:"
100 M$="This is a string we want to word wrap. I wonder if I can make something that will wrap like I think it should?":GOSUB 1
110 PRINT "WORD > WIDTH:"
120 M$="123456789012345678901234567890123 THAT WAS TOO LONG TO FIT BUT THIS IS EVEN LONGER ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890ABCDEFGHIJKLMNOPQRSTUVWXYZ1234 SO THERE.":GOSUB 1
130 PRINT"TIME TAKEN:"TIMER-TM
140 END

His routine is small and fast. It does not implement UC uppercase conversion, does not use the last character of the line, and has issues with words longer than the line length — but just look at the code size and speed savings! This is a great, efficient approach when you can control the output. As long as you aren’t displaying “supercalifragilisticexpialidocious” it works great.

However, Jim seems up to the challenge, and he made some small changes to allow his wrap routine to handle words longer than the screen width. Again, just four lines of code:

0 CLS:CLEAR255:DIMCC,C1,C2,M$:GOTO10
1 C1=1:CC=WD+1
2 CC=CC-1:ON-(MID$(M$,CC,1)<>""ANDMID$(M$,CC,1)<>" "ANDCC>C1)GOTO2:C2=CC-C1:IFCC=C1 THENC2=31:CC=C1+WD-2
3 PRINTMID$(M$,C1,C2):C1=CC+1:CC=C1+WD:ON-(C1<=LEN(M$))GOTO2:RETURN
10 CLS
30 INPUT"SCREEN WIDTH [32]";WD
40 IF WD=0 THEN WD=32
50 INPUT"UPPERCASE ([0]=NO, 1=YES)";UC
60 TIMER=0:TM=TIMER
70 PRINT "SHORT STRING:"
80 M$="This should not need to wrap.":GOSUB 1
90 PRINT "LONG STRING:"
100 M$="This is a string we want to word wrap. I wonder if I can make something that will wrap like I think it should?":GOSUB 1
110 PRINT "WORD > WIDTH:"
120 M$="123456789012345678901234567890123 THAT WAS TOO LONG TO FIT BUT THIS IS EVEN LONGER "
121 M$=M$+"ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890ABCDEFGHIJKLMNOPQRSTUVWXYZ1234 SO THERE.":GOSUB 1
130 PRINT"TIME TAKEN:"TIMER-TM
140 END

His new version, while still not using the last character of a line, now will break up words like supercalifragilisticexpialidocious. Because, you know, you have words like that in your text adventures all the time. And speaking of text adventures, he sent in this link to an archive of text adventures including many Jim (and his son) wrote. For many years he was using his original word wrap routine just fine (since he controlled the output) so all his additions are really just un-needed hoops to jump through for my abusing text case :)

Thanks, Jim, for sharing this with us! If anyone else wants to take a shot at it, feel free to send me a .DSK or .CAS image of your version. I have been using the XRoar emulator to do this testing (and take screen shots) on my Mac, and XRoar is also available for Windows, Linux and other systems.

Until next time, I hope things will be…

OK

…with you!

See also: part 1, part 2, part 3, part 4, part 5, part 6, part 7, part 8 and part 9.

A recent post by Art “ADOS” Flexser on the CoCo mailing list mentioned a few commercial programs for the Radio Shack Color Computer that were designed to optimize BASIC programs:

On Jan 2, 2015, at 12:26 AM, Arthur Flexser wrote:

A little googling identified the utility I was referring to as “The Stripper” from Eigen Systems. Apparently, there was also a similar program by Bob van der Poel called “Packer”. Maybe one or the other is available online someplace.

These should be useful for those finding tight memory for Basic programs in
the 4K contest.

The 4K contest he mentions is a programming challenge I recently organized to see what someone could do if they had the original 1980 4K Color Computer. You can read about it here:

http://www.cocopedia.com/wiki/index.php/1980_4K_CoCo_Programming_Challenge

In addition to the programs Art mentioned, I also had one given to me by Carl England. I used it on one of my programs at Sub-Etha Software. I do not know how it compares with The Stripper or Packer, but beyond true optimization of the code, it did about all you could do. Here are the tricks he used which produce the smallest and fastest version of a BASIC program, but they usually rendered it un-editable and hard to read.

NOTE: Code can be written for size or speed. Carl’s program optimized for size which in some cases made it faster since BASIC had less to parse, but as you will see, some optimizations might increase execution time making it slower. Maybe.

Remove all spaces

The less bytes to parse, the smaller and faster it will run. It has to be smart enough to know when spaces are required, such as “FORA=1TOQ STEP1” when a variable needs a space after it before another keyword.

Pack/combine lines where possible.

Any line called by a GOTO had to remain at the start, by following lines would be combined up to the max size of a BASIC line. Only when it had to be broken by logic (ELSE, etc.) would it not be combined. For example:

10 FOR I=1 TO 100
20 GOSUB 50
30 NEXT I
40 END
50 REM PRINT SOMETHING
60 PRINT "HELLO WORLD!"
70 RETURN

…would end up as:

10 FORI=1TO100:GOSUB60:NEXTI:END
60 PRINT"HELLO WORLD!":RETURN

Remove all REMs.

Obvious. I *think* his program would adjust a GOTO/GOSUB that went to a REM line to go to the next line after it, and remove the REM:

10 GOSUB 1000
20 END
1000 REM PRINT SOMETHING
1010 PRINT "HELLO"
1020 RETURN

…would become like:

10 GOSUB1010:END
1010 PRINT"HELLO":RETURN

NOTE: Even without packing, I learned not to GOTO or GOSUB to a REM since it required the interpreter to parse through the line. I would GO to the first line of code after the REM:

10 GOSUB 1010
...
1000 REM MY ROUTINE
1010 PRINT "HERE IS WHERE IT STARTS"
...

Every thing you do like that saves a bit of parsing time since it doesn’t have to start parsing 1000 and look up a token then realize it can ignore the rest of the line.

Not bad so far

But that’s not all!

The BASIC input buffer is some maximum number of bytes (250?). When you type a line to max, it stops you from typing more. When you hit ENTER, it is tokenized and could be much smaller. For instance, “PRINT” turns in to a one-byte token instead of the five characters. Carl’s program would combine and pack the tokens up to the max line size. Thus, it created lines that BASIC could run which were IMPOSSIBLE to enter on the keyboard. If I recall, you could LIST and they would print (?) but if you did an EDIT you were done.

Renumber by 1.

GOSUB2000 would take up one bye for the token, then four bytes for the line number. If you renumber by 1s, it might make that function be GOSUB582 and save a byte. Multiply that by every use of GOTO/GOSUB/ON GOTO/etc. and you save a bit.

Even without one of these compressors, try a before/after just doing a RENUM 1,1,1. I recently posted an article with a short (27 line) word wrap routine in BASIC. Doing this renum saved 7 bytes.

Removing NEXT variables.

I am not sure if this is just something I knew, or if his program also did it. If you use FOR/NEXT and it is used normally, you don’t need the NEXT variables like this:

10 FOR D=0 TO 3 'DRIVES
20 FOR T=0 TO 34 'TRACKS
30 FOR S=1 TO 18 'SECTORS
40 DSKI$ D,T,S,S1$,S2$
50 NEXT S
60 NEXT T
70 NEXT D

The NEXTs could also be

50 NEXT S,T,D

Or

50 NEXT:NEXT:NEXT

Ignoring spaces, “NEXT:NEXT:NEXT” takes up one less byte than “NEXTS,T,D” (NEXT is turned in to a token, so it is TOKEN COLON TOKEN COLON TOKEN versus TOKEN BYTEVAR COMMA BYTEVAR COMMA BYTEBAR”.

This takes up less memory, but there is a speed difference:

10 T=TIMER
20 FOR I=1 TO 10000
30 REM DO NOTHING
40 NEXT I
50 PRINT TIMER-T

Run this and it shows something in the 1181 range (speed varies based on other things BASIC does; pound on keys while it runs and it takes more time, for example). Change the “NEXT I” to “NEXT” and it shows something in the range of 1025. The more FOR variables, the more the savings, too.

10 TM=TIMER
20 FOR D=0 TO 3
30 FOR T=0 TO 34
40 FOR S=1 TO 18
50 REM DO SOMETHING
60 NEXT S
70 NEXT T
80 NEXT D
90 PRINT TIMER-TM

…shows around 345. Changing it to:

60 NEXTS,T,D

…changes it to around 336 – slightly smaller and faster since it is not parsing three different lines.

60 NEXT:NEXT:NEXT

…changes it to around 293! One byte smaller and slightly faster.

AND THERE’S MORE! But this post is already too long.

What I think would be cool is an actual BASIC OPTIMIZER that could do some smart things to programs, much like we do with the C language optimizers for asm and C. For example, noticing stupid things:

A$ = B$+"."+"."+C$

to

A$ = B$+".."+C$

And removing NEXT variables, or doing minor restructuring based on what it knows about the interpreter.

I suppose, back in the 80s, processors were so slow and memory so limited that doing such an optimizer might not be practical. But today, imagine how you could optimize a .BAS file on a modern computer (just like we have 6809 cross-hosted compilers that compile and link in the link of an eye).

Maybe this has already been done for some other flavor of BASIC? Hmmm. I may have to do some Googling.

• 2015/1/4 Update: After reading this, you can check out the next installment, too.
• 2015/1/5 Update: The BASIC listings should be fixed now.

In a recent article, I demonstrated a simple way to do a word wrap output routine in Extended Color BASIC on a Radio Shack Color Computer. When I went to try to use the routine, I found a few issues with it that I would like to address here.

My first version was able to word wrap all the way to the last character on a line, but I failed to test against a string that was longer than the screen width (with no spaces in it). This would only happen if you had a very long word on a very narrow screen (supercalifragilisticexpialidocious would be a word too long to fit on a 32-column CoCo screen, for example). I fixed this issue, and also optimized the routine to handle short strings better by checking for them at the start instead of the end.

I now have three test cases to check for: short strings that do not need to wrap, long strings that do need to wrap (with a word ending on the final 32nd column), and strings with word(s) longer than the screen width.

The first version I presented tried to avoid using any additional strings. Simply doing something like A$=A$+”BACON” causes a new larger string buffer to be allocated, the original data copied over, new data appended, and original string assigned to it and the old one released. I wanted to avoid that, so my routine worked just by printing out sections of the original string.

The end result was a routing that worked, but due to the nature of BASIC, was quite slow. Text did not just appear – it paused a bit before printing each line. In my test program, this was a bit annoying, so I decided to see if I could make it a bit faster.

While it’s true that the CPU overhead of doing string manipulation is significant, much more CPU time is spent processing tokenized BASIC. If you could save some BASIC time by doing string manipulation, you should come out ahead with a faster problem.

First, here is the test I am using for both my word wrap routines:

10 CLEAR200
20 CLS
30 INPUT"SCREEN WIDTH [32]";WD
40 IF WD=0 THEN WD=32
50 INPUT"UPPERCASE ([0]=NO, 1=YES)";UC
60 TIMER=0:TM=TIMER
70 PRINT "SHORT STRING:"
80 A$="This should not need to wrap.":GOSUB 1000
90 PRINT "LONG STRING:"
100 A$="This is a string we want to word wrap. I wonder if I can make something that will wrap like I think it should?":GOSUB 1000
110 PRINT "WORD > WIDTH:"
120 A$="123456789012345678901234567890123 THAT WAS TOO LONG TO FIT BUT THIS IS EVEN LONGER ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890ABCDEFGHIJKLMNOPQRSTUVWXYZ1234 SO THERE.":GOSUB 1000
130 PRINT"TIME TAKEN:"TIMER-TM
140 END

And this is the updated original word wrap routine that does not allocate any extra strings. I have also renamed the variables in my subroutines, starting all the temporary variables with Z (ZS for start of string, ZE for end of string, etc.). I did this to avoid conflicts with my larger program.

1000 REM WORD WRAP V1
1010 '
1020 'IN : A$=MESSAGE
1030 ' UC=1 UPPERCASE
1040 ' WD=SCREEN WIDTH
1050 'OUT: LN=LINES PRINTED
1060 'MOD: ZS, ZE, ZP
1070 '
1080 LN=1
1090 IF A$="" THEN PRINT:RETURN ELSE ZS=1
1100 IF UC>0 THEN FOR ZP=1 TO LEN(A$):ZP=ASC(MID$(A$,ZP,1)):IF ZP<96 THEN NEXT ELSE MID$(A$,ZP,1)=CHR$(ZP-32):NEXT
1110 ZE=LEN(A$)
1120 IF ZE-ZS+1<=WD THEN PRINT MID$(A$,ZS,ZE-ZS+1);:IF ZE-ZS+1<WD THEN PRINT:RETURN
1130 FOR ZE=ZS+WD TO ZS STEP-1:IF MID$(A$,ZE,1)<>" " THEN NEXT:ZP=0 ELSE ZE=ZE-1:ZP=1
1140 IF ZE<ZS THEN ZE=ZS+WD-1
1150 PRINT MID$(A$,ZS,ZE-ZS+1);
1160 IF ZE-ZS+1<WD THEN PRINT
1170 LN=LN+1
1180 ZS=ZE+1+ZP
1190 GOTO 1110

When I start up a 32K (or larger) CoCo 1/2, PRINT MEM shows 22823 bytes available (some memory is reserved for graphics screens, so there are ways to get even more memory to BASIC if you aren’t doing graphics).

After loading the program, I check memory again and determined this version took 1101 bytes.

When I run the program, it handles all the test cases as I expected, and reports that the time taken as 113 (counts of the TIMER, with each number being based on the screen interrupt – 60hz on the US machines. Is it different on PAL machines that run at 50mhz?)

This gives me an idea of large the program is and how fast it is to run.

I then took this version and converted it (keeping the lines the same as much as possible) to one that used LEFT$() and RIGHT$() to chop the input string up as it went, making the code simpler at the cost of pushing more work on the BASIC string manipulation routines. It looked like this:

1000 REM WORD WRAP V2
1010 '
1020 'IN : A$=MESSAGE
1030 ' UC=1 UPPERCASE
1040 ' WD=SCREEN WIDTH
1050 'OUT: LN=LINES PRINTED
1060 'MOD: ST, EN
1070 '
1080 LN=1
1090 IF A$="" THEN PRINT:RETURN
1100 IF UC>0 THEN FOR ST=1 TO LEN(A$):EN=ASC(MID$(A$,ST,1)):IF EN<96 THEN NEXT ELSE MID$(A$,ST,1)=CHR$(EN-32):NEXT
1110 ZE=LEN(A$)
1120 IF ZE<=WD THEN PRINT A$;:IF ZE<WD THEN PRINT:RETURN
1130 FOR ZE=WD+1 TO 1 STEP-1:IF MID$(A$,ZE,1)<>" " THEN NEXT:ZP=0 ELSE ZE=ZE-1:ZP=1
1140 IF ZE=0 THEN ZE=WD
1150 PRINT LEFT$(A$,ZE);
1160 IF ZE<WD THEN PRINT
1170 LN=LN+1
1180 A$=RIGHT$(A$,LEN(A$)-ZE-ZP)
1190 GOTO 1110

When I load this version and check memory, it gives me 1058 — 43 bytes less than the first version. This also means there will be less bytes for the interpreter to have to process so it might run faster, too.

However, when I tried to run it, the program crashed with an Out of String Space error (?OS ERROR). Even though the BASIC program was smaller, it was now needing to allocate additional/temporary strings to do things like A$=LEFT$(A$,xxx). By default, Color BASIC sets aside 200 bytes for strings, and that was not enough for this version.

To fix this, I had to change the “CLEAR 200” on line 10 to be something larger, like “CLEAR 300”. That was enough for the program to run and I saw it’s time used was around 106. This was only slightly faster than the method that did not require extra string space so it really would only be useful if you needed that teeny tiny speed improvement and had the extra memory to spare.

Now, if the extra string space required was no more than the size saved by the smaller code, it would end up being an advantage. For my program, I do not expect memory to be an issue (it will be a fairly small program) so I may very well end up optimizing as many functions as I can for speed over memory.

Speaking of optimizations, coming up soon will be some notes on easy ways you can optimize BASIC to make your program take up less memory and/or run faster.

Until then, I’ll see you at the “OK” prompt…

2015/1/2 Update: Please see my follow-up article for two improved versions of this.

Last night, I began writing a program on my 1980s Radio Shack Color Computer. I am planning on going through hundreds of old floppy diskettes and copying them to disk image files.  The program I began writing will help automate this task.

I am using a new bit of retro hardware called the CoCoSDC. It acts like a floppy drive controller, but instead of writing to round pieces of magnetic plastic, it writes that data out to disk image files on an SD card. You can learn more about CoCoSDC in another series of articles I have been writing.

CoCoSDC is a brilliant piece of design work in that it detects and adjusts for the various models of Color Computers (1, 2 or 3) it is plugged in to. I decided my program should do the same, so my goal is to have one BASIC program that could be loaded on an original 1980 Color Computer 1 or 2, using its 32 column display, or run on a 1986 Color Computer 3, using the 40 or 80 column text screen. There are a few challenges I needed to solve:

• The program should work on an original Radio Shack TRS-80 Color Computers or early model TRS-80 CoCo 2s, which had a 32 column display with uppercase character set. (On the Motorola 6847 VDG chip used by this machine, lowercase letters were represented by inverse uppercase characters.)
• The program should take advantage of the later model Tandy Color Computer 2s that had an enhanced VDG chip that could display true lowercase. This option should still be available for earlier model CoCos which may have an aftermarket lowercase kit (like my old grey CoCo 1 has).
• The program should work on a Tandy Color Computer 3, and let the user select between 32, 40 or 80 column display. This would allow it to worked hooked up to a crappy old TV display, or have nice 80 column text for users that had a good monochrome composite monitor or RGB-A color monitor.

I quickly designed and wrote a functional prototype, missing only a few features I had in mind. I started out by hard coding it to use a variable for the screen width so I could center text and and such. For example:

WD = 32
A$ = "CENTER THIS!"
PRINT TAB(WD/2-LEN(A$)/2);A$

By making that PRINT line a subroutine, I could call it anywhere I wanted to print centered text:

10 WD = 32 'SET SCREEN WIDTH
20 CLS 'CLEAR SCREEN
30 A$="IT WORKS!":GOSUB 1000
40 END
1000 REM PRINT CENTERED A$
1010 PRINT TAB(WD/2-LEN(A$)/2);A$
1020 RETURN

I also made a routine to display a horizontal row of dashes so I could use that with nicely formatted menus.

Eventually, I needed to display some verbose text to the user, and knew I would need to make a routine to handle wrapping long lines. It’s easy to hard code PRINT statements when you know your screen width, but when it can vary, we can have the program do it for us.

Earlier in 2014 I implemented such a word wrap routine in C for a Raspberry Pi program I was designing. Unfortunately, porting that code to BASIC wouldn’t be possible since it took advantage of too many C features that have no BASIC equivalents. Instead, I had to design a new one.

Also, I wanted the option to pass in strings with upper and lower case and have them converted to uppercase. The only design restriction I enforced was to try not to do any string rebuilding. Interpreted BASICs have their own type of garbage collection (like you might find in Java and other modern languages) that do all kinds of memory shifting when you add two strings together. My program could be faster if it avoided that. (Not that it really matters, but good habits learned later in my programming career are difficult to break even when I am pretending it’s 1983.)

Here is the first version I came up with:

2015/1/5 Update: Please see my next article for two improved versions of this.

10 CLS 15 INPUT"SCREEN WIDTH [32]";WD:IF WD=0 THEN WD=32
20 INPUT"UPPERCASE ([0]=NO, 1=YES)";UC
25 TM=TIMER
30 A$="This is a string we want to word wrap. I wonder if I can make something that will wrap like I think it should?":GOSUB 1000
35 PRINT"TIME TAKEN:"TIMER-TM
999 END
1000 REM WORD WRAP
1001 '
1002 'IN : A$=MESSAGE
1003 '     UC=1 UPPERCASE
1004 '     WD=SCREEN WIDTH
1005 'OUT: LN=LINES PRINTED
1006 'MOD: ST, EN
1007 '
1010 IF A$="" THEN PRINT:LN=1:RETURN
1015 IF UC>0 THEN FOR ST=1 TO LEN(A$):EN=ASC(MID$(A$,ST,1)):IF EN<96 THEN NEXT ST ELSE MID$(A$,ST,1)=CHR$(EN-32):NEXT ST
1020 LN=0:ST=1
1025 EN=LEN(A$)
1030 IF MID$(A$,ST,1)=" " AND ST<EN THEN ST=ST+1:GOTO 1030
1035 IF EN-ST>WD THEN FOR EN=ST+WD TO ST STEP-1:IF MID$(A$,EN,1)<>" " THEN NEXT EN ELSE EN=EN-1
1040 IF EN=ST THEN EN=ST+WD-1
1045 PRINT MID$(A$,ST,EN-ST+1);
1050 LN=LN+1
1055 IF EN-ST+1<WD THEN PRINT
1060 ST=EN+1:IF ST<LEN(A$) THEN 1025
1065 RETURN

Note: This is not my normal production programming style. I created this example for better readability, but in the future I will share some of the tricks we used at Sub-Etha to optimize BASIC programs to take up less memory and run faster. (They won’t be very readable…)

The subroutine at line 1000 expects the string to be in A$, the width of the display in WD, and the variable UC can be set to 1 to force the output to be in uppercase (which is slower). When it returns, LN will contain how many lines were printed. I also print out the TIMER so I can compare the speed of the routine, and see how much slower it is with uppercase conversion.

On the right are screen shots of the wrapped output with and without uppercase conversion. You can see that converting a few lines of text the way I did it took about five times longer.

There is one extra feature I should mention. One of the things that bothers me about many word-wrap routines I have seen is that they tend to ignore the final character of a line meaning that if you print a line that is exactly 40 characters long to a 40 column display, they usually wrap the last word even though it would have fit on the line. This is because, at least on all the systems I have experience with, when you print to the final character, the cursor moves to the start of the next line, then the PRINT command finishes and adds a carriage return. Here is an example of printing three 32 column lines on the CoCo:

10 CLS
20 PRINT"12345678901234567890123456789012"
30 PRINT"12345678901234567890123456789012"
40 PRINT"12345678901234567890123456789012"

You get something like this:

BASIC does not know that a line was skipped before it adds its own carriage return. You can prevent BASIC from adding a carriage return by adding a semicolon to the end of the PRINT line:

10 CLS
20 PRINT"12345678901234567890123456789012";
30 PRINT"12345678901234567890123456789012";
40 PRINT"12345678901234567890123456789012";

Most word wrap routines I have seen just don’t bother dealing with this, and never use the final character of the line. For my routine, I wanted a line that was exactly the length of the screen width to fit, so I always add the semicolon, then in line 1055 I print a carriage return if the line was shorter than the screen width (and thus BASIC didn’t already move the cursor to the next line).

Little things like this make the code bulkier than it needs to be.

Now I turn things over to you… This can be done much better. How would you implement a word wrap? And note there are several goals that would require different code:

• Code size may be most important.
• Execution speed may be most important.
• You might want to use as few variables as possible.
• You might want to avoid string manipulation.
• You might not be able to alter any variables passed in (thus, if the user passes you A$, you are not allowed to change A$).

For me, I wanted to avoid string manipulation (for speed) and use fewer variables. Without that goal, I could have done the word wrap routine easier by making a copy of the string the user passed in and manipulating the copy. This is why my uppercase conversion makes changes to the string the user passed in. If I had the goal of not modifying what the user passed in, I would have had no choice other than making a copy in another string variable.

The choice is yours. Send in your best attempt and explain your goal. Here are the requirements:

• A$ will be set to the string the user wishes to display.
• WD will be set to the screen width.
• UC will be 0 if the string is to be displayed as-is, or not 0 to convert to uppercase.
• On return, LN will be the count of how many lines were displayed.

If you need a quick and easy emulator to run it in, check out XRoar. I have tips on how to get it running over at CoCopedia:

http://www.cocopedia.com/wiki/index.php/Using_XRoar

Have fun!

P.S. This example requires Extended Color BASIC. As it turns out, while the 1980 Color BASIC supports MID$(), you cannot use it to modify a string. Thus, A$=MID$(B$,1,1) would work, but MID$(B$,1,1)=”N” would not. My first CoCo had Extended Color BASIC so I never had to live without the extra features.