Category Archives: Uncategorized

Insta360 X4 firmware 1.0.6 / 1.0.8 has many new features


  • 2024-04-17 – Added USB mode, 5.7K+ and charging display.
  • 2024-04-18 – Automatic screen brightness! Also, 1.0.8 is out but the release notes look the same as 1.0.6. It was a tiny update file.
  • 2024-04-19 – Added link to Eat Sleep 360 video.

There are quite a few things in the firmware that none of the X4 videos mentioned, so I assume these were not in the beta firmware the YouTubers had.

Some quick first impressions, coming from the X2 then X3:

  1. This thing feels larger and bulkier.
  2. The rubber lens cap for it is much thicker, to allow room for the screw-on lens protectors. This means cases, etc. will have to be much thicker, as well, to store the X4 with the lens cap on.
  3. The included pouch cannot hold the X4 with the lens cap. It will hold the X4 with the included Thermo Cover Grip, though, and has pockets for the lens protectors and cleaning cloth. I would not put the USB-C cable in there, as it can stick out of the pocket and scratch your X4.

Firmware notes:

After activation, I see a random (?) WiFi password is assigned. An X3 firmware update gave us the ability to change the default 88888888 (which the X4 still defaults to, per videos I have watched). It looks like Insta360 now randomizes it so this step is not needed to prevent nearby folks from accessing and download all your files while your camera is on ;-) (I have not tested to see if the open access is still there, if you know the WiFi password, but I will soon.)

After activation, the firmware shows you about adding lens protectors, and changing settings to match what type you have (plastic, or premium). THere is also an “automatic” setting where it will try to detect that you are using lens protectors. I expect this means they impact stitching.

There is then a nice tutorial that walks you throgh the user interface – swiping up and down and such to navigate the menus.

THe user interface is fancier now. When a picture is taken, you see a small thumbnail appear, then fly off the screen. There are a few spiffy things like that I have noticed, so far.

You also get pop ups that warn you if lighting is too low for the mode you are in.

NEW from X3:

  1. Lens Guard Mode – Auto, Standard, Premium, No Lens Gaurd
  2. Screen Reader – “When on, the camera provides voice prompts for certain commands or actions.”
  3. Prompt Sound – Now has “Adaptive” in addition to High, Medium, Low and Mute.
  4. AI Highlights Assist – “AI will analyze video highlights during filming for faster editing on the Insta360 App.” It mentions this increased power consumption and temperature.
  5. Gesture Control – this works well. Show a two finger “peace sign”, and you get a countdown (so you can move your hand) and it takes the photo. Hold you palm and it will start or stop recording. On this on/on screen is a little animation of a person showing how to do each one. (Scroll down to see the other. It was not intuitive that there was more below this animation; I expected it to just show me both.) THIS IS NEAT.
  6. Timed Capture – The X4 has a clock. Turn this on, and you set a Start Time and Duration (which can be “infinite”) and a Repeat Frequency (Once, or Every day). You also set shooting mode (video, photo, all the modes, 360 or single lens, etc.) and parameters (resolution and frame rate), and image parameters (auto, ISO, etc.).
  7. Audio Settings – adds “Auto Wind Noise Reduction.” Old “Window Noise Reduction” is now called “Active Wind Noise Reduction.”
  8. There is a setting of all the quick access modes that now has defaults for Motorcycling, Skiing, and Outdoors. You can “+” to add a new one and pick from a list of presets (Surfing, Running, Biking, Cars, etc.). You can also Customize where you can make your own, and it will show as “Customize” or as one of the preset names you set it to. This is still not as good as being able to give it your own name, but better.
  9. UPDATE: There is no USB setting. When you plug it in to a computer, you get a screen asking “U-Disk Mode” or “Reverse Charging”.
  10. UPDATE: In addition to 5.7K, there is also 5.7K+. “”Close to 8K image quality but with a smaller file size. 5.7K+ is not suitable for low light conditions.”
  11. UPDATE: While charging, the screen displays a circle and the percentage charged.
  12. UPDATE: Automatic screen brightness! I missed the on screen button next to the slider. In a dark room, the screen goes dim. In bright light, the brightness increases so you can see it. Nice battery saver!

