Notes on portprn.img Portprn.img is a machine language routine. Load it ,8,1 and SYS 4096 ($1000) The STOP key will break it at any time. The idea behind this program is a fairly simple one: The C64 accepts input, one line at a time, over the user port to which is connected an RS 232 interface. It translates the input from pure ascii into petscii as the data is received, and then prints it to a printer (device 4) on the bus. I went to this effort because I bought a second computer, which has a serial interface, and did not want to spend money on another cheap dot-matrix printer. The 1526 is a perfectly sound, if not lightning fast, text printer. The setup serves my purposes, kludgy or not. Although I have had problems getting it to work with a screen dump, it works fine when printing under program control. Screen notes: The screen shows the status of both the (serial printer) bus and the (RS 232 user) port. The checkmarks indicate the state (open/closed) of each. In addition, the error codes are read and sent to the screen as characters. Error checking per se is not done, rather, the results in the Accumulator or in the status byte are sent -- good, bad, or indifferent -- straight to the screen. It's a lazy way out, but if things aren't working, at least the codes are there to be analyzed. They are in the following order: RS 232 Status open: Error result in Accumulator and readst byte from kernal OPEN init: Error result in Accumulator from kernal CHKIN close: blank; never closed. Printer Status open: Error result in Accumulator from kernal OPEN init: Error result in Accumulator and readst byte from kernal CHKOUT close: Readst byte from kernal UNLSN, error result in Accumulator and readst byte from kernal CLOSE Of course, what you see are the screen codes (PRG Appendix B). Programming notes: The RS 232 interface is set at 1200 bps, even parity, seven data bits, one stop bit. The x-line handshake is implemented, although the port buffer is almost always empty when operating at ML speeds. Alphanumeric and punctuation characters are translated; carriage return and form feeds are fed straight to the printer. All others, including tabs and linefeeds, are stripped. This is only significant ML program I have ever written. I prefer compilers, but because Oxford Pascal does not recognize the user port at all, this seemed a natural application. The source code is commented and makes liberal use of symbols as I made notes to myself along the way. It was originally supposed to be a spooler, but that seems to be impractical for reasons outlined below. My choice of location was purely arbitrary and probably less than ideal. It wouldn't be very difficult to change, were you so inclined, by re-assembling with a different origin. I used the EA assembler by Lew Lasher available (or was) on this SIG. The buffered line is stored at $7000, and probably should be moved closer to the code, I guess. I don't pretend that it is the most elegant code ever written, but I think it may serve as a starting point if you are thinking of writing a communications program, or have a situation similar to mine. I have read three books on ML programming, including both of Richard Mansfield's highly acclaimed volumes. Helpful as they were, communications I/O was not in any of them. Nobody discusses the difference between CHROUT and CIOUT, for instance, and for me there was a lot of trial and error. For this reason, it is my hope that the source code will be instructive. Why not a spooler? Both the bus and the port communicate bit-by-bit (no pun intended). Assembly/disassembly of the BYTES used within the C64 to the BITS it needs to communicate is done in zero page by the CPU. Our friend the 6510 does one thing at a time, does it very well, and then goes on (like Major Winchester). Ergo, it cannot address both the port and the bus at the same time, as they need the same ZP routines. This limitation made it necessary (as I understand it) to close the bus down completely when printing. Hardware note: I constructed a null modem cable crossing pins 2/3, 4/5, 6/20. Crossing 5/20 should work as well. The software drops DTR (20) when it receives a carriage return, causing the sending machine to hold off.
Amiga7878