Uploaded November 2022 | Updated September 2026, 2 weeks ago
This is a demonstration on how to enable the DCP (Diagnostic Control Program) of the IBM 5100, then use it to enter a brief PALM machine code sequence of instructions. This program displays the full set of characters built into the display card and projected onto the CRT.
Also showing how key presses are processed in the Level 3 interrupt and scan code results stored in registers, which can be read as memory offsets.
NOTE: This video is a practice to a longer upcoming video about the tape unit (in terms of lighting and avoiding glare on the screen and how to show both the screen and what keys are being pressed).
The program that was entered is described in greater detail at the following link:
https://voidstar.blog/ibm-5100-character-sets/
For general topics about the IBM 5100, see:
https://voidstar.blog/ibm-5100-personal-computer/
And for details of how this particular IBM 5100 was obtained:
https://voidstar.blog/ibm-5100-5110-sources/
This is a demonstration on how to enable the DCP (Diagnostic Control Program) of the IBM 5100, then use it to enter a brief PALM machine code sequence of instructions. This program displays the full set of characters built into the display card and projected onto the CRT.
Also showing how key presses are processed in the Level 3 interrupt and scan code results stored in registers, which can be read as memory offsets.
NOTE: This video is a practice to a longer upcoming video about the tape unit (in terms of lighting and avoiding glare on the screen and how to show both the screen and what keys are being pressed).
The program that was entered is described in greater detail at the following link:
https://voidstar.blog/ibm-5100-character-sets/
For general topics about the IBM 5100, see:
https://voidstar.blog/ibm-5100-personal-computer/
And for details of how this particular IBM 5100 was obtained:
https://voidstar.blog/ibm-5100-5110-sources/


![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)





