docs(twitter): add 1688022114962374656 corpus (NOTimothyLottes SPC vintage 640x480 + 15KHz CRT plan)

4-post thread, 2 images, Aug 6 2023. Same day as the RDNA2 assembler
design doc (1688286623375454208). SPC project: vintage 640x480 VGA
style render + 640x240 fallback for 15 KHz arcade CRTs (PGM-esk) +
CRT shader scaling on Deck + OLED/LCD. Mix of render pixel aspect
changes, less than 480 lines, letter-box for integer Y scaling.
15 KHz output path docked: HD Fury Nano (no <480p) -> HDMI-to-VGA
-> sync combiner (GBS-C bug workaround) -> GBS-C line-drops 480p60
to 240p60 component. Bitmap font uses right angles + 2x2 stroke in
8x16 (pow2) so 640x240p still gets readable 8x8. Overscan safety:
Y axis easy - keep cursor pinned in 'safe' zone, still print lines in
overscan area (visible on non-overscan CRTs).
This commit is contained in:
ed
2026-07-27 02:01:57 -04:00
parent 5db46d3b64
commit d2098c8dec
4 changed files with 109 additions and 0 deletions
Binary file not shown.

After

Width:  |  Height:  |  Size: 6.0 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 1.2 KiB

@@ -0,0 +1,35 @@
---
title: "The next challenge is overscan safety, since real non-VGA CRTs will be used in d"
author: "NOTimothyLottes"
handle: "@NOTimothyLottes"
post_url: "https://x.com/NOTimothyLottes/status/1688022114962374656"
post_id: "1688022114962374656"
timestamp: "2023-08-06 03:00:08"
post_count: 4
reply_count: 0
repost_count: 0
like_count: 1
view_count: 340
---
# @NOTimothyLottes — The next challenge is overscan safety, since real non-VGA CRTs will be used in d
## Post 1 (2023-08-06 02:45:18)
1st SPC project: to be based on vintage 640x480 render (VGA style), +fallback to 640x240 for 15 KHz arcade CRTs (PGM-esk), and CRT shader scaling on Deck and OLED/LCD. Use mix of render pixel aspect changes, running less than 480 lines, and letter-box to keep integer Y scaling.
![Media 1](./media/1688018382543597568_1.png)
## Post 2 (2023-08-06 02:50:32) — reply to Post 1
My 15 KHz CRT output path when docked is HD Fury Nano (won't do <480p) doing HDMI to VGA, with a sync combiner (to workaround GBS-C bug), into GBS-C which line drops 480p ~60Hz to 240p ~60Hz and outputs component. The 640 width gets maintained even if some CRTs cannot resolve it.
## Post 3 (2023-08-06 02:57:50) — reply to Post 2
Presents issues for UI, namely that my bitmap fonts need to look good in both 480p and 240p modes, so for editor (assembler) I'm going with a font that uses right angles and designed around 2x2 stroke width, in a 8x16 (pow2) bitmap, so 640x240p still gets a readable 8x8 (below)
![Media 1](./media/1688021533904510976_1.png)
## Post 4 (2023-08-06 03:00:08) — reply to Post 3
The next challenge is overscan safety, since real non-VGA CRTs will be used in development. The Y axis has an easy fix, simply keep cursor pinned in the 'safe' zone, but still print lines in the overscan area (so they can be seen when attached to non-overscan CRTs/etc too).
@@ -0,0 +1,74 @@
{
"root_post_id": "1688022114962374656",
"posts": [
{
"post_id": "1688018382543597568",
"author": "NOTimothyLottes",
"handle": "NOTimothyLottes",
"text": "1st SPC project: to be based on vintage 640x480 render (VGA style), +fallback to 640x240 for 15 KHz arcade CRTs (PGM-esk), and CRT shader scaling on Deck and OLED/LCD. Use mix of render pixel aspect changes, running less than 480 lines, and letter-box to keep integer Y scaling.",
"timestamp": "2023-08-06 02:45:18",
"media_urls": [
"https://pbs.twimg.com/media/F20LgFtWQAAMtcv?format=png&name=orig"
],
"reply_to_id": null,
"quote_of_id": null,
"metrics": {
"reply_count": 1,
"repost_count": 0,
"like_count": 3,
"view_count": 708
}
},
{
"post_id": "1688019698904969216",
"author": "NOTimothyLottes",
"handle": "NOTimothyLottes",
"text": "My 15 KHz CRT output path when docked is HD Fury Nano (won't do <480p) doing HDMI to VGA, with a sync combiner (to workaround GBS-C bug), into GBS-C which line drops 480p ~60Hz to 240p ~60Hz and outputs component. The 640 width gets maintained even if some CRTs cannot resolve it.",
"timestamp": "2023-08-06 02:50:32",
"media_urls": [],
"reply_to_id": "1688018382543597568",
"quote_of_id": null,
"metrics": {
"reply_count": 1,
"repost_count": 0,
"like_count": 0,
"view_count": 188
}
},
{
"post_id": "1688021533904510976",
"author": "NOTimothyLottes",
"handle": "NOTimothyLottes",
"text": "Presents issues for UI, namely that my bitmap fonts need to look good in both 480p and 240p modes, so for editor (assembler) I'm going with a font that uses right angles and designed around 2x2 stroke width, in a 8x16 (pow2) bitmap, so 640x240p still gets a readable 8x8 (below)",
"timestamp": "2023-08-06 02:57:50",
"media_urls": [
"https://pbs.twimg.com/media/F20Ogh8XoAAq7hR?format=png&name=orig"
],
"reply_to_id": "1688019698904969216",
"quote_of_id": null,
"metrics": {
"reply_count": 1,
"repost_count": 0,
"like_count": 1,
"view_count": 439
}
},
{
"post_id": "1688022114962374656",
"author": "NOTimothyLottes",
"handle": "NOTimothyLottes",
"text": "The next challenge is overscan safety, since real non-VGA CRTs will be used in development. The Y axis has an easy fix, simply keep cursor pinned in the 'safe' zone, but still print lines in the overscan area (so they can be seen when attached to non-overscan CRTs/etc too).",
"timestamp": "2023-08-06 03:00:08",
"media_urls": [],
"reply_to_id": "1688021533904510976",
"quote_of_id": null,
"metrics": {
"reply_count": 0,
"repost_count": 0,
"like_count": 1,
"view_count": 340
}
}
],
"source_url": "https://x.com/NOTimothyLottes/status/1688022114962374656"
}