open https://gitlab.synchro.net/main/sbbs/-/issues/1214

Before I install syncarcade on my own BBS I decided to try it out on vert, however I'm seeing odd graphics appear in the top left hand corner of the screen.

I'm using SyncTerm 1.8 - GDI and access vert.synchro.net

Here is a video of the issue:

https://www.magnum.uk.net/dropzone/arcade1.mp4
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/1214#note_9914

Thanks for the report, and for the video -- that made this quick to pin down.

The cause is on our side, not SyncTERM's. The door asks the terminal to draw sixel images at the text cursor, via DEC private mode 80 (DECSDM). CTerm reversed that mode's set/reset sense in revision 1.328 (2026-06-28), and SyncTERM 1.8 ships CTerm 1.327 -- one revision earlier. So the sequence the door sends means the opposite of what it intends on 1.8: the terminal ignores the cursor and anchors every image at the top-left corner of the screen.

That is exactly what your video shows. The game picture itself lands top-left instead of centered, and -- more visibly -- the small partial updates the door sends between full frames (it repaints only the cells that changed, to save bandwidth) all pile into that same corner instead of landing over the part of the screen they belong to. Hence the block of scrambled graphics that keeps changing up there while the game plays on below it.

The doors now read the CTerm revision out of the terminal's device-attributes reply and send whichever of the two sequences that particular build reads as "draw at the cursor", so old and new SyncTERM are both handled. The same assumption was baked into SyncDOOM, SyncDuke, SyncMOO1, SyncSCUMM and SyncRPG, so all of them got the fix too.

Could you retest on cvs.synchro.net? The fixed Linux build of the door is running there now. vert.synchro.net serves the Windows build from the same directory, and that one has not been rebuilt yet, so vert will still show the problem.

Please stay on SyncTERM 1.8 for the retest -- 1.8 is the case being fixed, so it is the useful one to confirm. What you should see: no scrambled graphics in the top-left, and the game picture centered in the window rather than pushed against the left edge.

The change is not committed or released yet. It is deployed on cvs.synchro.net precisely so it can be confirmed against a real 1.8 client first.

-- *Authored by Claude (Claude Code), on behalf of @rswindell*
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

close https://gitlab.synchro.net/main/sbbs/-/issues/1214
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/1214#note_9915

cvs works great :smile:
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/1214#note_9921

Update: the fix is on master now, in two commits.

b3caee6dd4 (collect-11-eyes, 2026-08-04) is the fix for what you saw. The
doors read the CTerm revision out of the terminal's device-attributes
reply and send whichever of the two mode-80 sequences that particular
build reads as "draw sixels at the cursor", so SyncTERM 1.8 and current SyncTERM are both handled. SyncDOOM, SyncDuke, SyncMOO1, SyncSCUMM and
SyncRPG had the same assumption baked in and were fixed with it.

20100f171c (lost-3-self, 2026-08-04) goes a step further, on Deuce's suggestion. A revision number only answers for CTerm, and the VT340 manual documents this mode backwards -- so a terminal built from those specs
behaves like SyncTERM 1.8 while reporting nothing about itself. The doors
now MEASURE it instead of inferring: a terminal drawing at the cursor
leaves it at the bottom of the image, one anchoring at the corner leaves
it untouched, and that difference is visible over the wire. The technique
is hackerb9's testdecsdm.sh (github.com/hackerb9/vt340test). It costs no
extra round trip -- the doors already sent a cursor-advance probe for a different question, and it now answers both.

The retest request stands, and cvs.synchro.net is now running both
commits. Please stay on SyncTERM 1.8: it is the case being fixed, so it is
the useful one to confirm. What you should see is no scrambled graphics in
the top-left, and the game picture centered in the window rather than
pushed against the left edge.

vert.synchro.net will keep showing the problem for now. It serves the
Windows build of the door, which has not been rebuilt against these
commits yet.

-- *Authored by Claude (Claude Code), on behalf of @rswindell*
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

reopen https://gitlab.synchro.net/main/sbbs/-/issues/1214

Before I install syncarcade on my own BBS I decided to try it out on vert, however I'm seeing odd graphics appear in the top left hand corner of the screen.

I'm using SyncTerm 1.8 - GDI and access vert.synchro.net

Here is a video of the issue:

https://www.magnum.uk.net/dropzone/arcade1.mp4
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/1214#note_9942

Hi DM, getting some odd graphics at the bottom of the screen:

https://www.magnum.uk.net/dropzone/arcade2.mp4

(using cvs)
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/1214#note_9946

Thanks -- and that is a second, separate bug, which the first fix is what
made visible. Sorry for the repeat trip.

The door repaints only the cells that changed between frames, and it sized those patches in whole text cells. That is what the cursor address in front
of a patch needs, but not what the decoder behind it needs: a sixel is read
six pixel rows at a time, and SyncTERM's 8x16 character cell makes those patches 16, 32 or 80 rows tall. None of those is a whole number of six-row bands, so every patch ended in a partial one.

CTerm did not clear its band mask between bands until 2026-06-28. Below
that, the columns of a partial last band that the band does not paint keep
the PREVIOUS band's pixels instead of being left alone. So each patch left
a stale sliver at its foot, and a sprite moving across the screen smeared
that into the dotted trail your video shows. It is SourceForge ticket #258
on the SyncTERM side.

That also explains why SyncTERM 1.10a is clean and 1.8 is not: the CTerm
fix landed after 1.8 was released. And it is why this only appeared now -- until last night's fix the patches were all landing in the top-left corner,
so there was nothing in the right place to leave a trail behind.

Every other terminal was already getting whole-band patches; SyncTERM was
the one exception, on the reasoning that whole cells were enough. The door
now sizes every patch in whole bands regardless of the terminal. It costs
about 3% more data, which run-length encoding absorbs almost entirely.

Could you retest on cvs.synchro.net once more, again on SyncTERM 1.8? The
new build is running there. What you should see this time is no trail
behind the cannon as it moves, and nothing accumulating below the row of
spare lives at the bottom.

vert.synchro.net still serves the Windows build and has not been rebuilt,
so it will keep showing both problems for now.

-- *Authored by Claude (Claude Code), on behalf of @rswindell*
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/1214#note_9959

The problem is now resolved - thanks.
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)