Pico Computer 3 Fuzix v0.25

Everything here is new since v0.23. v0.24 was published without an
announcement, so its changes are included below, under their own
heading — if you are coming from v0.23 you want both halves.

The screen modes, and what you type

MODE 1 and MODE 2 differ in size and depth and in nothing else —
640×480 in one bit against 320×240 in sixteen. Console output, PRINT
and TEXT behave identically in each, subject to OPTION CONSOLE, as
they do on a PicoMite with OPTION LCDPANEL CONSOLE.

MODE 1 used to leave text to the kernel console while MODE 2 drew it
with the interpreter's own glyph engine. That was a divergence dressed
as an improvement: two text engines with two cursors, so PRINT and
TEXT disagreed about where text went and PRINT @ moved only one of
them. Worse, in MODE 2 nothing echoed what you typed at an INPUT —
a program drawing its own text has to silence the console, or every
PRINT appears twice, and the terminal's echo then reaches only the
serial port. A program whose first line was MODE 2 printed its prompt
and then took input invisibly.

INPUT echoes, and shows a cursor. The interpreter does the editing
itself now, as MMBasic always has: characters appear as they are typed,
Backspace and Del rub out, Tab expands to the next multiple of
four, and MMBasic's own underline cursor — on for two thirds of a
second, off for a third — sits where the next character will go. The
echo follows OPTION CONSOLE like everything else printed.

Sprites

Sprites load from BMP files. SPRITE LOADBMP and BLIT LOAD (also
spelt BLIT LOADBMP), with the reference's window arguments:

SPRITE LOADBMP #1, "sheet", 64, 0, 16, 16   ' one 16x16 tile out of a sheet

The decoding is loadimage's, in another process, so no BMP reader is
compiled into your program. A window running off the picture is refused
rather than clipped, and — as in the reference — the colours are taken
by bit extraction rather than dithered: a sprite is data that gets
blitted about, and a dithered one changes colour when it moves.

A file name with no extension gets one. LOAD IMAGE "shot" and
SPRITE LOADBMP #1, "sheet" now append .bmp, which is what MMBasic
does and what programs written for a PicoMite expect.

SPRITE LOAD works at all. It parsed its file's header with a C
library function bcrun does not bind, so any program containing the
statement — anywhere, whether it ran or not — died at load with
no runtime function "sscanf".

The screen, and other programs

A child process no longer takes the screen back. A graphics program
that ran one — LOAD IMAGE, LOAD JPG/PNG, the sprite loaders — had
the console's display half switched back on underneath it the moment
that child exec'd, which painted the console cursor into the program's
picture and, invisibly until something printed, left its own output
mirrored onto the screen it thought it owned. The claim belongs to the
process that made it now.

New software on the card

TSCP chess, in /root/MMBasic/chess: Tom Kerrigan's engine in
Ceptimus's MMBasic conversion, with its pieces and its opening book,
distributed with the author's agreement. Run it from its own directory
and type help at the tscp> prompt. It is also this port's
demonstration of the sprite loaders — the pieces are cut out of one
240×20 BMP — and chess/mkspr.bas turns that sheet into the .spr file
SPRITE LOAD reads, on the machine itself.

From v0.24, which was never announced

F2 in the editor builds the program and runs it. On a PicoMite F2
is "save, exit and run", and the interpreter took the program straight
back. mmedit had no answer for that: it printed the two commands you
would have to type and left you at the shell. It now hands the file to
the compiler, which builds it — a .bas through mmbc first — and runs
it if it built. Ctrl-W does the same, as it does in MMBasic, and the
legend along the bottom of the screen has always said F2:Run.

# mmedit prog.bas          F2
cc -r prog.bas
wrote prog.mb.c
..........................
hello from prog
#

cc grew the -r that makes that possible, and it is worth having at
the prompt in its own right: cc -r prog.bas is a build and a run in
one command. Nothing runs if any pass failed.

A compile error stops there, with the errors on the screen — unlike the
interpreter, which put you back in the editor at the offending line.
And one thing to know before trusting the run: a line mmbc cannot
translate is commented out and reported, not treated as an error, so
the program builds without that line and F2 will run it. Read the
report rather than the fact that something ran.

cc's manual page was also describing a different compiler. It
documented -c, -S, -E, -O, -D, -I, -l, -M and -X, none
of which the cc on the card accepts. It now lists the five real
options and names the absent ones.

Verified on both boards

PC3: MM.VER 0.25, mmedit's F2, cc -r, chess built and run from the
shipped card with its pieces checked by pixel readback, INPUT's echo
measured on screen, wifi, ntpdate, a TLS fetch with certificates
checked, and httpd served to a browser. PC2: no radio (Pico Computer 2), the console mirror held across a child process, and fsck clean on
all five passes with the root read-only.

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.