Hallo Besucher, der Thread wurde 23k mal aufgerufen und enthält 135 Antworten

letzter Beitrag von Ballblazer am

Iomega ZIP 100 - Parallel am c64?

    Zitat von Juergen Johannes

    Hallo C=Mac,
    hier noch ein weiteres C64 Formatierprogramm für CMD HD. Mit Pfeil zurück kommst du in das vorherige Verzeichnis. Das Programm hat eine Hilfefunktion. Viel Erfolg.

    Der Vollständigkeitshalber:
    Hat auch nicht funktioniert.


    Muss wohl doch den alten Mac hervorkramen, der einzige Rechner mit SCSI-Anschluss und von dort stammt die ZIP-Disk.


    Gruss C=Mac.

    Zitat von C=Mac

    Der Vollständigkeitshalber:Hat auch nicht funktioniert.


    Muss wohl doch den alten Mac hervorkramen, der einzige Rechner mit SCSI-Anschluss und von dort stammt die ZIP-Disk.


    Gruss C=Mac.

    Ich hätte noch eine Idee. Du hast doch jetzt eine SCSI2SD an Deiner CMDHD. Lege auf eine SD ein CMD System an ( nicht größer als 100 MB, zb. auf eine 1GB Karte, oder kleiner). Kopiere dann die SD am PC mit Rawcopy und kopiere dann das erstellte Image zurück auf Deine Zipdisk. Jetzt solltest Du eine funktionierende Disk für das CMD System haben. :) . Danach könnte auch ein anderes Formatieren funktionieren.


    Gruß Jojo

    Ich habe mir gerade den gesamten Thread durchgelesen.


    Ich hätte definitiv Interesse an einer Lösung ein Parallel-Zip an den C64 anzuschließen und würde mich da gern einbringen, sehe aber insbesondere die ersten Schritte für ziemlich schwer an. Ich wüsste nicht, wo ich da ansetzen soll. Ich habe noch nie etwas für den Userport des C64 programmiert und habe nicht die leiseste Ahnung, wie man überhaupt ein paralleles ZIP-Laufwerk ansteuert. Der Amiga-Treiber gibt vielleicht Aufschluss drüber. Das klärt aber noch nicht, wie man überhaupt das Parallelkabel mit dem Userport verdrahten müsste...


    Ab dem Punkt, wo es möglich ist, einzelne Sektoren zu lesen/schreiben, die man per CHS oder LBA adressiert, ist der Rest geschenkt. Ein rudimentäres FAT16 habe ich schon gefühlt ein Dutzend Mal in meinem Leben implementiert.

    Wie bereits geschrieben, die Hardware zum testen hätte ich da, auch wenn das IEC-ATA noch nicht zusammengebaut ist (falls das Verwendung finden soll).
    Softwareseitig kann ich leider nicht wirklich was dazu beitragen.
    An einer Software / Hardware Lösung wäre ich jedenfalls interessiert.

    Mir wäre es im Prinzip egal, ob man ein Parallel-ZIP am Userport anschließt oder ein Zip-Laufwerk am IEC-ATA. Für meine Zwecke allerdings wäre es wichtig, dass auch andere Filesysteme auf dem ZIP-Laufwerk, also z.B. FAT16, verwendet werden können, denn sonst stellt sich wieder die Frage, wie man die Dinger auf einem anderen Gerät liest/schreibt. Das IEC-ATA müsste also (auch) einen block read/write unterstützen. Wenn ich mir allerdings die Spezifikation anschaue, unterstützt es genau das nicht. :-)


    Zitat von der Webseite: "Don't support all Commodore DOS commands, especially the memoryread/write/execute and block read/write/allocate/free."


    Da der C-Code allerdings vorliegt, könnte man auch dort entsprechende Änderungen vornehmen. Ist so ein IEC-ATA schwer zu bekommen? Ich habe die nächsten Wochen ein bisschen Zeit und würde mich da gern dran versuchen.

    Zitat von Larry

    Wie bereits geschrieben, die Hardware zum testen hätte ich da, auch wenn das IEC-ATA noch nicht zusammengebaut ist (falls das Verwendung finden soll).
    Softwareseitig kann ich leider nicht wirklich was dazu beitragen.
    An einer Software / Hardware Lösung wäre ich jedenfalls interessiert.

    Ich bin jetzt mal ein bisschen tiefer in die Thematik eingetaucht. Es scheint noch niemand ausprobiert zu haben, aber ich bezweifle, dass ein ATAPI/IDE-Zip so ohne Weiteres funktioniert. Ich habe nichts darüber gefunden, wie so ein Zip-Laufwerk angesprochen wird, aber das IECATA unterstützt nur LBA-Adressierung (deswegen funktioneren auch kaum Festplatten < 540MB) und ich bezweifle stark, dass das Zip-Laufwerk darauf reagiert. Für ATAPI sollte es aber einen Standard geben. Eventuell kann man sich da etwas bei CD-ROM-Laufwerken abschauen, die haben ja auch eine ATAPI-Schnittstelle.


    Als Basis würde ich das IECATA in der Version 1 nehmen. Das hat zwar einen kleinen Microcontroller, aber wie ich bereits erwähnt habe, plane ich keine Implementierung des Filesystems auf dem IECATA. Ich weiß, dass die neueren Versionen des IECATA genau das machen. Die haben FAT32-Unterstützung, aber entsprechend groß ist auch der Speicherbedarf und der Microcontroller wurde schon 2x getauscht, um dem immer größeren Resourcenhunger zu genügen. Die "Philosophie" von Commodore, ein dummes OS (in dem Fall der Kernel) und schlaues Laufwerk zu machen, hat mir noch nie gefallen. Für mich gehört das Filesystem zum OS und ein Laufwerk hat nur Daten zu liefern. Aus Kompatibilitätsgründen folgen aber die meisten Laufwerke dem Beispiel von Commodore, z.B. SD2IEC, das IDE64 oder eben das IECATA. Das einzig "dumme" Laufwerk, was ich kenne, ist das Tapecart.


    Die Basis für die Firmware wird dann die V1.3. Die steht noch unter der GPL. Alles, was danach kam, scheint nicht mehr Open Source zu sein. Ob spätere Versionen auf dem IECATA V1 funktionieren, ist sowieso fraglich. Um mir ein IECATA zu bauen. wäre natürlich eine Platine toll. Falls jemand so ein Ding übrig hat, kaufe ich es ihm gern ab. Das Ding auf Lochraster aufzubauen wäre mit etwas zu pfrimelig. Ich würde dann eher ein paar Platinen fertigen lassen, habe aber so etwas noch nie gemacht. Gibt's da einen hErsteller, bei dem man auch kleine Stückzahlen günstig bekommt? Ich bin da für jeden Tipp dankbar. Die Gerber-Files sind ja auch der Seite vom IECATA (http://djupdal.org/cbm/iecata/) noch vorhanden.

    Zitat von Snear

    Gibt's da einen hErsteller, bei dem man auch kleine Stückzahlen günstig bekommt? Ich bin da für jeden Tipp dankbar.

    Sprich doch mal den @NLQ hier aus dem Forum an. Von Ihm habe ich damals die Platine erhalten. Vielleicht hat er noch welche die zum Verkauf stehen, oder kann bzgl. Bezugsquelle und anderen Tips weiterhelfen.
    Im Forum müsste auch einiges zum Thema NLQ-HD zu finden sein. Ich meine (bin nicht sicher...), daß das Ding auch mit HDs größer 540 MB funktioniert.

    Ja. Festplatten größer 540MB funktionieren. Ich habe eine 2GB Festplatte an meiner IEC-ATA.



    Leider werden wohl immer noch keinde D64-Dateien unterstützt. Das IEC-ATA fungiert sozusagen als One-File-Sammler.


    Diesen Job macht es aber sehr gut und unterstützt JiffyDOS.

    Die IEC-ATA-Hardware benutzt einen M162. Dieser hat nur 16kB FLASH. Hier ist leider kein Platz für LBA-Routinen, sodass nur CHS-HDs unterstützt werden, die so um die 540MB haben könnten.


    Die NLQHD-Hardware (http://www.nlq.de) benutzt einen M1284. Dieser hat 128kB FLASH. Hier passen die LBA-Routinen rein, sodass HDs bis 128GB unterstützt werden. Die Firmware ist nicht in C sondern in Assembler. Der Sourcecode ist auf der Homepage und kann benutzt werden.

    Zitat von NLQ

    Die IEC-ATA-Hardware benutzt einen M162. Dieser hat nur 16kB FLASH. Hier ist leider kein Platz für LBA-Routinen, sodass nur CHS-HDs unterstützt werden, die so um die 540MB haben könnten.

    Bist du sicher? Für mich sieht es so aus, als wenn nur LBA unterstützt wird und daher Festplatten, die CHS verwenden, nicht funktionieren. Aber ich kann mich irren.


    Mir ist klar, dass deine Version deutlich besser ist und sehr viel mehr kann als das ursprüngliche IECATA, aber ich möchte bei einer minimalen Variante ansetzen um ATAPI-Unterstützung mit einzubauen und deshalb bei C bleiben, weil alles andere auch jeden zeitlichen Rahmen sprengen würde. Der Assembler-Code ist einfach schon zu umfangreich als dass man da mal eben ein paar Änderungen vornehmen könnte.


    Gelernt habe ich erstmal, dass das IECATA in der ersten Version mit seinem AVR8515 definitiv zu klein ist und ich zumindest ein IECATA V2 brauche. Da es dafür keine Gerber-Dateien im Netz gibt, werde ich mal beim Dienstagstreff nachfragen.