http_resp_buf rendered as ASCII on C64 screen (missing PETSCII translation)

[JC-000]

Summary

After a successful HTTPS GET, the C64's display routine writes
http_resp_buf bytes directly into screen RAM. Because screen RAM
uses C64 screen codes (not ASCII), the decrypted response body
(HELLO FROM TLS SERVER) renders as graphics characters instead of
readable text.

Details

• The response bytes in http_resp_buf are correct — this is verified
  server-side (the C64 sent the expected GET and the TLS 1.3 record
  layer decrypted the 200 response body correctly). Only the on-screen
  rendering is wrong.
• The boot banner already does the right translation — see the
  banner text path in src/boot.s. The HTTP response display path
  needs the same ASCII -> screen-code conversion applied before the
  sta $0400,x (or equivalent) writes.

Severity

Cosmetic. Networking / TLS / HTTP parsing are all correct. This only
affects what the user sees on the C64 screen after a successful GET.

Suggested fix

Apply the same ASCII -> screen-code translation that the boot banner
uses when writing http_resp_buf bytes to screen RAM. A short lookup
table (or the standard $20/$40/$60 bias rules) covers the printable
ASCII range needed for typical HTTP response bodies.

[JC-000]

Originally posted by @JC-000 on 2026-04-19

Re-opened after initial "non-bug" verdict (361151e) was found wrong on hardware: the all-uppercase test body HELLO FROM TLS SERVER rendered correctly by coincidence of CHROUT's $40-$5F bias, but mixed-case content (e.g. lowercase letters in a Date: header) still rendered as graphics characters on real U64E at 48 MHz turbo.

Real fix in PR #30: new 36-byte ascii_chrout helper in LOADER uppercase-folds lowercase ASCII and drops control bytes before CHROUT. Regression guard in tools/uci/test_https_print_body.py now uses a mixed-case listener body (Hello from TLS server v1.) and asserts no $40-$5E graphics-range screen codes appear on the body row. Validated on U64E at 48 MHz turbo.

Closing via PR #30.