Uploaded July 2025 | Updated September 2026, 2 weeks ago
This video is a tribute to the build-up and launch release of the Commander X16, compiled from segments of 8BG's prior videos. It is the source video for the down-sampled version that was included on the original SD-card content, using a process developed by badmai from the X16 Forum so that it could be played using the VERA hardware. The SD-card actually uses a slightly shorter 5min version, so this is the "extended" edition.
Used with permission from Kevin and David. In addition to being a VERA-capability demonstration (in the on system VERA adaptation conversion), this is also a tribute to their efforts and many challenges on bringing the X16 into reality. Presented here is a sequence of main highlights over the years.
00:30 Kevin Williams introduces Gameduino (their first experiment, 2019)
01:00 Cloantro Commodore ROM/BASIC V2 licensing (this got resolved!)
01:15 Where the Commander X16 name came from (originally was 65816 based! see 05:02 )
01:40 Simplified back to a VIC-20 baseline (see the original video on why!)
02:02 Two video card submissions
02:27 First X16 board prototype with VERA
02:33 Michael Steil offers Kernal ROM help! (see also his VCF talks)
02:48 Perifractic helps on the logo! (also helped setup original X16 website)
03:34 Nobody *yet* has made a tracker! But then two people did :)
03:40 Sound chip issue (which eventually got resolved)
04:00 Nicco1690 adapted audio for Quarx port (and other audio samples for X16)
04:05 The GoFundMe was a success - provided up front funds to get materials (and tools) to make 100 initial boards!
04:40 Solder dipping station attempted, but Dev board too large (this may get used later for Gen2/3 smaller boards)
04:52 Brief look at the Lazer3D case!
05:02 Kevin mentioned they tried the 65C816 but just couldn't make it affordable (see original video for more in depth reasoning)
05:30 $50 system still the goal! Still "Assembled in USA" for now (Suntronics)
06:20 Board still needs "final assembly" and ROM loadout
This video is a tribute to the build-up and launch release of the Commander X16, compiled from segments of 8BG's prior videos. It is the source video for the down-sampled version that was included on the original SD-card content, using a process developed by badmai from the X16 Forum so that it could be played using the VERA hardware. The SD-card actually uses a slightly shorter 5min version, so this is the "extended" edition.
Used with permission from Kevin and David. In addition to being a VERA-capability demonstration (in the on system VERA adaptation conversion), this is also a tribute to their efforts and many challenges on bringing the X16 into reality. Presented here is a sequence of main highlights over the years.
00:30 Kevin Williams introduces Gameduino (their first experiment, 2019)
01:00 Cloantro Commodore ROM/BASIC V2 licensing (this got resolved!)
01:15 Where the Commander X16 name came from (originally was 65816 based! see 05:02 )
01:40 Simplified back to a VIC-20 baseline (see the original video on why!)
02:02 Two video card submissions
02:27 First X16 board prototype with VERA
02:33 Michael Steil offers Kernal ROM help! (see also his VCF talks)
02:48 Perifractic helps on the logo! (also helped setup original X16 website)
03:34 Nobody *yet* has made a tracker! But then two people did :)
03:40 Sound chip issue (which eventually got resolved)
04:00 Nicco1690 adapted audio for Quarx port (and other audio samples for X16)
04:05 The GoFundMe was a success - provided up front funds to get materials (and tools) to make 100 initial boards!
04:40 Solder dipping station attempted, but Dev board too large (this may get used later for Gen2/3 smaller boards)
04:52 Brief look at the Lazer3D case!
05:02 Kevin mentioned they tried the 65C816 but just couldn't make it affordable (see original video for more in depth reasoning)
05:30 $50 system still the goal! Still "Assembled in USA" for now (Suntronics)
06:20 Board still needs "final assembly" and ROM loadout





