diff options
| -rw-r--r-- | TODO | 7 | ||||
| -rw-r--r-- | doc/scrollback.txt | 63 |
2 files changed, 65 insertions, 5 deletions
@@ -12,6 +12,8 @@ FujiChat features, we're almost at parity! Other stuff: +- More scrollback. Of course it needs more memory... see doc/scrollback.txt + for my ideas on this. - Status indicators # M J etc should disappear at some point. When the user switches windows. Also maybe there should be a timer. - ^U works, but is slow (calls backspace() in a loop, which does a @@ -38,11 +40,6 @@ Other stuff: make this useful would probably bloat the code too much. Some way to change the IRC server/port within the app would be very useful though. -- Loading/title screen. Display immediately before the config init - segment is loaded, and again when it runs the client. Its DL and - data can be kept in scrollback RAM, since scr_init() clears it. - Should be small & simple (one line of GR.2 probably). Have to - not disable ANTIC DMA during the client load. - Input box history. Up-arrow to recall previous command. Unfortunately this needs a lot of RAM. Maybe just one previous command, so you can up-arrow to re-ping someone, etc. 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. |