Hallo Besucher, der Thread wurde 28k mal aufgerufen und enthält 131 Antworten

letzter Beitrag von Frenetic am

Jiffydos für Plus4

    Zitat von Crisp

    Also das rumfliegende Jiffy ist ein 32K File welches Basic und Kernal in sich hat... dieses muss evtl für den +4 wieder in 2 x 16K große Files geteilt werden...

    Hab jetzt mal ne dumme Frage. Beim Plus4 sitzt doch das Basic in U23 und das Kernal in U24. Wie kann das denn in einem File sein? Wenn ich es richtig denke ist in diesem kursierenden File 1x das CBM Kernal und 1x das Jiffy Kernal (jeweils NTSC) welches mittels eines Umschalters ausgewählt werden kann. Und dieser Mod patcht beide Kernals auf PAL. Beim Basic muss doch nichts gepatcht werden, oder doch?

    Zitat von Bobbel

    Wenn ich es richtig denke ist in diesem kursierenden File 1x das CBM Kernal und 1x das Jiffy Kernal (jeweils NTSC) welches mittels eines Umschalters ausgewählt werden kann. Und dieser Mod patcht beide Kernals auf PAL. Beim Basic muss doch nichts gepatcht werden, oder doch?

    Das stimmt so meines Wissens.

    Zitat von AREA51HD

    Hat jemand von euch C16+4 in verbindung mit SD2IEC oder 1541 mit Jiffy Dos Stabil zum Funkionieren gebracht?


    Das ROM was ich vom Jim Brain gekauft habe, läuft nicht wirklich stabil.
    Zum Teil stürzt der Rechner schon beim Direktory ab...

    Ist es eine PAL-Version? Ich meine, es wurden mal nur NTSC-Versionen ausgeliefert?

    Im Anhang ist eine mit F-Tasten funktionierende Version. Ein Vergleich könnte das Problem vielleicht ans Tageslicht bringen.

    Zitat von AREA51HD

    Weihnachten hat man ja mal Zeit, und genau 30 Jahre nachdem ich meinen C16+4 bekommen habe wurde wieder Leaper gestartet.
    Von cbmhardware das ROM Gebrannt, und neuer versuch mit 1541, 1581 und SD2IEC, leider ist der Fehler noch immer unverändert vorhanden.
    Screenshots liefere ich in Kürze nach...

    Ich habe mich nach langer Zeit auch wieder für den +4 interessiert und mir deshalb zwei in der Bucht geholt.
    Dann ein JiffyDOS 6.01 Image bei Jim Brain gekauft und auf ein EPROM gebrannt.
    Resultat: Egal in welchem der +4 ich das JiffyDOS stecke, die Maschine wird instabil beim Lesen von IEC,
    egal ob von einem SD2IEC oder einer mit JiffyDOS ausgestatteten 1581.
    Ich wollte z.B. eine 100KB große SEQ Datei in eine REL Datei mir 128 Byte Records umkopieren.
    Dabei zeigte sich, dass beim Lesen der SEQ Datei in unregelmäßigen Abständen (ca. 50 - 300 Bytes) Lesefehler auftreten.
    Die BASIC ST Variable meldet dann entweder 66 (EOF und Timeout Read) oder 3 (Timeout read und Timeout write).
    Wenn der Leseversuch wiederholt wird, klappt es.
    Da aber kaum eine Software nach jedem gelesenen Byte den Status abfragt, hilft dieser Workaround nur bei eigenen Programmen.
    Durch Testen verschiederner Kombinationen (C64, +4 mit SD2IEC, 1541, 1581 und mit/ohne JiffyDOS) habe ich herausgefunden,
    dass der Fehler zweifelsfrei im JiffyDOS (PAL Version) des +4 liegt. Das ist echt schade.
    Es müsste zu beheben sein, aber dazu braucht man einen Logic Analyzer und viel Geduld.
    Leider fehlt es mir am Analyzer und ich wollte eigentlich nicht viel Geld ausgeben, um das Problem zu lösen.
    Na ja, dann werde ich mich wohl wieder mehr mit dem C128 und C64 beschäftigen.
    Es wäre aber schön, wenn sich jemand mit entsprechendem Equipment diesem Problem widmen würde.

    In einem Anderen Thread habe ich auch versuche mit verschiedenen Laufwerken und Rechnern gemacht.


    Es ist wohl Fakt das Jiffy in den Meisten PAL C16+4 nicht Stabil Läuft


    Bei @cbmhardware scheint das Jiffy zu laufen, wäre interessant ob er einen Abweichenden Quarz verbaut hat z.b. von einem Halbherzigen NTSC-PAL umbau.


    Nach vielen versuchen bin ich zum ergebnis gekommen, das es wohl Kritische Bitmuster gibt die recht sicher zu Fehlern führen, leider sind auch meine kenntnisse
    zu schlecht um Jiffy zu Patchen, wenns ja 1-2 Byte gebe, wo man die Software feintunen könnte, vermutlich die die unterschiedlich zu PAL und NTSC sind...

    Dann werde ich das an meinem +4 auch mal ausprobieren. Hatte da auch erst wie Bobbel die Bedenken, weil Kernel und Basic getrennt sind, muss ich mal schauen wie ich das mache.

    Zitat von AREA51HD


    Bei @cbmhardware scheint das Jiffy zu laufen, wäre interessant ob er einen Abweichenden Quarz verbaut hat z.b. von einem Halbherzigen NTSC-PAL umbau.

    Man kann halt nur die Quarze im Original verbauen oder mit den exakt passenden Werten, sonst wird ein Rechner weder von PAL --> NTSC oder auch umgekehrt NTSC --> PAL laufen. Der Rest vom Umbau ist ja kaum effektive Arbeit.


    Zitat von AREA51HD

    Nach vielen versuchen bin ich zum ergebnis gekommen, das es wohl Kritische Bitmuster gibt die recht sicher zu Fehlern führen, leider sind auch meine Kenntnisse zu schlecht um Jiffy zu Patchen, wenns ja 1-2 Byte gebe, wo man die Software feintunen könnte, vermutlich die die unterschiedlich zu PAL und NTSC sind...

    Wo im Adreßraum liegen denn exakt diese besagten Bitmuster?

    Zitat von AREA51HD


    Nach vielen versuchen bin ich zum ergebnis gekommen, das es wohl Kritische Bitmuster gibt die recht sicher zu Fehlern führen, leider sind auch meine kenntnisse
    zu schlecht um Jiffy zu Patchen, wenns ja 1-2 Byte gebe, wo man die Software feintunen könnte, vermutlich die die unterschiedlich zu PAL und NTSC sind...

    Die Abhängigkeit von Bitmustern habe ich auch untersucht und kann sie nicht bestätigen.
    Ich habe immer wieder dieselbe Datei lesen lassen und bei jedem Versuch traten die Lesefehler an unterschiedlichen Stellen auf.
    Bei einer Abhängigkeit von Bitmustern müssten die Fehler ja reproduzierbar immer an der gleichen Stelle auftreten.
    Ich glaube eher, dass das Timing so knapp kalkuliert ist, dass es gelegentlich versagt.
    In meinen Tests hängen die Fehler jedenfalls weder vom Dateninhalt noch von der Position in der Datei ab.
    Die Fehlerverteilung ist zufällig, die Auftrittswahrscheinlichkeit bei meinen Tests war 1.2 %, also im Mittel alle 87 Bytes.

    Den Adressraum oder welches Bitmuster es ist kann ich leider nicht genau sagen.


    Was nur sicher ist das sich die Fehler relativ genau repoduzieren lassen.
    Wenn das z.b. das Spiel Leaper geladen wurde, gibt es das Intro "Mit der Tanzenden Maus" oben im Bildschirm, und einem umlaufenen Rahmen.
    Zu 100% ist bei mir der Rahmen unvollständig wenn das Spiel mit Jiffy geladen wurde, genau so gibt es spiele die zu 90%+ laufen wenn sie mit Jiffy geladen werden z.b. Berks und Spiele die nie laufen wenn die mit Jiffy geladen wurden, wohlbemerkt alles onefiler.

    Zitat von AREA51HD


    Was nur sicher ist das sich die Fehler relativ genau repoduzieren lassen.
    Wenn das z.b. das Spiel Leaper geladen wurde, gibt es das Intro "Mit der Tanzenden Maus" oben im Bildschirm, und einem umlaufenen Rahmen.

    Welche Version / Crack / Download von Leaper denn? Leaper murkst so einiges in der erweiterten Zeropage rum ...

    So ich habe mal Daten gesammelt :saint:




    Es Funktionieren eine ganze Reihe von spielen nicht mit Jiffy aber mit dem Normalen Kernel schon.
    Das ist nur EIN Beispiel von vielen, und der Fehler ist halt netterweise immer sofort bei einem Bildschirm zu sehen, andere Spiele haben
    Datenmüll in den Leveln, oder Crashen beim Starten...
    Testprog.prg



    So sieht der Startbildschirm aus:



    Fehlerfreier Intro Screen geladen mit Original Kernel, und mit Jiffy DOS in 1541, oder Jiffy 1581 oder SD2IEC, oder Orginal rom in 1541




    So sieht der Bildschirm aus wenn man es mit Jiffy ROM im C16+4 und Jiffy ROM in der 1541 probiert:


    So sieht der Bildschirm aus wenn man es mit Jiffy ROM im C16+4 und Original ROM in der 1541 probiert:


    Nicht falsch verstehen, es geht nicht darum nur das eine Spiel zu fixen, sondern die Grundsätzliche Problematik bei Jiffy geladenen Daten...

    Ich habe jetzt weitere systematische Tests durchgeführt:
    Ein 5 KB große sequentielle Datei erstellt, in der 20 mal die Bytewerte von 0 bis 255 gespeichert sind.
    Diese Datei wird byteweise von einem BASIC Programm gelesen und danach die Statusvariable ST geprüft.
    Wenn sie das Timeout-Bit gesetzt hat, wird der Lesevorgang wiederholt und der Wert, bei dem das Problem auftrat, angezeigt.
    Resultat: Bei jedem Durchgang treten die Fehler an unterschiedlichen Positionen mit unterschiedlichen Werten auf.
    Beispiel für einen Durchgang: 12 Fehler mit den Werten: 8F FE FA DD 3A 17 26 05 5F 67 D5 FE
    Hier ist nichts reproduzierbar außer der Tatsache, dass immer ca. 10-20 Lesefehler pro Durchgang auftreten.


    Der selbe Rechner mit dem Original Kernal ROM liest die Datei dagegen fehlerlos.