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

letzter Beitrag von Frenetic am

Jiffydos für Plus4

    Ich vermute, dass es zwei verschiedene Probleme sind, was die Sache extrem verkompliziert:


    Bei AREA51HD ist der fehlerhafte Intro-Screen immer, wenn im Plus4 das JiffyDOS-Kernal ist, selbst dann, wenn in der 1541 das CBM-DOS ist. Wenn das JiffyDOS-Kernal feststellt, dass eine Floppy ohne JiffyDOS-Routinen angeschlossen ist, dann werden die Original-CBM-IEC-Routinen benutzt. Der Fehler tritt selbst beim Benutzen dieser CBM-Routinen auf, sodass der Fehler nicht im JiffyDOS-IEC-Timing liegt, sondern an irgend einer Änderung des Kernals an irgend einer anderen Stelle. Das dürfte extrem schwierig herauszufinden sein.


    Bei Bit Shifter müsste das Problem das JiffyDOS-IEC-Timing sein.
    Kannst du mal sagen, welchen Originalwert die 12 fehlerhaften Bytes haben sollten.
    Ist der Fehler nur am realen Plus4 oder auch in VICE?


    Hat jemand ein kommentiertes Kernal-Listing für den Plus4?

    Wenn ein JiiifyDOS bedingter Lesefehler aufritt, so wird als Bytewert immer $0D (Return) gemeldet und in der ST Variablen ist Bit 1 gesetzt (meistens in Kombination mit Bit 6).
    Ein erneuter Einleseversuch führt aber immer zum korrrekten Wert. Ich hatte die Originalwerte in meinem Post angegeben, der Fehlerwert ist immer $0D.
    Ich werde Deinen Vorschlag aufgreifen und probiere das Programm mit den JiffyDOS Routinen auch mal in VICE aus.

    Ich glaube ich muss mir ein paar :picard: abholen...


    Gestern und heute habe ich eine Liste von Spielen erstellt die unter Jiffy nicht zu laden sind, anschließend habe ich es nochmal mit den Standard ROMS probiert.
    Erstaunlicherweise liefen die bis auf 2 ausnahmen alle auch dann nicht, dabei war ich mir sicher das die alle mal funktionierten...


    Die 256MB SD karte habe ich dann mal in den PC gesteckt und wollte es unter VICe probieren, liefen auch nicht..


    Einen HEX Editor geöffnet und die nicht funktionierenden spiele mal geöffnet, einige große blöcke mit nur 0xFF inside.
    Laut dateisystem sollte ich damals ende 2008 die Files auf die Karte Kopiert haben, beginnender Datenverlust?


    Die Good ROMs nochmal gesucht und nochmal unter Jiffy probiert, sieht schon viel besser aus, ich teste nochmal intensiv auf echter hardware...


    Nur das Leaper Phänomen ist geblieben, ist aber unkritisch da nur Intro betroffen ist...

    Zitat von AREA51HD

    Einen HEX Editor geöffnet und die nicht funktionierenden spiele mal geöffnet, einige große blöcke mit nur 0xFF inside.
    Laut dateisystem sollte ich damals ende 2008 die Files auf die Karte Kopiert haben, beginnender Datenverlust?

    Äh, ja... Flash ist nunmal vom Prinzip her dasselbe wie ein EPROM, nur mit kleineren Strukturen und deshalb weniger Datenerhaltungszeit. Flash taugt nicht als Archivmedium! Gilt auch oder insbesondere für SSDs!

    Zitat von AREA51HD


    Gestern und heute habe ich eine Liste von Spielen erstellt die unter Jiffy nicht zu laden sind, anschließend habe ich es nochmal mit den Standard ROMS probiert.
    Erstaunlicherweise liefen die bis auf 2 ausnahmen alle auch dann nicht, dabei war ich mir sicher das die alle mal funktionierten...

    Mich würde diese Liste trotzdem mal aus Neugierde interessieren, insbesondere wenn es irgendwelche Cracks sind.

    Uff, die SD Karte habe ich Formatiert und mal H2test2.exe drüber laufen lassen, mit dem Ergebnis das alls in Ortnung ist.
    Leider habe ich die PRG Dateien nicht gesichert gehabt da sie Schrott waren, die Dateinamen hatte ich um 2008 C16 Direktory gerecht angepasst und nicht lauffähiges oder uninteressantes über bord gewurfen.





    Aktuell ist die TOSEC vom C16 vom Webarchive drauf, da ist wirklich vieles nicht lauffähig von und die langen Dateinamen ein graus...


    Was damals noch lief und heute defekt war, soweit alles ohne Cracks...
    Planet Search
    Bounder
    Leaper (Intro Bug)
    Arg Arg
    Berks
    Baby Berks

    Um den Timeouts beim Lesen mit JiffyDOS auf die Spur zu kommen, habe ich die JiffyDOS Version der ACPTR Routine im PLUS/4 analysiert:


    Hier ist zum Vergleich das Timing der C64 Routine (ebenfalls die JiffyDOS ACPTR Routine)

    Wenn die beiden CPU's gleich schnell liefen (was sie nicht tun), wäre die PLUS/4 Routine etwas schneller.
    Der C64 holt jeweils 2 Bits des zu empfangenden Bytes zu den Zyklen 38, 48, 59 und 70 ab.
    Der PLUS/4 macht es an den Zyklen 36, 45, 54 und 64.
    Die CPU Geschwindigkeit der 7501/8501 CPU des PLUS/4 ist darüber hinaus nicht konstant, sondern
    1,77 MHz solange der Rasterstrahl sich im Rahmen befindet und ca. 1 MHz (?) im nutzbaren Bildbereich.
    Die ACPTR Routine schaltet den TED deshalb auf langsam, damit der Takt konstant und berechenbar ist.
    Wenn man jetzt das Timing des 7501/8501 exakt bestimmen könnte, wäre es möglich die ACPTR
    des PLUS/4 nachzujustieren um die ärgerlichen Timeouts beim Lesen abzuschalten.
    Vielleicht hat ja jemand bessere Informationen über das Timing der 7501/8501 CPU in Kombination mit TED
    und der PAL Version als ich. Dann könnte man die schon immer fehlerhaften JiffyDOS Routinen
    für den PLUS/4 PAL endlich fixen.


    Die LOAD Routine scheint übrigens beim PLUS/4 einwandfrei zu funktionieren.
    Die schaltet allerdings während des Ladens den TED / Bildschirm komplett ab
    und kann dann mit einer konstanten Geschwindigkeit der CPU von 1,77 MHz arbeiten.


    Für die ACPTR Routine ist das Bildschirm abschalten keine Option.
    Es wäre furchtbar, wenn jedes Lesen eines Bytes den Bildschirm flackern ließe.

    Zitat von Bit Shifter

    Die CPU Geschwindigkeit der 7501/8501 CPU des PLUS/4 ist darüber hinaus nicht konstant, sondern
    1,77 MHz solange der Rasterstrahl sich im Rahmen befindet und ca. 1 MHz (?) im nutzbaren Bildbereich.

    Der Quarz hat 17,73447 MHz. Beim Zeichnen des Rahmen wird dieser Takt durch 10 geteilt, wenn TED auch was vom Bus will durch 20. Man darf auch nicht vergessen, daß TED im Rahmenbereich noch 5 Refreshzyklen pro Zeile für das RAM durchführt.


    Es kommt noch dazu, das TED nicht nur eine, sondern 2 Badlines pro Zeile durchführt und die auch noch direkt hintereinander.


    Weiteres Timing kann man im 'TED System Hardware Manual-1.pdf' finden. Sollte sich noch im Netz finden lassen.

    Ich habe mir jetzt mal den Unterschied zwischen der NTSC und der PAL Version von JiffyDOS für den PLUS/4 angeguckt.
    Neben der unterschiedlichen Belegung eines nicht benutzten ROM Bereichs ab $FD00 ($00 vs. $ff) liegt der Unterschied
    in genau einem Bit, das Bit 6 an der Adresse $F33F. Der Wert von $F33F wird beim Neustart oder Reset in das TED
    Register 7 übertragen, das Bit 6 regelt den Modus NTSC (Bit6 = 1) oder PAL (Bit6 = 0). Der Patch vom NTSC
    JiffyDOS zu PAL JiffyDOS besteht also darin, dass der PAL Computer korrekt das PAL Bit auf 0 gesetzt bekommt, weil
    er mit dem NTSC Modus ohne Austausch des Quarzes nicht funktioniert. Der JiffyDOS Code selbst hat keine
    unterschiedlichen Routinen für NTSC oder PAL. Beim C64 ist es auch so und scheint zu funktionieren.
    Anscheinend liegen die Differenzen im Timing dort innerhalb der Toleranzen in der synchronen Datenübertragung.
    Beim PLUS/4 hingegen klappt es hin und wieder nicht.

    Ich habe das Problem mit den Timeouts beim Lesen mit JiffyDOS von einem SD2IEC schließlich eingekreist.
    Es ist kein Software-Problem, sondern ein Hardware-Problem.
    Folgende Komponenten müssen über den IEC Bus miteinander verbunden sein, damit es auftritt:


    1) Der Computer ist ein PLUS/4 oder C16
    2) Es ist ein Floppylaufwerk mit JiffyDOS (getestet 1581 und 1571) angeschlossen.
    3) Es ist gleichzeitig ein SD2IEC oder petSD+ (mit anderer Adresse als das Floppylaufwerk) angeschlossen.


    Leider ist dies meine Standard-Konfiguration, weshalb mich der Fehler auch so lange plagte.


    Gegenanzeige:


    Ein C64 oder C128 hat mit (JiffyDOS) Floppylaufwerk und SD2IEC gleichzeitig keine Probleme.
    Wenn nur das Floppylaufwerk oder nur das SD2IEC an den PLUS/4 angeschlossen sind, gibt es auch keine Lesefehler.


    Ich kann nur vermuten, dass die PLUS/4 und C16 am IEC Bus elektrisch leichte Abweichungen zu den C64 aufweisen.
    Wenn dann ein SD2IEC nicht direkt, sondern mit einer dazwischen geschalteten Floppy am PLUS/4 hängt
    und zusätzlich das zeitempfindliche JiffyDOS Protokoll läuft, kommt es immer wieder zu den beschrieben Timeouts.


    Das ist zwar jetzt keine Lösung, aber immerhin eine Erklärung.
    Ich finde es schade, dass ich nicht am PLUS/4 direkt mit Floppy und SD2IEC arbeiten kann, aber
    man kann damit leben.


    Puh, das war eine langwierige Fehlersuche :whistling:

    Zitat von cbm-warrior

    Ist in dieser Aussage die 1551 mit eingeschlossen?

    Die 1551 und ein SD2IEC haben kein Problem mit der Koexistenz. Das hat wohl damit zu tun, dass beide Geräte an verschiedenen Anschlüssen (1551 am Modulport, SD2IEC am seriellen IEC Bus) hängen. Die oben beschriebenen Probleme treten nur auf, wenn ein SD2IEC nicht allein am IEC Bus betrieben wird.

    Zitat von Bit Shifter

    Ich kann nur vermuten, dass die PLUS/4 und C16 am IEC Bus elektrisch leichte Abweichungen zu den C64 aufweisen.

    Das kann auch durch die leicht unterschiedliche Taktfrequenz passieren. Mehr Geräte am seriellen Bus heisst längere Kabel und damit eine höhere parasitäre Kapazität, was die Signalflanken verlangsamt. Möglicherweise würde es reichen, das Timing des JiffyDOS-Plus/4-Kernals an der richtigen Stelle um einen CPU-Takt zu verändern, um die Probleme zu beseitigen.

    Zitat von Unseen

    Das kann auch durch die leicht unterschiedliche Taktfrequenz passieren. Mehr Geräte am seriellen Bus heisst längere Kabel und damit eine höhere parasitäre Kapazität, was die Signalflanken verlangsamt. Möglicherweise würde es reichen, das Timing des JiffyDOS-Plus/4-Kernals an der richtigen Stelle um einen CPU-Takt zu verändern, um die Probleme zu beseitigen.

    Das habe ich schon versucht. Ich habe in die ACPTR Routine des JiffyDOS eingegriffen und an mehreren Stellen (Nach Beginn des Transfers, zwischen Daten und Handshake, etc.) zusätzliche Zyklen eingebaut oder eingespart. Meistens gab es keine Änderungen, gelegentlich wurde die Fehlerhäufigkeit höher oder niedriger, aber sie ging nie auf Null.
    Außerdem beträgt der CPU-Frequenz-Unterschied zwischen C64 und PLUS/4 ca. 1%. Da die Übertragung eines Bytes inklusive Handshake ca. 80 Zyklen dauert und der Abstand zwischen den Übertragungen eines Bitpaars zum nächsten 10 Zyklen, macht der Geschwindigkeitsunterschied im Übertragungsprotokoll nichts aus.

    Zitat von Unseen

    Waren das nicht eher 10% für PAL und fast 15% für NTSC?

    Ich habe da leider auch bisher widersprüchliche Informationen gefunden.
    Aber bei 10% Unterschied dürfte die Jiffy-Routine des PLUS4, die wie die des C64 getaktet ist, gar nicht funktionieren, sondern müsste schon nach den ersten 4 Bits asynchron werden.

    Zitat von NLQ

    Hierbei muss man allerdings berücksichtigen, dass die 1541-Warteschleife auf das C64-Übertragungs-Start-Signal 7 Zyklen (7µs) ist, sodass von den 10 Zyklen effektiv nur 3 übrig bleibe. Das ist schon recht knapp.

    Jedenfalls habe ich experimentell (mit vielen gebrannten EPROM an der echten Hardware getestet) versucht das Timing zu verändern, aber keine Verbesserung erzielt.
    Dass hingegen nach Abstöpseln der Floppy der alleinige Betrieb eines SD2IEC fehlerfrei funktioniert, legt nahe, dass das Timing nicht das Problem darstellt, sondern das Zusammenspiel der drei Geräte PLUS/4, Floppylaufwerk und SD2IEC am IEC Bus.


    Auf der "http://plus4world.powweb.com/plus4encyclopedia/500248" habe ich folgende Tabelle gefunden:
    Wobei für das Jiffy_ACPTR die Zeile 6 gelten müsste.
    Bei der CPU freq handelt es sich meiner Meinung nach aber nicht um den Takt, aus dem man die Ausführungszeit der Befehle in Mikrosekunden berechnen kann, sondern um die effektive Frequenz, die man erhält wenn auch das Anhalten der CPU durch den TED mit eingerechnet wird.