Hello, Guest the thread was called1.1k times and contains 12 replays

last post from Larry at the

Wie JiffyDOS erkennen unter BASIC

  • Hallo zusammen,


    für ein kleines BASIC Coding Projekt müsste ich ermitteln, ob JiffyDOS im Rechner zu Verfügung steht. S-Jiffy lassen wir mal außen vor.
    Es gibt 3 Möglichkeiten JiffyDOS im C64 zur Verfügung zu stellen: Als Kernal im Rechner, von der SuperCPU wenn der Schalter ON ist, von der RamLink (ggf. RamDrive) wenn der Schalter ENABLED ist.


    Ich kann testen, ob eine SCPU an ist, aber zur Abfrage des Schalters habe ich nichts gefunden. Gleiches gilt für die RamLink.
    Je nachdem ob JiffyDOS zur Verfügung steht, soll ein Teil des Codings ausgeführt werden, oder eben nicht wenn kein JiffyDOS da ist.


    Es geht hier um den C64 bzw. 128er im C64 Modus.


    Für Tipps / Lösungen wäre ich wirklich dankbar.

  • Ich würe ja auf den String "JIFFY" im Kernal - der von der Einschaltmeldung - prüfen, mit einer FOR-PEEK-NEXT-Schleife.

    "Steve Jobs hat User hervorgebracht, Jack Tramiel Experten." - Quelle unbekannt.


    Mein Herr, ich teile Ihre Meinung nicht, aber ich würde mein Leben dafür einsetzen, dass Sie sie äußern dürfen." - Voltaire.


    "Diskutiere nie mit einem Idioten - er zieht dich auf sein Niveau hinunter und schlägt dich dort mit seiner Erfahrung!" - Volksweisheit.

  • für ein kleines BASIC Coding Projekt müsste ich ermitteln, ob JiffyDOS im Rechner zu Verfügung steht. S-Jiffy lassen wir mal außen vor.


    Es gibt 3 Möglichkeiten JiffyDOS im C64 zur Verfügung zu stellen: Als Kernal im Rechner, von der SuperCPU wenn der Schalter ON ist, von der RamLink (ggf. RamDrive) wenn der Schalter ENABLED ist.

    Fällt bei Dir die Benutzung von JiffyDOS über ein Easy Flash 3 Modul auch unter "im Rechner" ? ;)
    Das stellt nämlich auch die Möglichkeit von JiffyDOS bzw. anderen Kernals zur Verfügung..

  • Eigentlich muss man sich nur jeweils ein Byte in den Jiffy-Dos ROMs aussuchen, welches für das entsprechenden DOS einzigartig ist. Darauf wird dann geprüft.

    In der Zeitschrift für Assyriologie übersetzte H. Zimmern 1896 einen fast 3000 Jahre alten Text, der in den Ruinen der Bibliothek des Assurbanipal in Ninive gefunden wurde, aus der Keilschrift ins Deutsche. Auf dem Tontäfelchen hatte der Umanu (Weisheitsvermittler) Shaggil-kinam-ubib notiert:

    ,Schaust du hin, so sind die Menschen insgesamt blöde.‘

    Das fasst im Prinzip alles ganz gut zusammen.“

  • Fällt bei Dir die Benutzung von JiffyDOS über ein Easy Flash 3 Modul auch unter "im Rechner" ?

    Nein EF kann ich ausschließen. Das ganze soll für die BBS Software C*BASE dienen. Da macht ein EF wenig Sinn, auch wenn wahrscheinlich nicht unmöglich ist eine EasyFlash Version davon zu machen.



    Eigentlich muss man sich nur jeweils ein Byte in den Jiffy-Dos ROMs aussuchen, welches für das entsprechenden DOS einzigartig ist. Darauf wird dann geprüft.

    OK dann suche ich mal weiter im ROM Bereich.

  • OK dann suche ich mal weiter im ROM Bereich.

    Der Bereich der RS232- und/oder TAPE-Routinen beim Origjnal-Kernal sollte bei Jiffy jedenfalls anders sein.

    "Steve Jobs hat User hervorgebracht, Jack Tramiel Experten." - Quelle unbekannt.


    Mein Herr, ich teile Ihre Meinung nicht, aber ich würde mein Leben dafür einsetzen, dass Sie sie äußern dürfen." - Voltaire.


    "Diskutiere nie mit einem Idioten - er zieht dich auf sein Niveau hinunter und schlägt dich dort mit seiner Erfahrung!" - Volksweisheit.

  • Der Bereich der RS232- und/oder TAPE-Routinen beim Origjnal-Kernal sollte bei Jiffy jedenfalls anders sein.

    Statt direkt Bytes zu PEEKen könnte man auch versuchen, diese Routinen anzuspringen - ein Kernal-OPEN auf z.B. Device 1 sollte ja einen bestimmten Fehler zurückgeben. Einerseits wäre das "sauberer", andererseits muss dazu dieser Fehlercode anders sein als der, der von einem Standardkernal ohne Datassette erzeugt wird.


    Aber um eine wirklich passende Lösung für das Problem finden zu können, sollte das Problem näher erläutert werden: Was genau soll denn bei gefundenem Jiffy passieren und was beim Standardkernal? Warum soll unbedingt auf Jiffy geprüft werden und nicht auf "irgendein Speeder"?

  • Warum soll unbedingt auf Jiffy geprüft werden und nicht auf "irgendein Speeder"?

    Weil wenn JiffyDos vorhanden ist, sollen JiffyDos Befehlen ausgeführt werden, wie z.B. das Kopieren von Dateien usw.

  • Statt direkt Bytes zu PEEKen könnte man auch versuchen, diese Routinen anzuspringen

    Das ist sicher sinnvoller :thumbup: ... weil wenn ich mir das Super-CPU-ROM so ansehe weiß ich gar nicht, ob das irgendwas mit dem normalen C64-Kernal gemeinsam hat? (Nicht nur wegen der Einschaltmeldung.)


    Aber ich räume das Feld und lasse die Software-Experten vor :D ... war nur so ein schneller Gedanke und ist ja eigentlich nicht "meine Baustelle" =O ...

    "Steve Jobs hat User hervorgebracht, Jack Tramiel Experten." - Quelle unbekannt.


    Mein Herr, ich teile Ihre Meinung nicht, aber ich würde mein Leben dafür einsetzen, dass Sie sie äußern dürfen." - Voltaire.


    "Diskutiere nie mit einem Idioten - er zieht dich auf sein Niveau hinunter und schlägt dich dort mit seiner Erfahrung!" - Volksweisheit.

  • Weil wenn JiffyDos vorhanden ist, sollen JiffyDos Befehlen ausgeführt werden, wie z.B. das Kopieren von Dateien usw.

    Und was macht das Programm ohne Jiffy? Alles zu Fuß, d.h. Byte für Byte kopieren? Oder kommt dann eine Fehlermeldung, die dem Nutzer sagt "diese Funktionalität ist nur mit Jiffy verfügbar"? Falls letzteres, kann man sich die Abfrage sparen und einfach separate Programmversionen für Standardkernal und Jiffy machen. Das mag nicht sehr elegant wirken, löst das Problem aber 100%ig.


    Denn: Ein bestimmtes ROM anhand spezieller Bytes oder Prüfsummen erkennen zu wollen, um daraus auf das Vorhandensein einer bestimmten Funktionalität zu schließen, frustriert alle Benutzer mit obskuren alten oder gepatchten Jiffy-Versionen, die zwar die gewünschte Funktionalität aufweisen, aber vom Testalgorithmus nicht erkannt werden.


    Eine andere Lösung wäre noch: Man verhindert via POKEs (frag mich nicht wie) den Programmabbruch bei Fehlern und versucht den "*"-Kopierbefehl einfach zu benutzen. Direkt danach prüft man, ob es funktioniert hat oder nicht und weiß dann, ob die Funktionalität verfügbar ist. Diese Vorgehensweise (also Versuch+Fehlerbehandlung) ist ja eigentlich der Normalfall.

  • Und was macht das Programm ohne Jiffy? Alles zu Fuß, d.h. Byte für Byte kopieren? Oder kommt dann eine Fehlermeldung, die dem Nutzer sagt "diese Funktionalität ist nur mit Jiffy verfügbar"? Falls letzteres, kann man sich die Abfrage sparen und einfach separate Programmversionen für Standardkernal und Jiffy machen. Das mag nicht sehr elegant wirken, löst das Problem aber 100%ig.
    Denn: Ein bestimmtes ROM anhand spezieller Bytes oder Prüfsummen erkennen zu wollen, um daraus auf das Vorhandensein einer bestimmten Funktionalität zu schließen, frustriert alle Benutzer mit obskuren alten oder gepatchten Jiffy-Versionen, die zwar die gewünschte Funktionalität aufweisen, aber vom Testalgorithmus nicht erkannt werden.


    Eine andere Lösung wäre noch: Man verhindert via POKEs (frag mich nicht wie) den Programmabbruch bei Fehlern und versucht den "*"-Kopierbefehl einfach zu benutzen. Direkt danach prüft man, ob es funktioniert hat oder nicht und weiß dann, ob die Funktionalität verfügbar ist. Diese Vorgehensweise (also Versuch+Fehlerbehandlung) ist ja eigentlich der Normalfall.

    Das Programm soll, wenn Jiffy vorhanden ist, Files kopieren per JiffyDOS Filecopy "spezial" Befehl siehe hier. Wenn kein Jiffy vorhanden ist, soll eben nichts kopiert werden. Da ich nicht anfange für C*BASE ein FileCopy zu bauen, was mit dem C*BASE Code nicht in Konflikt kommt, automatisiert und parametrisierbar läuft (quasi wie ein cron Job mit rsync) ist das dann ein Kompromiss mit dem die SysOps leben müssen (und wahrscheinlich auch können, da die eh fast alle Jiffy einsetzen....).