Replacing Parts of Strings in C64 Basic

In an earlier part of my C64 Text Adventure series, I mentioned later versions of Commodore BASIC had a MID$= command that allowed you to replace part of a string with a new value, but C64 BASIC does not have this ability.

A few people wanted more information about this, so here it is.

C64 String Commands Recap

If you recall, the C64 has actually a nice set of string (text) related features. Read about C64 BASIC string commands over on that article but for now the most important for extracting parts of a string are:

• LEFT$ – Get the characters at the start of the string
• RIGHT$ – Get the characters at the end of the string
• MID$ – Get characters from the middle of a string

and also LEN (gets the length of the string)

Replacing Fixed-Length Strings

Part of the confusion is from my example using MID$ rather than RIGHT$ in my string-sandwich:

My original thinking was this made it flexible for working with variable-length strings, but on reflection we still have fixed positions for which character we are replacing (we swap the character at position 4 with the letter ‘X’).

That’s the problem with the C64 not having a REPLACE or even an INSTR function like many other dialects of BASIC. INSTR (or functions like it) will search for a string within another string, and return the character position. This would allow you to look for the character ‘D’ and use that number to figure out where to start and end the replacement.

For situations as in our text adventure where our strings reference room connections (with two digits each for North, East, South, West, Up and Down), we would have duplication in the strings. We couldn’t replace ’00’ with ’04’ as in many cases that would make multiple exits change to point to that room.

Fixed-Length Data Makes Everything Easier?

There’s a good reason why fixed-length data fields were used for years in early critical systems

If the string is fixed length with fixed width strings within it, the math becomes easier and the code is quicker to run. There’s a good reason why for a long time fixed width data fields were the norm in critical systems.

Thinking more about this, a more reusable subroutine might be something like the following, you just need to know the total width of your record (12 characters), the field width (2 characters in this case), and where in the record the field starts (4):

Replacing part of a fixed-length string

Alternatives to String Manipulation

Rather than using strings and messing around with characters within those strings, for my exits data I could use a multi-dimension array instead:

Why don’t I? Let’s look at the pros and cons, based on my assumptions:

Pros

• Much faster for lookups and comparisons.
• Easier for logic and changes.
• No string garbage collection or manipulation overhead.
• Cleaner to display exits or move the player between rooms programmatically.

Cons

• Slightly more memory per entry (each number is stored as 5 bytes internally).
• Less compact and more complicated to save/load from file in plain text form.
• More complex if the room connections end up stored in DATA statements.

Conclusion (Not Concluded)

Maybe I should refactor the code to use a multi-dimensioned array, or at least test it, but right now I have a working game engine plus I am now working on a map editor and exporting the rooms from that tool. If I change now, even if the approach is better, that sets me back and down a rabbit hole I might never escape from!