Hallo Besucher, der Thread wurde 15k mal aufgerufen und enthält 68 Antworten

letzter Beitrag von NLQ am

sd2iec 0.5

    Ich sollte häufigere Releases machen, jetzt musste ich doch glatt einen älteren Thread raussuchen um zu wissen was ich üblicherweise hier schreibe...


    Bugfixes:

    • LarsP-Hardware sollte jetzt vollständig funktionieren
    • Das Pi-Symbol wird (wieder) korrekt hin+hercodiert
    • Dateinamen mit Leerzeichen am Ende funktionieren halbwegs in M2I-Dateien. Halbwegs, da die Endleerzeichen jetzt bei M2I immer und überall abgeschnitten werden - sowohl bei der Ausgabe als auch beim Vergleich eines empfangenen Dateinamens.


    Neue Features:

    • D64-Support - Lesen, Schreiben, Anhängen, Löschen und Blockzugriff
    • Diskwechseltaster
    • JiffyDos Laden/Speichern
    • Speichern einiger Einstellungen im EEPROM


    Der D64-Schreibsupport ist nicht 100%ig getestet, ich empfehle Backups von wichtigen Daten anzulegen. Ausserdem ist der Schreibzugriff darauf im Augenblick reichlich langsam weil ich versucht habe möglichst ohne zusätzliche Pufferbelegungen auszukommen - das wird sich wohl in 0.6 ändern (ebenso die lange Verzögerung für die BLOCKS FREE-Zeile).


    Dank Blockzugriff ist es jetzt auch möglich, CP/M auf dem C128 von SD-Karte zu booten wenn man vorher ein passendes Diskimage mountet. Ebenso funktionieren Infocom-Adventures jetzt, bei der Abfrage am Anfang ob man eine 1541 verwendet muss man ablehnen damit deren Fastloader nicht verwendet wird.


    Zum Diskwechseltaster steht hoffentlich genug im Readme - PC4 (Shadowolf) oder PA4 (LarsP) gegen Masse löst die Funktion aus, entweder anhand einer mit XS:name gesetzten Wechselliste oder mit einer AUTOSWAP.LST aus dem aktuellen Verzeichnis (wenn vorhanden) - jeweils mit einem Namen pro Zeile, maximal 250 Zeichen pro Zeile, Zeilenendenmarker egal (Dos/Mac=C64/Unix gehen alle).


    JiffyDos ist zu gutem Teil 1570 zu verdanken, auch wenn der Code jetzt nicht mehr viel Ähnlichkeit mit seinem ersten Patch hat. =) Es funktioniert in unseren Tests auch ohne Quarz und wahrscheinlich sogar ohne den internen Oszillator erst kalibrieren zu müssen, das Protokoll ist für seine Geschwindigkeit bemerkenswert gutmütig. Um aber ganz sicher zu sein ist Jiffy erstmal nur auf Geräteadresse 8/9 an und auf 10/11 aus - nachträgliches Umstellen ist unabhängig von der Adresse mit "XJ+" bzw. "XJ-" möglich. Um den Kalibrierungswert auszulesen muss man nur "X" ans Laufwerk senden und den Fehlerkanal auslesen, um ihn zu ändern "XC<zahl>", mit zahl zwischen 0 und 255 (Empfehlung: Kleine Schritte vom Defaultwert aus testen). Eine automatische Kalibrierung wird evtl. irgendwann nachgeliefert falls sie notwendig werden sollte.


    Damit man den Kalibrierungswert und den Jiffy-Schalter nicht ständig neu übermitteln muss werden beide mit "XW" ins EEPROM des Controllers gesichert. Hoffentlich funktioniert das auch ohne Brownout-Erkennung gut genug, sicherheitshalber wird eine Checksumme dazugeschrieben und bei Abweichungen wieder die Defaultwerte (Jiffy nach Adresse, Kalibrierung was auch immer Atmel reingeschrieben hat) genommen. Wenn die Parameter ins EEPROM geschrieben wurden hängt der Jiffy-Support nicht mehr von der Adresse ab sondern bleibt so wie man es eingestellt hat.


    Die in einem anderen Thread mal erwähnten Pläne zu einem S2I-Fileformat sind vorläufig wieder auf Eis gelegt. Andere Dateitypen als PRG und DEL funktionieren mit sd2iec natürlich trotzdem in M2I-Dateien.


    Für die Statistikfans: 27944 Byte von 30712 im Flash belegt


    Ach ja, Download-URLs wären ja auch noch was nettes:

    Läuft soweit einfwandfrei auf meiner 1.6er Hardware. Hab das Laden mit Super Jiffydos probiert und keine Probleme feststellen können.
    Auch d64 Dateien lassen sich perfekt "mounten" und daraus lesen.
    Was ich festgestellt habe, sobald ich in Verzeichnisse mit einer größeren Anzahl von Dateien wechsle, wird das Anzeigen des Directories sehr langsam. Alle weiteren Operationen danach gehen dann auch sehr langsam vonstatten. Sprich wenn ich anschließend ein d64 mounte, mir davon das Directory anzeigen lasse usw. ist dann ebenfalls alles sehr langsam. Laden von Programmen ist aber trotzdem mit hoher Geschwindigkeit möglich.

    Zitat von wattie

    Was ich festgestellt habe, sobald ich in Verzeichnisse mit einer größeren Anzahl von Dateien wechsle, wird das Anzeigen des Directories sehr langsam.


    Normale Directoryanzeige mit F1? Reguläres Verzeichnis auf der Karte oder ein D64/M2I? So lange nur das Directory geladen wird sollte die Anzahl der Dateien eigentlich keinen Unterschied machen (egal ob FAT/M2I/D64), der Zugriff auf den nächsten Eintrag braucht nahezu konstante Zeit. Langsam sollte es normalerweise erst werden wenn man (wie es zB FIBR macht) ständig andere Dateien öffnet, weil dann der Inhalt des 1-Sektor-Caches verlorengeht.


    Zitat

    Alle weiteren Operationen danach gehen dann auch sehr langsam vonstatten. Sprich wenn ich anschließend ein d64 mounte, mir davon das Directory anzeigen lasse usw. ist dann ebenfalls alles sehr langsam.


    Kannst du mal ein paar Details mehr nennen (ungefähre Anzahl von Dateien in den Verzeichnissen, genaue ausgeführte Befehle)? Das passt irgendwie gar nicht zum Verhalten das ich erwarten würde.


    Zitat von Shadowolf

    Jetzt bräuchte ich nur mal Jiffy im DTV, alleine schon, um Verzeichnisse zu wechseln.


    Es gibt auf http://www.kahlin.net/daniel/dtv/index.php ein winziges .PRG-File an das man nur noch ein Kernalimage hängen muss um selbiges im DTV-Ram zu starten. JiffyDos selbst sollte Google finden können.

    Zitat von Unseen

    Normale Directoryanzeige mit F1? Reguläres Verzeichnis auf der Karte oder ein D64/M2I? So lange nur das Directory geladen wird sollte die Anzahl der Dateien eigentlich keinen Unterschied machen (egal ob FAT/M2I/D64), der Zugriff auf den nächsten Eintrag braucht nahezu konstante Zeit. Langsam sollte es normalerweise erst werden wenn man (wie es zB FIBR macht) ständig andere Dateien öffnet, weil dann der Inhalt des 1-Sektor-Caches verlorengeht.

    Genau, mit F1 das Directory anzeigen lassen. Es ist ein reguläres Verzeichnis. Karte ist eine 1gig Sandisk FAT16 formatiert. Beim Auflisten der einzelnen Einträge sind es so gefühlte 2 Sekunden bis der nächste Eintrag angezeigt wird.

    Zitat von Unseen

    Kannst du mal ein paar Details mehr nennen (ungefähre Anzahl von Dateien in den Verzeichnissen, genaue ausgeführte Befehle)? Das passt irgendwie gar nicht zum Verhalten das ich erwarten würde.

    Das Verzeichnis beinhaltet rund 200 D64 Images. Ins Verzeichnis mit CD wechseln geht ganz normal. Danach beim Auflisten mit F1 wirds wie oben gesagt langsam. Wenn ich danach mit CD:Imagexy.d64 in ein D64 Image wechsle, wird ja zunächst die Statusmeldung ausgegeben. Auch das dauert dann relativ lange bis ich den Prompt wieder habe. Die Meldung wird ungefähr bis zur Hälfte ausgegeben, danach hackt es wieder so gefühlte 2-3 Sekunden, und der Rest der Statusmeldung wird dann Zeichen für Zeichen mit kurzen Verzögerungen ausgegeben. Im gemounteten Image dann mit F1 ist dann wieder so wie oben beschrieben mit Verzögerung der Anzeige der einzelnen Einträge.
    Das alles betrifft aber nur das Wechseln in Verzeichnisse und das Auflisten. Lade ich z.B. aus nem D64 ein Programm, wird es von Jiffy ziemlich schnell geladen.


    Ich hoffe das war einigermaßen verständlich so wie ich's beschrieben habe.

    zu früh gefreut ;-(



    C64+mmc2iec+sd2iec 0.5 LarsP + Turboload 2.1


    sys2085


    Formatieren: ------------
    Programm LOAD: 01:00.3 2.27
    Programm SAVE: 00:09.9 12.83
    SEQ schreiben: 00:33.6 2.56
    SEQ lesen: ------------ Absturz.. READY ??


    ---


    Turbo 2.1 und Turbo 2.2 arbeiten NICHT zuverlässig!?
    Auch ein geladenes Donkey Kong.prg arbeitet nicht!


    Peter

    Die Fuse-Settings von ihm sind doch Ext. Crystal und scheinen für einen modifizierten LarsP-Aufbau mit Quarz ohne Bootloader okay. Peter, ist übrigens nicht so geschickt, Hexwerte für die Fuse-Settings hier völlig ohne weiteren Kontext zu posten, nachher probiert's noch jemand damit mit einem Shadowolf-MMC2IEC aus, damit wird er dann nicht viel Freude haben (da bei den Fuses kein Bootloader aktiv).


    Kondensatoren beim Quarz richtig gewählt? Je nach Quarz muss da was zwischen 22 und 68pF ran (doppelte Lastkapazität/Cl, siehe Quarz-Datenblatt).

    Zitat von wattie

    Genau, mit F1 das Directory anzeigen lassen. Es ist ein reguläres Verzeichnis. Karte ist eine 1gig Sandisk FAT16 formatiert. Beim Auflisten der einzelnen Einträge sind es so gefühlte 2 Sekunden bis der nächste Eintrag angezeigt wird.


    Ok, ich kann es jetzt reproduzieren - ich hatte mir mal wieder komplette Tests(*) auf einer von Shadowolfs Platinen mit mega32 gespart weil Jiffy ja sauber lief und ich ansonsten keine Probleme erwartet habe. =(


    EDIT2: Das ist deswegen so langsam, weil die Firmware meint dass jemand ständig auf den Disk-Change-Taster hauen würde. Das liegt daran, dass der Compiler nicht den Code erzeugt hat den ich erwartet habe um das JTAG-Interface abzuschalten wodurch das Abschalten nicht funktioniert und der Controller intern ein ständig wechselndes Signal auf dem Pin erzeugt.


    Sieht nach einem interessanten Problem aus, ich habe zZt keine Ahnung woher es stammen könnte. Aber das wird schon. Hoffentlich.


    (*) Eine Testsuite die man auf eine SD-Karte entpacken kann und mit der man dann möglichst viele Features von sd2iec vollautomatisch testen kann wäre toll. Meinetwegen auch PC-basiert mit OpenCBM(+Vice), auch wenn da keine Schnellader gehen.


    Peters Probleme debuggen ja netterweise gerade schon andere Leute. =)

    Zitat

    Es gibt auf http://www.kahlin.net/daniel/dtv/index.php ein winziges .PRG-File an das man nur noch ein Kernalimage hängen muss um selbiges im DTV-Ram zu starten. JiffyDos selbst sollte Google finden können.


    Sowas habe ich schon zu Test-Zwecken, ist 33 Blöcke lang, muss ich laden, löst einen Reset aus und ist dann Jiffy 6.01.


    Schöne Sache, dafür würde ich auch sofort 20 Euro auf den Tisch legen - wenn Maurice noch was verkaufen würde.


    Nur, wie bekomme ich das fest in mein DTV?
    Schliesslich kann man ja nicht einfach einen C64-Kernel in das DTV brennen, da gibt es im DTV-Kernel mit Sicherheit einige Besonderheiten bezüglich der Initialisierung.
    Und auf das FLASH kann ich dann auch nicht mehr als Laufwerk zugreifen, was zugegenermassen jetzt nicht so fatal ist.


    Also ein Jiffy-DTV-Kernel wäre schon super.

    Der Quartz ist ein Pollin Überbleibsel...
    Mann ich frage mich, wenn das alles sooo kritisch ist und
    Turboload nur alle 254 Bytes synchronisiert, Jiffy aber nach jedem Byte... ob es dann nicht was dazwischen tut.. alle 4,8,16,64.. Byte..?


    Gibt es sowas? Kann man das (anstatt Turboload?) einbauen..


    Bringt uns das wieder zum Vorschlag von x1541.. einen speziellen Turboload fürs mmc2iec bauen?


    Kann ich Jiffydos auch ohne ein ROM zu haben als Programm etc. laden um das mal zu testen..?


    Peter

    Zitat von PeterSieg

    Der Quartz ist ein Pollin Überbleibsel...
    Mann ich frage mich, wenn das alles sooo kritisch ist und


    Das ist nicht sooo kritisch mit Quarz - wenn man den Quarz richtig anschliesst.
    Und dazu muss man eben auch die Last-Kapazität von dem Quarz kennen oder man bekommt eben nicht die gewünschte Frequenz.


    Edit: löte doch Spasseshalber nochmal je 22 pF dazu oder eben gleich 2x47 pF.


    Zitat


    Turboload nur alle 254 Bytes synchronisiert, Jiffy aber nach jedem Byte... ob es dann nicht was dazwischen tut.. alle 4,8,16,64.. Byte..?


    Gibt es sowas? Kann man das (anstatt Turboload?) einbauen..


    Der AR6 Fastloader synchronisiert wohl alle 4 Bytes.
    Das ist aber garnicht das Problem.
    Der Turbo-Disk Fastloader ist neben Jiffy schlichtweg der einzige bisher implementierte, sprich, es muss auch jemand machen - was bestimmt nicht als Vorwurf in Richtung Unseen gemeint ist.


    Die Idee sowas selbst zu implementieren habe ich mir schliesslich aus dem Kopf geschlagen.
    Dafür bin ich aus 6502-Assembler viel zu lange raus und AVR-Assembler habe ich noch garnicht versucht.


    Zitat


    Bringt uns das wieder zum Vorschlag von x1541.. einen speziellen Turboload fürs mmc2iec bauen?


    Kann ich Jiffydos auch ohne ein ROM zu haben als Programm etc. laden um das mal zu testen..?
    Peter


    Das war wohl eher mein Vorschlag. :)
    Und ja, man kann Jiffy zu Test-Zwecken von Karte als Programm laden.
    Wie das geht steht ja weiter oben.

    Auf dem MMC2IEC ist Jiffy-LOAD sowieso schneller als Turbo Disk-LOAD. Letzteres ist bei weitem nicht optimal programmiert (mischt Geschwindigkeitsgewinn durch sehr seltene Synchronisierung mit relativ langsamer Bittransferschleife). Geschwindigkeitsvergleich siehe MMC2IEC-Wiki-Seite .


    Was weitere Schnelllader-Varianten angeht, kann man alles machen (ich habe einen - nicht releasefähigen - 40x-Schnelllader nur für MMC2IEC hier, der einfach nur eine Turbo Disk-Variante mit schneller Bittransferschleife ist), nur WER es WANN macht, ist die Frage :).


    Jiffy-LOAD lässt sich prinzipiell natürlich auch als kleines .prg auskoppeln. Ich schätze mal, das sauber und releasefertig zu machen sind ein paar Stunden langweilige Arbeit...

    Hallo Leute,
    wie ich sehe versucht ihr mit Quartzen und so das Jiffitiming hin zu bekommen.
    Der NLQ hat eine Version für den iec-ata gebaut mit jiffi. und stabiel.
    Er hat ein Calibrierungsprogramm geschieben, was in der Lage ist den internen Taktgeber anzupassen.


    http://home.arcor.de/jochen.adler/ajni2idi.d64


    Eventuell kannst du damit was anfangen. Es verwendet ein neues Kommando calc was dann noch bei dir eingebaut werden müsste

    Hallo. das ist jetzt bitte nicht böse gemeint!
    Manchmal geht mir das Steno und Rätselraten ganz schön auf die Nerven!
    Ist dieses Programm gemeint: dtv_speed_load.prgFast disk turbo for the DTV. ?
    (Auch da natürlich keinerlei Erklärungen.. Insider wissen das was/wie..wohl..)
    Und wenn ja, wie hänge ich da, was dran?


    Ich glaube ich gehe jetzt erst mal ein bißchen spazieren bei dem schönen Wetter.. ;-)


    Peter

    Zitat

    Jiffy-LOAD lässt sich prinzipiell natürlich auch als kleines .prg auskoppeln. Ich schätze mal, das sauber und releasefertig zu machen sind um die 15 Stunden langweilige Arbeit...

    Hym.. 30€ als Bounty Prämie sind dann sicherlich nicht DER Anreiz.. aber evtl. finden sich ja noch mehr..
    Ich baue noch ein weiteres mit Quartz auf. Von Reichelt. CL=32pf ;-) Mal sehen.. was dann passiert..


    Peter