--- /dev/null
+- hacks/apple2 and hacks/apple2-main related c/h files were copied and altered to be like apple2
+- hacks/Makefile.in was altered to remove most hacks and only build apple2 and our new analogterm
+- ./configure --with-gl=no
+- make
+
+TODO
+- vt100 double line? $ printf '\033#3Foo\n\033#4Foo\n'
+ It seems that this is not used with modern terminfo/curses
+ applications.
+- Jump/fast scroll, smooth/slow scroll (one line at a time).
+- h/l 1: Application Cursor Keys
+- O_o, in xterm: \033[5 q , [1 q , [2 q , [3 q , [4 q , 5, 6...
+ To change text cursor style.
+- Cursor color '\033]12;green\007' quite interestingly labels work.
+ Numerics not always?
+- Maybe line position relative/absolute (d/e vpa/vpr?)
+- Verify if in xterm when scrolling blank lines really have color
+ disabled. Since pseudocolor support was added, vifm seems to have
+ strange color problems in relation to scrolling.
+ Confirmed that xterm uses the background color when creating blank
+ spaces. Analogterm improved but still some oddities with vifm to
+ fix, related to scrolling.
+- With the current pseudocolors impementation, the current cursor
+ position in sc(1) is no longer visible... Ignoring black bg
+ color improves things for now.
+ Update: the cursor no longer uses text blinking support. The custom
+ implementation fixes this.
+- Now that pseudocolors are implemented, dialog(1) and possibly
+ other programs look strange.
+- When under tmux/screen, dialog(1) attempts to use higher characters
+ rather than DEC Special Graphics. May perhaps be configurable...
+- When under tmux, dialog(1) no longer uses DEC Special Graphics.
+ Some programs also use those extended characters like wordgrinder.
+- Interestingly, since we're a monochrome terminal, when using
+ "xterm" for $TERM tmux uses color for copy-paste text selection
+ and appears to have no option to change that. On the other hand,
+ if using "xtermm" for xterm-monochrome, tmux then correctly uses
+ the inverse attribute. This also affects the status bar if colors
+ are used. However, vim doesn't automatically switch to t_Co=0, and
+ when told so, no longer behaves the same, it strangely no longer
+ uses underline. When using dialog(1), the colors appear inversed
+ with "xtermm". With "xtermm" dialog(1) also no longer uses DEC
+ Special Graphics. Under Linux via ssh it seemingly attempts to use
+ it unsuccessfully since the common chars like q are used, and it's
+ in inverse mode. Verify if inverse works with the gfx mode. The
+ terminfo entry explains everything. Apparently it's an unsupported
+ historical variant.
+ Various key sequences are not properly supported, smacs (DEC
+ Special Graphics) issues ^N instead of \E(0, underline mode is
+ unsupported, etc. Let's use xterm and simulate pseudocolors instead.
+- Our font's '3' is a bit strange, its separator likely too low.
+ Make sure to also update the graphics character set.
+- Our font's 'R' is a bit strange.
+- Our font's 'p' and 'q' are a bit peculiar.
+- Font's 'f' too
+- So does 'j'...
+- And 'k', 'K'
+- In tmux when selecting text it's not highlighted. See what
+ text attribute it uses that we possibly don't yet support.
+ This was fixed by implementing background color text attribute,
+ simulating it with reverse text.
+- The beam starts too weak at the beginning of an "on". It then
+ gets brighter for longer horizontal lines.
+ The logic might be in analogtv_thread_draw_lines()
+ This has improved since, comments in the code.
+- Possibly some optional text clipboard support for copy/paste.
+ Interesting related ESC sequences: CSI ? 2004 h, CSI ? 2004 l
+- Possibly alternative screen buffer: CSI ? 1049 h, CSI ? 1049 l
+ tput ti and te and smcup, rmcup
+- Maybe support for vt220 cursor control (hide/show): CSI ? 25 l/h
+ Could also switch between block/underline to allow a certain level of
+ visibility, useful for debugging. Ignored for now, with block cursor
+ always enabled.
+- Maybe 12-13 l/h, cursor blinking enable/disable. Currently ignored.
+- Interesting may be double sized characters...
+- See PseudoColor StaticColor
+- Determine why # is the fallback character for high glyphs.
+ Perhaps replace it by something better looking.
+ Ideally increase character support.
+- Interesting is that the terminal doesn't support UTF-8 glyphs
+ yet but that it gracefully degrades to ASCII when French UTF-8 text
+ is displayed, at least for accents. More complete support would
+ be nice. Could use UCS-16 or UCS-32 internally.
+- BACKSPACE is sent as ^H and unlike for various keys like DELETE
+ there is no ANSI control code. In top, the pid entry line editor,
+ backspace doesn't work in analogterm but does in xterm. Determine
+ why. Under xterm, stty reports two extra lines, one related to
+ EOL2 and another one related to ^H so both could be related,
+ termios(4) mentions ERASE. Also, wordgrinder expected a BACKSPACE
+ event but received ^H, so the corresponding action needed to be
+ rebound, otherwise it would report no binding for ^H.
+ Also interesting, when in cat, under analogterm I get ^H for
+ backspace, when it just works under xterm.
+ stty -a shows even more info, including erase that is not bound
+ to the same, ^? vs ^H.
+ Update:
+ Interestingly, if starting analogterm with -bs and then using
+ stty erase ^H (default is otherwise ^?), backspace suddenly works
+ under cat and top (but not under gnu top remotely).
+ And the urxvt man page is interesting:
+ Apparently sending the Delete terminal key sequence for the
+ backspace key is common, along with sending the "execute" terminal
+ code for the actual Delete key.
+ And according to xterm man page, if backarrowKeyIsErase resource
+ is on (on by default), it queries stty in order to determine what
+ to send.
+- [>0c Secondary DA request (distinguishes VT240 from VT220)
+ Seems to not be supported by the current state system for >
+ https://www.real-world-systems.com/docs/ANSIcode.html
+ May not be necessary
+ https://stackoverflow.com/questions/29939026/what-is-the-ansi-escape-code-sequence-escc
+- Currently special characters and unicode typically result in
+ suboptimally chosen glypths like #. This affects applications
+ that use extended line graphics characters for boxes rather than
+ vt100 DEC Special Graphics charset.
+- Some query features are not supported like cursor position,
+ terminal type, and "Query window/icon labels using hexadecimal",
+ "Send Device Attributes", "Device Status Report".
+ Some programs may expect this and fail...
+ Update: a function was written and exported to have access to the file
+ handle and allow to send text to the application. A few of those reporting
+ functions were written using it. The functions was a hack around the fact
+ that the structure is private.
+- Oddly, the e3 editor appears to query the terminal attributes
+ without properly being able to read the terminal's response.
+- Vim uses the terminal insert/replace modes, using l and h.
+ This is not yet implemented. Vim otherwise now works fine.
+ Revise.
+- Some applications attempt to use two screens, this is not implemented.
+- Cleanup code using single row/col #define macro everywhere.
+ It's currently a huge mess.
+- Unify the silly double-terminal-state. Messy and confusing.
+- Optimize avoiding the unnecessary per-frame multiple malloc/free
+- Perhaps better allocate video memory to be able to optimize
+ multiline operations.
+- Add a -noise option to pass to analogtv_draw()
+- Maybe add live controls to adjust analog parameters. There is
+ a function that needs to be called again when altering those.
+- ctrl-s freezes, but, without capacity to resume, even X11 close
+ event gets ignored. Will have to ensure xon/xoff is handled better.
+ For now, tcsetattr(3) parameters disable XON/XOFF handling.
+- Interestingly when using xterm, rxvt or screen for TERM, console
+ output is more optimized, especially visible in top and more/less
+ with man pages with large synopsis. Compared to using vt100.
+ When looking at the vt100 terminfo entry, it actually adds delays,
+ like $<2>.
+ https://man7.org/linux/man-pages/man5/terminfo.5.html
+ Apparently xon/xoff related too, something I have to work on.
+ This problem is fixed by emulating a more complete xterm instead.
+ It seems that xterm is the de-facto standard from which
+ termcap/terminfo and applications degrade.
+- Add explicit TERM setting, seems to be in generic xscreensaver
+ command handling code.
+- Maybe try to implement smooth scrolling and line/char delete/insert
+ - xterm's line insert functionality seems to not be implemented yet
+ (L). This explains why scrolling up in more/less fails and only
+ updates the first row. Terminfo db has il1 and il <param>.
+ Line insertion is basically reverse-scrolling starting at a
+ particular offset and that can extend the wanted number of
+ lines. The scrolling window should be restricted to the field
+ if any is configured.
+ - Plus there's rmir/smir to enable/disable automatic insert mode
+ ([4l, [4h)...
+ - Then kich1=\E[2~, the insert key.
+- Cleanup headerfile, removing unnecessary prototypes/definitions
+- Add common graphics characters to make frames. Lynx uses some
+ to implement its scrollbar. Wordgrinder also uses some.
+ This entry seems redundant.
+- Maybe support read-only text/regions
+- Maybe support text windows (?)
+- Delete acts like backspace but should delete
+ This is inverted in utils/textclient.c textclient_putc()
+ This entry seems redundant.
+- Isolate code outside of xscreensaver, make a GNUmakefile.
+ Ironically the result will be more portable on common unix.
+ And much cleaner once consolidated.
+- Maybe add an option for HIRES/color mode.
+- It'd be nice to support 80x50, 132x50, etc...
+ It'd require analogtv code changes.
+- Would be nice for analogtv to simulate amber or green display
+ optionally. And to also support a less blurry mode simulating
+ screens with higher phosphor.
+ This is partly done but no configurable parameter yet.
+- When in recent xterm mode, when starting vim with no file I get
+ some c10;?11;? artefact, probably something xterm terminals must
+ implement or swallow. Also, xterm uses 0x9B too not only ESC.
+- Tack seems to be a decent program for terminal testing, other
+ than vttest.
+- ninvaders is very slow and not very responsive. This could serve
+ to work on some optimizations. It's also possible that it has
+ to do with user input handling. When reducing refresh rate like
+ with 0 delay using more CPU, it's more responsive.
+ This should be configurable.
+
+From the xanalogtv man page:
+ Notable X resources supported include the following which correspond to
+ standard TV controls: analogTVTint, analogTVColor, analogTVBrightness,
+ and analogTVContrast. They range from 0 to 100, except for tint which
+ is an angle between -180 and +180.
+Although this doesn't seem to be completely true, I can increase
+brightness way beyond 100 were it also increases thickness in
+analogterminal.
+
+NTSC related
+https://web.archive.org/web/20050105095004/http://www.ee.washington.edu/conselec/CE/kuhn/ntsc/95x4.htm
+https://web.archive.org/web/20050204191229fw_/http://www.ntsc-tv.com/ntsc-main-02.htm
+https://en.wikipedia.org/wiki/NTSC#cite_note-11
+/data/doc/NTSC/
+"The master oscillator is 315/22 = 14.31818 MHz, from which the
+3.579545 color burst frequency is obtained by dividing by four;
+and the 31 kHz horizontal drive and 60 Hz vertical drive are also
+synthesized from that frequency. This facilitated a conversion to
+color of the then common, but monochrome, RCA TG-1 synchronizing
+generator by the simple expedient of adding-on an external 14.31818
+MHz temperature-controlled oscillator and a few dividers, and
+inputting the outputs of that chassis to certain test points within
+the TG-1, thereby disabling the TG-1's own 31500 Hz reference
+oscillator."
+https://upload.wikimedia.org/wikipedia/commons/thumb/f/fd/Ntsc_channel.svg/800px-Ntsc_channel.svg.png
+
+$ hacks/analogterm -fast -geometry 1024x768 -program /bin/sh -tv-brightness 3 -tv-contrast 100
+$ hacks/analogterm -fast -geometry 1024x768 -program /bin/sh -tv-brightness 0 -tv-contrast 70
+-geometry 1364x1024
+
+https://retrocomputing.stackexchange.com/questions/17312/did-any-european-computers-use-10-line-fonts
+"The Videx Videoterm 80 column card for the Apple II (very different
+from the 80 column display on the Apple //e) used an 6845 that had
+a programmable character height (and width), with a maximum of 8x16
+pixels for characters. You could change the font by burning your
+own EEPROM, but the standard font was 7x9 (or 9x9 if you count
+spacing between characters) for 80x24 characters on a monitor.
+Apparently at some stage they also offered a 7x12 (or 9x12) font
+for 80x18 characters, but this feature was then removed (the 80
+column card I had didn't aloow this). So it looks like your
+sentiment of "to get 25 text lines, an 8x10 font would be ideal"
+was not shared by everyone ... though you could have burned your
+own EEPROM to get such a font."
+"
+
+
+hacks/analogterm -fast -geometry 1364x1024 -program /bin/sh -tv-color 10
+
+1152x921 is approx 12" 5/4 on a 24" monitor
+912x720 is approx 12" 5/4 old display on a modern 24" monitor.
+
+hacks/analogterm -fast -geometry 1364x1024 -program /bin/sh -tv-color 0
+hacks/analogterm -fast -geometry 1364x1024 -program /bin/sh -tv-color 0 -tv-brightness 2 -tv-contrast 140
+hacks/analogterm -fast -geometry 1364x1024 -program /bin/sh -tv-color 0 -tv-brightness 2 -tv-contrast 140 -del -bs
+
+hacks/analogterm -geometry 1364x1024 -bs
+stty then often useful to set ERASE properly (to fix).
Repositories / xscreensaver-5.35.git / commitdiff