Posts by markusC64

    "Early Birds" sind nun mal leider auch Beta-Tester. Ein Grund für mich, nie ganz vorne mit dabei zu sein.

    Wohl wahr. Wie mans macht, macht mans falsch. Apple ist dafür bekannt, dass auf deren Geräten in der Regel kein älteres MacOS läuft als bei Einführung des Gerätes drauf war... Mit den frühen Kauf hat man dann zumindest maximale Auswahl, aber dafür die Bugs in der Software...


    Aber ein CCC-Clone vom Fast-Auslieferzustand ist in der Tat eine gute Idee. Den kann man dann sowohl zum Testen als auch als Backup nehmen - davon gebootet und Zurückkopieren sollte ja klappen statt der defekten Wiederherstellung. Ich werde wohl am Wochenende einen solchen Klon anfertigen...

    Und ansonsten habe ich ja für kontinuierliche Backups die eingebaute Timemachine

    Von der Idee nicht schlecht. Aber:

    Und ich meine, dass ich auch daraus mein System wieder herstellen kann, wenn ich von der Recovery-Partition boote

    Das geht auch vom Prinzip her - nur hat Apple da einen Bug reingetan bei den M1 Modellen... Auf den Bugfix wartet man derzeit noch. https://www.heise.de/news/Macs…er-lahmlegen-4964790.html


    Immer diese Bugs bei neuen Sachen... wird gefühlt immer schlimmer.


    Edit: Ich gönne mir noch ein

    Quote

    Nutzer der neuen M1-Macs – MacBook Air, MacBook Pro oder Mac mini – sollten vorerst auf eine Neuinstallation des Betriebssystems, soweit möglich, verzichten, bis Apple eine Möglichkeit geschaffen hat, dies wieder normal über die macOS-Wiederherstellung durchzuführen.

    Kann man denn da momentan nicht den BigSure Installer aus dem Appstore laden ?

    Gute Frage... Zumindest das könnte sein, dass das klappt.


    Der andere Artikel zu den bootbar machen wurde aber offensichtlich nicht angepasst - es gibt auf M1 kein MacOS < 11.


    Die soll man wiederherstellen, indem man in die Internet-Recovery bootet - das wiederum ist lt. Heise aber broken und braucht erst ein Update, welches noch nicht erschienen ist. Backup also dringend angeraten, denke ich mal.


    Edit: Nee, den App-Store download kann man nicht trauen. Der bietet auf M1 auch Catalina an... Das kann nichts werden.... Woher weiß ich dann, ob ich eine M1 Version bekomme?!

    dann kannst du den macOS-Installer aus dem AppStore direkt auf das USB/ Thunderbolt Stick/Drive anwenden ... hier ist eine Schritt für Schritt Anleitung

    Gibt es im AppStore die M1-Variante??? Ich dachte, der wäre für Updates, also Intel...


    Wir sind im Thread "Erste Apple Macs mit ARM-Prozessoren".

    hier ist eine Schritt für Schritt Anleitung https://support.apple.com/de-de/HT201372

    Sorry, was ich da sehe, sieht alles nach Intel aus, nicht nach M1.



    Edit: Bei Intel würde ich ein Image mit "Paragon Hard Disk Manager" ziehen als Backup und gut. Habe ich beim iMac con 2013 auch so gemacht... Aber mich interessiert derzeit M1.

    Mehr als gut 60'000 (65535?) Blocks scheint auch gar nicht zu gehen in 1 Partition, wie es aussieht.

    65280? Track 1 bis 255 mit Sektor jeweils 0 bis 255 macht 255*256 oder der Wert, den ich vorschlage.


    Quote from Anleitung CMD HD

    Native-Modus-Partitionen besitzen 256 Sektoren pro Spur und können 1 bis 255 Spuren enthalten.

    Nein, letzte Version ist vom 07.06.2020 und wir es wohl zumindest für den C64 auch bleiben.

    Also ist die quasi final. Wie wäre es dann, jene Version in die Wolke hochzuladen?


    Ich bin mir nämlich auch unsicher, ob ich die aktuelle Version habe. Wenn die quasi finale dann in der Wolke wäre, das wäre sicherlich hilfreich.

    Am Beispiel „Learning English, Modern Course 1“ habe ich das mit einer nichtöffentlichen Alpha von g64conv analysiert - hier ein Auszug aus Track 31:


    Man sieht sehr deutlich, dass Track 31 Sektor 10 sehr viel langsamer geschrieben worden ist als der Sektor 9 davor. Bei der Speedzone wäre ein Wert von 4 µs theoretisch optimal.

    Bei Track 2 sind mehr Speedwerte verändert worden - ich führe den für den Kopierschutz relevanten hier auf mit einem Vergleichswert:


    Hier wäre ein Wert von 3,25µs der ideale Wert.


    Sektor 9 hat 3,32µs pro Bit (hier nicht aufgeführt)

    Sektor 10 hat bspw. 3.54µs pro Bit(hier nicht aufgeführt)

    Sektor 11 hat 3,17 µs pro Bit

    Sektor 12 hat 3,17µs pro Bit.

    Sektor 13 dagegen wieder 3,30µs pro Bit (hier nicht aufgeführt) - alles gemessen.


    Edit: Mit g64conv messe ich die Dauer der 10 bzw. 325 Rawbytes. Also nicht die Gaps, sondern nur der eigentliche Block (Block kann dabei Headerblock oder Datenblock sein, daher auch die 2 Größen).

    Das könnte einen Schub für ARM-Windows bedeuten. Parrallels verkündet, eine Apple Silicon Version von Parallels Desktop sei in Arbeit. Da liegt die Vermutung nahe, da könne die ARM-Version von Windows drauf laufen - und diverse ARM Linux. Schauen wir mal, was es wirklich bringt.

    Aber wenn es am C64 nicht geht dann sollte man auch unter VICE den Typ nicht wechseln können. Wenn man es kann, dann sollte es aber auch funktionieren.

    Das Problem ist IMO ein anderes - gerade unter Windows hat man eine UI, wo man Abweichungen vom Standard einstellt. Man wird eher selten per Kommandozzeilenparameter die Laufwerksauswahl machen. Bestenfalls lädt man nachdem VICE gestartet ist per UI eine andere Konfiguration ein - was ähnlich sein sollte wie ein Wechsel, ich aber nicht getestet habe. Denn das ist um Längen komplizierter nachzuverfolgen, was da passiert - es interessiert im Rahmen eines Bugreportes also nicht.

    Dann hast Du ein textuelles g64 statt ein textuelles P64 versucht zu alignen. Ist mir auch schon passiert :-)


    Beim Umwandlen g64 nach txt den Parameter "p64" vergessen oder an der falschen Stelle ist die vermutete Ursache. (Edit: oder "p64" versehentlich groß geschrieben, iirc ist das case-sensitiv).


    Edit 2: Der Geos-Test soll natürlich mehrere Fliegen mit einer Klappr schlagen - zum einen bekommt man so raus, wie viel Unterschied die verwendete 1541/70/71 beim zweiten Teil des Tests macht. Und zum anderen halt, ob es prinzipiell geht.

    https://www.c64copyprotection.com/bounty-bob-strikes-back/ sagt mir, dass das eine der am schwersten zu kopierenden Games ist. Dass da eine Wandlung nach G64 und nach Flux zurück nicht geht, ist kein Wunder... Wenn ich die rare Info dort richtig interpretiere, darf man das auch nicht alignen, weil die Halftrack sauch ausgenutzt werden - synchronisiert zu den Fulltrack.


    Da hast Du nur eine Chance über eine Quelle, die schon Flux ist. Und die vom gw-Autor versprochene Erweiterung, dass wir (wenn g64conv so weit ist) ohne alignen arbeiten können.


    Edit: Kurz: Solange wir alignen müssen als Workaround für ein Problem beim Schreiben, so lange zählt das Ergebnis nicht, weil es nicht gehen kann.

    Interessant wäre mal, die Images aus GEOS 64 und 128 V2.0 GE jungfräulich auszuprobieren. Zum einen, ob diese funktioneiren nach dem Konvertieren und zurückschreiben, zum anderen, ob sich das Symptom aus https://www.pagetable.com/?p=1128 damit reproduzieren lässt. Wie in den Kommentaren angedeutet, lässt sich das Symptom perfekt mit einem Kryoflux reproduzieren - der nutzt aber zusätzlich Mastering Information aus dem per Kryoflux erzeugten G64.


    Edit: Im Moment tu ich mich etwas schwer - auf der einen Seite wäre eine 1-Step-Konvertierung sicherlich nice. Auf der anderen Seite will man evtl. auch noch Halftracks wegwerfen (was in der obigen Anleitung nicht aufgeführt ist, weil das ein anderes Thema ist). Oder man will das als P64 testen (VICE Bugfix wäre dazu hilfreich). Ist alles nicht so einfach, wie es scheint. Oder wie im Moment will man alignen.

    Wenn Du drankommst, irgendwas mit mehreren Speedzones auf einen Track - das wäre das, was mit Zoomfloppy nicht geht und deswegen besonders interessant ist. Allerdings wird man das dann nicht aus einem G64 holen können - in sämtlichen verfügbaren G64 ist jene Info nicht enthalten.

    Eine konkrete Liste von solchen Images suche ich allerdings auch noch..