initial commit

6 files changed, 987 insertions, 0 deletions

diff --git a/doc/Compatibility.txt b/doc/Compatibility.txt
new file mode 100644
index 0000000..cc47ab5
--- /dev/null
+++ b/doc/Compatibility.txt
@@ -0,0 +1,33 @@
+FujiChat has so far been tested with:
+
+Serial Interfaces:
+
+SIO2PC + Bob-Verter driver [*]
+ATR8000 serial port [*]
+Atari 850 (Atari driver) [!]
+Black Box [!]
+P:R: Connection
+
+[*] = hardware handshaking not supported or not tested; requires patched
+slattach binary for higher baud rates; probably limited to 4800 baud.
+
+[!] = hardware handshaking tested and working (with unpatched slattach)
+
+DOSes:
+
+Atari DOS 2.0S
+SpartaDOS X 4.x (use 'X' command)
+MyDOS 4.5
+
+Display drivers:
+
+XEP-80 (ABBUC driver)
+CON80.SYS and CON64.SYS (Sparta X)
+Omniview 80
+
+FujiChat is known not to work with ClausB's old E80 driver, and probably
+won't work with ACE-80 either (untested).
+
+Misc:
+
+Atari CX-85 (numeric keypad)
diff --git a/doc/HOWTO b/doc/HOWTO
new file mode 100644
index 0000000..53bbe5c
--- /dev/null
+++ b/doc/HOWTO
@@ -0,0 +1,161 @@
+How to run a TCP/IP stack on an Atari 8-bit
+-------------------------------------------
+
+You will need:
+
+1. An Atari 8-bit computer with at least 48K of RAM
+2. A Linux box with:
+3. A recent snapshot of cc65. 2.12.0 won't work. I used 2.12.9.20080831.
+4. SLIP support in your Linux kernel (try "modprobe slip")
+5. Some way to get an Atari program from your Linux box to your Atari, so
+   you can run it. I use an SIO2PC cable and AtariSIO, and "axe" for
+   writing files into an ATR image.
+6. An RS232 serial interface for your Atari. I use the same SIO2PC cable
+   as (5) for this. Other possibilities are an 850, P:R: Connection,
+   R-Verter, etc.
+
+
+Before building the Atari program, you should get a copy of the R:
+handler (device driver) that's needed for your Atari to talk over the
+serial port, and copy it to rhandler.xex in the source directory. In
+general, whatever R: handler you use with Bobterm or Ice-T will work
+fine. The shipped copy of rhandler.xex is the Bob-Verter driver, which
+works great with an SIO2PC cable.
+
+Run "make" to compile and "make disk" to build the ATR image uiptest.atr.
+This is a bootable disk with DOS 2.0S and the uIP demo program as
+AUTORUN.SYS (with R: handler prepended to it).
+
+Boot the disk, wait for it to finish loading. You should see "Press Return
+to connect". At this point, you should start SLIP on your serial port,
+then press Return on the Atari. If you've done everything right, the Atari
+should connect to the remote host!
+
+What you have to do to start a SLIP interface depends on what you're
+using as a serial interface on the Atari, and whether it's the same
+device as you'll use to load the code into the Atari. Most motherboards
+these days have only one serial port (if any), so if you're doing drive
+emulation, you'll have to switch between the drive emulator software
+(e.g. atariserver) and SLIP mode on the same serial port (or run drive
+emulation on one machine and SLIP mode on a second). If you're lucky
+enough to have two serial ports on your Linux box, and own an SIO2PC
+and an 850 or other Atari RS232 interface, you can run SLIP on one Linux
+serial port all the time and atariserver on the other all the time.
+
+Note: atariserver will NOT work with USB-to-RS232 adaptors. sio2linux
+theoretically might, but in practice usually doesn't. It *should* be
+possible to run SLIP over a USB adaptor though (but I haven't tried it).
+
+Another note: For some reason, the uIP code doesn't run if it's loaded
+from MyPicoDOS (the built-in loader in atariserver). This is why you
+need to create an actual DOS ATR image for use with atariserver.
+
+
+850, P:R: Connection, R-Verter, or "dumb" SIO2PC as serial device
+-----------------------------------------------------------------
+
+To start SLIP mode on your Linux machine's serial port, you should be able
+to use the "slattach" that came with your system. If you don't have this
+program installed, you'll have to find out what package it belongs to
+(on Slackware and Debian, that's the net-tools package, and it's highly
+unlikely that it wouldn't already be installed).
+
+Actually, slattach won't work if your R: device doesn't have the hardware
+handshaking lines connected (this is true of the SIO2PC, and for most
+other devices it depends on how your cable was made). From slattach's
+documentation, it looks like the -L option (local mode, no HW handshake)
+should work, but it won't due to a bug in slattach. You can use the
+patched version (see next section) if you don't have HW handshaking.
+
+The start_slip.sh script does everything that's needed to fire up a SLIP
+connection for uIP to use. There are some config options at the top of
+the script (to set the port, baud rate, etc), make sure these are correct.
+
+If you've got working hardware handshaking, you should be able to do
+9600 baud. This has been tested on the 850 and works well. 19200 may
+even work, if your device & driver support it. Without handshaking,
+the maximum reliable speed seems to be 4800 baud (you could try 9600,
+but it probably won't work). Speed isn't really *that* important for
+IRC anyway.
+
+
+Auto-sensing SIO2PC as serial device
+------------------------------------
+
+If using a Steve Tucker SIO2PC (the auto-sensing kind), slattach has to
+be patched slightly. Get net-tools-1.60, patch it up to 1.60-19, then
+apply slattach_rts.diff. Compile net-tools, copy slattach to someplace on
+your PATH (don't overwrite the one in /sbin or /usr/sbin! I renamed my
+patched version to a8_slattach). You can find the net-tools-1.60 source
+and the 1.60.19 patch here:
+
+ftp://ftp.slackware.com/pub/slackware/slackware-12.1/source/n/net-tools
+
+(Note: you don't have to be running Slackware to use the sources,
+that's just a handy place to download them from)
+
+Run "make" to build. It'll ask you a lot of questions about what protocols
+& hardware your system supports; the answers are not too important,
+so long as you say yes to SLIP support and TCP/IP. Don't do a "make
+install", just copy slattach somewhere like /usr/local/bin/a8_slattach
+
+
+Using the same serial port for drive emulation and SLIP
+-------------------------------------------------------
+
+If using atariserver, you have to load & unload the atarisio module,
+it won't play nice with SLIP. Use atariserver_slip.sh (which can be
+configured a bit by changing the variables at the top). If you prefer, you
+could use sio2linux instead of atariserver, but it's slow and occasionally
+just fails to work on my system. If sio2linux works OK for you, it's
+easier to deal with because it just uses the serial port device instead of
+loading a kernel module that "takes over" the port the way atarisio does.
+
+
+Other hardware
+--------------
+
+If you've got some other way to get the code to your Atari that doesn't
+involve a serial port (such as a MyIDE or S-Drive, or maybe a Black Box
+with removable media, or just another Linux box with its own serial port),
+you can run start up SLIP on your serial port with start_slip.sh and
+leave it running forever. Unlike PPP, the SLIP protocol doesn't really
+"connect" to the other side of the serial line, so there's no need to
+restart SLIP if you reboot the Atari.
+
+
+Other OS
+--------
+
+If you aren't running Linux, you can still use SLIP.
+
+- Free/Net/OpenBSD: follow the Handbook for setting up a SLIP connection,
+  plus NAT or Masquerading (whatever the BSD terminology is).
+  Unknown whether it'll work without hardware handshaking.
+
+- Mac OS X: has slattach, which appears to be the same as the Linux version.
+  Unknown whether it'll work without hardware handshaking. No idea whether
+  OSX supports NAT/masquerade (bet it does though).
+
+- Windows: in theory it's possible to either use SLIrP with Cygwin, or
+  else the built-in "Direct Cable Connection" (which exists in at least
+  Windows 98 through XP, but has been dropped in Vista). You'd want to
+  enable "Internet Connection Sharing", too.
+
+  It also should be possible to run SLIrP on a TCP port on either your
+  Windows machine or some other host, and configure APE's R: TCP/IP
+  emulation to connect to this host and port. In effect you'd be running
+  SLIP over TCP.
+
+  Yet another way to use uIP with Windows would be to use a virtual (emulated)
+  machine running Linux (e.g. using qemu or possibly VirtualBox). At least
+  one user has successfully done this.
+
+- Some "serial terminal server" devices may support SLIP. I'm pretty sure
+  at least one model made by Lantronix does. If you have one of these,
+  let me know how (or if) it works.
+
+NOTE: If your OS has "Compressed SLIP", "CSLIP", "VJ Compression", or any
+SLIP-related option named similarly, DISABLE it. uIP does not support
+compressed SLIP.
+
diff --git a/doc/README b/doc/README
new file mode 100644
index 0000000..24d40b0
--- /dev/null
+++ b/doc/README
@@ -0,0 +1,396 @@
+FujiChat v0.1: An IRC client for the Atari 8-bit
+-------------------------------------------
+
+FujiChat is a simple IRC (Internet Relay Chat) client for Atari 8-bit
+(400/800/XL/XE) computers, based on the uIP TCP/IP stack. It uses a SLIP
+connection to talk to the outside world, and supports a subset of the IRC
+commands available in full-featured clients. 48K of memory is required
+(and extended memory is not used, so it can coexist with RAMdisk drivers
+and such).
+
+Capabilities:
+
+- Can connect to an IRC server, and:
+- Join a channel
+- Send and receive channel and private messages
+- Actions (/me does whatever) are supported
+- Part the channel and join a new channel
+- Most IRC slash-commands are available
+- Client responds to CTCP PING and VERSION requests
+- Client can send CTCP PING and VERSION requests
+- Client responds correctly to server PINGs (with PONG)
+
+Limitations:
+
+These are listed approximately in order of severity, and will be addressed
+in future versions in approximately the order shown here.
+
+
+- The user interface is extremely crude (almost non-existent)
+- Try not to accidentally hit the Break key. It may result in weird
+  behaviour (though it usually doesn't)
+- Editing is extremely crude: only backspace, delete line, and delete
+  word are supported
+  (future versions will probably support emacs-like key bindings)
+- Currently, the client can only join one channel at a time. Attempts
+  to join a second channel before parting the first will fail. (future
+  versions may allow joining multiple channels, but probably no windowing, so
+  the channels' text will appear mixed together on the screen)
+- Many client features like logging, scrollback, nick highlighting, DCC,
+  multiple windows, nick completion, etc are missing. Some of these will
+  be added in future versions, but some would just take too much memory
+  to fit in 48K. (future versions are planned to have at least tab-completion
+  of nicks, and possibly a small scrollback buffer. A limited number of
+  multiple channel/msg windows is not out of the question)
+- There is no nick list displayed. At any time you can use /names #channel
+  or /who #channel to see who else is in the channel (or press ctrl-N
+  or ctrl-W), but the client doesn't attempt to track other users'
+  joins/parts/quits. (future versions may track the nick list and display
+  it as a separate screen, e.g. you press Option to see it)
+- The characters {, }, `, and ~ are not printable on the Atari. Instead they
+  are rendered as inverse-video [, ], ', and ^, respectively (future versions
+  will probably use a custom font to display these characters)
+- mIRC-style color and bold codes are not interpreted at all. They will
+  be displayed as ATASCII graphics characters (future versions will strip
+  color codes and may display bold as inverse video)
+- Most CTCP commands are unsupported (and DCC will likely never be supported)
+- Private messages from other users appear mixed in with channel text
+- Text is displayed in GRAPHICS 0, meaning it's 40 columns by 24 lines,
+  with no support for multi-colored text or anything fancy like italics
+  or underlines. It might be possible to do an Ice-T style 80 column
+  display, but it's a pig (8K for the graphics mode, plus at least 1K
+  for the font, plus rendering/scrolling is slow and might result in
+  serial buffer overruns if I'm not careful). It might instead be possible
+  to do a 40-column display with 4 or 8 character colors, using P/M overlays,
+  which would result in some visible flicker, but the overall effect isn't
+  too painful. This would require a lot less RAM and CPU cycles than the
+  80-column mode.
+
+As you can see, FujiChat is more defined by what it can't do than what it
+can, at the moment :)
+
+Configuration:
+
+The default config is stored in the file FUJICHAT.CFG in a binary format
+(not human readable). If the config file is missing at startup, FujiChat
+will start up in its config menu. If the config file was loaded, you
+will be asked "Use defaults [Y/n]?"; answering N will take you to the
+config menu.
+
+The first step in the config menu is to choose an IRC server. FujiChat
+comes with a short list of server IP addresses, which you may select
+from by entering the number of the server. You may also enter any IP
+address at the prompt, to use a server not in the built-in list. (As
+soon as I've debugged the DNS code, you'll be able to use hostnames, but
+for this release we're stuck with IP addresses only)
+
+The next step is to choose your IRC nickname. The different IRC networks
+have different limits on the maximum length of a nick, but all networks
+support at least 9 characters. FujiChat limits your nick to 20 characters.
+
+IRC forbids certain characters in a nickname: they may not start with
+a hyphen, and must consist of letters, numbers, or the characters:
+- [ ] { } ` _ \ ^
+Note that FujiChat does NO checking for invalid characters in your nick!
+
+The next two options are the background and foreground colors. These are
+standard Atari color register values (chroma/luma) to be used for the
+GRAPHICS 0 text background and foreground registers. Try not to set
+them to the same thing; you won't be able to see any text if you do!
+
+When you're done, you'll be asked whether or not you want to save the
+config. If you answer N, the options you just entered will be used for
+the current session only.
+
+Connecting to IRC:
+
+To set up a SLIP connection between your Atari and another host on your
+network, see the file HOWTO.
+
+The following instructions assume you have a properly configured SLIP
+connection, including NAT/Masquerade if required.
+
+The default IRC server is in the US, and is known not to work well for
+users in Europe. FujiChat has a short list of NewNet IRC servers built
+in (accessible from the "IRC Server" config menu), or you can enter any
+other IP address. To find the IP address of a server, you can use a tool
+such as "nslookup" or "dig", or simply ping the host from your Linux box.
+
+To connect to the IRC server, choose "Connect" from the main config menu.
+At this point, FujiChat will open a TCP connection to the server. Within
+a few seconds, you should start seeing messages from the IRC server.
+
+Once the connection is made, FujiChat will attempt to register
+your nickname and host. If your primary nickname is already in use,
+registration will fail, and you will see a server message informing you
+of this. If this happens, choose a different nickname and type "/nick
+<nickname>" (and press Return).
+
+After your nickname is registered, the server will send its "message of
+the day" (the MOTD). On NewNet, the MOTD tends to be very long, and there's
+no way to skip or abort it, so be patient.
+
+Once the MOTD has finished, the connection is ready to use. At this point,
+you can use the /join command to join a channel and start chatting!
+
+[Note: There's no way to tell the server not to send the MOTD. I could
+add an option to FujiChat to make it not *display* the MOTD, but your
+serial port's bandwidth would still be starved, and you wouldn't be able
+to get much chatting done]
+
+How to use IRC:
+
+[This section is written as an intro for someone who's completely new
+to IRC. Apologies if it seems condescending...]
+
+Before you can chat with other users, you must find some users to chat to.
+The normal place to do this is in an IRC "channel". Think of the IRC network
+as a giant building (a castle, or maybe a convention center). Each channel
+is like a room within the larger building.
+
+Channels have names that usually start with a # character. The rest of
+the name usually describes the usual topic of conversation on the
+channel. For instance, the channel #atari is about (you can guess this
+but...) Atari computers and video games.
+
+The act of entering a channel (room) is known as "joining" the channel.
+To do this, you connect to the IRC server, then type "/join" followed
+by the channel name. Example:
+
+/join #atari
+
+[FujiChat only allows joining one channel at a time, in the current
+version. Future versions may support multiple channels]
+
+Unlike a real room, the IRC channel will be created if it doesn't already
+exist. You'll know this happened if the channel's names list only shows
+your nickname.
+
+It's possible to get a complete list of channels from the IRC server, but
+this is really time-consuming (there are thousands on a typical network),
+and FujiChat doesn't provide a way to scroll through them. You can search
+for channels by name by using wildcards with the /list command. Example:
+you want to talk about cars. Try the following command:
+
+/list *cars*
+
+(Also, /list *auto*, since a car channel might be called something with
+"automobile" or "automotive" in its name).
+
+Also, for many common topics, you can just try using the topic name as
+the channel name (/join #music, /join #beer, /join #unix). Chances are
+it exists, and no harm is done if it doesn't.
+
+Once you've joined a channel, you'll be presented with a list of all
+the users in the channel, and anything you type (other than commands
+beginning with a slash (/)) will be sent to everyone in the channel.
+
+Text from other users will appear like this:
+
+<Bob> Hi there!
+
+Text you type will appear in inverse video. It will only be sent to the
+server when you press Return. You can use the backspace key to correct
+typos, or press shift-backspace to delete the entire message without
+sending it. (Future FujiChat versions will support the other Atari
+editing keys)
+
+IRC also supports private messages, which are sent to only one user.
+To send someone a private message, use the /msg (or /m) command:
+
+/msg Bob Hello
+
+When you receive a private message, it looks like this:
+
+MSG: <Bob> Howdy
+
+To reply, you would type "/msg Bob whatever you want to say".
+
+When you receive a private message, you can press the Tab key at the
+start of a new message to insert "/msg <nick> ", where <nick> is the user
+who last sent you a private message. This is handy for carrying on long
+private conversations, though you should be careful: Tab always sends
+to the last person who messaged you. If you unexpectedly get a message
+from a third party during a private conversation, you might accidentally
+send to the wrong person! Future versions of FujiChat will track more
+than one conversation, using Tab to cycle through all recent message
+recipients.
+
+IRC also supports the concept of channel operators (known as "ops"). These
+are people who "own" the channel, and have the power to kick other users
+out, ban them from the channel, set the channel topic, and a few other
+things. Channel operators' nicknames will be display in the nick list
+with an @ in front of them. Most channel operators are friendly folk
+who will help you out and answer "newbie" IRC questions, unless you're
+rude or repeatedly break the channel rules.
+
+Higher up on the food chain are IRC server operators (known as "opers").
+These godlike entities shouldn't be bothered with everyday mortal
+concerns, but sometimes you have a real problem and they're the only ones
+who can help. Most IRC networks have a channel where the opers hang out
+(usually listed in the MOTD text).
+
+IRC commands:
+
+[This is far from a complete list. Actually, different IRC servers/networks
+may have their own custom commands, so it would be very difficult to
+give a 100% complete list]
+
+IRC commands begin with a slash (/) character, and may take zero or more
+parameters. In the list the following conventions are used:
+
+<channel> represents a channel name, including the leading # character.
+IRC channel names generally always start with a #, but some servers may
+support special types of channels that begin with a different character.
+
+<nick> represents a user's nickname.
+
+<message> represents chat message text (whatever you want to say). This
+is free-form and generally should only include printable characters. IRC
+limits the length of a message to 510 characters. FujiChat further limits
+outgoing messages to 256 bytes, and will ring the Atari's "bell" if you
+try to type a message longer than this.
+
+If any of the above are shown in [] (square brackets), suck as [<nick>],
+this means the parameter is optional.
+
+/join <channel>
+
+Join a channel. You may only chat in one channel at a time in the current
+version of FujiChat. If you attempt to join a channel that does not already
+exist, most IRC servers will create the channel for you. The /join
+command may be abbreviated "/j".
+
+/part
+
+Leave the current channel. You must do this before joining a different
+channel. If you want to leave IRC (disconnect from the server), you
+don't have the /part the channel (simply use the /quit command)
+
+/nick <nick>
+
+Change your nickname. The server will respond with an error message if
+you try to use an invalid nick, or one that's already in use. If the
+command succeeds, there will be no response.
+
+/me <message>
+
+Send an "action". Other users will see your nick prefixed to the message,
+so that it looks like a sentence.
+
+Example: If your nick is Bob, and you type "/me is using FujiChat",
+it will appear to other users as something like:
+
+* Bob is using FujiChat
+
+/msg <nick> <message>
+
+Send a private message to another user. The /msg command may be abbreviated
+as "/m" or spelled the long way as "/privmsg".
+
+/quit <message>
+
+Quit IRC. The server will disconnect you, and FujiChat will give you
+the option to reconnect or return to the main menu. The <message>
+is optional.  All users in the current channel will see the <message>,
+which could be something like "Nice talking to everyone", or give the
+reason why you're leaving IRC ("Wife needs to play M.U.L.E."). If you
+don't supply <message>, the server will just use your nick in place of it.
+
+/ping <nick>
+
+Send a CTCP PING request to a user. When the user's client receives the
+request, it will respond with a "pong". This is useful for determining
+whether the user is still connected to the IRC network. Also, if the
+response takes a long time to show up, you'll know there's a lot of
+network lag between you and the other user. (Future versions of FujiChat
+may calculate & display the lag time for you)
+
+/version <nick>
+
+Send a CTCP VERSION request to a user. The user's client will usually
+respond with the name of the client software and its version, although
+most clients can be set up to say anything the user wants, or nothing
+at all. FujiChat responds to other users' version requests with
+"FujiChat 0.1 (Atari 8-bit)".
+
+/ignore <nick>
+
+Ignore (don't print) any and all messages from <nick>. If no <nick>
+is given, /ignore shows the list of nicks that are being ignored.
+Up to 10 nicks can be ignored in the current version of FujiChat.
+When you ignore someone, they don't have any way to know that you're
+ignoring them (they don't get a message telling them).
+
+/unignore <nick>
+
+Stop ignoring a user. To clear the entire list (stop ignoring all ignored
+users at once), use "/unignore -a".
+
+/quote <message>
+
+Send a string directly to the server, verbatim, instead of to the current
+channel you've joined. If you don't know what this command is good for,
+don't worry about it: it's mostly used by the author as a debugging tool.
+
+Keyboard Macros:
+
+These are only active at the beginning of a line (in other words, you
+can't send them when you're in the middle of typing a message). The
+macros are:
+
+Control-N: performs a "/names #channel" for the currently joined channel.
+Control-W: performs a "/who #channel" for the currently joined channel.
+Tab: inserts the text "/msg nick" at the beginning of the line, where
+  the nick is that of the last user who sent you a private message.
+
+There may be a user-definable keyboard macro facility in a future version
+of FujiChat (or maybe not, if it'd make the client too bloated).
+
+Other IRC commands:
+
+Most other commands are supported in a dumb kind of way. Anything you
+type that starts with a slash, and isn't one of the recognized commands
+listed above, will be sent to the server with the slash removed and
+the command name converted to uppercase. This works pretty well for
+commands like /away, /kick, /mode, /topic, etc:
+
+Kick a user from a channel (if you're a channel operator):
+/kick <channel> <nick> [<message>]
+
+Ban a user from a channel (again, you must be a chanop):
+/mode <channel> +b <nick>
+
+Get a list of who's in a channel:
+/names <channel>
+
+Get a fancier list:
+/who <channel>
+
+NewNet-specific command: log in to NickServ
+/ns id <password>
+
+See RFC1459 for a complete protocol specification. Any of the commands
+shown there can be sent by prefixing them with a / character.
+
+RFC1459 on the web:
+http://www.rfc-editor.org/cgi-bin/rfcdoctype.pl?loc=RFC&letsgo=1459&type=http&file_format=txt
+
+Credits:
+
+FujiChat is written by B. Watson (aka Urchlay on NewNet).
+
+FujiChat includes software (the uIP TCP/IP) stack by Adam Dunkels. Without
+Mr. Dunkels' excellent and well-documented software, FujiChat probably
+would never have been more than a pipe dream.
+
+FujiChat also includes the Bob-Verter driver by Bob Puff.
+
+Special thanks to SteveS and Beetle for being my guinea pigs (erm, I mean,
+beta testers)
+
+You're invited to come hang out in #atari on NewNet any time. You can
+usually find me there, although I may be asleep at the keyboard. If you
+have trouble getting FujiChat to work, or have a bug report or feature
+request, or if you just use FujiChat, I'd like to hear from you.
+
diff --git a/doc/about.txt b/doc/about.txt
new file mode 100644
index 0000000..28f5a73
--- /dev/null
+++ b/doc/about.txt
@@ -0,0 +1,35 @@
+# Try to keep the lines <= 39 chars,
+# but the reader can handler up to 199 char/line.
+# Comment lines (like this one) are ignored.
+FujiChat: an Atari 8-bit IRC client
+(c) 2008 B. Watson (aka Urchlay)
+
+Version 0.4, 20081019
+
+This program includes the uIP TCP/IP
+stack, (c) Adam Dunkels.
+
+Bob-Verter driver (c) 1989, Bob Puff
+
+[insert legalese krap here]
+[more legalese]
+[it's going to take up a few lines]
+[...]
+[...]
+[I hate legalese]
+
+[Long line that should be handled correctly by the line-counting logic. It's 3 screen lines.]
+
+Special thanks to the FujiChat alpha
+testers:
+
+- Beetle
+- charliec
+- SteveS
+
+...and the rest of the NewNet #atari
+crowd.
+
+Stop by #atari sometime and say hi,
+everyone's welcome!
+
diff --git a/doc/newdesign.txt b/doc/newdesign.txt
new file mode 100644
index 0000000..8e45fab
--- /dev/null
+++ b/doc/newdesign.txt
@@ -0,0 +1,81 @@
+/* TODO: move the non-IRC-related config to a separate SETUP program,
+	and a separate UIP.CFG file. This will be shared by all apps that
+	use uIP, such as the planned telnet and FTP clients. Also it means
+	we don't have to bloat each program with a complete config UI
+	for things like the local/peer/DNS IP addresses.
+
+	In fact the SETUP utility might resolve IP addresses for us, so
+	each app might not need its own copy of the resolver... though
+	that's maybe a bit clumsy to use for FTP, since you generally want
+	to easily be able to connect to arbitrary servers (unlike, say, IRC
+	where you usually use the same server all the time). Perhaps SETUP
+	could resolve arbitrary hostnames, then write them to a /etc/hosts
+	type of file. Parsing /etc/hosts entries is fairly lightweight,
+	could be done in all the client programs...
+
+	...or maybe what should happen is that there should be a RESOLV
+	program that can resolve hostnames, and read/write them in text
+	form to a HOSTS.TXT file... and also parses the HOSTS file and
+	stores the hostname strings and 4-byte IP addresses in a fixed
+	area of memory. The app programs could just look up hostnames in
+	this memory area, without having to open & parse HOSTS themselves.
+	cc65 programs by default start at $2E00. The Bob-verter driver ends
+	around $2200 (other R: drivers should be comparable), which gives
+	us around 3K of unallocated memory. Assuming the average hostname/IP
+	pair is 50 bytes, that'd give us about 60 of them. The RESOLV program
+	would stop the user from adding more hostnames when there's no space
+	for them (and let them delete some to make room, maybe commenting them
+	out so they remain in the HOSTS file for future uncommenting).
+
+	Ultimately there should be a master AUTORUN.SYS file with a menu
+	that runs the other sub-apps (or lets you exit to DUP). Menu would
+	have options like "DNS", "IRC", "FTP", "Telnet", and "Network
+	Setup". Of course I need to write a program loader, there's no
+	exec* functions in cc65! The Network Setup option would let you
+	specify the R: driver you want to load, so it wouldn't have to
+	be prepended to any of the executables, and would be auto-loaded
+	the first time you try to run any of the apps that need it. It'd
+	be nice if the main menu program had at least a few DOS functions
+	as well (delete/copy/rename/lock/unlock, format too?)
+
+	Probably, FujiChat's 1.0 release will be as a standalone IRC client,
+	with the current config UI stuff as-is. The other stuff would be
+	released months from now, under the label "FujiNet" or something, and
+	include a new version of FujiChat as one of several apps.
+
+	The final distibution disk will need at least some documentation in
+	Atari-readable text format, plus a doc-reader program.
+
+	All the subprograms need to end with RTS to the menu program, which
+	shold be small and stay resident in addresses not touched by cc65
+	(I've got 128 bytes each in the cassette buffer and page 5, also
+	256 more in page 6. Should be easy to squeeze into 512 bytes, no?)
+
+	So a disk directory would contain:
+
+	DOS.SYS, DUP.SYS
+	AUTORUN.SYS - the main menu and subprogram loader
+	BOBVERT.XEX - the Bob-verter R: driver
+	A850.XEX - the 850 R: driver (from DOS 2.0S I guess)
+	MIO.XEX, BLACKBOX.XEX, etc, drivers for other serial ports
+	HOSTS.TXT - the /etc/hosts file, human-readable and -editable
+	README.TXT - docs
+	MORE.XEX - doc reader (should handle ASCII or ATASCII EOLs)
+	SETUP.XEX - set up global network settings (local/remote/dns IPs, also
+	            things like screen colors, key-repeat rate, etc).
+	DNS.XEX - lookup hostnames, maintain and parse HOSTS.TXT
+	FTP.XEX, TELNET.XEX, IRC.XEX, PING.XEX - the apps
+	FTP.CFG, TELNET.CFG, IRC.CFG, etc - app-specific settings
+	FUJINET.CFG - global settings
+	...if there's room on the disk, a small text editor might be nice
+	to include.
+
+	The whole thing should be distributed as a bootable, single-density
+  	DOS disk (undecided which DOS, either 2.0S or MyDOS 4.5).
+
+	Alternatively, all the XEX files might be named COM, and the whole
+	thing could run under a CLI DOS like Sparta (if it'll actually
+	run). The apps could take optional CLI arguments, also... and the
+	AUTORUN.SYS would actually be unnecessary!
+
+ */
diff --git a/doc/notes.txt b/doc/notes.txt
new file mode 100644
index 0000000..3f25388
--- /dev/null
+++ b/doc/notes.txt
@@ -0,0 +1,281 @@
+Definitely need to rewrite huge swathes of code in asm.
+Candidates are:
+
+fujichat.c: main(), handle_keystroke(), and the protocol parsing
+routines
+
+rs232dev.c: the whole thing could be rewritten in asm for speed,
+but the size isn't so bad.
+
+uIP itself: have to investigate. Some of the code is pretty
+hairy. Before rewriting in asm, should make it so we can
+compile without TCP listen support, since we don't use it.
+
+
+Need to re-do the R: handler stuff. At least one driver (the
+plain Atari 850 one) actually crashes when loaded from either
+the DOS menu or aexec. Apparently it *only* works if it's
+loaded as autorun.sys. So, something like this:
+
+- Initial autorun.sys on disk loads a program called makeauto.
+[done]
+
+- makeauto asks for the serial driver, then concatenates the
+driver + menu.com into a new autorun.sys (renaming the old
+one to autorun.old or something), then asks user to reboot.
+[done]
+
+- Any time fujiconf loads and can't find an R: handler, it tells the
+user and runs makeauto for him (or anyway asks, with default Yes). The
+"set R: driver" stuff in fujiconf needs to move to makeauto (and be
+changed so it appends files instead copy).
+
+- FujiChat itself still won't contain any R: detection or
+anything, beyond the RS232 Not Initialized error message
+[done]
+
+- While I'm at it, fix the filename paths so they *all* begin with
+the D: prefix.
+[done]
+
+- Possibly menu.com has a new menu item, "RS232 Setup", and warns
+the user "You must run RS232 Setup before using FujiChat"
+
+20081124 bkw: Add /peek, /poke, /fgcolor, /bgcolor commands.
+
+Also, now that we're parsing numerics from the server, it'd be
+nice to do the alternate-nick thing, for when the nick is in use.
+
+20081124 bkw: Keep a time-of-day clock (don't use RTCLOK to store
+it though). At connect, send /TIME to the server, parse the results.
+The config file will need a timezone setting.
+
+20081121 bkw: Feature idea: auto-away when attract mode kicks in,
+with default away message (but don't announce to channel). Un-away
+as soon as a key is hit. Possibly let the user set a timeout
+instead of letting the OS default to 9 minutes.
+[done, using default OS timeout only]
+
+Ideas for logging:
+
+Will anyone give a shit about logging to disk? If so, it wouldn't
+be impossible... but we'd likely drop packets (or does uip_stop()
+gracefully handle this, maybe with a callback?)
+
+/log [on|off|flush|file filename|search <term>]
+
+Keep the disk file open? Log stuff to memory, then just before
+the buffer fills, write it out to disk.
+
+Logging to memory, looks like we have a little over 5K for this.
+When we get ready to log a message that would put us past the end
+of the buffer, memmove() the buffer down by some amount (say 1/4
+of its size).
+
+Log viewing is a mode. While enabled, handle_keystroke() will do
+the --more-- thing. Traffic indicator's still active, and we
+still log stuff to memory, but *don't* print it. If the log
+has to be shifted down, also shift down the currently-viewing
+pointer. If the view pointer points too low to move, set it
+to the bottom of the log buffer if it isn't already (user will
+get confused, but what you gonna do?). Forward/backward searches
+should work. Filtering by nick should work.
+
+When entering logviewer mode, save the current end-of-log address.
+Any time the log moves while viewing, also subtract from this
+address. More stuff can be coming in & being logged above this
+address... on exiting logviewer mode, anything aboved the saved
+address should be printed to the screen immediately.
+
+In this model of "scrollback" support, we actually don't scroll
+per se, we're *still* using stdio to print stuff. It might be
+that on entering logviewer mode, we should run through the log,
+counting characters, so we'll know where each screens' worth
+starts (for going back/up in the viewer). Either that, or we
+could print the damn thing backwards?
+
+At a price of 3 bytes per message, we can store timestamps. Not
+sure if it's worth it. Actually maybe we can just store a single
+byte in the buffer every N minutes, to give a rough guide to
+how long ago the next bunch of messages were.
+
+How bout this for a lightly compressed format: we're only storing
+7-bit printable ascii, in 8-bit bytes, so...
+
+1st byte:
+
+0-31 - No message, just timestamp. Next message starts at
+next byte in buffer. The value is the minutes-1 since the
+last timestamp. Basically, every minute of wall-clock time,
+a timestamp of 0 is added to the buffer if someone has said
+something in the past minute. If not, there will already
+be a timestamp at the end of buffer, so just increment it
+(unless it's at the max value, in which case add a zero
+timestamp after it). We can use these to e.g. print
+"(42 minutes silence)" or such. I'd like to be able to
+do "N minutes ago" type messages, but to do that I have to
+run through the buffer backwards to calculate what they
+should be (then forwards to actually read messages from it).
+
+Anything else: 1st char of nick, or 0x80 meaning "same nick as last
+message" (or 0x81 meaning "my nick"?). Some care has to be taken when
+memmoving the buffer: blocks of messages from the same user need to be
+treated as a unit (kept entirely, or disposed of entirely).  For this
+to make sense, such blocks have to be kept short (say, less than the
+move-amount).
+
+Next bytes are the rest of the nick, with bit 7 set for the last
+one. In case of a 1-char nick, 1st and only char has bit 7 set.
+
+After last nick char comes the message.
+For the first byte, if the top bit is set, the bottom 7 bits are:
+
+0 - empty message
+1-31 - stuff like join/quit/part (don't bother to store part,
+quit, or kick messages? or store normally?)
+Anything else - normal message character (the only one, if the
+top bit is set).
+
+Further message bytes are stored with the top bit of the last byte
+being set.
+
+So if someone joins, says hello, and parts (<c> means 'c' with high
+bit set:
+
+Use<r>\x01\x80Hello\x80\x02
+
+(Assuming \x01 is the join code and \x02 is the part code)
+
+This is 13 bytes. If we stored what a normal client stores in its
+log, it might look like:
+
+User has joined\n
+<User> Hello\n
+User has left\n
+
+Which is 16+13+14 = 43 bytes. Most clients would actually store the
+channel name with the joins/parts; I left them out to make the
+comparison more fair (we don't penalize them for storing info that
+we don't store, only for storing the same info less densely).
+
+
+20081120 bkw: smallest 0.4 binary, with all FEAT_* turned off except
+for FEAT_LOW_RAM_BUFFERS, the BSS ends at $920E. With COL80E relocated
+to $9A00, that gives us 1K for stack. Not great, but might work. It's
+still too big to use with E80 (by about 3K, counting the stack).
+
+COL80E loads at $7A00-$7F80, but doesn't really seem to use any RAM
+from $8000-A000 with BASIC disabled. If the code could be relocated so
+it loads at $9A00, we'd have a fighting chance of squeezing fujichat to
+fit. Currently fujichat loads $2E00-8D3B... meaning there'd be a little
+over 3K for stack & data/bss variables. Need to examine cc65's map file,
+see how high the data/bss stuff goes. Moving the input and output buffers
+to low RAM is going to help a lot. It also might be possible to move
+the stack to low RAM (it's supposed to sit right above the heap, but
+fujichat isn't using malloc(), which unless I'm mistaken means no heap
+usage... though some of the libraries it links with might be using it).
+
+Try compiling uip without UDP checksums, with fewer TCP/UDP conns,
+asm optimize anything that doesn't compile efficiently?
+
+It looks like TCP listen support could be made a compile-time option
+that could be disabled. IRC doesn't need to listen on ports except
+for DCCs, and we probably can't ever make those work anyway. It
+won't save much (guesstimate is 50-75 bytes)...
+
+Each TCP conn is supposed to take 30 bytes. For now we only need one,
+but we have 5, so wasting 120 bytes there.
+
+[so far, changing max. tcp conns, listen ports, and udp conns to 1,
+and disabling udp cksums, has saved 325 bytes. Worth it, but need to
+make sure the app still works!]
+
+[also, make some of FujiChat's features able to be removed at
+compile-time. Removing them all saves 963 bytes, and makes the BSS
+end at $96cb! If COL80E were relocated to $9A00, we'd have 800-odd
+bytes for the heap/stack, which still ain't enough... Possibly
+the stack could be shrunk by 256 bytes and relocated to $2700?]
+
+E80 is probably a lost cause. It seems to take 12K, which seems like an
+awful lot. Screen is hard-wired to $6E70, but it seems to not use any
+RAM from $A000-BFFF with BASIC disabled. moving the whole thing up 8K
+(assuming I can relocate the code) gives us a start address of $8E70,
+or 3K lower than COL80E, or 130-odd bytes(!)  above the end of cc65's
+code segment (ouch!)... however maybe I could leave it unrelocated, and
+use a linker script to move all the data/bss/heap/stack/etc (everything
+but the code, and maybe some of the code too) to the $A000-BFFF area
+(8K seems like a good bit, the stack is 2K).
+
+Fast E40 driver doesn't have to be a full E: replacement! Instead, we only
+need to hook the "put 1 byte" routine, and do the following:
+
+Check & see if byte-to-print is printable or an EOL. If it's neither,
+jump to the OS's print-one-byte routine.
+
+If the screen is about to scroll (if we're on bottom line and byte is
+0x9b, or if we're on bottom line + last column and byte is printable),
+we capture the top line (first 40 bytes) of screen RAM and store in
+scrollback buffer.  We can probably detect when the line ends in >1
+spaces, and not store those.
+
+If a screen scroll is needed, do it ourselves, *fast*. This may turn
+out to be too messy or bloated to deal with, but I think it might not
+be so bad.
+
+If the char is printable, print it, *fast*. Fast E40 doesn't have to
+support margins other than 0 and 39, which should help. Also we can
+make assumptions about where the screen RAM is if need be, and use
+multiple ZP pointers into it (using the FP zero page area).
+
+However much scrollback RAM we have, we have to subtract 1K from it for
+a viewing buffer. This allows us to keep printing to the main screen
+RAM while it's not showing, and buffering it as it scrolls, without the
+viewing buffer changing while we look at it... also when done viewing,
+we toggle back to displaying main screen RAM instantly.
+
+I'm thinking there have to be separate builds for Fast E40 and whatever
+80-col driver I get working. The 80 version won't have any support for
+scrollback at all, not least because there's no RAM for the buffer!
+
+Also if there's ever going to be a separate edit buffer "window",
+or multiple channel windows, fast E40 is where they'll live.
+
+It might also be possible to do word-wrap. Not sure whether that's better
+done in the driver or in the app. Doing it in the app means it'll work
+in 80-column mode, too.
+
+...potential new feature: should be able to do ping times by sending the
+low 2 RTCLOK bytes in numeric form, then when the response comes back,
+decode back into 2 bytes, subtract from current RTCLOK, convert to
+10ths of a second, and print.
+
+I *really* wish I could do CSLIP. Maybe later. Not delved too deeply
+into the guts of uIP... maybe the serial driver could transparently
+do the comp/decomp, and speak plain SLIP to uIP? (would this be
+too slow, cause drops? Even if it doesn't make us drop packets, would
+the CPU overhead negate any benefit to be gained from it?)
+
+Also on the drawing board, keyboard buffering during rs232 I/O. Fairly
+straightforward, I think. Don't actually cgetc() or anything, just
+save the contents of CH in a buffer if it's not $FF, and set it
+to $FF to clear the keystroke. In fact, there's a prototype of it
+in keybuftest.c (just needs to be integrated).
+
+Another idea: a status line wouldn't be so hard to do, even without a
+fancy E: driver. Could write directly into the first 40 bytes of screen
+RAM. I don't want to give up a line of display though... but instead of
+a full status line, it'd be cool to display a little up or down arrow
+in the upper-right corner during rs232 sends/receives (save & restore
+the character that really goes there). The screen codes for the up
+and down arrows are $5C and $5D ($DC and $DD for inverse).
+
+/j or /join without a channel should rejoin the current channel, if
+FujiChat thinks it's in a channel. This would give us an easy way
+to rejoin the channel if kicked.
+
+There needs to be an extra-dumb terminal program for use with manual
+login systems. It should fit in 1K or so, load on top of fujichat's
+input/output/msg buffer space, and RTS back to fujichat when it's
+done. Later on there should be a chatscript engine that loads in
+the same space and works the same way.
+