Raymond Kinman is an artist. Specifically, a master woodcarver. He is also famous for his carvings that have been used at Disney theme parks. Yes, Disneyland actually uses hand carved signs!

I had no idea when I took that photo at Disneyland in 2003 that this was actually a hand carved piece. I guess I just assumed it was some fiberglass mold:

You can learn more about Mr. Kinman and see photos of some of his Disney projects at this site:

https://woodcarverguru.com

But I digress.

A.I. – Again, indeed.

Today’s topic is, once again, A.I. I have written about A.I. While I hate A.I. slop as much as anyone, I see great value in it as a tool when used by artists, musicians and other creative people. Just like a great guitar can’t make a bad guitar player sound good, a great A.I. doesn’t make a random person able to create works of art or the next Top 40 hit. (Though, since art and music tastes are subjective, it could certainly produce something you really love to see or listen to. There have been many “bad” songs that have gone to #1, and many “bad” paintings that have become legendary.)

But I digress. Again.

Here is Mr. Kinman’s Facebook group where he shares updates:

https://www.facebook.com/groups/325935821195236

And here is what he recently posted about A.I. I think this is worth a read as it comes from a master artists with 50+ years of experience.

I’m going to take on something controversial here, so if you’re interested, you’re going to have to slow down and take a minute to read this…’cuz I’d really like to hear your thoughts. I’m going to make the case for why I think using AI can actually be a very good thing for artists.

First, I’m not unaware of the downside. If you think AI is a bad thing for the world, you’re not wrong. I have a fairly decent understanding of the technology and how it works, at least from a layman’s point of view, and I can see nearly an infinite number of ways this could go wrong for humanity. Yeah, the environmental impact. All of it. There is an astonishing upside too, but I’m going to leave that argument alone for now because that’s a rabbit hole I don’t want to go down.

Instead, I want to make the case for what AI is doing FOR the arts and how this has the potential to become a very good thing for artists.

Think about what happened when photography was invented.

Before the camera, one of the primary ways an artist could make a living was painting portraits of wealthy and powerful people. If you wanted a convincing image of yourself, you needed somebody who had spent years learning how to reproduce the human face, the human body, clothing, light and texture with extraordinary accuracy. Then photography came along and suddenly a machine could do that job far faster and more accurately.

You can imagine how frightening that must have been for painters. Why would anybody pay me to spend weeks or months painting a portrait when they can have a photograph taken in minutes? This spells disaster for the artist. The end of painting.

But it wasn’t.

Something much more interesting happened. Photography freed artists from having to spend their careers proving that they could reproduce reality. Artists were suddenly free to explore what else painting could become. Van Gogh, Matisse, Picasso and countless others didn’t have to compete with the camera. They could ask entirely different questions about art. Photography didn’t kill painting. It helped liberate it.

I think AI may be doing something similar, and I want to show you what that looks like in my own work.

Stone and wood complement one another beautifully, and I had this idea I wanted to explore. I wanted to carve a translucent alabaster relief of a beautiful, tasteful female form, backlit so the stone would glow in the shallow areas, and set it inside a deeply carved wooden frame. I’ve never done any stone carving before, my work has always been in relief woodcarving.

The problem is that I don’t draw very well, and I’m certainly not an illustrator. I can sketch a little, enough to work out my ideas anyway. Everything starts there. The human touch. So I made the little sketch you see here. Then I took the idea to AI.

I asked it to help me visualize what I was imagining. I asked it to push back on my own biases and show me what I wasn’t seeing. I asked it to show me possibilities I hadn’t considered. I asked what I needed to learn about carving stone, what tools I might need, how translucent alabaster behaves with light, and what might actually be possible.

In other words, I asked it to help me see. And it does this astonishingly well.

The second image is not the sculpture. It isn’t even the finished design. It’s a working model of an idea. That distinction is super important to me. Now I have something I can look at, question, change and develop. I can take this model to a real illustrator and have a human being refine it into a workable design. Then I can take that design into my shop and carve the actual sculpture entirely by hand. I’ll be the one holding the tools. I’ll be the one reading the stone. I’ll be the one making the cuts and figuring out what the material will and won’t allow me to do.

I’ve spent nearly fifty years learning how to draw, carve, design and see. AI hasn’t replaced any of that experience. What it has done is give me a way to explore ideas and understand them at a speed I never could before.

If I don’t understand composition, AI can give me a pretty picture. If I DO understand composition, it can give me hundreds of possibilities to examine, reject and develop. If I don’t understand carving, it can give me an image of something that looks like it could be carved. If I’ve been carving for fifty years, I can look at that image and start asking whether the forms actually make sense in wood or stone.

The technology doesn’t eliminate the need for artistic knowledge. In many ways, it makes that knowledge more valuable because I still have to know what I’m looking at. So I’m not interested in having AI make my art for me. I’m interested in using it to expand what I’m capable of imagining.

Photography didn’t end painting. It changed what painting could be. Maybe AI is going to do the same thing for all of us.

For me, this is what I mean by The Human Touch. The tech helps me see farther than I could see before, but eventually the idea comes back into human hands.

And that’s where the art happens.

Your thoughts?

– Raymond Kinman via a post at https://www.facebook.com/groups/325935821195236

Wow. This is so nicely said. A huge thanks to Mr. Kinman for allowing me to share his words here.

Development Diary entry #0

And so it begins… ;-P

In a recent post about BASIC INSTR, a few comments were left trying to clarify or justify or explain the behavior of why “” is reported as matching the first character in the search string.

PRINT INSTR("ABC","A")
1

PRINT INSTR("ABC","C")
3

PRINT INSTR("ABC","X")
0

PRINT INSTR("ABC","")
1

Copilot AI at least pretends to know the actual reason, which involves saving a few precious bytes in the early 4K Microsoft ROM. The behavior was then retained for backwards compatibility as Microsoft BASIC expanded. Copilot even reports the behavior continued into VB.NET, though I did not fact check this answer.

LuisCOCO commented:

This is logical, if you search for three letters it searches for that piece but when searching for nothing it starts in the first position and searches for zero characters in the destination since it is useless to search for more letters if you search for fewer letters, that brings a null string as the first data found and compares it with the null to search and gives true

– LuisCOCO

Indeed, without a check for an empty string, the search would stop there. “Compare an X byte string to a Y byte string”. As the scan is performed, I suspect the moment a character does not match, it sets the return value to 0. Without looking at the code (yet), my assumption is that it starts with 1 as the return value and just exits when no more bytes are available to compare (immediately with a zero byte target string) leaving the 1 there. Since code exists to flag it with a zero if it a mismatch is encountered, perhaps they did just want to save a few instructions rather than doing a check then branch to that zero return.

Unless there truly is an intentional reason it works this way.

William “Lost Wizard” Astle, who wrote the 6809 assembly (LWasm) I use quite often, explained some math stuff:

Put another way, the empty string is self-evidently a valid substring of every string at every position within that string so it will naturally match the position where the search starts. This is also mathematically correct when you look at set theory. The null set is a subset of all sets.

– William Astle

It seems math folks are fine with how INSTR works. Though math set theory is not where my mind would have been as a child learning BASIC back in junior high school.

William Astle then sends me on a side quest with this comment…

Incidentally, strstr() in C does exactly the same thing with an empty target string.

– William Astle

Let me C what I can find…

strstr() works similarly to BASIC’s INSTR, except it returns a pointer to where the match was found in memory. If no match was found, it returns a NULL pointer (which is 0, matching INSTR).

const char * strstr ( const char * str1, const char * str2 );

BASIC gives back a base-1 index, so 1 for a match at the first character of the search string, or 5 for a match starting at the 5th character of the search string. Strings in MS BASIC used “normal” base-1 counting numbers for the index. If you use MID$(), LEFT$(), RIGHT$() and similar string functions, they all use 1 for the first character in a string.

C uses base-0 for indexes, so if you have a string in C:

char *st = "ABC";

…the first character would be index 0, st[0], while in BASIC:

ST$="ABC"

…the first character would be index 1, MID$(ST$,1,1).

strstr

A quick test program to confirm…

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int main (int argc, char **argv)
{
    char *search = "ABC";
    char *target = NULL;
    char *ptr = NULL;
    
    // const char * strstr ( const char * str1, const char * str2 );
    // A pointer to the first occurrence in str1 of the entire sequence of
    // characters specified in str2, or a null pointer if the sequence is
    // not present in str1.

    printf ("search = '%s' (%p)\n", search, search);

    target = "A";
    ptr = strstr (search, target);
    if (NULL == ptr)
    {
        printf ("target '%s' not found in '%s'\n", target, search);
    }
    else
    {
        printf ("target '%s' found in '%s' at index %d\n", target, search,
                (ptr - search));
    }
    
    target = "C";
    ptr = strstr (search, target);
    if (NULL == ptr)
    {
        printf ("target '%s' not found in '%s'\n", target, search);
    }
    else
    {
        printf ("target '%s' found in '%s' at index %d\n", target, search,
                (ptr - search));
    }
     
    target = "X";
    ptr = strstr (search, target);
    if (NULL == ptr)
    {
        printf ("target '%s' not found in '%s'\n", target, search);
    }
    else
    {
        printf ("target '%s' found in '%s' at index %d\n", target, search,
                (ptr - search));
    }
    
    target = "";
    ptr = strstr (search, target);
    if (NULL == ptr)
    {
        printf ("target '%s' not found in '%s'\n", target, search);
    }
    else
    {
        printf ("target '%s' found in '%s' at index %d\n", target, search,
                (ptr - search));
    }

    return EXIT_SUCCESS;
}

Yuck. I should have made a function… This produces:

search = 'ABC' (0x58a8ed9ba008)
target 'A' found in 'ABC' at index 0
target 'C' found in 'ABC' at index 2
target 'X' not found in 'ABC'
target '' found in 'ABC' at index 0

I realize my example is … not optimal. strstr() is returning a pointer to memory, and my example is subtracting the pointer where the target string was found from the pointer where the search string is. If they are the same, the math is 0 for the first character. But if the function actually returns a 0 (NULL), that means it was not found. I should have considered that before writing this example ;-)

