Date   : Wed, 16 Oct 1985 21:33:44 GMT
From   : "R.Thomas" <rbt%sftig.uucp@BRL.ARPA>
Subject: (Apple CPM) AE Ramworks and PCPI Applicard questions

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