Pico Computer 3 - Fuzix v0.17

Pico Computer 3 running Fuzix: a kernel, a C compiler and an MMBasic
translator, all on the machine itself.

Flash both. fuzix.uf2 to the board, pc3-sd-cc.img.gz to an SD
card of 1 GB or more. The card's binaries are statically linked, so a
new kernel with an old card runs the old C library, and since v0.9 the
two refuse each other outright rather than misreading.

The keyboard stops working when a program is busy — fixed

A program streaming PRINT output could not be stopped with Ctrl-C
from the USB keyboard, while Ctrl-C from the serial console worked.

The keystroke was never decoded. TinyUSB's host task is pumped from
three places and all three assume the process eventually stops running:
the idle loop, the moment before a tty reader blocks, and a preempt
trampoline gated on not being inside a syscall. A process that only
writes reaches none of them — always runnable, never reading the tty,
and inside write() for almost the whole of a line because every
character is rendered to the display on the way past.

The symptom named it exactly: typing during the stream produced one
character, the first key pressed, and only once the program had ended.
hid_poll leaves exactly one report request in flight, and the
completion callback both decodes the report and is the only thing that
lets it re-arm — so the first key completed its transfer in hardware and
sat undelivered, and every later key had no outstanding request to
complete and was lost on the wire.

There is now a fourth pump site on the output path, where the time
actually goes: 88 bytes of kernel flash, one 32-bit timer read per
character, a real pump at most every 5 ms.

New in MMBasic

• LOAD JPG, LOAD PNG and SPRITE LOADPNG — MMBasic's own
  picojpeg and upng, as separate programs, so a BASIC program that never
  touches an image pays nothing for them. PNG needs the whole image
  inflated before a pixel appears, which is why it comes out of a PSRAM
  arena. Transparency is composited by simply not drawing the pixel,
  where the reference reads the screen back.
  Watch the default: transparent is 0, which is palette black, so
  a PNG with a transparent surround draws a black box. Pass -1 to let
  the screen show through. A real PicoMite does the same.
• ARRAY SLICE and ARRAY INSERT — one line through an array of
  two or more dimensions, and far quicker than the equivalent FOR
  loop. MATH SLICE and MATH INSERT are the same two commands, as
  they are in the interpreter.
• COLOUR MAP — a whole array of colour codes 0-15 turned into
  RGB888 in one statement, through the default palette or one of your
  own.

That empties the "finish what is already there" category of the coverage
list: 220 of MMBasic's 353 names now translate.

Also fixed

• DIM s(4) = (1,2,3,4) under OPTION BASE 1 filled the wrong
  elements — s(1) held 2 and s(4) held nothing.
• A refused batch of pixels in LOAD IMAGE/JPG/PNG was ignored,
  so an image could be quietly incomplete. It stops now.
• mmedit's function-key line was always one keystroke late: blank on
  entering the editor until you pressed something, or for five seconds.
  Measured 5.43 s before, 0.41 s after.
• ...and that fix erased every status-line message, which a user
  found by beautifying a program: BEAUTIFIED went up in red and the
  function-key legend went straight back over it 17 ms later, too fast
  to read. NOT FOUND, CLIPBOARD IS EMPTY and the rest went the same
  way. Fixed, and pc3-sd-cc.img.gz was rebuilt for it on 19 August —
  if you took the card image before then, take it again. Nothing else
  in the release changed.

Verified on the machine

Gates: make check clean, cgate byte-identical, tokgate 84/0, fcctests
62/0, qemu native sweep 63/0, c-testsuite 165, cpptest clean,
ioctlcheck 62 codes with no duplicates, relcheck agrees on 0.17.

On the board: MM.VER answers 0.17 from a program the card's own mmbc
and cc built; both array-slice tests produce output identical to the
host, the manual's own two examples among them; a PNG loads with 256 of
256 pixels changed; and the editor's legend was timed with the fixed and
unfixed binaries in turn.

Built against TinyUSB 0.20

The kernel now uses TinyUSB 0.20, whose improvements are in the USB
host stack — which on this machine is the keyboard and the hub. It
is the version the PC3's MMBasic firmware uses, so all three
environments on the board are finally on one.

It had not been. BUILDING-PC3.md had said "TinyUSB must be 0.20" from
the day it was written while the kernel was built against the 0.18 the
SDK bundles, because the upgrade command it gave named a path that does
not exist unless the SDK is fetched rather than local. The instruction
could not be run, was not run, and no gate looks at this. The build
now asserts the version at configure time and refuses to compile
against the wrong one, printing the command to fix it.

Found on the way, and worth knowing if you build this yourself: which
SDK the build used was recorded only in build/CMakeCache.txt —
the Makefile's PICO_SDK_PATH is commented out and nothing else set
it. Deleting build/ silently changed the USB stack. The build now
uses the self-contained SDK that pico_sdk_import.cmake pins (2.3.0),
so it no longer reaches outside its own tree.