But I digress…

Which came first?

A quick (and non fact-checked) web search about when strstr was added to C reveals:

The strstr function was added to the C standard library as part of the ANSI C standard (C89/C90), which was approved in 1989 and published in 1990.

Well, at least it worked the same way BASIC programmers would have been used to. But I do wonder if there was an earlier implementation of BASIC that introduced INSTR, or similar.

Another quick (and non fact-checked) web search says DEC BASIC-PLUS for the PDP-11 had a similar function and was introduced in 1970.

If I can figure out how to use the PDP-11 online emulator, maybe I can figure this out:

https://www.pcjs.org/software/dec/pdp11/tapes/basic

But here is the manual, which specifically documents this behavior:

The next-to-last entry:

“If only the substring is null, and if int-exp is equal to zero, INSTR returns a value of 1.”

– https://www.dmv.net/dec/pdf/bp2v27rm.pdf

Though, that manual has a copyright of 1987 and 1991, so… maybe not quite where it started.

I found one from 1975:

“If B$ is a null string (B$ = “”), the INSTR functions returns the value 1. The null string is a proper substring of any string and is treated conventionally as the first element of A$ in null string search operations. In addition, if both A$ and B$ and null strings, the INSTR function returns the value of 1″

– https://www.bitsavers.org/pdf/dec/pdp11/rsts_e/V06/DEC-11-ORBPB-A-D_BASIC-PLUS_LangMan_Jul75.pdf

