Amiga Elysian Archive/AmigaElysianArchive.iso/comm/jrc99n.lzh/read.me

Text File | 1990-04-05 | 14KB | 272 lines

read.me
-------
04/04/90
================================================================================

   Here's gamma #6 for you to tinker with.

   #5 was definately alive... with a nasty little bug.  It had to do with
inexplicable (and scarey) gurus that occured in previously functional sections
of code.  Anyways, it's fixed.

   You may also notice an almost 20k drop in weight.  That was due to a few
days of toying with compiler options in Lattice and removing the two internal
fonts.  A lot of people are not using them, so why penalize them with 8k
of additional weight that they're not using?

   All the fonts have been placed in an LHARC 1.10 archive, use the command
"LHARC -m -x e fonts fonts:" to extract all the fonts to your fonts: directory.
The two formerly internal fonts are now jrcibm/8 and jrcibm/16.  The pearl/8
font is used with SkyPix.

   Another biggie may have been finally fixed too.  This deals with the problem
a few people were experiencing with an A2091 or A590 disk controller where the
JR-Comm couldn't seem to find its files.  Although the BANGZERO and PATCH590
files hide this problem, I had to figure out what exactly was going on.

   For those who have had this problem occur, please test to see if it no longer
happens when not using these two patches.  Run the program for awhile to make
sure there aren't other areas of the program that react to this that have been
overlooked.

   The session timer has been increased to 3 hours from the original 90 minutes.
Also, there are rumors floating around that JR-Comm stops working after 30
days.  This is totally false, all that happens is that a "guilt" screen is
posted that tells the user that their evaluation period has expired.  Other
than that, the program is still completely functional.


03/26/90
================================================================================

   Here's gamma #5 for your debugging pleasure...

   Ok, here's the deal.  I hammered away on SkyPix all weekend and think
I've finally cured all the ills in that emulation.  I've been calling
T.B.A.G. MouseTrap and Lapse of Reason repeatedly and used most of the
demos and doors for tests, everything worked.  I also checked downloads for
those who've said that the download window had no display, I'm sorry to
say that it worked properly every time for me.  If you continue to have
problems with this, please leave exact information on the system you had
the problems with and the things you did prior to starting the download.

   The skypix pathname logic has been changed a bit.  All brushes and sound
files are now sent to that directory rather than creating a seperate
subdirectory for each phonebook entry.  This was due to the possibility of
ending up with complete pathnames that are longer than the maximum allowed by
AmigaDOS.

   I tweaked on the dialer a bit more and think I got a handle (finally)
on the lock-up some of you have experienced.

   Other than the few minor bugs that were repaired, as listed in the
bugs.doc text file, I've not had a chance to look into the title bar on
problem when starting.  I'm going to be in New York for the next two days
on business and figured I'd leave you with this while I'm gone.

   Have at it.

03/22/90
================================================================================

   Here's gamma #4 for you to take a wack at...

   I've squashed just about all the non-SkyPix related bugs that have been
posted since the 0.99j release.  I'm going to concentrate on SkyPix while
you have a look at this version, how's that for multi-tasking?

   There have been a few bugs that I've been unable to verify, not that
they don't exist, it's just that they may be dependant on a specific
sequence of actions.  For instance, I caught the chat line problem because
of it only occuring in a specific order of keystrokes, same goes for the
low memory stomp when double-clicking on the only selected entry in the
phonebook.  Special thanks to Steve (who seems to be especially good at
finding these types of problems).

   Anyways, the list of problems I've not been able to verify, or locate
by driving the code by hand are:

   -  ZMODEM uploads locking up or causing a guru when aborting via the
      close window gadget.

   -  Send user ID causing a loop.

   -  Deleting the current jrcomm.def file while running JR-Comm, then saving
      a new one which results in a crash.

   -  Not hitting return on a string gadget after changing the contents
      which causes various problems, which ones?  longer or shorter
      resulting string?  more details on this.

   As the few remaining bugs get found out you're going to have to get more
detailed at reporting them in order for me to ferret them out.  Like I mentioned
above, you may have to run through a specific sequence of keystroke, menu and or
gadget selections in order to repeat it.  These logic state dependant bugs will
be impossible to pin down without detailed, step-by-step instructions for me
to duplicate and fix them.  I can't stress this enough.

   The program has broken the 190k barrier as you may have noticed.  Along
with working on SkyPix, I'm going to be converting all the gadgets from
static (always there) to dynamic (allocated only when needed).  This should
cut down on the code size by a considerable amount, hopefully by at least
15k, maybe more, I can't really tell until after I've completed it.  I can
tell you that there are over 250 gadgets there, so it is a good bit of data.
It can't be reduced completely, since there are position and other data that
has to be kept somewhere in order to create them when needed.

   The only drawback I can see to this is that it is going to take a bit
longer to open a requester since the gadgets are going to have to be created
first.  I hope that the increased time delay isn't excessive, we'll see...

03/10/90
================================================================================

   Here's gamma #3 for your testing delight.

   The review buffer still has the same problems when trying to deal with
incoming data while also scrolling through the review buffer.  Basically, it's
sick as a dog.  I've more-or-less figured out the problem, which unfortunately
probably can only be fully cured by a rewrite.  Guess I was too slick for my
own good by trying to make as much of the display and review buffer code common
as possible.  This is especially evident when using any of the emulations other
than TTY.  I really got myself in a jam with this one, but I'll take a breather
and see if I can round of this can of worms without resorting to a larger can...

   See the bugs.doc for the fixes/addtions to this version.

   The big thing is to pound on the transfers, the asynch file I/O has been
