braner@batcomputer.UUCP (01/17/87)
[]
FLEXCOPY - program to copy one disk to another, across formats.
BINARY POSTED in a separate file.
As usual, source code is available upon request.
FUNCTION
This program copies the complete contents of one disk onto another.
It first finds out which sector is the last one actually holding data,
and copies all sectors up to that one. The destination disk has to
have enough space to receive all the data, and may be preformatted,
or formatted through this program. The source or destination may also
be an (installed) RAM disk. One disk may have a different PHYSICAL
structure than the other (e.g. a different number of sides), but both
must share the same LOGICAL structure (i.e. the same size sectors,
clusters, FAT and root directory).
NOTE
You CAN copy a double-sided disk to a single-sided one, provided
the consecutive block of sectors holding all the data fits on the
smaller disk. That may not be the case, even when TOS tells you that
less than 351K are used, since there may be empty "holes" in the
middle of the used sectors, where files have been deleted. To get
around that, copy the data FILE BY FILE to a virgin RAM disk, then
use FLEXCOPY to copy the RAM disk to the destination floppy disk.
WARNINGS
Not for hard disks (or future, very large, floppies).
(12-bit FAT entries assumed.)
This program will not work with "copy protected" disk formats,
including the "FAST" format with its "dead" sectors.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
What follows is mostly SPECULATION. If you know THE TRUTH please tell us.
It seems that GEMDOS tries to keep track of the directory-tree on each
drive. And it tries to do it in a transparent manner. There are two
problems with keeping such a tree:
(1) GEMDOS has a fixed amount of space allotted for this - hence the
infamous "40 folder limit".
(2) The old directory tree has to be erased and a new one built after
the media in a drive has been changed. GEMDOS knows when a floppy
has been removed, but what about other removable devices (tape
cartridges, 'Bernoulli box', etc)? And also the RAMdisk, in case
it's overwritten (behind the back of the file system)?
Problem #2 should be fixable, and doing that for a hard disk at appropriate
moments should fix the "40 folder limit" too, I suppose.
The RAMdisk Mediach() routine always says "not changed", but that turns out
to be irrelevant. That's confusing the chicken and the egg: Mediach() looks
up a preexisting value, presumably put there by GEMDOS...
So how can one tell GEMDOS that the (RAM, hard) disk has been changed?
- By having Rwabs() return the error code -14. Once. And forcing GEMDOS
to call Rwabs() that special time - calling Rwabs() ourselves won't do any
good as far as making GEMDOS forget its 'tree of folders'...
FLEXCOPY does that after the destination disk has been overwritten, as
follows: (Megamax syntax)
...
extern dmch();
extern drvnum();
asm{
dmch: MOVEA.W #0x476,A0 /* Rwabs() vector */
LEA oldvec(PC),A1
MOVE.L (A0),(A1) /* save old */
LEA tmpvec(PC),A1
MOVE.L A1,(A0) /* poke new */
RTS
tmpvec: MOVE.W drvnum(PC),D0
CMP.W 14(A7),D0 /* target drive? */
BEQ.S now
MOVE.L oldvec(PC),A0 /* do normal */
JMP (A0)
now: MOVE.L oldvec(PC),0x476 /* restore normal Rwabs */
MOVEQ #-14,D0 /* "media has changed" */
RTS
oldvec: DC.L 0
drvnum: DC.W 0
}
...
main()
{
...
*((int *)&drvnum) = drv2; /* poke our target drive ID */
Supexec(&dmch); /* install our funky Rwabs() */
Dfree(dinfo,drv2+1); /* make GEMDOS call it */
...
}
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- Moshe Braner