The 1970 manual does not show INSTR in the index:

http://bitsavers.trailing-edge.com/pdf/dec/pdp11/lang/basic/basic_pts/DEC-11-AJPB-D_PDP-11_BASIC_Programming_Manual_Dec70.pdf

But Google AI tells me it was in a 1971 edition:

http://ftpmirror.your.org/pub/misc/bitsavers/pdf/dec/pdp11/rsts/PL-11-71-01-01-A-D_RSTS-11UsersGuide_May71.pdf

In that 1971 manual, I found this:

Unfortunately, the 1971 manual does not specifically address what happens with a null/empty string, but we can for sure say it was definitively documented to do that in the 1975 manual, and without any mention to it being a change from the earlier releases, likely was there in 1971.

I think we have a winner. As described, it is clear the intent matches William Astle‘s comment about null being a proper substring of any string. Microsoft implemented it the way it

Conclusion

I guess all I have to say is that I’d have preferred is for INSTR to return 0 if an empty string was passed in.

Unless someone can tell me the benefit of having it return 1, that is. I am a big fan of changing my own personal views when I learn new information. Just ask me about politics sometime. . . #independent

Wayback in the 1990s, Vaughn Cato and I were corresponding, and somehow some topics came up about rendering a 3-D maze on the CoCo.

