Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site sftig.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxn!mhuxm!sftig!rbt From: rbt@sftig.UUCP (R.Thomas) Newsgroups: net.micro.apple,net.micro.cpm,net.micro Subject: (Apple CPM) AE Ramworks and PCPI Applicard questions Message-ID: <609@sftig.UUCP> Date: Wed, 16-Oct-85 17:33:44 EDT Article-I.D.: sftig.609 Posted: Wed Oct 16 17:33:44 1985 Date-Received: Fri, 18-Oct-85 00:41:37 EDT Distribution: net Organization: AT&T Bell Laboratories, Summit, NJ Lines: 108 Xref: watmath net.micro.apple:2242 net.micro.cpm:4740 net.micro:12383 The following is the text of a letter I sent today to Applied Engineering about their Ramworks ramdisk driver for the PCPI Applicard CPM card for the Apple II series. My question for the net is -- Does anybody have a fix for these problems? Also, if Steven N. Hirsch is on the net (He appears to have been the author of the driver in question...) would he please get in touch with me. Please respond by E-mail, if possible. Thanks in advance Rick Thomas {ihnp4, akgua, most other backbone sites}!attunix!rbt (201) 522-6062 ------------------------------------------------------------------ October 16, 1985 Applied Engineering PO Box 798 Carrollton Texas 75006 Dear Sirs: I recently bought a copy of your ramdrive device driver for the Applied Engineering Ramworks(tm) board and the PCPI Applicard(tm). I have noticed a couple of problems with it that I hope you will correct in later releases. I would also appreciate it if you could send me an appropriate patch for the release I have. I am using it on an 'enhanced' Apple IIe, with an Applicard in slot 4, an Apple Super-Serial card in slot 1 for my serial printer, an Apple Duo-Disk in slot 6, and an Apple extended 80 column color card in the Auxiliary slot. I was told over the phone by your tech support people before I bought it, that the software would work with the Apple color card just as well as with the Ramworks card, though the resulting ramdrive would be small. In fact it does seem to work quite well. There is enough room in the ramdrive for a copy of Turbo Pascal, PIP, and a few other useful utilities, and even a small amount of scratch space left over. I have a small "SUBMIT" file on my boot disk that loads up the ramdrive with the things I want on it at system startup time. The feature of configuring the ramdrive as disk A: is really very nice! The first problem is really quite trivial, and I would not mention it at all, except that I am already writing to you about the second problem. The first problem is that the "R" and "W" that are supposed to flash in the lower right corner of the screen, appear as mousetext instead of letters on my enhanced IIe. As I say, not a big problem, but something worth noting for future releases. Personally, I would have preferred to hear the speaker grumble a little bit when the ramdrive was working, instead of having one character of my screen be taken away from me, but that is a matter of preference. (After all, real disk drives make noise when they are doing something, why not the ramdrive too?) The second problem is somewhat more serious. The README.WS file that comes on the same disk with the software warns of a potential conflict between the PCPI BUFFER.DVR printer driver and the ramdrive software over control of the first (in my case the only) bank of auxiliary memory. It says to "Be aware of this, and install accordingly." But it does not say what installing accordingly means. Is there an alternate printer driver that does not use the aux memory? Or is there a patch to BUFFER.DVR to prevent it from using the aux memory. BUFFER.DVR works just fine without the auxiliary memory on machines without the extended 80-column card. It buffers in the leftover part of main memory. So it presumably could be patched to ignore aux memory altogether, but the README.WS file does not give a clue as to how to accomplish this. With these questions in my mind, I said to myself, "nothing ventured, nothing gained." and decided to try it anyway. To my surprise, it seemed to work! I put things in the ramdrive, and got them back intact. I queued up several small files to the printer and could still use the ramdrive. The queued files printed fine. They were obviously not being overwritten by the stuff I put in the ramdrive. So, OK, BUFFER.DVR must be using the leftover main memory first, and only going to the aux memory as a last resort. "Well," said I, "lets really load it up and watch it rip!" So I queued up a very large file to print that should have filled up the available main memory and sloshed over into the aux memory, then tried some ramdrive activity. Still OK! "Better and better!" said I, feeling really fine. But still, that warning in the README.WS file must have meant something! So I queued up a second copy of the same print file and about half way through it, the entire system hung. Everything stopped at once. I had to cold boot to clear it up. So the conclusion is that if I am careful not to fill up the printer buffer too full, I can use it the way I have it configured. But it would be awfully nice to have some kind of patch that would keep it from hanging if I get careless and queue up too much printer output. Also, the README.WS file should be more explicit on the subject of "installing accordingly". Sincerely, Rick Thomas