hammered by me, but I want to make damn sure it's 100%.


Asynchronous file I/O
---------------------

   JR-Comm now uses asynchronous file I/O.  What's that mean?  Think of the
transfer buffer as being two equally sized buffers half as large as the size
defined in the general parameters requester.  By sending a message to AmigaDOS
telling it to write the contents of one buffer, we can continue with receiving
more of the file to the other buffer while AmigaDOS is still writing the rest
of the first buffer out to disk.  There's no real need to understand the
details of what's happening here, the end result is higher throughput to disk.

   Now floppy users can enjoy ZMODEM throughput in excess of 1720cps at
19.2kbps, as tested by two Amigas tied directly via a 19.2kbps connection
using both internal serial ports and XON/XOFF handshake enabled.

   You can't use YMODEM-g for downloads to floppy unless you are using a
serial device driver that supports the lowering of RTS when the internal
serial buffer is almost full.  Additionally, the modem you're using must
also recognize this signal and stop sending data to your machine, the HST
series of modems from USRobotics is known to support this type of hardware
hadnshake.  XON/XOFF handshake cannot be used with this protocol due to the
requirement of full 256 byte transparancy.  The serial.device driver supplied
by Commodore does not support this method of hardware handshaking (1.3.2
release), therefore this protocol can't be used to receive to a device as
slow as a floppy.  Transfers to ram or to hard disk will work with no problems,
so long as a 2 or 4 color display is used.  By using an 8 or 16 color screen,
you will run the risk of getting backed-up and most likely overflowing the
serial driver, which will cause the YMODEM-g transfer to fail.

   In addition to file transfer downloads, the capture buffer and the printer
are now controlled asynchronously.  File uploads (protocol and ASCII) are
also double-buffered via asynchronous file I/O.


SkyPix pathname details
-----------------------

   There is now a SkyPix pathname in the general parameters requester.  This
path should point to a sub-directory in your JR-Comm pathaname.  For example,
"JRCOMM:skypix" could be used.  What JR-Comm will do is create a pathname by
adding the name of the phonebook entry to the SkyPix pathname so that all files
unique to the Atredes or SkyLine BBS can be kept in a private directory to avoid
potential filename collisions with other systems.  If the created sub-directory
doesn't already exist (in the case of first-time calls) JR-Comm will create it
automatically  for you.

   So, you're calling a system with the name of "AnySkyBBS", the created
pathname after a connection is established would become, "JRCOMM:skypix/AnyBBS",
using the example from above.  JR-Comm will then direct any brush or sound
files to that directory so that they can be saved for future use when calling
that system again, this can really decrease the time spent online by not having
to receive these files each time you call.

   To prevent files from getting cross-wired, JR-Comm will reset the pathname
to the root SkyPix path once carrier is lost (you hang up your modem).  This
is yet another reason to have a functional DCD signal, see chapter 2 on this.

   If you use SkyPix but dial manually instead of using the dialer, all files
received will be placed in the root SkyPix path.

================================================================================

02/28/90
--------

   Ok, here's number two in the gamma series.  Lots of bug stomps, read the
bugs.doc file to see which ones were done, and any I may have overlooked.
Please let me know if I didn't fix one that you've already posted.

   Make sure to test the ones you did find to insure that they've indeed been
repaired.

   Renamed the install script to install_floppy, this script is only for
first time floppy users who want to create a bootable JR-Comm master disk.

   Also wrote an install_fonts script so that only the fonts will be copied
over, it will create the necessary directories if they don't already exist.


02/23/90
--------

   First off, yes, my real name is John, but I've been known by the moniker
"Jack" by everyone since before I could speak.  I won't go into the rather
bizzare naming ritual my family observes, but suffice it to say that my father
and I share the same first name while our middle names are given for members
or surnames of prior generations.  Thankfully, I was not cursed with a "junior"
or numeric postfix.  Anyways, the "John" is now in place for copyright reasons,
just thought I'd clear that up...

   ...And now back to our feature presentation...

   Here is the first gamma release of JR-Comm 1.0.  Everything that will be
included in the 1.0 distribution archive is present in the hopes that a good
number of you will actually try to use as many of the features as you can so
that you can help put the final "polish" on JR-Comm before it is unleashed to
the world.

   The primary motive here is speed, please get back to me with any bug reports
as soon as you can, I want to post one more gamma before freezing it for 1.0.

   In addition to beating on the program itself, please check that the floppy
installation script works and that the documentation jives with what is really
happening with the code.  I've gone over it a few times, but I've probably
missed more than my share of things.

   Also note that there is no JR-Update program included, I've not had time
to write one yet.  So, save those 0.94a phonebooks and macros files for the
1.0 release.  No other versions will be supported for conversion to 1.0
format, the beta releases were private, so you shouldn't have been using them
in the first place...

   I had also wanted to have the external phonebook editor ready for inclusion
with the 1.0 distribution archive, but it won't be ready for another month or
so.  I didn't want to hold up the release of JR-Comm any longer, so I'm going
to be posting that seperately.

   One last note.  In the 0.94a release I had said that I planned on keeping
the unregistered public one release behind the one that registered users get.

   Unfortunately, the real world has shown me that this is not going to be
possible due to a small number of ethically deficient individuals as well as
one or two "nefarious betazoids".

   As a result, JR-Comm now sports a registration front-end along with a
90 minute session timer for unregistered copies of JR-Comm.  An associated
"guilt" screen is displayed after the user has exceeded his/her 30 day
trial use period.  Excepting these two features, JR-Comm is in every other
way, fully functional.

   -jack-