diff options
| -rw-r--r-- | doc/ideas.txt | 81 |
1 files changed, 48 insertions, 33 deletions
diff --git a/doc/ideas.txt b/doc/ideas.txt index 15d44dc..bdefce3 100644 --- a/doc/ideas.txt +++ b/doc/ideas.txt @@ -7,53 +7,68 @@ Features that should be implemented: comes from phigan (thanks!) - Support for (some of) the extra RAM in 64K machines. Can get an - extra 4K because we don't need the international font or the - floating point routines, and we can plop our custom font directly - into $E400. *Maybe* look into using the 800 OS, which would give + extra 4K (97 lines) because we don't need the regular or + international font or the floating point routines. This can be done + in the standard executable: most of the work happens in the config + segment. + + It has to be possible to disable, in case the user's using + e.g. Sparta 3.x (uses the under-OS RAM already) or the HSIO patch + that uses the intl font area for code... though, we don't *do* + disk I/O once the client starts, so maybe we can ignore the HSIO + patch issue. + +- *Maybe* look into using the 800 OS, which would give another 3K (the rest of the $C000 area besides the intl font). - This would be a separate executable (fnchatxl.xex). + The issue here is "live-booting" the OS (switching from XL to + OSB on a running system without a reboot or even a warmstart). + The_Doctor__ says this is possible. I'm not sure I want to bother + with this... + +- Use any extra RAM in the code area, between the end of the code + segment and the start of the stack, as extra screen memory. + Currently that's 1.7K, or 42 extra lines. + +- Use any extra RAM in the data area, between the end of the BSS and + the start of the display list/etc (at $3360), as extra screen + memory. Currently that's 1.4K, or 34 extra lines. - Support for 130XE, 256K XL, etc extended RAM. Apparently a lot of people have 1MB these days. *Lots* of screens, each with lots - of scrollback, would be the main (only?) use for the extra RAM. - Separate executable (fnchatxe.xex). - -- Custom cgetc() that doesn't block forever, and does its own - keyclick (using POKEY, not the console speaker), so we can - disable the click even on an 800. Also maybe we can set the - key repeat rate on an 800... and since the clicks are done - via POKEY, 800 users can *turn the volume down*. Also since - we won't be using WSYNC, it opens up the possibility of - using DLIs (if I can think of a useful use for them). - -- Adaptive scrollback (dynamic screen size). Using fewer screens - would mean you get more scroll. Shorter screens steal lines from - the top of the tallest screen as needed. Requires a display list - that's all LMS, and each line needs to be 42 bytes (the extra - 2 bytes are a pointer to the previous line, or 0 for the top line). - Some lines would have to be blacklisted because they'd cross a 4K - boundary. As a side effect, scrolling in new text would be *fast*, - no need to move memory around, just allocate a new line and change - the display list. + of scrollback, will be the only use for the extra RAM. Most of the + work is done in the config segment (detecting banks and letting the + user choose which ones to use) so it won't bloat the executable + much. Already have the dynamic screen stuff, with support for + multiple pools, so the groundwork is done at least. - URL handling. Extract URLs from message text, send them to a UDP port on a local machine that knows how to deal with them. + Or, show them as a QR code (FujiNet supports that). - Some method of copy/paste, using the keyboard or maybe a joystick. -- Cut buffer for ^U ^K ^W, like bash/emacs. LImited size (like, +- 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. + done as dual-head: Keep the regular Atari display for the edit box, + the status bar, and maybe some other info. The actual screens can + display on the XEP80. Unfortunately to do this right, I'll have + to use the XEP80's E: handler (so it'll work with modern XEP80 + replacements like the 1090XL 80-column board), and that means giving + up 1.5KB of memory (the driver is bloated). 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. + +These last two, xep80 and R:, will be compile-time options. I can't +afford the RAM it would take to keep all that code resident at once +and choose at runtime. So, 4 executables: + +- fnchat.xex, 40 columns, FujiNet networking. +- fnchatx.xex, 80 columns, FujiNet networking. +- fnchatr.xex, 40 columns, R: networking. +- fnchatrx.xex, 80 columns, R: networking. |