The top row has the top-most pixels chopped off and the status bar isn't flush against the bottom of the screen. Some JXL or Sixel graphics are left behind under the status bar when re-displaying the status bar.
I don't see any pixels "chopped off" anywhere... and the ×43 modes use 8×8 fonts on a 350-row window leaving six rows that are not part of any character cell. For 80 column modes, this is standard EGA.
Last edit: Stephen James Hurd 1 day ago
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The top-most pixels of each cell of the top row are choped off. More noticably, there's a "gap" under the status where graphics can be displayed and remain after the status bar is restored - all demonstrated in the screenshots.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There are no pixels chopped off the top of the row. The 'M' and 'l' have the same pixels as ones lower. The "gap" is normal for EGA modes, which use a 350-row display with an 8×8 font. You can see this clearly using RIPterm or other EGA software in DOSbox or what have you.
This is what the real 80×43 mode did on real hardware, and RIP at least makes use of that.
Stipulating that the top row is not missing pixels, what about the graphics drawn under/below the status bar that remain visible after the status is restored - that isn't an issue? Subsequent clear screens don't clear it either.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Correct, that is not an issue, that is how the corresponding modes on real hardware actually behave.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
1 day ago
Claude's input on this:
Re the second part (graphics remaining visible under the status line) -- that
one is independent of the layout question.
In C80X43 the canvas is 640x350 and the text area is 43*8 = 344, so the
bottom 6 scanlines belong to no character cell. Cell-addressed operations
reach the framebuffer through vmem cell coordinates (vmem_fill_rect() and
friends), so clrscr/ED cannot touch those 6 rows by construction -- there is
no cell to fill.
bitmap_movetext_screen() is the one place that deliberately steps outside
cell coordinates for them:
So the gap scrolls with the text, but nothing can clear it. Whatever is drawn
there (sixel or JXL covering the full canvas) persists until something writes
those pixels again.
This predates DECSSDT -- that comment and code are already in
syncterm-1.9rc4, which has no DECSSDT at all. Status-line hiding did not
introduce it; it only made it reachable, since a program that hides the
status line is told the canvas is 640x350 rather than 640x336 and draws into
the gap.
C80X43 and VESA_132X43 are the two standard modes with 43 rows on a 350-line
canvas, which matches the 132x43 behaviour reported above.
Not disputing the layout point: 350 lines with an 8x8 font does leave 6
unused rows, and nothing is chopped off the top.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
FYI, 132x43 appears to have the same issue.
I don't see any pixels "chopped off" anywhere... and the ×43 modes use 8×8 fonts on a 350-row window leaving six rows that are not part of any character cell. For 80 column modes, this is standard EGA.
Last edit: Stephen James Hurd 1 day ago
The top-most pixels of each cell of the top row are choped off. More noticably, there's a "gap" under the status where graphics can be displayed and remain after the status bar is restored - all demonstrated in the screenshots.
There are no pixels chopped off the top of the row. The 'M' and 'l' have the same pixels as ones lower. The "gap" is normal for EGA modes, which use a 350-row display with an 8×8 font. You can see this clearly using RIPterm or other EGA software in DOSbox or what have you.
This is what the real 80×43 mode did on real hardware, and RIP at least makes use of that.
Ah, 1056×350 is a VESA mode available on Cirrus CL-GD5420/5422/5426.
Stipulating that the top row is not missing pixels, what about the graphics drawn under/below the status bar that remain visible after the status is restored - that isn't an issue? Subsequent clear screens don't clear it either.
Correct, that is not an issue, that is how the corresponding modes on real hardware actually behave.
Claude's input on this:
Re the second part (graphics remaining visible under the status line) -- that
one is independent of the layout question.
In C80X43 the canvas is 640x350 and the text area is 43*8 = 344, so the
bottom 6 scanlines belong to no character cell. Cell-addressed operations
reach the framebuffer through vmem cell coordinates (vmem_fill_rect() and
friends), so clrscr/ED cannot touch those 6 rows by construction -- there is
no cell to fill.
bitmap_movetext_screen() is the one place that deliberately steps outside
cell coordinates for them:
So the gap scrolls with the text, but nothing can clear it. Whatever is drawn
there (sixel or JXL covering the full canvas) persists until something writes
those pixels again.
This predates DECSSDT -- that comment and code are already in
syncterm-1.9rc4, which has no DECSSDT at all. Status-line hiding did not
introduce it; it only made it reachable, since a program that hides the
status line is told the canvas is 640x350 rather than 640x336 and draws into
the gap.
C80X43 and VESA_132X43 are the two standard modes with 43 rows on a 350-line
canvas, which matches the 132x43 behaviour reported above.
Not disputing the layout point: 350 lines with an 8x8 font does leave 6
unused rows, and nothing is chopped off the top.
Ticket moved from /p/syncterm/tickets/279/
Can't be converted: