Fuzix for the Pico Computer 3 and Pico Computer 2 — release 0.27.
One kernel serves both boards; it works out which one it is at boot.
What is new
A program that would not start, and the knob that starts it. A
compiled program has to fit the process pool beside the biggest other
process — usually the shell you typed the command into — so that the
swapper can always bring it back in. When it does not, the kernel says
so and names what it could not fit beside:
exec: pid 27 needs 76 blocks, 74 free beside a 10-block neighbour (pool 84)
That is not a report of free memory, and reading it as one sends you
looking at the wrong number. THUMB_BUDGET caps the native code the
compiler adds, so a large program keeps most of its speed and still
loads. PETSCII Robots is the worked example: 209,022 bytes and 76
blocks uncapped, 196,782 and under 74 with THUMB_BUDGET=140000, which
is the difference between refusing to start and playing. The knob is
not new — having it written down is. The manual chapter "When a program
will not start" covers it, along with THUMB_VERBOSE, BCODE_ONLY,
and what exec ./prog.bc is good for.
Every compiled program is smaller, because main gives back its dead
bytecode. A function translated to native ARM has kept its original
bytecode since the translator learned to reclaim it — except the main
line, excluded on the strength of a comment that had outlived the code
it described. Robots loses 5,428 bytes of code and two thirds of its
relocations; a program whose work sits in one long main line rather
than in Subs gains far more.
The MMBasic translator lives in the tree. Applications/mmb2c now
holds the translator, the Python reference implementation it is checked
against byte for byte, the runtime headers and the BASIC corpus, and
the compiler builds straight out of it instead of from copies kept in
step by hand. Nothing about the machine changes and the binaries are
byte-identical; there is simply one of each file now.
Proven on hardware
Both boards, before this was published.
Pico Computer 3 — banner Pico Computer 3, release 0.27 (on FUZIX 0.5); MM.VER 0.27 from a BASIC program translated, compiled and run
on the machine with cc -r; wifi -f to a DHCP lease; ntpdate and
the clock set; tlsca loading 12,368 bytes of certificates; a TLS
fetch returning 200 OK; httpd serving a 14,226-byte file to a browser
byte-identical to the source; and PETSCII Robots built and started on
the shipped card.
Pico Computer 2 — boots, reports no radio (Pico Computer 2),
MM.VER 0.27, root remounted read-only and proved so by a write that
failed, and fsck clean through all five passes. That board's radio
pins are its SD chip select, so a quiet filesystem is the thing being
tested.
Installing
Flash fuzix.uf2 the usual way — hold BOOT, click RESET, drag it onto
the drive that appears — and write pc3-sd-cc.img.gz (ungzipped) to a
card of 1 GB or more with any raw-image tool. The whole card is
overwritten. Then connect a monitor and a USB keyboard, switch on, and
log in as root; there is no password.
/etc/wifi.conf ships a placeholder, so wifi -f on a fresh card
joins nothing until you put your own network in it.
Assets
| file | |
|---|---|
fuzix.uf2 |
the kernel, for both boards |
pc3-sd-cc.img.gz |
the SD card, with the compiler and the BASIC corpus |
FUZIX-PC3-MANUAL.pdf |
the manual |
PC3-C-MANUAL.pdf |
programming the machine in C |