Development Diary entry #0

And so it begins… ;-P

Updates:

• 2026-06-11 – I have an active support ticket with Apple and it has been escalated to engineering. They requested me send them a generic (none of my content) project that crashes as well as diagnostic logs. I was able to create a brand new Library and then a new 360 project then add things to it — a few titles, some FCP sound effects, a Generator item and a background, and even that crashes. I also did a short project that was non-360 and had no issues with that. Let’s hope they can figure this out!

---

I am posting this to get this into the search engines. I am hoping to hear from others that have had this same issue, and might have a solution.

I recorded 360 video (7680×3840) using Insta360 X5 and a DJI Osmo 360 cameras. I export the 360 video out to a flat video file using Insta360 Studio or DJI Studio desktop apps. I then bring this in to Final Cut Pro for editing. I have been doing this for years with no problems.

A few months ago, I went to make a new video. I found my project, that worked fine last year, now crashes Final Cut Pro. Sometimes it crashes on opening the project, sometimes when clicking around, sometimes it works for 15 minutes then crashes when I click on a view icon, etc. Very random.

I tried making brand new empty projects and recreating my template manually. Still crashes.

I eventually reset my macOS and then restored from a Time Machine backup. Even this “clean” reinstall still crashed.

I spent an hour or so on with Apple Support and we never figured out what was causing it, but we could even make it crash using only template items built in to Final Cut Pro — none of my graphics, video, or audio files.

The next test was to install a fresh copy of macOS with nothing else on it. I logged in to my Apple Store account and downloaded Final Cut Pro — the only app on this install of macOS.

And I can still get that to crash.

It looks like some bug with 360 video and the current Final Cut Pro, or some issue with the current macOS version.

Anyone encountered this?

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…