Uploaded May 2025 | Updated September 2026, 2 weeks ago
To celebrate the 50th anniversary of the IBM 5100, we developed this capability demonstration of a demoscene-type side scroller for the PALM processor. Typically, only IBM CE/FE specialist were aware of the built in DCP (diagnostic control program) that allows direct setting of main memory (commonly called a "system monitor"). However, the PALM instruction set is described in the original IBM 5100 MIM documentation (Appendix C). In addition, after researching the IBM SCAMP prototype project that led to the IBM 5100, we found a 1972 document that fully describes the PALM instruction set - making this a contemporary processor with the Intel 4004/8008, but built using IBM's proprietary SLT (solid logic technology) fabrication (or "Dutchess" modules).
In general, the IBM 5100 is the closet one can get to the 1960s technology that ran the IBM S/360 and S/3 systems. But it has all the attributes that we are familiar with today in a personal/portable computer: boot up system software, keyboard input, video display, and a byte addressable memory space.
The IBM 5100 is also associated with the famous John Titor time travel story of c. 2001, which is later depicted in the Steins;Gate anime series c. 2011.
This is also a demonstration of the "daisy chain" multi-monitor output capability of the IBM 5100, using the BNC composite output video output jack on the back side of the system.
Because the BASIC (and APL) of this system faithfully replicates the "line printer" style of interactive usage, this type of (side scroller) program is not possible using this system's BASIC or APL software. And there is onboard support for anything like VT52/VT100, etc., so this is not just using any kind of escape-sequence parsing. The 64x16 CRT screen display is mapped to a region of main memory. And so, a custom machine code program can be loaded and perform logic operations that manipulate this memory region (a convention later used on the Commodore PET and subsequent systems).
A BASIC-only 16KB configured IBM 5100 was price listed at about $6500, which included the 200KB capacity DC300 data storage tape (which had more capacity than the 8" floppy disks at the time). Other vendors (like 3M) later released QIC DC61250 tapes, that used the same format and double the storage capacity (without requiring any system or ROM changes).
A deeper look of the PALM assembly code used for this software will be prepared after the June VCF Dallas 2025 event.
NOTE: We've gone back and forth on whether this should be called a "vertical side scroller" or "horizontal scroller" :)
The sound bites near the middle of this video are clips from the Steins;Gate series, of each of the three main characters.
For a discussion on the SCAMP prototype:
https://voidstar.blog/scamp-a-review-50-years-later/
For a discussion about this specific program, see:
forum.vcfed.org/index.php?threads/ibm-5100-side-scroller-presentation-new-palm-machine-code.1253061
Tech docs, code, and notes are also here:
github.com/voidstar78/IBM_5100_DOCS/tree/main/SIDESCROLLER
And for my discussions on the IBM 5100:
https://voidstar.blog/ibm-5100-personal-computer/
youtube.com/watch?v=JIJNrBaTenM
To celebrate the 50th anniversary of the IBM 5100, we developed this capability demonstration of a demoscene-type side scroller for the PALM processor. Typically, only IBM CE/FE specialist were aware of the built in DCP (diagnostic control program) that allows direct setting of main memory (commonly called a "system monitor"). However, the PALM instruction set is described in the original IBM 5100 MIM documentation (Appendix C). In addition, after researching the IBM SCAMP prototype project that led to the IBM 5100, we found a 1972 document that fully describes the PALM instruction set - making this a contemporary processor with the Intel 4004/8008, but built using IBM's proprietary SLT (solid logic technology) fabrication (or "Dutchess" modules).
In general, the IBM 5100 is the closet one can get to the 1960s technology that ran the IBM S/360 and S/3 systems. But it has all the attributes that we are familiar with today in a personal/portable computer: boot up system software, keyboard input, video display, and a byte addressable memory space.
The IBM 5100 is also associated with the famous John Titor time travel story of c. 2001, which is later depicted in the Steins;Gate anime series c. 2011.
This is also a demonstration of the "daisy chain" multi-monitor output capability of the IBM 5100, using the BNC composite output video output jack on the back side of the system.
Because the BASIC (and APL) of this system faithfully replicates the "line printer" style of interactive usage, this type of (side scroller) program is not possible using this system's BASIC or APL software. And there is onboard support for anything like VT52/VT100, etc., so this is not just using any kind of escape-sequence parsing. The 64x16 CRT screen display is mapped to a region of main memory. And so, a custom machine code program can be loaded and perform logic operations that manipulate this memory region (a convention later used on the Commodore PET and subsequent systems).
A BASIC-only 16KB configured IBM 5100 was price listed at about $6500, which included the 200KB capacity DC300 data storage tape (which had more capacity than the 8" floppy disks at the time). Other vendors (like 3M) later released QIC DC61250 tapes, that used the same format and double the storage capacity (without requiring any system or ROM changes).
A deeper look of the PALM assembly code used for this software will be prepared after the June VCF Dallas 2025 event.
NOTE: We've gone back and forth on whether this should be called a "vertical side scroller" or "horizontal scroller" :)
The sound bites near the middle of this video are clips from the Steins;Gate series, of each of the three main characters.
For a discussion on the SCAMP prototype:
https://voidstar.blog/scamp-a-review-50-years-later/
For a discussion about this specific program, see:
forum.vcfed.org/index.php?threads/ibm-5100-side-scroller-presentation-new-palm-machine-code.1253061
Tech docs, code, and notes are also here:
github.com/voidstar78/IBM_5100_DOCS/tree/main/SIDESCROLLER
And for my discussions on the IBM 5100:
https://voidstar.blog/ibm-5100-personal-computer/
youtube.com/watch?v=JIJNrBaTenM







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


