1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
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.
|
