Charging by the Byte

Originally published on: Wed, 27 Jan 2010 00:47:12 +0000

In my college days in the mid-80's, my computers of choice were the Commodore 64 and Commodore 128. During this time, I was an active member of the local C-64 Bulletin-Board System (BBS) community.

One evening, I received a private e-mail asking if I was up for some paid consulting work for the C-64. I didn't know the gentleman who asked, but he was a friend-of-a-friend, so I agreed to take a look at the problem. I'm afraid I can't remember the requestor's name, so I'll just refer to him as "Mr. X".

Mr. X was a pharmacist who had built some sort of system in C-64 BASIC that helped him at his job. He had built a small database of sorts using RELative files to hold the data. To speed up the code a bit, he used a machine-language BASIC extension library from an Abacus book. This enhanced BASIC library intercepted the routines that process BASIC, wedged in some new commands, and made some alterations to some existing commands.

His BASIC code ran better with the extensions that dealt with RELative files as they provided a verb to read in data by record-number directly into a string. The syntax was something like: READ@ s$, file, rec

Where file was the open file-number and rec was the desired record-number.

To enhance his program even further, he tried to compile the code using Blitz! from Skyles Electric Works.

Blitz! worked just fine at speeding up most of his code, even most of the extensions from the Abacus library. However, it refused to compile any line that contained the READ@ command.

Mr. X offered me the princely sum of $20 to fix things so that he could Blitz! his program with the BASIC wedge. I agreed. The $20 would have been nice alone, but the challenge was something I couldn't resist.

He transferred the files to me using the ubiquitous Punter protocol. I immediately went to work. I used a different BASIC compiler and received the same error that Blitz! had yielded for him.

C-64 BASIC compilers like Blitz! tried to allow for extensions to the BASIC language. If these compilers encountered BASIC tokens that they didn't recognize as being syntactically correct, they often just passed the text directly into the regular interpreter. This technique worked for most situations. However, the BASIC language already had a token for a verb called READ.

The READ verb is used in BASIC to copy data from DATA statements into variables. Both of the compilers we were using had assumed that we were trying to use the normal READ verb, not realizing that the Abacus wedge was doing a little bit of looking ahead in the input stream to see if the token for the @ symbol followed the READ token.

As far as the compilers were concerned, the line of code with READ@ was in error as the @ symbol had no meaning when following READ in regular BASIC.

My solution?

Well, I didn't have the Abacus book, but I had the ML code in a traditional READ/POKE loop in the BASIC code. I disassembled the ML code with an ML monitor ( Bill Yee's Micromon was my favorite ) and began to see if I could determine where the code was checking for the READ token. I found the two tokens READ and @ next to each other in a little table.

I changed the positions of each token in the DATA statement and changed the code to observe the new format for the enhanced READ verb so that the command had to be issued in this manner: @READ s$, file, rec

Note the @ symbol appearing first. Since the @ symbol was not a valid way to begin any BASIC statement, my BASIC compiler passed this text directly on to the BASIC interpreter which was wedged with the Abacus extension library. Everything ran correctly.

I e-mailed Mr. X and described how to swap the two ML numbers in his code and also informed him that he'd need to change the READ@ to @READ. I was fairly certain that this would also work with Blitz!

I got an e-mail back indicating that the changes allowed him to compile his code. He brought over the $20 while I wasn't home, so I never got to meet him face-to-face.

As I was thinking about the $20 I thought about the items that I had to change. Really, the heart of the change was just swapping two bytes in the ML library. $10 per byte! ( Yeah, I know I had to change the BASIC code, too, but I didn't count that. The ML code was really the significant piece that needed to be fixed. )

I sometimes look at compiled code I've written in my professional career and marvel at how financially-well off I'd be if I could be paid $10 per byte for each EXE file. ;-)

Unless otherwise noted, all code and text entries are Copyright ©2010 by James K. Lawless

Save to StumbleUpon
Digg it
Save to Reddit
Share on Facebook
Share on Twitter
More bookmarks