DieseSeite gibt es auch in Deutsch
*** ATTENTION ***
Older versions of 1581-Copy (0.4, 0.41 ... 0.49,
0.50, 0.51 and 0.52) are affected by a critical
bug, please do not use them anymore. Should
the occasion arise, please remove all older versions of 1581-Copy from
your web pages and FTP servers.
*** ATTENTION ***
A tool for C64 freaks. It has been designed for Commodore users,
who own a CBM 1581 or compatible disk drive for simple data transfers between
the Commodore and IBM-PC world. This copy program allows data transfers
to and from CBM 1581 compatible disks on a standard PC with a standard
PC floppy disk drive connected to a NEC µPD765 compatible floppy
disk controller (FDC). It is not possible to do file based transfers, you
can only transfer the contents of the whole disk between an image file
(all the sectors are concenated to one file) and the physical disk within
the PC disk drive.
To handle single files you can use other tools, like:
The complete source code of this tool is included for all the poeple,
that still want to know, how the floppy disk controller can be programmed
directly on the hardware level. But I recommend the sorces from Ciriaco
García de Celis used by myself, if you want to know much more
about this:
The development of this 1581 disk copy tool serves the purpose of
a design and feasibility study, because after finishing and testing all
the planned features, the implementation shall be integrated into Joe
Forster/STA's Star Commander,
so that direct file manipulations of CBM 1581 disks becomes possible.
A simple utility that determines which types of parallel ports are
installed on which port addresses. It is able to detect the LPT port types
SPP (the IBM standard parallel/printer port), PS/2 (bidirectional IBM LPT
port), EPP and ECP. There's a special switch, so that you can use
it for recreating the BIOS translation of the LPT port number (LPT1, LPT2,
...) and the port address (call it in the AUTOEXEC.BAT). On some BIOS versions
this is especially needed if you are using a PS/2 port type, because the
BIOS may nod recognize the port if it is switched into input mode.
All sourcecodes are included, therefore this tool may be capable for
you to see, how parallel port accesses could be done.
A little utility for people from the Commodore C64 scene, who use
Joe
Forster/STA's Star Commander
for transferring files from original CBM 1541 disks to the PC's and vice
versa. It should help with the more and more complex configuration, because
it is able to detect the used cable
types, when connected CBM floppies are switched on. It prints out all
the configuration data then (used LPT ports and cable types) and checks
if the used cables are working.
A little upgrade of version 0.17 with added support for the cable
types XM1541 and XA1541. Because DOS and tools for DOS are not used much
anymore, this version is not tested much compared to version 0.17.
Attention!!! The AVL tree (until version 0.97
including) contains a bug, if you add a node, that has been removed
for other reasons before. The balance factor is not initialised in the
add method. The new version with the bug fix is in progress. As a first
step you can download the following snapshot, that contains the fix and
some addtional test methods:
PathAVLTree, version 0.98.04, 2000-03-07
This is an AVL tree, that hasn't been implemented rekursively but iterativly.
The Delete method internally uses a stack, but with the Insert method the
rekursion could fully be removed. The design bases on algorithms, that
were published and described by the german computer magazine c't, issue
1/92, page 174 ff. But the source code has been converted to C++ with extensive
use of templates and a first step for introducing an interator concept.
The main goal was it to optimize the run time performance and to reduce
the memory consuption (space per node); for this reason virutal methods
are not used (the type conversions needed, are done by a special template
wrapper class). The programming interface is an low level design to provide
as most flexibility as possible, the user has to create and to delete all
the nodes himself, because the AVL tree does only manage the nodes. But
it would not be a problem to extend the interface to key based management
with integrated methods for creation and deletion of the nodes.