-
-
Notifications
You must be signed in to change notification settings - Fork 1
Upstream
Xpeccy+ follows Xpeccy by SAM style as a one-way feed:
useful upstream work is taken from it, nothing goes back - upstream has pull requests
disabled. Since 30 August 2026 this is not a GitHub fork either: the repository was detached
from the fork network. Nothing about the feed changes, because the git side never depended on
that label - upstream is a remote like any other, and the commands below are the same ones.
Most of what gets taken is uneventful and needs no record beyond the commit itself. This page is for the rest - the upstream changes that were looked at and deliberately left out, and the places where this fork keeps an answer of its own. A commit cannot say "I took this file but not that idea", and without a note somewhere the same argument gets re-fought at the next build.
Since 12 September 2026, builds are no longer gone through one at a time. The two trees have diverged far enough - machines instead of profiles, a rebuilt raster and border, our own timing and pacing, the log, the ZX-only build, folders as disks, run-ahead - that reading a whole upstream build as a unit costs more than it returns, and most of what is in one lands in a place where this fork deliberately does something else.
What still returns something is asking about one file, at the moment that file is being worked on:
git log upstream/master -- <path>
git diff main:<path> upstream/master:<path>
He knows this hardware, and a fix of his usually stands on its own. Both outside fixes in the
BaseConf work of September 2026 came out of exactly that query: the screen position of the
Evo text mode, and an NMI being taken ahead of a maskable interrupt. Take one with
git cherry-pick when it applies, otherwise write it here and say in the commit message
where it came from.
The old routine marked each build as handled with git merge -s ours. That has stopped, and
it should not be restarted: the mark moves the merge base, which would cut the per-file log
above off at the mark - the one query still being relied on. git log main..upstream/master
is therefore not a list of pending decisions any more. It is a feed to browse, and it grows.
Builds through 20260824 carry such a mark from the old routine; 20260828 and 20260830
were reimplemented here rather than merged, and nothing newer is marked at all.
Build 20260818 - the NOGFX and NOTSU bits of #00AF. Skips the bitmap and text layer
for the whole line when the picture is switched off, and adds the previously unimplemented
bit that turns tiles and sprites off. Prepared and built here, not merged. Both bits are
already handled where the picture is drawn in this fork, so what actually changes is text
mode under NOGFX and NOTSU itself, and nothing tested here exercises either. It is waiting
for a reason to go in, not for a fix. The one thing worth checking before it does: the bit
that is said to be NOTSU is upstream's reading of the hardware, and the TSConf documentation
does not describe it.
Build 20260819 - the line rendered in the horizontal blanking. Moves the whole-line
pre-render from the start of the line into the blanking, so that a line is prepared one line
ahead the way the video controller does it, and rewrites the frame interrupt position to
match. Tried and rejected: sprites come out shifted and the top line of the picture fills
with rubbish. The same shows on upstream's own build, so it is not something the merge
introduced. The reasoning behind it is sound and may come back later - the interrupt position
really is counted from the leading edge of the blanking, which the tsconf firmware confirms -
but the change as it stands costs more than it fixes.
Where the frame interrupt fires. Upstream adds the cost of rendering the line to the position, which drags the interrupt around with whatever is on screen and, on a heavy line, puts it past the end of the line, where it is never reached at all. That is a freeze, and it was one, in a demo, reproducibly. Here the position comes from the register alone.
Color 0 in text mode. Upstream shows the border wherever a text pixel has color 0. Only the tile and sprite layer is transparent; in the text layer color 0 is a color like any other, which is also what unreal does.
Palette writes take effect at the start of the next line rather than in the middle of the line being drawn. This one is a deviation from the hardware and is written down as such: unreal applies such a write at once. Applying it mid-line here leaves single dots of the wrong color, because the write lands a dot or two away from where the hardware would have put it, so the line boundary is the lesser of the two errors until the timing is exact.