Posts by Uridium

    Scheint schon gar nicht die Initialisierungsphase zu schaffen. Vermutlich stimmt was mit den Abhängigkeiten nicht. Irgendeine Bibliothek fehlt, hat die falsche Version, befindet sich an der falschen Stelle oder ähnliches. Normalerweise würde man jetzt kurz einen Debugger wie radare2 ansetzen, um irgendwie Output zu kriegen, aber das geht hier wahrscheinlich zu weit. Vielleicht ist das auch genau das Problem, weshalb die offizielle Version derzeit gestoppt wurde.

    vermutlich möglich, aber sinnlos

    Als Uhr vielleicht. Aber als Systemmonitor (ähnlich Conky) könnte man ja auch sinnvolle Dinge darstellen, wie Visualisierung des SID, Ableiten der CPU Auslastung, Taktgeber, Bitflags, IRQs, Diagnosegeschichten oder ein buntes Patchfeld., dass relevante Speicherzellen farbig repräsentiert. Keine Ahnung, was man da raus holen könnte. Ein permanentes Overlay, das Systeminformationen in Echtzeit anzeigt finde ich durchaus spannend.

    Gab ja mehrere Laufwerke wie z.B. NEC, TEAC oder Chinon mit unterschiedlichen Köpfen. Wenn das eine Laufwerk die Bits bei einer schwachen Diskette noch mal kippen kann, heißt das nicht automatisch, dass das andere Laufwerk das auch kann. Wenn ein starkes Laufwerk bereits alle Bits auf 0 gesetzt hat (Formatierung), sieht das für das schwache Laufwerk (bei erneuter Formatierung) so aus als hätte es die Bits selbst auf 0 gesetzt, was aber nicht der Fall ist. Erst beim nächsten Schreibvorgang, wenn sich die Daten von der Formatierung unterscheiden, wird sich herausstellen, ob das Laufwerk wirklich in der Lage ist die Bits zu kippen, bzw. die Diskette zu beschreiben. Und selbst das könnte sogar noch einmal gut gehen, wenn sich die Bits evtl. in eine Richtung leichter magnetisieren lassen als in die andere.

    Wo kommt das denn her, bzw. wo kann mehr darüber erfahren? Offiziell scheint das nicht zu sein. Zumindest behaupten das einige Seiten, die bewusst nur offizielle Versionen katalogisieren (wie hier).


    Edit: Wobei... hier sieht das schon ganz anders aus. Danke für das 'Xcopy TNG' Kongo-Otto.


    ich hatte dd- Disketten die kein Amiga mehr zum Formatieren angenommen hat.

    Keine Ahnung. Nach meinem Verständnis müsste das Laufwerk alle DD Disketten fressen können, egal was da drauf ist. Vielleicht hat das PC Laufwerk die Oberfläche sauber geschliffen oder ähnliches. Vielleicht waren das auch keine "richtigen" DD Disketten. HD Disketten hatten neben der höheren Partikeldichte auch noch Änderungen wie andere Oberflächenbeschichtung und Materialstärke. Die haben glaube ich geglänzt, während die DD Disketten eher matt waren. Kann gut sein, dass gewisse Hersteller da einfach mal HD Disketten als DD umgelabelt haben. Später wurden die DD Disketten aufgrund der gefallenen Nachfrage bestimmt teurer/seltener als HD.

    Bei NG- Copy dauert das Formatieren und gleichzeitige verifizieren mit einem Laufwerk 1:25min. Mit zwei Laufwerken 2:45min.

    Im Emulator: X-Copy, 3x Laufwerke, Format/Verify: A500 = 5:54min, A4000(68040) = 5:51min. Also kein CPU Bottleneck. Der Amiga kann wahrscheinlich immer nur ein Laufwerk gleichzeitig ansprechen. Vielleicht braucht es aber auch spezielle OS Funktionen (>Kick13), die das X-Copy nicht beherrscht. Was ist denn NG-Copy? Google ist da sehr zurückhaltend.

    auf die ich gleich zugreifen kann.

    Trugschluss. Du kannst nur die beschriebenen Daten überprüfen, nicht die Diskette. Gesunde Daten (Formatierung) bedeutet nicht gleich gesunde Diskette. Ein schwaches Bit-0 ist beim Formatieren immer noch 0 und korrekt. Beim nächsten Bespielen, wenn es auf 1 gesetzt werden soll, aber nicht mehr. Das heißt, die ganze Formatiererei bringt dir genau gar nichts. Verify bedeutet nur, dass das Bit den gewünschten Wert hat. Es sagt nichts darüber aus, ob es noch in der Lage ist seinen Zustand zu ändern.

    Eine Sehr gute Methode die vor allem Zeitsparend ist und das lästige vorhergehende Vorformartieren nicht mehr erfordert.Ich habe in kurzer Zeit gut ein Dutzend io - Disketten und kann diese Methode empfehlen wenn es mal auf die schnelle gehen muss.

    Wenn das ADF das final verweilende Zielimage darstellt, macht das Sinn. Wenn Du aber direkt danach andere Daten aufspielen willst (und diesen Vorgang nur als Überprüfungsmethode genutzt hast), ist das genau der gleiche Unfug wie Vorformatieren.

    Das Eine schließt das Andere nicht aus. Wenn ich aber beim Beschreiben keine Möglichkeit der Verifizierung habe (z.B. filecopy im CLI, Speicherstände, Tools ohne Verify, usw), bietet sich als Integritätsprüfung ein Kopier- oder Lesevorgang an. Und der kann auch in /dev/null landen.


    Edit: Unter "ins Ram kopieren lassen" meinte ich sämtliche Vorgänge unter X-Copy, die die Disk einfach einmal auslesen.

    "Formatieren -> Verify -> Beschreiben" bringt nichts.
    Eher so:
    "Beschreiben -> Verify"


    Verify heißt ja nichts anderes als dass man es einmal ausliest. Und das kann man z.B. auch mit X-Copy machen, indem man es einmal ins RAM kopieren lässt.
    Vorher formatieren muss man grundsätzlich nicht, wenn man Disketten (sektoriell/raw) kopieren oder ADF Images schreiben möchte (die Formatierungsdaten stecken da ja schon drin).

    Damit ist es "4E" und "AD". Die innere Prüfsumme 2221 stimmt. Die Äußere weiß ich nicht, ggf. übergehen.


    Ich habe die beiden Programmteile zusammengefasst (unten angehängt).

    Quote

    John Conway's Game of Life. Cells either thrive or die depending on the number of neighbours they have.
    Controls:
    Follow on-screen prompts. Press 1 to set the cells (* to set, Space to erase, Crsr keys to move, R to return to menu), then press 3 to watch them evolve (F7 to return to menu).

    Files

    • life-vc20.zip

      (4.83 kB, downloaded 9 times, last: )