Beta release of Term One components: Apple Super Serial Card driver and a Dumb Terminal for Testing Serial Port Drivers by Scott Alfter Skunk Works Software Co. 43 Megan Dr. Henderson, NV 89014 Phone: (702) 896-2676 Internet: alfter@uns-helios.nevada.edu GEnie: S.ALFTER Programs and Documentation Copyright (C) 1990 by Scott Alfter dba Skunk Works Software Co. All Rights Reserved Hardware Requirements These routines require an Apple IIe, IIc, IIc Plus, IIGS, or a suitable clone. If you have a IIe or IIGS, a Super Serial Card or compatible is required. (Some internal modems, such as the Applied Engineering DataLink and DataLink 2400, have a Super Serial Card "front end." These modems will work with these routines. In fact, they have been successfully tested, debugged, and used with my DataLink 2400.) Please note that the IIGS modem port is not supported at the present time. Description This package includes four other files. Two are binary files to be used under ProDOS on an 80-column Apple IIe or compatible. The other two are source code in plaintext form for the binaries. SSC.DRIVER is an interrupt-driver serial port driver for the Apple Super Serial Card and compatibles. It should be loaded into main memory at $800. TEST.TTY is a short terminal program that lets you exercise all functions of any Term One serial port driver. (Presently the only driver available is for the Apple SSC.) It loads and executes at $2000. Use Instructions Load the files into main memory at the addresses given above. Once that's done, enter PR#3 to activate 80 columns. Finally, a CALL 8192 will start the terminal. The default setup is to initialize slot 2 at 2400 baud, 8 data bits, 1 stop bit, and no parity. Pressing Open-Apple-R cycles the baud rate through seven possible values: 300, 1200, 2400, 4800, 9600, 14400, and 19200 baud. Open-Apple-F alters the data format between the default and an alternate of 7 data bits, 1 stop bit, and even parity. Open-Apple-S cycles slot numbers from 1 through 7. If the driver can initialize the port with a certain configuration, the terminal will respond with " initialized." If not, either the baud rate is not supported by the port, or there is no port in the selected slot. If there is no card in a slot, or if there's some other type of card (disk controller, for example) in the slot, the driver will refuse to initialize. Also, not all serial ports can support all the baud rates Term One will use. For example, 14400 baud is not supported by the Super Serial Card. Select this rate and the terminal will beep you. If you change the baud rate of an active port, it will then stay at the previous setting (in this case, 9600) until you press Open-Apple-R to select a valid rate for that port (19200). Three other Open-Apple combinations are supported. Open-Apple-B sends a 233 ms BREAK over the line. Please note that the timing is only valid at a system clock rate of 1 MHz. If you have some sort of accelerated system, I'd like to hear how to tell how fast a given system is running so I can make the routine compensate for varying clock speeds. Open-Apple-Q exits the program and shuts down the serial port. Last but not least, Open-Apple-? gives you a list of available commands. The source code files are in plaintext format, but the pseudo-ops used are those for the MicroSPARC/MindCraft Assembler. If you want to port the source to another system such as Merlin or ORCA/M, translation of some pseudo-ops will be required. Also, note that the source code serves as technical information regarding the interface between the serial port driver and the rest of the Term One system. Known Bugs and Deficiencies The only one I can think of is the problem with timing a hardware BREAK. If you have a IIGS, IIc Plus, or any computer with an accelerator (TransWarp, Zip Chip, etc.), send me info on how to (1) detect that an accelerated system is being used and (2) detect the current clock speed. Presently the 233 ms BREAK will only last 233 ms at the standard 1 MHz clock rate. A IIc Plus will produce only a 58.25 ms BREAK, which is non-standard and probably insufficient for most systems to act on. Why Did I Do This? Right now, I'm not completely sure how I want to get the Term One telecommunications system into the Apple II market. I could make it freeware or shareware and distribute it electronically. I could put an ad somewhere like Nibble and generate mail-order sales. I could, if I'm particularly adventuresome, approach a software publisher such as Beagle Bros and try selling it to them. Getting ad space in a magazine costs big bucks, though, and selling software to companies is a time-consuming process that sometimes hinders the distribution of your work. (For example, I have sold two programs to Nibble over the years. Only one of them has been published; they've had the other program for over three years and have done nothing with it.) I suppose I should explain how the Term One system will work before I try getting into the freeware/shareware bit. Term One will be a set of (usually) four interconnecting modules. For use as a terminal, these four parts will consist of (1) a serial port driver to control the serial port or card used in a particular set-up, (2) a display driver for visual output to the user, (3) a file-transfer module that will support one file-transfer protocol, such as XMODEM or ZMODEM, and (4) a kernel to tie the other three parts together and make a complete terminal program. The best part of this setup is that I can work on it a little bit at a time. Instead of writing one huge program that would be crippled by a bug lurking in some obscure section of code, modules can be tested by themselves. It also provides flexibility and upgradability. The first example of this flexibility is with the serial port driver. This package includes a "full-up" serial port driver for the Apple Super Serial Card and compatibles. I started with this interface because it is what I have in my setup. (Actually, I have an Applied Engineering DataLink 2400, which is described in ads as having an SSC "front end," but the net effect is the same.) I don't have an Apple IIGS; I have a IIe. This means that someone else will have to write a driver for the IIGS modem port. But just as easily as the GS modem port could be supported by Term One, other hardware could be supported as required. Now for the freeware/shareware question. This package contains the above-mentioned SSC driver and a "dumb" terminal that exercises all the medium-level functions (initialize port, get character, send BREAK, etc.) expected in a Term One serial port driver. The SSC driver is useless standing on its own, unless you have your own telecomm program you want to write. Writing interrupt-driven serial port drivers is a fate I wouldn't wish on anybody. Since that's the case, I've decided to come up with a very loose rule for distribution of the driver. You can copy it freely and give it to whoever you want. Source code is included, so if you see something missing, fix it. The source code, by the way, explains the protocol that the Term One kernel uses to communicate with the driver; you are advised to not mess with this protocol, though if you see something lacking in the efficiency of a routine in the driver, fix it and send me the change you made so I can incorporate it in future releases. If you want, you can even use the driver in your own software; all I ask is that you stick my name somewhere in the credits to your program. The terminal program is something of a quick hack; it was just a few hours' work to debug as fully as possible. It will not be a part of the final Term One distribution, but is only a beta-testing tool for serial port drivers. Its functionality is equivalent to a display driver and the kernel, rolled up in one package taking less than 1K of memory. Again, you can do pretty much what you want with this program, so long as you give me credit in any derivative works. Since this is only a beta release, I can hardly guarantee that the routines will work right all of the time. I think I've worked the bugs out (I especially hope all the bugs are out of the terminal program, given the fact that it is a testing program), but something may pop up. I can't and won't be held responsible for any losses you may incur as a result of using these routines. If something does go wrong, I would appreciate very much if you'd send me something through email or snail-mail describing your problem. Since source code for both programs is provided, you may be able to track down the problem, in which case I would be doubly grateful.