Vaughn wrote a demo which was called toast for reasons I no longer remember. It parsed a text file representing the maze, and would let you “walk” through it using the arrow keys. The code was written in C (though there may be some assembly helper routines in there, I haven’t checked) for the Radio Shack Color Computer 3 under the OS-9 operating system.

Here is a quick demo of what toast looked like:

Here is the maze data file:

18 16
#  ##########
#           #
#           #
########### #
          # #
          # #
          # #
          # #
          # #
          # #
      ##### ######
      #          #
      #          #
      #          #
      #          #
      ############

The readme included with this version had the following notes:

Here is the latest version of the maze program.  I think that it now
always displays the walls correctly, but let me know if you find a problem.

I have also included a demo of the bitmap scaling routine.  Just run
mapgraph to try it out.

  Until Later,
  Vaughn Cato ([deleted]@st6000.sct.edu)

I will share what mapgraph does in a future post ;-)

I plan to reach out to Vaughn and ask if he would be okay with sharing the source code for this.

Until then…

At the 1994 Atlanta CoCoFest, the following vendors were present:

Booth 20 was unoccupied, as the vendor did not make it. They did leave a stack of flyers explaining their absence. You can read the text of that flyer in the previous post.

Who was Klystronics? Beyond those that knew about it in 1994, the backstory was explained in my CoCoFest Chronicles book which you can download for free at the Color Computer archive.

First, my fest report text file (included in the book) alluded to it in the opening:

NOTE: Any discrepancies between what is contained in this report and what is real is merely coincidental. This includes, but is not limited to, names, locations, events, and inside jokes (like klystrons).

– Allen Huffman’s 1994 Atlanta CoCoFest report text file

That report also mentioned the booth:

Klystronics — Another new vendor. This group was offering a large supply of “gently used” klystrons, complete with manuals. The minimal water damage their inventory had didn’t seem to effect operation, though the yellow discoloration made them no longer match the CoCo’s case.

– Allen Huffman’s 1994 Atlanta CoCoFest report text file

…but the full backstory was not explained until the book itself came out a few years later. From the book:

---

MORE BEHIND THE SCENES

The Story About Klystronics

One of the more interesting tales I get to tale is that of the “mysterious” vendor, Klystronics. They were listed in the Fest booklet, and even had a table which was empty except for some flyers and an empty business card holder. To the casual observer (i.e. someone who fell for it) it would appear they just didn’t make it to the show. To the less casual observer, one might have found some of the information on the flyer a bit curious.

Klystronics was a practical joke played for the benefit of one individual, Nick Johnson. At the time, Nick was hanging out on the GEnie online service (thanks to its then-outstanding Star*Services which offered unlimited non-prime access for about five dollars per month). Nick had a macro he would use far too often while in chat sessions which said “PLEASE DO NOT URINATE ON THE KLYSTRON.” Terry Todd and myself found this quite annoying.

