Loadstar 195/195.d81/t.tyb-64

Text File | 2000-01-01 | 12.0 KB | 414 lines

        TINY YELLOW BROTHER

             (TYB-C64)

  Program and Text by Doreen Horne

     ML Module by Craig Bruce
          and Doreen Horne


    This is an adaption for the C64
of Craig Bruce's C128 program LITTLE
RED READER which transfers files
between MSDOS and CBM formats. TYB
requires that MSDOS disk operations
be done on a 1581 or compatible
drive. On the CBM side any drive can
be used.

    Being for the C64 has imposed
certain restrictions on the number of
MSDOS and CBM files that can be
handled. The C128 has the great
advantage of being able to store its
BASIC variables in BANK1 and use the
whole of BANK0 from $1C01 to $FF00 or
thereabouts for both a BASIC program
and storage space.

    The TYB-C64 BASIC program, whilst
based on the original LLR for the
C128 has had to be trimmed severely
(couldn't compete at all with the
expanded V2.7 on LS C128#41). To
provide more memory for BASIC
variables TYB has its binary code at
$C000. Other than that I only made
such alterations as were necessary
for the C64 (some locations in zero
page which were used for storage of
machine code variables by the C128
cannot be used for this purpose by
the C64 and vice versa). Also the
burst protocol which the 1581 and
compatible drives can use when driven
by a C128 had to be replaced by other
code.

    Even the SUPER CPU/C64 cannot
increase the the clock speed of the
C64's serial port to the necessary 2
Mhz required for the burst protocol
used by LRR when accessing MSDOS
disks. (I confirmed this with CMD).

    Using the replacement code, TYB-
C64 does not need Jiffy-DOS anywhere
at all but transfer speed is much
improved when Jiffy-DOS is involved
and Fender has confirmed that it runs
successfully even with RAMLink.

    You may ask why a C64 version at
all? My C128 equipment is slowly
giving up. I already have two C128C
keyboards and a 1571 drive out of
action and have only my C128D still
in working order. Secondhand
equipment is hard to come by and no
one is able and willing (and has
spares) to repair that which comes to
a halt. Australia is PC country!

    I found to my dismay that the BIG
BLUE READER/C64 will not even read a
disk directory file which is longer
than 1000 (probably 1023) blocks so
the only way forward is to make the
hardy C64 (with the assistance of
Craig Bruce's adapted LRR) do the
job.

    As the newer PCs run only on 3.5
inch disks there seems no point in
including code for 5.25 inch MSDOS
disks. TYB-C64 needs two drives and
whatever does the MSDOS work needs to
be 1581 compatible. The 1581 will
write only to a 3.5 inch disk
formatted in 720K MSDOS format.
WINDOWS does this for me. However if
an FD is used for MSDOS writing, like
LRR, TYB will write to a disk in the
high density 1.4M format.

    The maximum number of MSDOS files
that can be accessed is the first 30
on the disk and likewise the first 30
on the CBM disk. This had to be done
to avoid "out of memory" problems and
interminable garbage collections by
the C64. Everything else works much
the same as does LRR. Available free
disk space is the only limit to the
size of files which can be
transferred. These transfer from disk
to disk via a memory buffer of 1024
bytes.

    For those who may not have used
LRR what follows are some quick "how
to use" instructions. More "how it
works" information is found in
Craig's docs on LS 128 #41.

    The program always reverts to one
of the two main screens, either the
MSDOS directory screen or the one for
the C64 directory. As with LRR the
program can be used as an ordinary
file copier but if you intend getting
involved with MSDOS transfers then
the first thing to do is decide the
device numbers of your CBM and MSDOS
drives, using the F and M keys
respectively.
    With device numbers selected
ensure you are in the MSDOS screen
(see top left hand corner) then type
D to load the MSDOS directory even if
it is at that stage an empty
formatted disk.


 [CBM to MSDOS]
 [{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}]

    To transfer files from the CBM
disk to the MSDOS disk use the swap
key "/" (slash) to produce the CBM
screen, then use D to access the CBM
directory.

    The files will be presented as
BIN(ary)/P(RG) or ASC(ii)/S(EQ)
depending on their type in the CBM
directory. All SEQ files (shown as
ASC) will be translated to TRUEASCII
by the program unless the ASC is
changed to BIN. If you wish to
transfer the selected file to MSDOS
format to be used by that system as
an "attachment" for further
transmission to a CBM system then the
file information should be changed to
BIN(ary). All files designated BIN
are transferred with data exactly as
saved on the CBM disk.

    For use as email on a PC system
it may need translation to TRUEASCII.
Only a file in CBMASCII will
translate correctly so you need to
ensure that the word processor you
use to write this file in the first
place saves the file as CBMASCII and
not screen codes. If the file is
saved as TRUEASCII you won't need
translation and the BIN option should
be selected.

    The cursor is at the top of the
column marked S(elect) at first.
Using the T key at this point will
toggle/select for transfer all the
files presented. An "*" is shown
against each. The T key used again
de-selects the lot. Using the CRSR
keys up and down in this column and
typing RETURN alongside a selected
name will produce the "*" against
that name only.

    Similarly typing RETURN over BIN
or ASC in the TRN column changes the
translation status of that particular
file.

    When the selection process is
complete type C and the files marked
with the "*' will be copied to your
MSDOS disk.


 [MSDOS to CBM]
 [{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}{SHIFT-*}]

    To copy from an MSDOS disk to a
CBM disk ensure that you are using
the MSDOS screen (see top left hand
corner and use "/" to get there if
you are not). Use D to acquire the
directory of the MSDOS disk.

    It is presented in much the same
format as the CBM directory and the
selection and TRN columns work in the
same way but should you require the
result as a SEQ file then take the
CRSR key to the TYP column and type
RETURN. Similarly changing BIN to ASC
will ensure its translation from
TRUEASCII to CBMASCII. Use C to copy
when ready and the files will be
saved to your CBM disk.

    If there are more than 17 files
in your directories the balance is
shown on the second page and you can
get between the two screens
containing the directory by using the
"+" and "-" keys.

 [REMOVE:] When you have the MSDOS
directory on screen you can REMOVE
unwanted files by using R(emove). The
process is irreversible and what is
more this does not make inaccessible
files, if there are any, in the MSDOS
directory available. The "cancelled"
space is only written over when a new
file is saved to the MSDOS disk.
Whilst files transferred to MSDOS use
only 32 bytes in the MSDOS directory,
a file written to the disk by a PC
does on occasion use 64 bytes of
directory space and in the worst case
one could only have 10 files on the
directory available to TYB.

 [CBM/CBM COPY:] To use the program
as an ordinary CBM file copier two
drives are still required but two
1541s will do. Ensure that you have
used the F key to nominate the source
device and have the source directory
available on the CBM screen. If you
wish to change the source disk type D
for a new directory. Select your
files and type X. You will need to
provide the device number of the
destination drive then copying of the
selected files will proceed.

    In the MSDOS/CBM copying process
disk errors do happen. MSDOS #255
usually occurs if you try to load the
directory when you still have a CBM
disk in the drive. Change the disk
and type D again. It sometimes also
occurs if you try to read the same
MSDOS disk a second time. Whatever
the situation try typing D again.

    Error #3 (no address mark
detected on MSDOS disk) also turns up
sometimes when transferring, which
brings to a halt the copying process
of the file concerned. When this
happens during transfer from MSDOS to
CBM one does sometimes succeed in
getting the job done by having
another go when the screen indicates
that all other files selected have
been dealt with. When re-transferring
to CBM one need not scratch the
incomplete destination file. The
program will do it for you after a
request.

    Transferring from CBM to MSDOS is
another matter. If I understand the
original LRR documentation for the
C128 correctly it seems that after
the first fault one can recopy the
file to the same disk although there
appears to be snags about its
subsequent recovery. In my testing I
did not encounter any faults during
this process. If it does occur I will
use a newly formatted MSDOS disk when
trying again, and then endeavour to
transfer back to CBM any prior files
of importance on the questionable
disk for retransfer to a better
disk.

    Errors on the CBM side cause the
file being read/written to be closed.
They are reported and are usually
either a READ ERROR (corrupted
sector) or DISK FULL.

    There is one other thing which
persons who write files for email on
their CBM word processors have
probably already discovered. Keeping
the filename to eight or less
characters with a trailing .TXT makes
it easier to "insert" into the PC
system. Don't forget the need for
TRUEASCII!

    Another interesting fact for
users of a 1581 and MSDOS disks in
720K format is that the CBM disk has
a larger capacity than the MSDOS
disk. A newly formatted CBM disk with
its 3160 blocks free can hold 808960
bytes whereas the MSDOS disk has only
730112 bytes (2852 blocks) available
for use. As these are used in units
of 1024 bytes quite a bit gets wasted
if a program ends near the beginning
of a unit. The high density MSDOS
disk works in allocation units of 512
bytes. The CBM using a sector of 256
bytes at a time doesn't waste disk
space to the same extent.

    When transferring between CBM and
MSDOS it is a good idea to keep an
eye on the FRE bytes available on the
destination disk. If MSDOS space runs
out an error #00 will be reported.

    For generously making his
equipment available to me for testing
with JIFFY-DOS I do thank Merv
Carroll. My thanks too to Ivan Blitz,
who tested the program for me and
made sure that I had the equipment I
needed, and to Reiner Richter who
advised me that he'd been able to
write to and read from high density
MSDOS disks using TYB before I was
even satisfied that I was getting the
correct results on 720K format.

    When all seemed to be going well
on our PAL systems, I sent the files
to Fender, only for him to find that
I had managed to create an NTSC/PAL
incompatibility. To Fender my thanks
for repeatedly testing "another
possible correction", usually in the
early hours of his morning, until it
finally all came right.

    Endeavouring to convert the
original LRR to work on the C64 gave
my 1581 drives a hard time for
several months whilst I tried to
figure out how to read from and write
to PC disks. Useful available
literature on the subject does not
seem to exist. Without the original
binary code and BASIC program written
by Craig Bruce I probably would never
have got any further than that.

    My thanks to him for generously
making his LRR available in the
public domain.

  Doreen Horne
  Brisbane, Australia
  August 2000

  [FENDER'S POSTMUMBLE:] It's a good
thing email is cheap because Doreen
and I did a lot of it getting this
program ready for publishing. Copying
from MSDOS tp CBM was no problem; it
worked on the first version Doreen
sent, and it worked on every other
version. It was the CBM to MSDOS
copying that gave us fits.

 I kept getting corrupted directories
on the MSDOS when I wrote to them on
my high-end system, which has a
SuperCPU and RAMLink. Later versions
would work on my second system, as
long as I disabled RAMLink.

 But Doreen persevered (as I knew she
would) and this latest version she
sent works for me on both systems,
with or without RAMLink. The SuperCPU
does have to be switched down to 1
MHz, but that's expected for any
program that does heavy-duty writing,
especially to a foreign disk.

 We all have friends and relatives
with PCs. Now, thanks to Doreen Horne
and Craig Bruce, anyone with a
Commodore computer and a 3.5 inch
drive can share files with them.