Unleash the Beast!
You've built your MicroBeast and got it working, so you're probably feeling rightly proud of yourself. Maybe you've played a bit of Zork, or used the calculator. But now what? Beast User is here to bring you tips, tricks and tutorials to help you get even more fun out of your MicroBeast (or NanoBeast!)
The new Feersum Technology NanoBeast is nearly with us! It shares a lot of DNA with the MicroBeast, but there are some subtle differences that might call for special-case handling in any generic cross-beast software. How do we go about that?
The easiest approach is to look at the device_id location in the firmware. This will return 0x1 if you're currently running on a MicroBeast, and 0x2 if you're running on a NanoBeast, as per these defined constants.
The downside to this approach is that this magic memory location isn't at a fixed address: the next firmware released could move it to a different address. And it doesn't exist at all for firmware versions prior to 1.8.
This means that to be truly portable we'd have to detect the firmware version first, and then detect the hardware platform, which is a tad irksome, but not insurmountable.
What we need is a more portable approach.
We can start by taking a look at how the firmware does it: what's writing 0x1 or 0x2 into the device_id location?
This code is writing values to the PIO_A_CTRL and PIO_B_CTRL IO ports. These ports map to the Z84C20 PIO controller chip. This is the chip that provides the two 8-bit bidirectional I/O ports (with handshaking) that's used on the MicroBeast.
And that's the crucial part: the NanoBeast does not use the same chip, it has custom PIO logic in its own CPLD IC.
Here are the PIO-related IO ports for both devices, side by side:
| IO address | MicroBeast | NanoBeast |
|---|---|---|
| 0x10 | Port A data | Port A data |
| 0x11 | Port B data | Port A direction |
| 0x12 | Port A control | LCD Translate (low) |
| 0x13 | Port B control | LCD Translate (high) |
| 0x14 | Port B data | |
| 0x15 | Audio | |
| 0x16 | Interrupt control | |
| 0x17 | I2C data |
So we can see that on a NanoBeast, ports 0x12 and 0x13 are no longer PIO_A_CTRL and PIO_B_CTRL but rather something new and mysterious called LCD Translate. I surmise this is glue logic in the NanoBeast's CPLD to support the NanoExplorer peripheral, which has a single line LCD display.
Crucially, these registers have an ID function, in that if we write the value NIO_TEST_BITS to both LCD control registers, the lower one will respond with NIO_VALID_LOWER and the upper one with NIO_VALID_UPPER.
If we pull the same trick on a MicroBeast we will be writing to PIO_A_CTRL and PIO_B_CTRL. The value chosen (NO_TEST_BITS, 0x4f) has the effect of setting a PIO port into input mode (Mode 1), so it will affect the MicroBeast's PIO ports, but does so in an electrically safe way.
When we attempt to read back PIO_A_CTRL and PIO_B_CTRL on the MicroBeast we will get nonsense, because those registers are write-only in a real PIO chip.
The BeastOS firmware does hardware detection before it sets up the PIO ports to support system functionality. If we emulate how it works in our own code, we'll have clobbered the system PIO port configuration on a MicroBeast. Therefore it is crucial to restore the ports to a known, working state on the MicroBeast, otherwise we might find that the Real Time Clock, I2C, and UART no longer function.
Unfortunately it's not as simple as reading the incumbent values of PIO_A_CTRL and PIO_B_CTRL before we start messing about and restoring them afterwards: remember that real PIO control registers are write-only.
We can crib the right values from the firmware source code.
Here's what it looks like in Forth, the World's Greatest Language:
( microbeast ports)
0x10 constant M_A_DATA
0x12 constant M_A_CTRL
0x11 constant M_B_DATA
0x13 constant M_B_CTRL
( nanobeast ports)
0x10 constant N_A_DATA
0x11 constant N_A_DIR
0x14 constant N_B_DATA
( nanobeast detection)
0x4f constant NIO_TEST_BITS
0xd4 constant NIO_VALID_LOWER
0xfa constant NIO_VALID_UPPER
0xcf constant M_B_MODE
0xff constant M_B_IOMASK
: is-nanobeast
NIO_TEST_BITS M_A_CTRL OUT
NIO_TEST_BITS M_B_CTRL OUT
M_A_CTRL IN NIO_VALID_LOWER =
M_B_CTRL IN NIO_VALID_UPPER =
and
( restore state)
M_B_MODE M_B_CTRL OUT
M_B_IOMASK M_B_CTRL OUT
;
: wotbeast
is-nanobeast IF ." nanobeast" ELSE ." microbeast" THEN CR ;
is-nanobeast is a new word that does the actual checking, and wotbeast uses it to print a human-readable identifier.
And here's that code running on a NanoBeast and a MicroBeast, side by side:
If you'd like to watch a video of me doing this from scratch then you're in luck:
The 1.8 firmware's built-in device_id facility is supremely useful, as it is a cached version of the above hardware check, done at the right time (i.e. before the PIO ports got set up by the system for its own use).
If we can use that instead of probing the hardware ourselves then we don't perturb the hardware and we don't have to restore it afterwards.
But the forwards and backwards compatibility remains a problem. For this reason, it is highly likely that the NanoBeast release firmware will include the same functionality in a more portable form: possibly as part of the existing MBB_GET_VERSION BIOS call.
The new Feersum Technology NanoBeast is nearly with us! It shares a lot of DNA with the MicroBeast, but there are some subtle differences that might call for special-case handling in any generic cross-beast software. How do we go about that? Examining the firmware The easiest approach is to look
I just released version 0.6.1 of SLIDE, the PC<-->Beast serial file transfer tool.
This version of SLIDE brings it up to date with the latest version of the SLIDE Protocol spec. The headline item is the introduction of a "command channel" which allows your main computer to to send simple commands to the MicroBeast and get responses back, during a file transfer session. Currently those commands are:
VOLS - what volumes (drives) are present on the 'BeastDIR - what files are in a particular volume?REN - rename a fileDEL - delete a fileI know what you're thinking: all MicroBeasts have two drives but that might not always be the case!
These commands are mainly intended for use by impending BeasTTY features, but they're available right now in the command line helper tools:
./slide probe /dev/ttyUSB4 --start-cmd "slide r" --cmd volswill get you:
SLIDE — command-channel probe (wire v0.3 §2)
Port: /dev/ttyUSB4 @ 19200 baud
Probe: ENQ 0x05, 3 attempt(s), 500ms echo timeout
Typing slide r at the CP/M prompt...
✓ Z80 connected. (46 stray byte(s) skipped, wakeup signature seen)
--- Probe result (after handshake) ---
Outcome: supported
Attempts: 1
Queued before probe: (none)
Stray bytes during probe window: (none)
VER raw: 30 30 30 31 ('0001')
Version: major 0, minor 1
We speak: major 0, minor 1
--- CMD_VOLS ---
Status: 0x00 — ST_OK
Present: A: B:
Logged: A: B:
Current: B:
--- FIN exchange (session-intact check) ---
FIN echoed. The peer was still in its file loop and exited
cleanly — the probe did not disturb the session.
VERDICT: probe outcome 'supported', session intact. ./slide probe /dev/ttyUSB4 --start-cmd "slide r" --cmd dir --drive a:results in:
SLIDE — command-channel probe (wire v0.3 §2)
Port: /dev/ttyUSB4 @ 19200 baud
Probe: ENQ 0x05, 3 attempt(s), 500ms echo timeout
Typing slide r at the CP/M prompt...
✓ Z80 connected. (46 stray byte(s) skipped, wakeup signature seen)
--- Probe result (after handshake) ---
Outcome: supported
Attempts: 1
Queued before probe: (none)
Stray bytes during probe window: (none)
VER raw: 30 30 30 31 ('0001')
Version: major 0, minor 1
We speak: major 0, minor 1
--- CMD_DIR (A:) ---
Status: 0x00 — ST_OK
USER NAME ATTR BYTES
0 PIP.COM 7424
0 STAT.COM 5248
0 KCALC.COM 37504
0 SIEVE.COM 1792
0 MBASIC.COM 24320
0 ZORK1.COM 8704
0 ZORK1.DAT 84992
0 SLIDE.COM 2944
0 UPLOAD.COM 640
0 DOWNLOAD.COM 512
0 WRITE.COM 896
0 RESTORE.COM 768
0 SETOPTS.COM 512
0 VLOAD.COM 896
0 VPEEK.COM 896
--- FIN exchange (session-intact check) ---
FIN echoed. The peer was still in its file loop and exited
cleanly — the probe did not disturb the session.
VERDICT: probe outcome 'supported', session intact../slide probe /dev/ttyUSB4 --start-cmd "slide r" --cmd ren --match=SLIDE.COM --to=SLIDE2.COMresults in:
SLIDE — command-channel probe (wire v0.3 §2)
Port: /dev/ttyUSB4 @ 19200 baud
Probe: ENQ 0x05, 3 attempt(s), 500ms echo timeout
Typing slide r at the CP/M prompt...
✓ Z80 connected. (46 stray byte(s) skipped, wakeup signature seen)
--- Probe result (after handshake) ---
Outcome: supported
Attempts: 1
Queued before probe: (none)
Stray bytes during probe window: (none)
VER raw: 30 30 30 32 ('0002')
Version: major 0, minor 2
We speak: major 0, minor 2
--- CMD_REN (current drive SLIDE.COM -> SLIDE2.COM) ---
Status: 0x00 — ST_OK
(no records — probe-only exchange completed)
--- FIN exchange (session-intact check) ---
FIN echoed. The peer was still in its file loop and exited
cleanly — the probe did not disturb the session.
VERDICT: probe outcome 'supported', session intact../slide probe /dev/ttyUSB4 --start-cmd "slide2 r" --cmd del --match=RESET.COMgets you:
SLIDE — command-channel probe (wire v0.3 §2)
Port: /dev/ttyUSB4 @ 19200 baud
Probe: ENQ 0x05, 3 attempt(s), 500ms echo timeout
Typing slide2 r at the CP/M prompt...
✓ Z80 connected. (47 stray byte(s) skipped, wakeup signature seen)
--- Probe result (after handshake) ---
Outcome: supported
Attempts: 1
Queued before probe: (none)
Stray bytes during probe window: (none)
VER raw: 30 30 30 32 ('0002')
Version: major 0, minor 2
We speak: major 0, minor 2
--- CMD_DEL (current drive RESET.COM) ---
Status: 0x00 — ST_OK
(no records — probe-only exchange completed)
--- FIN exchange (session-intact check) ---
FIN echoed. The peer was still in its file loop and exited
cleanly — the probe did not disturb the session.
VERDICT: probe outcome 'supported', session intact.As you can see, it's a little verbose: there's a lot of diagnostic information in there that we used during backwards compatibility testing.
We did a lot of backwards compatibility testing...but there are always gremlins lurking. If you're feeling helpful please adopt slide v0.6.1 as your daily driver and give it a whirl while we wait for the new BeasTTY features - let me know of any issues!
I just released version 0.6.1 of SLIDE, the PC<-->Beast serial file transfer tool. This version of SLIDE brings it up to date with the latest version of the SLIDE Protocol spec. The headline item is the introduction of a "command channel" which
The People of the Line lived a simple, peaceful existence until one day an inter-dimensional portal appeared, spewing terrifying number-based aliens on the unsuspecting citizenry! Only you, with your conveniently digit-specific attack ship, can save the line dimension from unwelcome numeracy! 0:00 /2:05 1× nVADERS! is a game
BeasTTY got a major summer 2026 upgrade. Check out all the new features.
A VideoBeast release seems imminent: we round up all the currently known information.
Recently there was an innocuous comment on the MicroBeast discord from our Great Leader: which led me down a bit of a rabbit-hole. Why's it hard? It's hard because of a well-documented z80 shortcoming: if an LD A,I or LD A,R is itself interrupted,
If binary and hexadecimal is just so much gobbledegook to you, try this basic primer.
You've probably used a terminal emulator like Terraterm or Minicom with your 'Beast countless times, but you might be surprised to learn that it's actually designed to work with a specific terminal: the DEC VT52 circa 1975. Unlike the more well-known VT100, it's no looker. And also unlike the VT100, it is not well-supported by modern terminal emulators. The only ones I'm aware of are the one built into the Atari ST's GEM, xterm, and the open-source (Windows only) kgober/VT52.
This is a pity, because the VT52 supports a number of control codes that allow it to do exciting things like move the cursor, clear the screen, enter graphics mode and, .... well that's about it really, but you can achieve a lot with those, like:
The rudimentary game above uses VT52 control codes to move the cursor so that it can draw the bat, the ball and the score in their correct places. It's not blazingly fast, and it's a bit flickery, but it is playable!
The terminal that's being used to play that game is BeasTTY.
blowback
BeasTTY has a number of unique features:
The simplest way is to click on this link which also appears top-right on the github page.
Then click on the "Connect" button at the top, and choose your 'Beast in the resulting dialogue box:
Click on the big square in the middle (so the border goes solid) and hit ENTER, and you should be rewarded with your CP/M prompt:
Type some commands to get more output:
This is the "Amber CRT" display option with the original VT52 font. It looks its authentic best in white:
You can change the CRT colour (or switch to a modern "Clean" look) using the controls at the top of the screen:
If you want to change the font, open the "Settings" section underneath the main text window, and choose a font from the "CRT font" drop-down:
The fonts only apply in CRT mode: in "clean" mode you get a built-in monospaced font. Also note that the VT52 ROM font is the only one that supports the custom VT52 alternate graphics set (although I wouldn't get too excited, it's a pretty poor choice).
There are a couple of ways to send a file from your PC to your 'Beast using BeasTTY.
Just find the file you want to send in your file manager, and drag it onto the central region of the BeasTTY window (make sure your 'Beast is currently logged into a writable drive (i.e. B: not A:):
Notice the "chip" top right that shows you the progress: it also gives you the option to cancel the transfer.
This works because when you drag a file into the window, BeasTTY first sends the command "B:SLIDE R\r" to your 'Beast, which executes B:SLIDE.COM R which runs the SLIDE executable in receive mode.
So for this to work, you're going to need SLIDE.COM on your B drive. You can get it from the SLIDE repo.
Note that versions of the MicroBeast firmware from 1.7 onwards include the SLIDE.COM binary on the A disk as standard. In this case, you need to tell BeasTTY that you want to run the A drive version - you can do this by expanding "Settings", then expanding the "SLIDE file transfer" section, then changing the "Auto-send command" option: in this case, change it to A:SLIDE R - don't forgot the 'R' at the end ("receive" mode).
Another way to send a file is to click the "Send File" button at the top of the screen. This will give you a standard OS file picker where you can choose the file you want to send.
Sending a file from the 'Beast is initiated from the 'Beast itself. In the terminal window, type A:SLIDE S <name-of-file> or B:SLIDE S <name-of-file> if your SLIDE.COM binary is on the B drive.
The "S" after "SLIDE" means "send".
You can see in my example that the received file is automatically saved to a folder called "INCOMING" on my hard disk. This is achieved by setting the "Save received files to a folder" option and specifying a folder with "Change folder...".
If you turn off "Save received files to a folder" then received files will use the standard browser download mechanism.
SLIDE lets you send more than one file at a time!
Simply drag multiple files onto the BeasTTY window in one go. SLIDE will transfer them all individually.
It probably doesn't come as a great surprise to hear that you can select multiple files in the file picker that appears when you click on the "Send file" button:
Type SLIDE S <file1> <file2>... to send multiple files from the 'Beast to BeasTTY with SLIDE (that lone S means "Send"). You can specify as many files as you like, but remember that the whole line can only be 128 characters.
These will end up in your "Save received files to a folder" folder, as for the single file case. If you haven't set this folder, your browser will use the standard download mechanism, but it will likely prompt you first to check that it's OK to download multiple files.
You've probably used a terminal emulator like Terraterm or Minicom with your 'Beast countless times, but you might be surprised to learn that it's actually designed to work with a specific terminal: the DEC VT52 circa 1975. Unlike the more well-known VT100, it's
Series
Having fun with the MicroBeast's gorgeous LED displays.
Series
Let's take advantage of the 'Beast's excellent expansion options to build a simple working traffic light model.
Series
In this series of posts you'll learn to build a set of joystick interfaces for the MicroBeast/NanoBeast, each more capable than the last.
Got a tip or trick you want to share? Fancy writing a tutorial or even a whole series? Find us on the Discord channel and let's get started!