Settings has new options:

  1. “Touch to activate when off”
  2. “Power-off Charging” that tells what action happens when you plug in to charge (Charge only, Charge and power on, Charge and record). Charge and record could allow you hooking this up to a timed outlet and turning that outlet on to automatically start recording video, but I have not tested this yet.
  3. Long press Shutter Button to cancel recording – nice. That saves a swipe, I guess.
  4. Thermo Grip Cover – Automatic Recognitions, Installed or Uninstalled. A note about this – the cover has two white dots below it. I think that is how it knows the cover is installed. It also impacts stitching so you have to set the mode to match. The manual warns to not install or remove while recording or stitching will get messed up.
  5. Date and Time – set by the app but you can set it here. I do not know how it deals with time zones. I suppose you’d just have to sync your phone to the camera when you get to the new time zone? You can change the Date Format as well (MM/DD/YY versus DD/MM/YY or YY/MM/DD).
  6. Reset Tutorial – to go back and learn it all again.

There is alot here that wasn’t mentioned in any of the videos I watched, so I expect we will see Part 2 as the YouTubers get to play with the current firmware.

I will say again – this camera feels much larger and bulkier. I hope the added features are worth it.

More to come. Tonight I’ll try to record my X3-X4 comparison videos where I do some 5-10 minute clip without edits so folks can compare raw output rather than short demonstration clips.

UPDATE: Eat Sleep 360 posted a 3 minute video going over many of these options, and a few that I was unaware of.

Decaps of 1986 GIME chip via Sean Riddle, Erik Gavriluk and Roger Taylor


  • 2024-03-09 – Added Dropbox link for direct download, any more background details. I have let Roger know I am now ready to download the 1987 version files and get those available.

Last year, Roger Taylor went through the effort and expense to have the Tandy/Radio Shack Color Computer 3’s custom “GIME” chip decapped and scanned. Super high resolution images are available. This should give someone with the knowledge and skills the ability to reproduce these custom chips.

Read more about this, and other fascinating projects, on Roger’s Patreon page. Consider supporting him. He has made some interesting acquisitions lately, including a “did we know this existed?” Mexico CoCo 3 called a MicroSEP II. He has also spend thousands of dollars to acquire the source code archives of the late Steve Bjork.

These GIME chip scans are the works of:

  • Sean Riddle
  • Erik Gavriluk
  • Roger Taylor

Any distribution should include their credit.

Use this “1986 GIME.torrent” file to download with a BitTorrent client and help seed it for others to get a backup of these files. I also have the files in a Dropbox share for those really patient with downloading 140+ GB of image files.

The files are also currently on my Dropbox, if you want to try to download them from there:

I do not have the 1987 GIME chip scans yet, but will do the same with them once I have them.

Using the DJI MIC 2 with the iPhone native camera app

The DJI MIC 2 can pair to an iPhone via Bluetooth, but the built-in camera app (the “native camera app”) does not automatically use it. Various YouTubers and web pages and even ChatGPT say you have to use a third-party camera app that allows selecting the Bluetooth microphone.

But that is not true. You can run an app such a RODE Reporter, select the DJI MIC 2, then run the native camera app and it works fine.

Thank you, RichardTaylorTV, for not just echoing the same junk everyone else is doing.


Color BASIC overflow bug – same as Commodore’s?

I just saw a tweet from Robin @ 8-Bit Show And Tell concerning a bug in Commodore BASIC that existed in the PET, C64 and VIC-20.

VAL() takes a string and converts it in to a floating point numerical variable. The value of “1E39” is a number in scientific notation, and this appears to cause a problem.

In Microsoft BASIC, the notation “1E39” represents the number 1 multiplied by 10 raised to the power of 39. This is also known as scientific notation, where the “E” indicates the exponent to which the base (10 in this case) is raised. So, “1E39” is equal to 1 * 10^39, which is an extremely large number:

1E39 = 1 * 10^39 = 1000000000000000000000000000000000000000

