diff options
| author | B. Watson <urchlay@slackware.uk> | 2026-03-21 23:12:44 -0400 |
|---|---|---|
| committer | B. Watson <urchlay@slackware.uk> | 2026-03-22 00:39:50 -0400 |
| commit | fa9c7b244b646c214c2bbf9ab0c50499cc3858dd (patch) | |
| tree | 2086d1273cf51552d343a69bc0a3d0d51d777f90 | |
| parent | d29b04567a6083497ba827e8496210bbe3716dfa (diff) | |
| download | fujinet-chat-fa9c7b244b646c214c2bbf9ab0c50499cc3858dd.tar.gz | |
Update ideas.txt.
| -rw-r--r-- | TODO | 13 | ||||
| -rw-r--r-- | doc/ideas.txt | 14 |
2 files changed, 27 insertions, 0 deletions
@@ -12,6 +12,19 @@ FujiChat features, we're almost at parity! Other stuff: +- If an VBI-driven keyboard buffer turns out to be impossible or + too much of a PITA to contemplate, another idea to avoid dropping + keystrokes: after every keypress, wait something like 1/4 or 1/3 + second for another keypress, before checking for incoming net + traffic. As long as the user's typing 4 (or 3) keys per second, + he won't lose keystrokes. Probably have to put a limit on it, + a pathological case would be holding down a key long enough to + fill the edit box with 240 of the same character. That would + cause a 60 sec delay in net traffic, which might actually cause + us to time out... need some data on just how fast a fast typist + really types, and on average, how often they pause (to think or + read back what they just wrote, etc). Also look into detecting + key repeats (SRTIMER). - Write a cgetc() replacement that doesn't call the OS K: "get one byte" routine. I was avoiding it because it will need a 192-byte table (keycode -> atascii lookup)... but I'm spending more than 192 bytes diff --git a/doc/ideas.txt b/doc/ideas.txt index f70e47f..b9c9627 100644 --- a/doc/ideas.txt +++ b/doc/ideas.txt @@ -39,3 +39,17 @@ Features that should be implemented: - Cut buffer for ^U ^K ^W, like bash/emacs. LImited size (like, 240 bytes, same as the input box). + +- Support for the XEP80 (and its modern clones). This really should be + done as dual-head: Keep the regular Atari display for screen 1, + the edit box, and the status bar. The rest of the screens can + display on the XEP80. One problem with this is, scrollback memory. + Each of screens 2-7 will be ~2000 bytes per 80x25 chunk, so each + needs 4K to be able to scroll back 1 screens' worth. So XEP80 + support might end up being a 128K-and-up-only thing. + reifsnyderb has some code that deals with the XEP, written for use + with CP/M, that may be useful here. + +- R: support. Compile-time switch, separate executable. Use with + FujiNet, Lantronix, or anything else where we can go like + ATDThostname:port. |
