TYB-C64
-------

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 2 C128C keyboards and a 1571 drive out of action and
have only my C128D still in working order. Second hand 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.5inch 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.5inch 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. (If Fender has space he may be able to include the
original LRR documentation for the information of C64 users - it explains
things in more detail than I am doing here).

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, 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.

TO TRANSFER CBM FILES TO THE MSDOS disk use the swop key '/' 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 copying of the
files marked with the '*' will be done to your MSDOS disk.

TO COPY FROM MSDOS TO YOUR 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