This number has 39 zeros after the 1, making it a very large value.

– ChatGPT

I was curious to see what the CoCo’s Color BASIC did, so I tried it…

It appears that port of BASIC to the 6809 also ported over this bug. Anyone want to take a look at the source and see what the issue is?

…to be continued, maybe…

Color BASIC program line info dump program

These days, I feel like I am regularly saying “I’ve learned more this week about X than I learned in Y years of using it back in the 1980s!”.

This is another one of those.

Each line of a Color BASIC program is tokenized (changing keywords like PRINT to a one or two byte token representing them) and then stored as follows:

  • 2-Bytes – Address in memory where next line starts
  • 2-Bytes – Line number (0-63999)
  • n-Bytes – Tokenized program line.
  • 1-Byte – Zero (0), indicating the end of the line

The four byte header and the 1 byte zero terminator mean that each line has an overhead of 5-bytes. You can see this by printing free memory and then adding a line that has a one byte token, such as “REM” or “PRINT”:

Above, you see the amount of memory decreases by 6 bytes after adding a line. That’s five bytes for the overhead, and one byte for the “REM” token.

The BASIC program starts in memory at a location stored in memory locations 25 and 26. You can see this by typing:

PRINT PEEK(25)*256+PEEK(27)

There are other such addresses that point to where variables start (directly after the program), and where string memory is. Here is an example program from an earlier article I wrote that shows them all. (The comments explain what each location is.)


20 ' PEEK(25)*256+PEEK(26)

40 ' PEEK(27)*256+PEEK(28)

60 ' PEEK(29)*256+PEEK(30)

70 ' END OF ARRAYS (+1)
80 ' PEEK(31)*256+PEEK(32)

100 ' PEEK(33)*256+PEEK(34)

120 ' PEEK(35)*256+PEEK(36)

140 ' PEEK(39)*256+PEEK(40)

160 PRINT "PROG  SIZE";(PEEK(27)*256+PEEK(28))-(PEEK(25)*256+PEEK(26)),;
170 PRINT "STR SPACE";(PEEK(39)*256+PEEK(40))-(PEEK(33)*256+PEEK(34))
180 PRINT "ARRAY SIZE";(PEEK(31)*256+PEEK(32))-(PEEK(29)*256+PEEK(30)),;
190 PRINT " STR USED";(PEEK(39)*256+PEEK(40))-(PEEK(35)*256+PEEK(36))
200 PRINT " VARS SIZE";(PEEK(29)*256+PEEK(30))-(PEEK(27)*256+PEEK(28)),;
210 PRINT " FREE MEM";(PEEK(33)*256+PEEK(34))-(PEEK(31)*256+PEEK(32))

I thought it might be interesting to write a BASIC program that displays information on each line of the BASIC program. That information would include:

  • Start address of the line
  • Address of the next line
  • Line number of the line

Here is what I came up with. It can use generic PRINT in lines 40 and 70 (for Color BASIC) or a nicer formatted PRINT USING (for Extended Color BASIC) in lines 50 an 80.

20 L=PEEK(25)*256+PEEK(26)
30 NL=PEEK(L)*256+PEEK(L+1)
50 PRINT USING"##### #####";L;NL;
70 'PRINT PEEK(L+2)*256+PEEK(L+3);NL-L
80 PRINT USING" ##### ###";PEEK(L+2)*256+PEEK(L+3);NL-L
90 L=NL:GOTO 30

For this program, as shown, running on a virtual 32K Extended Color BASIC CoCo in the XRoar emulator, I see:

