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.