Hallo Al, > What is the current state of the project? At the moment I'm working on three versions: - V1541 This version only needs the IDE interface. It supports up to 65536 D64 images but instead of the normal 683 sectors, 768 sectors are reserved for every image. This enables one to use track 36 to 40 as well. V1541 has a feature that enables one to see which images already are in use. Some commands to handle images are available as well. It is not possible to copy data from one image to another. This one seems working alright. But I'm thinking about adding a feature that enables one to change to another image by pushing a button, just like the CMD drive can. - 16MB This version handles 16 MB partitions ie. disks with 254 tracks à 256sectors/track. This version supports subdirectories. This can be subdirectories within the partition but one can use a partition as sub directory as well. It is not possible to copy data from one subdirectory to another yet. As this will take quite knowledge how copying is done, I wonder if I will implement it. For the rest it seems to work fine now. Not knowing yet if I like this partition-as-subdirectory feature, I also have a version that handles images like V1541 does. Beside the IDE interface, 1 KB of extra RAM is needed. - FLHD This version is an "new" idea I got last week: using both the floppy drive and harddisk. I know I mentioned on my site to keep the floppy drive parallel to the harddisk but that was for copying data only. New about it is to use the floppy drive in cases where the incompatibility of the harddisk is a problem. This is the case where software, mostly speedloaders, address the mechanical drive directly. Like the Final Cartridge III does. The idea is that whenever an hardware related action is needed, the software checks a variable that tells it whether to address the floppy drive or the harddisk. I took the original ROM and where ever needed I replaced instructions with a JMP xxxx. At xxxx was checked what hardware was involved. In case of the floppy drive the original instructions are executed and a JMP is performed to the instructions following these original instructions. As there is not much free space in the original ROM, the extra routines are placed in the $8000/$BFFF area ie extra ROM needed. Which means a bit more hardware hacking. Not having access anymore to the RAM freed in the V1541 version, extra RAM is needed here as well. I just integrated the sources of V1541 with the original version and haven't tested anything yet. So far the update..... -- ___ / __|__ / / |_/ Groetjes, Ruud \ \__|_\ \___| URL: Ruud.C64.org De informatie in dit e-mailbericht is vertrouwelijk en uitsluitend bestemd voor de geadresseerde. Wanneer u dit bericht per abuis ontvangt, verzoeken wij u contact op te nemen met de afzender per kerende e-mail. Verder verzoeken wij u in dat geval dit e-mailbericht te vernietigen en de inhoud ervan aan niemand openbaar te maken. Wij aanvaarden geen aansprakelijkheid voor onjuiste, onvolledige dan wel ontijdige overbrenging van de inhoud van een verzonden e-mailbericht, noch voor daarbij overgebrachte virussen. APG Algemene Pensioen Groep NV is gevestigd te Heerlen en is ingeschreven in het handelsregister van de Kamer van Koophandel Limburg onder nummer 14099617 The information contained in this e-mail is confidential and may be privileged. It may be read, copied and used only by the intended recipient. If you have received it in error, please contact the sender immediately by return e-mail; please delete in this case the e-mail and do not disclose it's contents to any person. We don't accept liability for any errors, omissions, delays of receipt or viruses in the contents of this message which arise as a result of e-mail transmission. APG Algemene Pensioen Groep NV is registered in the trade register of the Chamber of Commerce Limburg, The Netherlands, registration number: 14099617 Message was sent through the cbm-hackers mailing listReceived on 2009-04-27 10:58:37
Archive generated by hypermail 2.2.0.