Debug

Paste raw bytes, or use \xNN escapes for control bytes (e.g., \x1B = ESC, \x07 = BEL). Click Feed to send the parsed bytes through the wasm VT52 parser in ONE boundary call. Click 64 KB Stress to demonstrate SC-4 (one feed() call for 65 536 bytes — observe the single DevTools Performance entry).

TX bytes (last 64):

(none yet — press any key on the terminal to see TX bytes)

Sending 0 files via SLIDE

Clear scrollback?

Wipes the 10,000-line history.

Visible screen is unaffected. Snaps to live tail if you're scrolled up.

Clear command history?

This can't be undone.

Serial Configuration

On by default. The MicroBeast's Z80 UART uses host-side RTS as its CTS input for hardware auto-flow-control — without this, Z80→PC transmits (wakeup byte, ACKs, file data) are blocked at the Z80 UART. Turn this off if your hardware has RTS wired to a reset line instead. DTR is always de-asserted on connect (Pitfall #12 reset-pulse concern). Takes effect on the next Connect click.
Off by default — the picker only lists the Silicon Labs CP2102N (the chip on stock MicroBeast hardware). Turn this on if your MicroBeast uses a different USB-serial bridge (FTDI, CH340, CP2104) or you're connecting via a virtual COM port (USB-IP, Bluetooth-SPP, ser2net). Takes effect on the next Connect click.

MicroBeast default is 19200 8N1, no flow control. Single-tab ownership is enforced by Chromium — close any other Beastty tab that holds this port first.

Recent errors 
(no recent errors)

Browser-reserved Ctrl combinations

Ctrl+W, Ctrl+N, Ctrl+T are claimed by Chromium (close tab, new window, reopen closed tab) and cannot be intercepted by a web page. Use Ctrl+F4, Ctrl+Shift+N, or a different keybinding on the MicroBeast side if you need those control codes. Everything from Ctrl+A through Ctrl+Z (except W, N, T) is forwarded normally, as are Ctrl+@, Ctrl+[, Ctrl+\, Ctrl+], Ctrl+^, Ctrl+_.

Keyboard Shortcuts

About Beastty

Build
Built
SourceTBD

No telemetry. No data leaves your browser.

Requires a Chromium-based browser (Web Serial is a Chromium-only API).

SLIDE File Transfer

Received files land in your Downloads folder. Toggle this to pick a fixed destination.
No folder selected
Which drive holds SLIDE.COM, and what it is called there. BeasTTY transfers files with SLIDE specifically, so this names that binary — if you have renamed it, put the new name here; it still speaks the SLIDE protocol and still takes the standard R and S arguments. BeasTTY appends those itself, so type the program name only. For any other transfer program (XMODEM, KERMIT and friends) you drive the MicroBeast by hand.
Beastty adds R or S and the Enter
On by default. Before sending a file, Beastty types the start command at the CP/M prompt for you — with the location above, that is A:SLIDE.COM R. Turn this off if you prefer to start SLIDE on the MicroBeast yourself. Dragging files out of the pull pane still uses the location above, so pulls keep working either way.
Off by default. Starts SLIDE with RV instead of R — newer slide.com builds read the V as "write this file straight into VideoBeast video memory" rather than to disk. Older builds do not understand it, so leave this off unless you know the MicroBeast is running a build that does. This changes the command above it, so it only does anything while Auto-start is on; with auto-start off you choose R or RV yourself when you start SLIDE. Pulls are unaffected.
When off, drops and picker selections begin transferring immediately. Filename collisions are auto-renamed.

Paste settings

What every line break in pasted text becomes on the wire. Clipboard text on Linux is LF-only, which the MicroBeast does not take as a line break at all — hence the CR default. A CRLF pair in the clipboard counts as one break, never two. This is a separate setting from Settings ▸ Enter key sends: that one governs the Enter key, this one governs paste, and the two can hold different values. "As-is" passes the clipboard bytes through untouched.
How many bytes go out back-to-back before the pump waits. Every chunk is exactly this size except the last, whatever the bytes contain. Burst size is not what governs delivery: on real hardware 1 byte every 100 ms and 2 bytes every 200 ms are the same 10 B/s and behave identically, so it is the throughput below that matters. Bigger chunks at the same throughput simply mean fewer, larger bursts.
Idle time between chunks, giving the receiver room to drain. Measured on a real MicroBeast with no flow control: 1 byte every 200 ms — 5 B/s — delivers an 800 B block into VIBE intact, and 10 B/s only nearly works. 150 ms is about 6.7 B/s, in the gap between them. "None" means no pause at all: the wire is the only limit.
Throughput What the two rows above add up to — chunk size divided by pause. It is shown, never set: you describe the cadence and read the rate off it. When the open port was opened with hardware flow control the pump does not pace at all, because the receiver handshakes per byte and that beats any fixed cadence — the two rows keep their values, and they apply again the moment a bare port is opened, but they are not in force and this line says so. ≈ 5 B/s

Pacing applies unless the open port uses hardware flow control — including when nothing is connected. The paste chip reports the rate actually achieved while a paste runs.

Copy from the other beast?

File
From
To