PCSVIEW2.PRG is an UNAUTHORIZED MODIFICATION to the original PCSVIEW.PRG, also
included in this archive.  When I downloaded PCSVIEW, I found two problems with
it, and one problem with fixing these problems (asside from the lack of source
code).

1) PCSVIEW.PRG seems to only want to read picture files from the A disk, even
if it is run from a different disk.  It also only reads files from the ROOT
directory of the A disk.

2) PCSVIEW.PRG will use a 50Hz screen frequency for some of it's supported
picture formats.  This is because it originates from Europe.  I don't know if
there is another reason for this.  This causes a problem for those of us (me)
who do not have a color monitor and use a TV set for color output.

Having lots of better things to do, I decided to try and fix these problems.
Since the original PCSVIEW.PRG file is only about 3K long, I thought it would
be no problem at all.  WRONGO!  PCSVIEW.PRG is stored in a compressed format,
using a program called ICEPACK.  The problem is that the ICEPACK program does
not support un-compressing the programs.  Fortunately, I was able to locate a
program called MULTPACK which would un-compress the file.  This un-compressed
version of PCSVIEW.PRG is included in this archive for those who don't have
MULTPACK (it is available on the "C"-word).  Other than being un-compressed,
there is no change to it.

Digging into the program, I discovered that it indeed seemed to be hard-coded
for the root directory of the A drive.  (It may have been possible for it to
change to a different drive somehow, but I didn't find out how.)  This has now
been fixed in the program PCSVIEW2.PRG.  It will now read picture files that
are on the default disk and directory, so if you have PCSVIEW2.PRG in the
subdirectory with the picture files and run it, you should be all right.

The second problem is corrected in PCSVIEW3.PRG (which also incorporates the
changes in PCSVIEW2.PRG).

These two files are also un-compressed.  I found a strange thing when I tried
to re-compress them with ICEPACK:  They ran OK, but did not blank out the
screen when loading the next picture, which means that between each picture,
the screen may fill with garbage.  Uncompressing them cleared up this problem,
so I don't know what is going on.

Technical stuff for hardcore fanatics:

The first problem was caused by the use of a string "A:\*.xxx" (where xxx is
either PI1, TN?, or PCS for the three supported picture formats) in a call to
SFIRST.  I simply added three to relative value of the pointer used in the
SFIRST call so the program generates the string "A:\*.xxx" but only sends
SFIRST "*.xxx".  Once it gets a file name back, it copied the first three
characters of the original string plus the name it got back in the DTA from
SFIRST or SNEXT into a table.  I changed the copying of the first three
characters from MOVE.B (A0)+,(A1)+ commands to MOVE.B (A)+,(A1) commands so it
still copied the three characters, but did not increment the pointer.  (When
modifying object code, one can not just remove or add commands, one must only
change things and keep everything at exactly the same length.)  I suppose I
could have just changed the three MOVE's into NOP's, but that wouldn't be as
fun, and also it would make it hard for someone else to figure out what was
originally there.

The second problem was simply finding the place where the frequency was changed
to 50 Hz and change the constant from 2 to 0.  (2 means 50 Hz, 0 means 60 Hz.)


Legal Notice: The changes I made were minor, and required for me to make the
programs work on my computer.  I believe that such modifications are perfectly
legal under the copyright laws.  There IS a copyright notice in the original
PCSVIEW.DOC file, but the program seems to be being freely given away and
these things that I changed were not listed as being intentionally included
limitations (such as the inability to print on a demo of a word processor), so
I think that what I did is legal.  If you like what I did, and it makes this
program more useful for you, please send money to the original author, not me.

-Ron V. Webber (ym on Delphi)