Depth: a ball behind the near pillars and in front of the far ones

The demo for what V5 added. Four pillars at four distances, each ONE 8 by
8 tile stretched to its own width and height, and a ball walking past all
of them at a distance between two.

What it shows is the thing an ordering cannot. The ball is sprite NOUGHT
and every pillar is numbered after it, so table order puts the ball in
front of all four - and it is still hidden behind two of them, because the
depth buffer is asked per column. Caught mid-straddle in the checks: the
ball is 48 wide and the pillar 32, so it shows on both sides and nowhere
across the middle.

Writing it found the conceptual trap in the feature, which is now written
down where somebody will hit it. The pillars first carried their own
distance in their entries AND wrote that same distance into their columns,
so each was asked whether it was in front of itself - and 20 is not nearer
than 20, so all four vanished. THE BUFFER IS WHAT HAS BEEN DRAWN AND A
SPRITE'S DEPTH IS A QUESTION ASKED OF IT. Scenery writes it; it does not
ask.

Also found that a scheme only gives a colour to index one. The default
palette sets each scheme's paper and ink and nothing between them, so
art drawn in index two comes out black until a program writes a palette.

And the fixture disk's root directory was full: four blocks, 32 entries,
all taken, so adding an app failed the whole disk build. Loudly, which is
the right way round - but it is a wall that moves for free, so it is eight
blocks and 64 entries now.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E2JrLzFvuFX9fgi1LDRjrW

Tests/makedisks.sh

@@ -65,11 +65,15 @@ for i in 1 2 3 4 5 6 7 8; do "$TOOL" put "$DISKS/sbfs.img" "filler$i.txt" >/dev/
 # to the hardware, so something has to check that one still gives the machine back.
 #
 # notes.txt is there so that loading something that is not a program can be tried too.
-# 512K, and four directory blocks for 32 files. It was 64K and 16, which was ample for a
+# 512K, and eight directory blocks for 64 files. It was 64K and 16, which was ample for a
 # disk that held programs and nothing else - but the native assembler reads SOURCE from
 # here, and the CosmOS sources alone are 104,142 bytes against the 65,536 a 256 block disk
 # holds. A machine that is going to assemble itself has to be able to hold its own source.
-"$TOOL" format "$DISKS/cosmos.img" 2048 4 >/dev/null
+#
+# Four blocks held 32 files and every one of them was taken, so adding an app failed the
+# whole disk build - loudly, which is the right way round, but it is a wall that moves for
+# free and there is no reason to stand next to it.
+"$TOOL" format "$DISKS/cosmos.img" 2048 8 >/dev/null
 "$ROOT/Assembler" -I "$ROOT/Programs/CosmOS/Source" \
     "$ROOT/Programs/CosmOS/Apps/greet.asm" -o "$WORK/greet.sbx" >/dev/null
 "$TOOL" put "$DISKS/cosmos.img" "$WORK/greet.sbx" >/dev/null
@@ -135,6 +139,11 @@ for i in 1 2 3 4 5 6 7 8; do "$TOOL" put "$DISKS/sbfs.img" "filler$i.txt" >/dev/
 "$ROOT/Assembler" -I "$ROOT/Programs/CosmOS/Source" \
     "$ROOT/Programs/CosmOS/Apps/Sprite.asm" -o "$WORK/Sprite.sbx" >/dev/null
 "$TOOL" put "$DISKS/cosmos.img" "$WORK/Sprite.sbx" >/dev/null
+# Depth.sbx is the one that shows what a depth buffer is for: a ball behind two pillars and
+# in front of two others, decided per column rather than by any ordering of the table.
+"$ROOT/Assembler" -I "$ROOT/Programs/CosmOS/Source" \
+    "$ROOT/Programs/CosmOS/Apps/Depth.asm" -o "$WORK/Depth.sbx" >/dev/null
+"$TOOL" put "$DISKS/cosmos.img" "$WORK/Depth.sbx" >/dev/null
 # Crash.sbx breaks in each of the four ways the system now catches, which is the only way to
 # reach a fault screen from a recorded test.
 "$ROOT/Assembler" -I "$ROOT/Programs/CosmOS/Source" \