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
64
65
66
67
68
69
70
71
72
73
74
|
These are not really TODOs, they're "might do" or "hope to do".
Features that should be implemented:
- /r to reply to the last person/channel who msg'd you, /a to msg the
last person/channel you msg'ed (server and private screens). Idea
comes from phigan (thanks!)
- Support for (some of) the extra RAM in 64K machines. Can get an
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).
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, 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,
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 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.
|
