- Rust 77.6%
- C 17.7%
- Nix 3.5%
- LLVM 0.8%
- Linker Script 0.4%
fc5ef61d42
The simulator is not the display -- it is one of two server apps that present the same display over the same UDP protocol. The other is the daemon that replaces the C firmware and drives the real panel. Neither is a client of the other. So display.rs, net.rs and hart.rs were in the wrong crate: nothing in them is simulator-specific. They move to servicepoint-display, which is a ServicePoint display minus the thing that emits light. The simulator keeps only panel.rs and its window; the hardware server will add a PRU backend against the same core. The end-to-end tests move with it. They never touched the window -- they cover exactly what the two servers have in common, which is everything a client can observe. No behaviour change. |
||
|---|---|---|
| crates | ||
| docs | ||
| programs | ||
| .gitignore | ||
| Cargo.lock | ||
| Cargo.toml | ||
| flake.lock | ||
| flake.nix | ||
| README.md | ||
servicepoint-riscv
Upload and run flat RV32IM programs on the CCCB AirportDisplay ("ServicePoint") over UDP.
The display firmware (mara/cape-cccb-apd) exposes a tiny RISC-V core via its
CMD_RISCV network command. Its 64 KiB RAM is mapped at 0x8000_0000, with the
reset entry point at offset 0. A program is a flat RV32IM binary that ends in a
0x00000000 halt word. See docs/protocol.md for the full
wire-format and machine-model reference.
Build
Uses a Nix flake (crane + Rust from nixpkgs 26.05):
nix develop # dev shell with cargo/clippy/rustfmt/rust-analyzer
cargo build --release
# or, build the package directly:
nix build
Usage
# Upload a flat RV32IM binary and start the core (defaults to the CCCB display):
servicepoint-riscv run program.bin
# Choose tick rate (µs/instruction) and target. Default is 1 = full speed;
# larger values slow the guest down. Note 0 is NOT "no delay" — the firmware
# reads it as its 125 µs default, the slowest setting.
servicepoint-riscv --target display.club.berlin.ccc.de:2342 run program.bin --tick-us 4
# Stage bytes into guest RAM without resetting:
servicepoint-riscv poke data.bin --offset 4096
# Halt the running core:
servicepoint-riscv stop
# Inspect the datagrams without sending them:
servicepoint-riscv run program.bin --dry-run
Default target is display.club.berlin.ccc.de:2342.
gorillas
A four-player GORILLA.BAS-style artillery game. The display is the screen; each player's terminal is only an input device, because the guest has no way to talk back to a client. One person starts the game, then everyone joins:
# one person uploads and starts it (this resets the core):
nix run .#gorillas -- start
# each player takes a slot 1..4 and aims live:
nix run .#gorillas -- play 1
# left/right aim up/down power space fire q quit
The packaged client already knows where its guest binary is. Building it by
hand (nix build .#gorillas) is only needed to upload it some other way, in
which case point the client at it with --binary or GORILLAS_BIN.
See docs/gorillas.md for the mailbox layout and why the
client is write-only.