The first column (ADDR) is the address of the BASIC line in memory. After that is the address of where the next line begins (NADDR), and it will match the address shown at the start of the following line. The third column is the line number (LINE#), and last is the size of the line (SIZ) which includes the tokenized line AND the terminating zero byte at the end of it.

The final line has a “next address” of zero, indicating the end of the file.

At the start of the program I included three comments:


In the output of the program, you see them described as:

 9729  9747     0  18  <- [0 'BASINFO.BAS]
 9747  9765     1  18  <- [1 REM BASINFO.BAS]
 9765  9782     2  17  <- [2 REMBASINFO.BAS]

You can see that the length of lines 0 and 1 are both 18, even though one looks like it should be shorter. In this case, the apostrophe (‘) abbreviation for REM seems to take as much space as “REM ” (with a space after it). This is because the apostrophe is encoded as a “:REM” (colon then REM). Alex Evans recently reminded me of this. This behavior would allow you to use it at the end of a line like this:


…instead of having to do:


But don’t do either! REMs at the end of the line can be the worst place to have REMs, since BASIC will have to scan past them to get to the next line, even if they are after a GOTO. This makes them slower. (Reminder to self: do an article on this since I’ve learned more since I original covered the topic in one of my Benchmarking BASIC articles…)

But I digress…

If you wanted to run this on your own program, you could do so by making this routine load at a high line of BASIC (higher than any lines you might be using), then you could save it as ASCII (SAVE”BASINFO”,A) and then use MERGE”BASINFO” (from disk) to bring those lines in to your program.

63001 NL=PEEK(L)*256+PEEK(L+1):PRINT USING"##### #####";L;NL;:IF NL=0 THEN END ELSE PRINT USING" ##### ###";PEEK(L+2)*256+PEEK(L+3);NL-L:L=NL:GOTO 63001

Now you could do RUN 63000 to see what your program looks like. (The highest line number Color BASIC allows is 63999 so you could change that to 63998 and 63999 if you wanted absolutely the most line numbers available for your program ;-)

You could also add “IF L=63000 THEN END” somewhere and have it stop when it hits that routine.

What use is this?

For an upcoming article, I expect to use a version of this code to “prove” something as it relates to BASIC and the length of lines.

But, it might also be fun to generate some statistics — longest line, shortest line, a graph of the different line lengths, etc.

Until next time…

CoCo 3 and the 1988 Houston Boat Show

I graduated high school in 1987. Even though the CoCo 3 had come out the year before, I had remained with my CoCo 2. Sub-Etha Software co-founder, Terry, got his CoCo 3 first. I remember him asking me questions that I could not answer because he had lots of new features I never had seen.

By 1988 I had my own CoCo 3. I don’t recall when I got it, but it had to be in 1987 since I was writing CoCo 3 programs in January. One such program (or programs) was to display video titles. My father was producing a video which would be running at the Callaway Boatworks booth at the 1988 Houston Boat Show.

A few years ago, when I was going through 400+ floppy disks to archive them to a CoCoSDC, I found this disk but it had sector errors. While I could RUN some of the programs, many would not load due to disk errors.

Since then, I discovered a hard drive copy of the disk I had made to my KenTon RGB-DOS drive system. This image was intact! I wanted to go through the titles “some day” and see what all I had done.

“Some day” happened last week. I used the toolshed “decb” utility to pull each BASIC program off the disk image and convert it to ASCII. I then looked through all of them in Visual Studio Code on my Mac. Certain programs would daisy-chain to other programs, using a RUN”NEXTPROG” command at the end. Some paused for a key (at a black screen) before drawing the titles. The BREAK key (and CoCo 3 ON BRK command) was used to skip to the next program (why did I do it that way?).

I was able to come up with a list of two segments of daisy-chained titles, and then the rest were just one-off titles on their own. I recorded the two sequences, and all the separate images, and posted the video to YouTube:

1988 Houston Boat Show graphics done on a CoCo 3 in BASIC.

Some internet searching shows that Callaway Boatworks no longer exists. A few others in the video have since disappeared from the market, but the Houston Boat Show continues to this day.

I wrote them to see if they could provide a vendor list from 1988. I did not expect a response, but got one! They sent me a scan of the exhibitors from that year’s show, and I can now locate the two spots that Callaway Boatworks had that year.

A huge thank you to Lynette M at the boat show for taking time to get me this information. My father passed away a few years ago, so I did not have him to ask about these things.

More to come…

Color BASIC Attract Screen – part 5

See also: part 1, part 2, part 3, part 4, unrelated, and part 5.

In part 4 of this series, Jason Pittman provided several variations of creating the attract screen:

Jason Pittman variation #1

If those four corners bother you, then my attempt will really kick in that OCD when you notice how wonky the colors are moving…

Jason Pittman
10 CLS0:C=143:PRINT@268,"ATTRACT!";
20 FOR ZZ=0TO1STEP0:FORX=0TO15:POKEX+1024,C:POKEX+1040,C:POKE1535-X,C:POKE1519-X,C:POKE1055+(32*X),C:POKE1472-(32*X),C:GOSUB50:NEXT:GOSUB50:NEXT
50 C=C+16:IF C>255 THEN C=143

Jason Pittman variation #2

Also, another option using the substrings might be to fill the sides by printing two-character strings on the 32nd column so that a character spills over to the first column of the next line:

Jason Pittman
10 CLS 0:C=143:OF=1:CH$=""
40 PRINT@0,MID$(CH$,OF,31):GOSUB 120
60 PRINT@481,MID$(CH$,OF,30);:GOSUB120
90 C=C+16:IF C>255 THEN C=143
120 OF=OF+2:IF OF>7 THEN OF=OF-8

Jason Pittman variation #3

One more try at O.C.D-compliant “fast”:

Jason Pittman
10 DIM CL(24):FORX=0TO7:CL(X)=143+(X*16):CL(X+8)=CL(X):CL(X+16)=CL(X):NEXT
190 DATA 1024,8,1,0,1032,8,1,0,1040,8,1,0,1048,6,1,0,1055,8,32,6,1311,6,32,6,1535,8,-1,4,1527,8,-1,4,1519,8,-1,4,1511,6,-1,4,1504,8,-32,2,1248,6,-32,2

The #3 variation using DATA statements is my favorite due to its speed. Great work!

The need for speed: Some assembly required.

It seems clear that even the fastest BASIC tricks presented so far are still not as fast as an attract screen really needs to be. When this happens, assembly code is the solution. There are also at least two C compilers for Color BASIC that I need to explore, since writing stuff in C would be much easier for me than 6809 assembly.

Shortly after part 4, I put out a plea for help with some assembly code that would rotate graphical color blocks on the 32 column screen. William “Lost Wizard” Astle answered that plea, so I’ll present the updated routine in his LWASM 6809 compiler format instead of as an EDTASM+ screen shot in the original article.

* lwasm attract32.asm -fbasic -oattract32.bas --map

    org $3f00

    ldx #1024   X points to top left of 32-col screen
    lda ,x+     load A with what X points to and inc X
    bpl skip    if not >128, skip
    adda #16    add 16, changing to next color
    ora #$80    make sure high gfx bit is set
    sta -1,x    save at X-1
    cmpx #1536  compare X with last byte of screen
    bne loop    if not there, repeat
    sync        wait for screen sync
    rts         done


The code will scan all 512 bytes of the 32-column screen, and any byte that has the high bit set (indicating it is a graphics character) will be incremented to the next color. This would allow us to draw our attract screen border one time, then let assembly cycle through the colors.

How it works:

  • The X register is loaded with the address of the top left 32-column screen.
  • The A register is loaded with the byte that X points to, then X is incremented.
  • BPL is used to skip any bytes that do not have the high bit set. This optimization was suggested by William. An 8-bit value can be treated as an unsigned value from 0-255, or as a signed value of -127 to 128. A signed byte uses the high bit to indicate a negative. Thus, a positive number would not have the high bit set (and is therefor not in the 128-255 graphics character range).
  • If the high bit was set, then 16 is added to A.
  • ORA is used to set the high bit, in case it was in the final color range (240-255) and had 16 added to it, turning it in to a non-graphics block. Setting the high bit changes it from 0-16 to 128-143.
  • The modified value is stored back at one byte before where X now points. (This was another William optimization, since originally I was not incrementing X until after the store, using an additional instruction to do that.)
  • Finally, we compare X to see if it has passed the end of screen memory.
  • If it hasn’t, we do it all again.
  • Finally, we have a SYNC instruction, that waits for the next screen interrupt. This is not really necessary, but it prevents flickering of the screen if the routine is being called too fast. (I’m not 100% sure if this should be here, or at the start of the code.)

The LWASM compiler has an option to generate a BASIC program full of DATA statements containing the machine code. You can then type that program in and RUN it to get this routine in memory. The command line to do this is in the first comment of the source code above.

20 IF A=-1 THEN 70
30 FOR C = A TO B
60 GOTO 10
70 END
80 DATA 16128,16147,142,4,0,166,128,42,6,139,16,138,128,167,31,140,6,0,38,241,19,57,-1,-1

The program loads at $3f00 (16128), meaning it would only work on a 16K+ system. There is no requirement for that much memory, and it could be loaded anywhere else (even on a 4K system). The machine code itself is only 20 bytes. Since the code was written to be position independent (using relate branch instructions instead of hard-coded jump instructions), you could change where it loads just by altering the first two numbers in the DATA statement (start address, end address).

For instance, on a 4K CoCo, memory is from 0 to 4095. Since the assembly code only uses 20 bytes, one could load it at 4076, and use CLEAR 200,4076 to make sure BASIC doesn’t try to overwrite it. However, I found that the SYNC instruction hangs the 4K CoCo, at least in the emulator I am using, so to run on a 4K system you would have to remove that.

Here is the BASIC program modified for 4K. I added a CLEAR to protect the code from being overwritten by BASIC, changed the start and end addresses in the data statements, and altered the SYNC code to be an RTS (changing SYNC code of 19 to a 57, which I knew was an RTS because it was the last byte of the program in the DATA statements). This means it is wasting a byte, but here it is:

5 CLEAR 200,4076
20 IF A=-1 THEN 70
30 FOR C = A TO B
60 GOTO 10
70 END
80 DATA 4076,4095,142,4,0,166,128,42,6,139,16,138,128,167,31,140,6,0,38,241,57,57,-1,-1

Using the code

Lastly, here is an example that uses this routine. I’ll use the BASIC loader for the 32K version, then add Jason’s variation #1 to it, modified by renaming it to start at line 100, and removing the outer infinite FOR Z loop so it only draws once. I’ll then add a GOTO loop that just executes this assembly routine over and over.

5 CLEAR 200,16128
20 IF A=-1 THEN 70
30 FOR C = A TO B
60 GOTO 10
70 GOTO 100
80 DATA 16128,16147,142,4,0,166,128,42,6,139,16,138,128,167,31,140,6,0,38,241,19,57,-1,-1
100 CLS0:C=143:PRINT@268,"ATTRACT!";
120 FORX=0TO15:POKEX+1024,C:POKEX+1040,C:POKE1535-X,C:POKE1519-X,C:POKE1055+(32*X),C:POKE1472-(32*X),C:GOSUB150:NEXT:GOSUB150
130 EXEC 16128:GOTO 130
150 C=C+16:IF C>255 THEN C=143

And there you have it! An attract screen for BASIC that uses assembly so it’s really not a BASIC attract screen at all except for the code that draws it initially using BASIC.

I think that about covers it. And, this routine also looks cool on normal 32-column VDG graphics screens, too, causing the colors to flash as if there is palette switching in use. (You can actually palette switch the 32-column screen colors on a CoCo 3.)

Addendum: WAR by James Garon

On 7/2/2022, Robert Gault posted to the CoCo list a message titled “Special coding in WAR“. He mentioned some embedded data inside this BASIC program. You can download it as a cassette or disk image here:

You can even go to that link and click “Play Now” to see the game in action.

I found this particularly interesting because this BASIC program starts with one of the classic CoCo attract screens this article series is about. In the program, the author did two tricks: One was to embed graphics characters in a PRINT statement, and the other was to embedded a short assembly language routine in a string that would cycle through the screen colors, just like my approach! I feel my idea has been validated, since it was already used by this game in 1982. See it in action:

And if you are curious, the code in question starts at line 60000. I did a reply about this on the CoCo mailing list as I dug in to what it is doing. That sounds like it might make a part 6 of this series…

Until next time…