At some point, our friend Bob Rutherford got together with us and we came up with the idea of Klystronics. Once the name was created, the joke fell into place. We acquired a booth, printed flyers (using a font I had never used for any Sub-Etha literature), and purchased a business card holder.

At the show, Nick wandered over and said “hey, did you guys know there is a company here called Klystronics?” or something to that effect. We held in laughter. He most likely was suspicious but if so he played along pretty well. The flyer had some meaningless babble about CoCo compatible Klystrons, but embedded in the words were numbers enclosed in brackets. If you put the letter next to the numbers together in numerical order you would decode the hidden message which basically clued one in to the fact that this was just a joke. At first Nick suspected something far more clever for the origin of the numbers, but towards the end of the show I do believe he figured it out. I am not quite sure if we ever told him officially that it really was us.

A few others were in on this joke, most notable Colin McKay. After the Fest, Colin played up the existence of Klystronics on the internet CoCo mailing list after someone wondered just who they were. Even Mike Knudsen chimed in observing that certainly they had nothing to do with the “klystron” tubes he was familiar with! He certainly was right. I have in my possession (thanks to Mike’s archives) a copy of the Klystronics message thread and I must say — it really makes me proud seeing how well this went over.

The following Fest, we planned to do more including having Bob Rutherford build a rather amazing device to attach to a CoCo. We never quire followed through, but Klystronics lived on in my Fest report — even though there was no booth nor mention of them in the official Fest booklet.

And now you know … the rest of the story. Maybe the comment about “water damage” will make a bit more sense.

Or, more likely, it will not.

---

I decided to post the original Kystronics flyer text on April 1, 2026. This was more involved than I expected. First, the raw text file seemed to use some embedded formatting codes. I could not remember what created them:

.pl1
.lm0
.ll137
.nf

This led me to trying to figure out how to export the document in a formatted version to match what I did back in 1994. I was using the text editor VED under OS-9 at the time, and suspected maybe I was using the companion VPT text formatted. After figuring out how to run it off my old OS-9 hard drive image in an emulator, I learned it did not like these codes.

Eventually, I just decided to feed it into A.I. (Copilot) and let it do it for me. It presented me with an ASCII version of document, correctly figuring out what codes mean blank lines, and what codes meant centered lines. BUT, it was 137 columns wide.

What? That wouldn’t even fit if I printed in landscape mode, which wasn’t even a thing on that printer back then.

A bit more research revealed I likely printed this on my Tandy DMP-132 printer in condensed mode, which would indeed allow 137 characters per line with a bit of margin on each side.

This led me to just simulating it by using a condensed dot matrix font and turning the text into a PDF.

That’s close-ish.

Some things seem obvious now…

As I pointed out, I tried to use a font Sub-Etha Software didn’t use for printing flyers, and change things up so it was not immediately obvious I created this. For instance, it spells “disc” with a C and I never did that. It also uses “Coco” without the second C capitalized. But, as I look at it now, I see a few things that would have tipped folks off.

• First, back then, I typed DOS as “Dos” as if it was a word. So did Klystronics. (And other folks of that era, but still, a hint.)
• Also, “S.E.S.” Dos and “B.H.” Dos? I’ve never heard of any RS-DOS replacements with those initials, but there were two companies at the fest that had matching initials.
• I also misspelled separately the same way I’d be misspelling it today if it wasn’t for auto-correct. And so did Klystronics. My Fest reports were full of that misspelling as well as mixing of where/were.
• Bored member? “lol”. That misspelling was intentional.

The document also has some things that could further tip off the joke.

• 16K RAM, but also supporting the Hi-Res Joystick Interface? Seems unlikely.
• Color Computer 2 but NOT Color Computer 1? Why would that be?
• Also, the name “Graham Cain” alluded to the two individuals behind it. One may be obvious, the other not at all.

But … the biggest tip was that there is also an encoded message hidden in this document. Look at the full text and see if you can decode it. That was the actual reveal.

Until next time…