diff options
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/Compatibility.txt | 33 | ||||
| -rw-r--r-- | doc/HOWTO | 161 | ||||
| -rw-r--r-- | doc/README | 396 | ||||
| -rw-r--r-- | doc/about.txt | 35 | ||||
| -rw-r--r-- | doc/newdesign.txt | 81 | ||||
| -rw-r--r-- | doc/notes.txt | 281 |
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. + |