Everything here is new since v0.25. The kernel (fuzix.uf2) and the
card image are both new: the USB fix is in the kernel, TILEMAP and the
rest are on the card.
Tiles
TILEMAP, MMBasic's tile engine — the command, the function, and
everything in them. Four maps, each a grid of two-byte cells drawn
from a tileset in a flash slot; 64 sprites that move over them;
TILEMAP DRAW for the window of the world you want, on N, F or
L, with a see-through colour; TILEMAP(COLLISION ...) and
TILEMAP(SPRITE HIT ...) for the game's logic; the map and attribute
tables read from a DATA label with your own READ position left
alone; every argument range and every error string the reference has.
The rules are MMBasic's — tiles count from 1 and 0 is empty, the
viewport chooses tiles rather than clipping them — and the PicoMite's
own Breakout runs unedited, from "Generating tileset..." to "Thanks for
playing!" (/root/cc/breakout.bas on the card, samples/breakout.bas in the tree). The manual's chapter
"Tiles and their sprites" has the tables. One recorded departure:
DRAW composes a row of tiles at a time through the blit window rather
than blitting each tile, which here would be a pair of system calls per
tile row.
FLASH LOAD IMAGE n, file$ [, O] decodes a BMP into flash slot
n (1–3), in the layout TILEMAP and BLIT FLASH read. Without O
an occupied slot is "Already programmed", as on a PicoMite, and
FLASH ERASE n clears it. The colours reduce the way the sprite
loaders reduce them, so a tileset made on the machine with SAVE IMAGE — which is how Breakout makes its bricks — round-trips exactly.
The decoding is loadimage's, in another process, so a program that
never loads a picture carries none of it.
A DATA item that names a CONST reads as its value. MMBasic's
own TILEMAP examples write their attribute tables as DATA SOLID, BRICK, ... and READ evaluates the names. Here they are folded when
the program is translated, wherever in the program the CONST is
declared. A string CONST stays text, since READ into a string
variable copies the item's text; an item that is not a constant is a
translation error naming the item, rather than a C compiler's.
The keyboard at boot
Booting with a USB keyboard attached no longer ends in panic: Invalid speed. Reported against v0.25 on both boards: now and then
the boot stopped with that line on the console, a blank HDMI and an
fsck on the next boot, while a keyboard plugged in after login was
always fine. The text was TinyUSB's host driver, which asked the root
port its speed at the start of every transfer and panicked if the
answer was "disconnected" — and a hub and keyboard powering up
together do drop the link for a moment while enumerating. The kernel
now runs TinyUSB 0.21, whose RP2350 host driver was rewritten, with
two fixes of this port's own: the driver as shipped panicked at host
start on a timed-out control transfer it had failed without clearing
its buffer, and the RP2350's hub turnaround fix (MULTI_HUB_FIX) is
switched on. A power-on boot may now print USB keyboard attached,
detached, attached in a row before the login prompt: that is the
same drop, handled. The story is in
Kernel/platform/platform-rpipico/PC3-IRQ-REVIEW.md; building the
kernel now needs the SDK's TinyUSB at 0.21.0 and patch(1), per
BUILDING-PC3.md.
The web server
httpd serves the whole file. A socket write() here returns
what the send window had room for, and httpd took anything short of
the full count as an error and closed the connection — so a file
longer than the window, about 5.6 KB, arrived cut off (breakout.bas
stopped at 5,802 of 14,226 bytes). Found while checking this release;
it now writes until the file is out, and the same file fetched from
another machine compares byte for byte with the original.
Verified on both boards
Both boards booted this kernel from this card image. PC3: the banner's
release 0.26, wifi -f (joined, DHCP lease), ntpdate, tlsca /etc/ca.pem (12,368 bytes, certificates checked), tlsget to
example.com (HTTP/1.1 200 OK), the card's own httpd serving files
of 4.5, 14 and 70 KB to another machine byte-identical to the
originals, MM.VER = 0.26 from a program built and run on the
board, tilepix.bas — the TILEMAP pixel-readback check — five zeros,
and cc -r sieve.c from the on-board C compiler; and, with a keyboard
on the hub, a reboot that printed USB keyboard attached, detached,
attached within 200 ms and went on to mount the root — the drop that
used to be the panic, handled. PC2: the same kernel
saying PICO COMPUTER 2, wifi answering no radio (Pico Computer 2),
MM.VER = 0.26, and with the root remounted read-only (proved by a
refused touch) fsck clean on every pass, then remounted read-write.
The usual rule after upgrading: recompile. The runtime is compiled
into bcrun and the layout helpers into the program, so a .bc built
before this release keeps the old behaviour of both. The card ships the
matched set, and MM.VER answers 0.26.
Updated kernel — 2 September
The fuzix.uf2 asset was replaced (commit 6ba513662; the card image and
manuals are unchanged) with three fixes to the TinyUSB 0.21 host driver,
found on this port's MicroPython sibling by putting a flash drive and a
touch panel on the hub beside the keyboard:
- a control transfer longer than two packets — a keyboard or panel whose
HID report descriptor runs past 128 bytes — panicked the original
kernel at boot withbuf_ctrl already available; such transfers are
now single-buffered; - a device slow to wake after its hub-port reset was abandoned by the
stack (it fails a transfer on the first timeout and never retries an
enumeration), which could cost you the keyboard when other devices
share the hub; every freshly reset device now gets 100 ms before it
must answer; - the host's event queue is four times deeper, so a burst of completions
at a multi-device power-up cannot silently drop one.
Proven on the board booting with a keyboard, a flash drive and a touch
panel all attached. The three faults are filed upstream:
tinyusb#3874,
#3875,
#3876. If your keyboard
worked, nothing changes; if boot sometimes lost it, fetch the kernel
again. The updated manual PDF carries the same note.
Updated kernel — 3 September
The fuzix.uf2 asset was replaced again (commit 347be6bc4) with a set of
USB host-driver hardening changes, validated against the PicoMite's own
TinyUSB 0.21 work on this hardware. The failures they address trace to a
documented silicon race — the RP2 chip keeps one handshake-result latch
shared between the control endpoint and the interrupt-endpoint poller, so a
keyboard's poll can misread a control transfer as timed out — and the fix
tolerates the race above the driver rather than rewriting it: a short grace
window on control-endpoint timeouts, keeping the control path exclusive to
the device being brought up during enumeration, and disabling a hub port
whose device failed to enumerate so it cannot interfere with the next one.
Board-proven booting with a keyboard, a flash drive and a touch panel on
the hub, the console responsive throughout and the keyboard working. If the
keyboard already came up reliably, nothing changes.