![Destiny Hunter Level Editor usage overview
This is a demonstration of a level editor created for the Destiny Hunter game. Like the game itself, the editor can run on the Commodore PET.
A demo of the game itself is here: https://www.youtube.com/channel/UCClmJOq3rLUTtTNYJU9lBFA
The editor runs in a text mode whereas the game runs in a graphics mode. Essentially this means a slightly different set of characters is available between the modes. Also in the graphics mode, the font spacing is tighter which allows for adjacent text to appear as a solid shape.
The editor allows drawing a map in an easy manner, using letters to denote terrain types (e.g. W for WATER tiles) and also visually showing the blocker status of any individual tile. blockers is just the term used here to indicate that the player and challenges in the game cannot move into that cell (its blocked, like a barrier). When saving the map information to disk, there are two files:
#) the map is compressed using a simple RLE algorithm: each alternating sequence of tiles becomes a [style][count] abbreviated form. For example, a sequence of five waters is stored as W5.
The information is packed onto the actual disk slightly differently. The W5 for example is packed into a [3bit][5bit] (1 byte) encoding since that is how the information is parsed by the game, and so this saves some memory there. The 3-bit means we can only have 8 different tile types (0-7), and the 5-bits means each sequence length can only be up to 32 characters (if you pay attention, 5-bits can only represent up to 31 as a little trick, when reading the data was take N and implicitly add 1, since the existence of single pair of RLE encoding implies at least 1 character in the sequence, so we save a slightly bit of space by this implicit assumption).
Here is an example of how the first map gets encoded:
3 symbol 0 (water), 4 copies (3+1) [_ _ _] [_ _ _ 1 1]
42 symbol 1 (beach), 11 copies (10+1) [001] [01010]
128 symbol 4 (land), 1 copy (0+1)
97 symbol 3 (rocks), 2 copies (1+1)
128 symbol 4 (land), 1 copy (0+1)
38 symbol 1 (beach), 7 copies (0+1)
76 symbol 2 (grass), 13 copies (12+1)
...and so on... NOTE: the above values are in decimal - it would be more convenient for them to be in hex, but to help transfer the data from the PET to the Windows machines I use to compile the software (where these encodings get directly embedded into the code), I had to use a common set of characters (which the numbers 0-9 happened to be, but not the hex values A-F).
#2) The blockers get saved in a separate file. It could have been the same file, but just to keep things easier and more obvious, it was divided into two separate files (for example, we can alter and muck with the RLE encoding format, without impacting the blocker data format, and vice versa). Blockers become a bit mask along each entire row of the game map.
Stage 1 doesnt have a lot of blockers, so here is an example from Stage 6:
0 [0,0,0,0,0],
1 [0,0,0,0,0],
2 [0,2,0,24,0],
3 [128,3,0,240,31],
4 [255,0,0,128,113],
5 [0,0,0,0,0],
...
Rows 0 and 1 arent currently part of the map, so their codes are always 0s. This just keeps the indexing consistent between the data file and the screen, so we dont have to add or subtract by 2 all the time (small detail, but a minor example of wasting a bit of space to reduce computation needs). Row 3 and 4 in this example have a lot of blockers, and the full set of 40 rows is expressed in a 40-bit sequence (5 bytes). For each bit, it means its corresponding column (for that row) is blocked for movement by the players and challenges. There are a couple exception: its not blocked by the bow weapon, and certain creatures may be exempt from being blocked (such as flying or ghost type creatures). So thats the thing about data: its all interpretation and depends on the context. Without that context, a data stream becomes almost useless.
One extra little detail here: the bits in the blocker code sequence are written backwards. Initially I didnt do that, I kept each bit in the same order as the columns. This meant in the code, I constantly had to do 8-ColumnOffset, wasting a bit of computation time- but it made it easier to debug, since I could look at a hex sequence and verify if the expected blocker bit was set. Later I reversed this, to save the computation (but also had to resave all my blocker files). So for example, in the first blocker byte, the first column 0 is bit 0, which is on the right side of the byte, not the left.
In old days, we would draw this as such:
_ _ _ _ _ _ _ _
| ^-column 1
^ column 2
So thats what I mean by backwards, youd normally think of columns going left to right, but thats not how bits are ordered within bytes :) Destiny Hunter Level Editor usage overview](https://i.ytimg.com/vi/wXhexS-ZkhE/mqdefault.jpg)




