Update TODO, add doc/scrollback.txt.

1 files changed, 63 insertions, 0 deletions

diff --git a/doc/scrollback.txt b/doc/scrollback.txt
new file mode 100644
index 0000000..7aa2b54
--- /dev/null
+++ b/doc/scrollback.txt
@@ -0,0 +1,63 @@
+Ideas for getting more scrollback (and/or more screens).
+
+This is just me writing down ideas that have been in my head for a
+while. None of this is set in stone, or even plastic.
+
+Currently (aa80b9e) there's 7285 bytes free (between the BSS and the
+stack). This would be enough for each screen to have another 25 lines
+(1000 bytes each), but we'd be screwed as far as adding other features
+(such as nick/channel lists for tab competion).
+
+So where does the extra memory come from?
+
+1. If we booted from the FujiNet (no DOS), we have 6400 bytes from
+$0700 (MEMLO) to the start of the code ($2000). This would be enough
+for 6 of the screens to have another 25 lines (73 each). Of course
+the user would have no place to save his config file (can we use the
+FujiNet for that, without bloating up the code?)... also, the
+load address could be bumped up to $2300 or so, which would give
+us all 7 screens.
+
+1.5. Same as 1, but we convert the binary to a boot disk, so we just
+load at $0700. Still can use the disk (image?) to write the config to
+a chunk of sectors. We don't get a filesystem, but we still could have
+multiple configs (even name them).
+
+2. If we're on an XL/XE, we can use 4K of the under-OS RAM: the
+regular font (1K), the international font (1K), and the floating point
+routines (2K) are not used. 4 screens' worth, so maybe screens
+1-4 get to be 73 lines... combine this with (1) and we have
+maybe 4 screens at 98 lines apiece plus 3 more at 73.
+
+3. If we're on an XL/XE and we load the 800 OS, we get an extra 7K to
+play with. The font (1K), FP (2K), and the 4K area at $C000 becomes
+free RAM. Caveat: I don't think it's actually possible to load the 800
+OS without rebooting into it (though I could be wrong).
+
+4. If we're on a 130XE, we have oodles of memory. We're already
+using 15K in the main bank, right? Move it to the $4000 area (split
+the code)... then use all 4 banks of the extra 64K... We could have
+more than 7 screens... original bank plus 4 more 16K banks would give
+us around 80 25-line chunks of memory... 8 screens with 250 lines
+each? Sure. Or 10 screens with 200 lines each. If we're on a 256K
+800XL, or a 576K XE, or have a U1MB... well, you get the idea.
+
+5. What else could we do with a 130XE? Well, software 80 columns, with
+scrollback... not as much of it. Suppose I do a 'squashed' 80x25 mode,
+where the characters are only 5 lines tall (with an ANTIC blank line
+between the rows of chars, for readability). That's 5000 bytes per
+80x25. With 80K for screen memory, that would be maybe 8 screens with
+25 lines of scrollback each. The edit box would still be 40-column
+GR.0 so no extra RAM needed there (we could fit the whole thing on the
+screen at once, though)... and 6 GR.0 lines for the status window too.
+
+Both (1) and (2) could be added to the regular fnchat.xex: just decide
+what memory to use at runtime, and make MAX_SCREENS a variable, and
+copy the OS to RAM.
+
+(4) would be called fnchatxe.xex, and (5) would be... fnchat80.xex?
+
+What about doing scrollback with an XEP80? Seems like it would be slow
+and cumbersome. Would need a lot less RAM than software 80 columns,
+and look a lot nicer. Could even do dual head! fnchatxp.xex, separate
+build.