Posts by LogicDeLuxe

    Ja, hallo, sowas habe ich eigentlich schon länger gesucht! Dem Kernal ist es also egal, ob eine Jiffy-Floppy oder eine Dolphin-Floppy dran hängt? Hauptsache eins von beiden?

    Es wird nur JiffyDOS beschleunigt. Für beides reicht der Platz nun wirklich nicht. Es steht aber auch in der Beschreibung:

    Quote

    - You'll get all features of the Dolphin DOS kernal, except for the parallel speed routines.

    Eine sinnvolle Ergänzung wäre evtl. ein Floppy-Dolphin-ROM, wo ebenfalls die Parallelroutinen gegen die von JiffyDOS austauscht sind. Damit wäre immer noch der Trackloader auf der Speichererweiterung aktiv und die Geschwindigkeit vermutlich ähnlich einer 1581 mit JiffyDOS, was schon ziemlich nah an die Parallelgeschwindigkeit ran kommt. Werde ich aber wohl nicht in absehbarer Zeit machen, da ich mit anderen Dingen beschäftigt bin und außerdem keine Dolphin DOS-Floppy mehr zur Hand habe.

    Nach meiner Erfahrung tun die sich in der Kompatibilität nichts. Jiffy ist halt in einer 1541 mangels Trackloader deutlich langsamer als auf anderen Laufwerken, hat aber den Vorteil, daß es als Quasistandard von nahezu allen Massenspeichern am C64 unterstützt wird.

    Ich hatte hier auch mal das Jiffy-Protokoll in das Dolphin-KERNAL eingebaut, damit man sich bei der Bedienung nicht immer umstellen muß, wenn man zwischen beiden wechselt:

    Please login to see this link.

    Zuerst hing er links, beim Remake dann rechts - na, und jetzt halt wieder links. Ist doch klar, dass dann noch Überbleibsel an der Wand rechts zu sehen sind. ;-)

    Und den hier nicht vergessen:

    Please login to see this attachment.

    Auch ganz praktisch, daß man da noch den Spielautomaten hingestellt hat, um sicher zu gehen, daß man nicht wegen Pleite stecken bleiben kann. Wäre das evtl. auch in der C64-Version möglich?

    Falls noch jemand über dieses Problem stolpert, hier ist die haarsträubende Lösung:

    Die Syntax würde geändert. Es heißt nicht mehr ? sondern :?. Nur blöd, daß weder die Fehlermeldung, noch die Dokumentation auf der offiziellen Seite diesen Umstand erwähnen. Um das raus zu finden, musste ich erstmal den Bug Tracker durchforsten:

    Please login to see this link.

    Und verwendet man die neue Syntax bei einer älteren FFmpeg-Version kommt auch kein Fehler, weil es dann z.B. deu: als Sprachcode interpretiert, der natürlich deu nicht als gesuchte Sprache erkennt. Dadurch werden optionale Spuren gar nicht erst mit kopiert. Der Fall ist nicht unwahrscheinlich, weil in diversen Distributionen eben immer noch alte Versionen installiert sind.

    Hier hatte einer ein ähnliches Problem: Please login to see this link.

    Da scheint es wohl seit der Version 7 ein Bug mit -map zu geben. Es ist auch nicht systemspezifisch, wie ich erst angenommen hatte. In Mint lief es lediglich deswegen, weil dort eine ältere Version vorinstalliert ist, die den Fehler noch nicht hatte. Mit der Version 6.1.1 geht es sowohl unter Linux wie auch unter Windows. Ein kurzer Stichprobentest mit der aktuellen Version zeigte, daß das Problem auch unter Linux auftritt.

    Ich werde dann wohl besser eine kompatible Version beipacken müssen.

    Ich habe ein Problem mit diesem Befehl:

    Code
    ffmpeg -i ufpetmp0 -i ufpetmp1 -map 0:v -map 1:s -map 0:a:m:language:ger? -map 0:a:m:language:eng? -map 0:a:m:language:ita? -map 0:a:m:language:spa? -map 1:a:m:language:art -map 0:a:m:language:lol? -c: copy test.mkv

    Unter Linux tut es das, was es soll. Unter Windows kommt jedoch diese Fehlermeldung, aus der ich nicht schlau werde:

    Code
    Stream map '' matches no streams.
    To ignore this, add a trailing '?' to the map.
    Failed to set value '0:a:m:language:ger?' for option 'map': Invalid argument
    Error parsing options for output file test.mkv.
    Error opening output files: Invalid argument

    Irgendeine Idee, wie ich das systemübergreifend zum Laufen bringe? ufpetmp0 kann je nach Situation unterschiedliche Tonspuren haben, die in test.mkv übernommen werden sollen, sofern vorhanden. Deswegen die vielen Sprachen mit '?'. Alle Dateien sind im MKV-Format und werden korrekt erkannt. Mit Wine kommt die selbe Fehlermeldung wie im echten Windows.

    Um nicht bei jedem Debug-Print einen #if-Block zu machen, habe ich das mit diesem Macro gelöst:

    Code
    //#define debug 1
    #if debug
      #define _printf(...) printf(__VA_ARGS__)
    #else
      #define _printf(...) //__VA_ARGS__
    #endif

    Je nachdem, ob debug definiert ist, werden die printf-Anweisungen kompiliert oder komplett mit allen Parametern weggelassen, da sie per // auskommentiert sind.

    Was mich dabei aber überrascht ist, daß das offenbar wirklich nur für einen Befehl gilt, auch wenn da noch mehr in der selben Zeile steht. Mit

    Code
    printf("test1\n"); _printf("test2\n"); printf("test3\n");

    wird bei nicht definiertem debug dies ausgegeben:

    Code
    test1
    test3

    Die zweite Anweisung wird nicht kompiliert, wie erwartet. Überrascht bin ich, daß aber die dritte Anweisung drin bleibt. Gehört das so? Gibt es da eine eindeutige Definition, wie Macros in C++ funktionieren sollten?

    Wine und Windowstreiber sind nicht vorgesehen. Dafür gibt es aber ein verwandtes System:

    Please login to see this link.

    In virtuellen Maschinen läuft es wohl, aber gerade auf echter Hardware, wo die Treibersache interessant wird, scheint es niemand zum laufen zu bringen. Von daher leider ziemlich nutzlos.

    Solche Images einzuhängen ist oft einfach nur im Kontextmenü.

    Wem sagst Du das? Das habe ich ja im zitierten Post im 2. Absatz geschrieben.

    Exe-Dateien werden unter Wine ausgeführt. Das ist aber nicht 100% kompatibel.

    Für solche Treibersachen wie ISOs mounten ist es ja auch nicht gedacht. Brennprogramme gehen aber grundsätzlich.

    Beispielsweise habe ich ein Tool unter Windows, welches ISO-Dateien als virtuelle Laufwerke einbindet.

    Das geht doch mit Bordmitteln. In Mint MATE mache ich einen Rechtsklick auf die ISO und wähle "Open With ►", "Disk Image Mounter". In anderen Distributionen wird das sicher ähnlich sein.

    Allerdings kann ich nur ISO-Dateien erstellen und editieren.

    Wenn's ein Windows-Programm sein soll, nehme ich ImgBurn für das Authoring:

    Please login to see this link.

    Das ist kostenlos und standardkonform. Zwei Dinge die man vom beliebten Nero nicht behaupten kann. Insbesondere kann man dort auch fachgerecht den Schichtwechsel bei einer DVD9 anpassen.

    Aber wenn es nur darum geht, ein ISO-Dateisystem zu erzeugen, findet man natürlich auch für Linux die üblichen Cdrtools:

    Please login to see this link.

    Weil auch die Interrupt-Routinen beschleunigt werden, bleibt prozentual mehr für die übrigen Routinen. Das ist nicht linear, aber absolut praxisrealistisch, wenn es um den Spieleeinsatz geht, denn die allermeisten Spiele wird man aus dem selben Grund auch nicht linear beschleunigen.

    Die erste Taktverdoppelung bringt in der Regel den meisten Gewinn. Je mehr im Interrupt passiert, desto deutlicher. Wenn z.B. normal 50% im Interrupt passieren, und man verdoppelt den Takt, dann brauchen Interrupt-Routinen nur noch 25% der beschleunigten Rechenzeit. Die übrigen Routinen laufen deswegen gleich 3 mal so schnell.

    Bouldermark zählt die Scanzyklen im Spielfeld, die es in einer Minute schafft. Ausgebremst wird das nur durch die Interrupt-Routinen, welche für die Darstellung, Scrolling, den Sound und die Animationen verwendet werden.

    Für korrekte Messungen auf PAL-Geräten ist darauf zu achten, daß das Norm-Flag richtig gesetzt ist. Sonst läuft der Benchmark zu lange. Wenn man den Turbo vor dem Reset einschaltet, funktioniert die Norm-Erkennung im Original-KERNAL nicht zuverlässig. In diesem KERNAL ist das aber gefixed:

    Please login to see this link.

    Würden sie prinzipiell sowieso, sofern die nötigen Bibliotheken da sind, nur ist es so gepackt noch einfacher.

    Ja, das ist der Sinn von Appimage, aber auch da kann es schonmal passieren, daß eine Komponente vergessen wurde. Hab ich schon gehabt. Da ich MATE nutze, nehme ich normalerweise Abstand, wenn der Name ein KDE-Programm suggeriert. Wieso hat es überhaupt diesen suggestiven Namen? Auf der GitHub-Seite liest man "The application is written in C++ with Qt and doesn't have any KDE dependencies.".

    Und so unglaublich groß ist es mit 52MB auch nicht. Mein SoftwareManager hat das nur als Flatpak drin, und es zeigt mir an: "1,3 GB to download, 4,1 GB of disk space required".

    Seit dem Test starte ich Windows eigentlich nur alle paar Wochen damit mich die Updates nicht erschlagen, sollte ich es nochmal brauchen.

    Und falls dabei mal plötzlich kein Bootmenü mehr erscheint und nur noch direkt Windows bootet, prüfe mal die Bootreihenfolge im BIOS. Die hat mir Windows schon mehrmals ungefragt geändert.