jake/SplitBit-Emulator
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Grid: fill the map, not the window

Browse Source 
Scrolling sideways walked off the end of what the program had filled, so
the grid went blank for six seconds and then came round again. A map row
holds 128 cells - 256 bytes at two a cell, whatever mode the screen is in -
and an eighty column screen shows eighty of them, so 48 were empty.

This is the third thing this loop has counted and the first right one. It
said forty, which filled half the screen. Then it asked the screen how wide
it was, which fixed what could be seen and was still wrong. ASKING THE
SCREEN IS RIGHT FOR FILLING A SCREEN AND WRONG FOR FILLING A MAP: a program
writing one screenful wants the window, and a program that scrolls wants
everything the window can be moved over. There is no register for that
because it is a property of video memory rather than of the display.

The check that should have caught it did not, and that is the more useful
half. periodic.py looked at 32 pixels - four cells at the left edge - so it
could not see a gap that was on the right, and at the cycle count it samples
the origin had moved to column 22 and the gap was off in the middle
distance. It reads the whole scanline now and says which column the picture
stops repeating at, which is how the two failures above were told apart.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E2JrLzFvuFX9fgi1LDRjrW
This commit is contained in:
Anachronaut
2026-08-30 19:00:28 -04:00
co-authored by Claude Opus 5
parent bcd42e75ca
commit 1aa45fcfc4
4 changed files with 44 additions and 10 deletions
Download Patch File Download Diff File Expand all files Collapse all files
Programs/CosmOS/README.md
+6
View File
@@ -690,6 +690,12 @@ carries. The map is 128 rows and 128 columns against a screen of 50 and 80, so t
around the edge are already drawn - scrolling moves the origin rather than 2,000 bytes of
screen, and what leaves the top has not gone anywhere.
It fills **all 128 columns of every map row**, not the eighty the screen shows. That is the
distinction a scrolling program has to make: asking the screen how wide it is - which there is
a register for - gives you the window, and a program that scrolls wants everything the window
can be moved over. Filling only the window leaves 48 empty columns, and scrolling sideways
walks into them.
The coarse registers move a whole cell and the fine ones move the remainder, and **they do not
carry into each other**, so the program does: