Posts by GenerationCBM

    Hat jemand eine Idee, aus welchem Programm das stammen könnte?

    Ohne jetzt jedes bisschen Firmware was man so hat gecheckt zu haben: die Bytesequenz findet sich z.B. in den Drive ROMs für die CMD FD-2000/4000er. Ebenso in vielen (allen?) Jiffydos-Kernals (wohlgemerkt Kernal, nicht Drives).


    Edit: Ebenso in ROMs für SuperCPU und RamLink, sowie in CMD-relevanten Disketten-Images mit CMD-Tools drauf (CMD Utilities, FD Utilities, HD Utilities und dergleichen).

    Wenn man es richtig (R)(TM) für diesen Use-Case vorgesehen macht, eigentlich schon. Der Insert-Disk-Code muss dann per Kreiseln um File-not-found den Diskwechsel korrekt erkennen.
    Und natürlich muss vom Loader die normale Directory benutzt werden, so dass man dann per Filecopy alle Dateien von .d64 nach .d71 (oder .d81) kopieren kann (die 1571 kann ja nicht einfach die Rückseite lesen, wenn sie als Vorderseite formatiert wurde, weil die Drehrichtung dann nicht stimmt und auch die Spurlage verschoben ist).

    So sieht's aus, richtig. Kurz und gut, wenn ein Stück Software von vornherein absichtlich oder unabsichtlich so gebaut ist, dass die Inhalte auch auf einer Seite existieren können und die Erkennung "Auffinden versus Seitenwechsel" gehandhabt wird, dann geht sowas. Ist das nicht der Fall, muss man an die Innereien ran.


    Die Frage kommt ja hin und wieder mal, so vulgo: kann man zwei D64 zusammenschrauben so dass ein D71 draus wird (geht natürlich nie) oder kann man die Inhalte zweier D64 in ein D71 rüberkopieren (geht unter sehr bestimmten Voraussetzungen, meistens aber nicht).

    Auf ein kurzen sync folgt ein GCR 0a und dann b2 bytes. Die b2 bytes füllen die gesamte restlichen Spur.

    Jein, der Drivecode sucht explizit nach $ac als Signaturbyte bzw. einer Folge davon, also 10 10 11 00 over and over.



    $0a ist 10 10 und $b2 ist 10 11 00 10, also dasselbe in grün.

    Dort fehlt jeweils ein Bit bzw. ist eines zuviel.

    Das meinte ich mit "gehustet", das Bitmuster kommt dadurch aus dem Takt. Ohne die Bits jetzt gezählt zu haben sind es trotzdem reichlich lange Folgen von $ac-Bytes, daher dennoch interessant zu sehen dass es Floppykernals gibt, die das nicht mitmachen und check fail zurückgeben - oder vielleicht auch grundsätzlich nicht mit Tracks jenseits 40 arbeiten wollen.

    Nun wäre es natürlich noch interessant zu ergründen, warum welches Image wo läuft und warum nicht. Die beiden geposteten unterscheiden sich nicht so sehr gravierend. Das PP-Image hat einen nicht weiter nötigen unformatierten Track 36 und einen leicht unrund gehusteten Track 41, in dem dennoch jedes Laufwerk (bzw. Laufwerk-Kernal) das nötige Bitmuster auffinden können sollte. Das andere Image hat keinen Track 36 und ein so dermassen homogen flaches Bitmuster in Track 41, dass man fast meinen könnte, er sei manuell so drangeflanscht worden. Stellt sich die Frage ob alternative Kernals mit diesen Bitmuster-Unterschieden Probleme haben (Timing?), oder grundsätzlich mit dem Zugriff auf Tracks jenseits 40.

    1571 (Knebel, gibt´s die auch als Garage?

    Nein.


    Und weil ich keine Ahnung habe: kann man die zwei Seiten .d64 eigentlich auch als .d71 umfummeln, so dass zweiseitige Dingens automatisch fortgesetzt werden ?

    Nicht ohne grossen Aufwand (also nicht "einfach so" zusammenkopieren). Jede Art von Diskettenwechsel-Logik oder -Prompt in der Software selbst müsste manuell rausgebaut werden. Das gilt eigentlich so gut wie immer.

    EDIT: ich glaube die originalen NT haben auch ihre Grenzen. Wenn ich mich recht entsinne kann glaube ich die REU zB schon das NT überfordern -- kann das sein?

    Zumindest hatte ich über die Jahre immer wieder gelesen, dass die für den C64 gedachte REU 1764 mit einem eigenen C64-Netzteil geliefert wurde, weil das originale Netzteil zu schwach ist. Ich nehme aber an, dass es sich dabei um das Netzteil handelt, welches üblicherweise auch beim C64C mitgeliefert wurde.

    Das mitgelieferte neue 1764-Netzteil für den C64 entsprach dem "normalen" C128-Netzteil (bis auf den Stecker).

    Wie stelle ich eigentlich bei winvice 3.8 dolphindos2 ein ?

    Indem du in den ROM-Settings die DolphinDos-ROMs für Kernal und Laufwerk einträgst anstatt die Original-ROMs zu verwenden.


    Hast Du noch mehr gepatchte (.d64) Games ?

    Also, das habe ich eben schnell von Hand gebaut, insofern... ja sicher, alles was ich patche, habe ich so... So einige Leute hier im Forum machen das ja gemeinhin ebenfalls bedarfsweise.

    Allerdings hast du immer betont, dass du Originale zurückschreiben willst, und das ist natürlich nicht mehr original, sondern ein Crack. Wenn auch ein minimalistischer (in diesem Fall nur zwei Bytes).


    ROBB

    Sakrileg!

    Gibt es eigentlich irgendwo einen gesammelten Überblick mit vergangenen Competitions, damit man sehen kann was schonmal gelaufen ist (drüben im Wiki oder so)? Nicht unbedingt alle Results, aber zumindest die Spiele?

    in Track 18, Sektor 0 werden auf eine mögliche "Geheimnachricht" durchforstet. Ist das ein reales Phänomen?

    Ja das wurde zum Teil genutzt. In meinen frühen Tagen haben wir dort unsere Mail swapping Adresse "versteckt", mit Hinweis im Intro ".... read the BAM...".

    Ist auch garnicht soo selten, und natürlich findet man das auch heute beim Einlesen alles wieder. Manche (moderne) Image Tools können nach sowas scannen.

    Bin somit nicht sicher ob an der Timing Theorie mit dem 8701 was dran ist?

    Doch doch, da ist schon was dran. :) Dass eines klaglos auf 469er-Boards läuft ist mindestens schonmal ungewöhnlich, aber bei den Dingern wundert mich inzwischen nicht mehr wirklich was. Weil früher niemand so wirklich wusste warum sie so zickig sind und an "neueren" C64 kaum überhaupt funktionieren wollen, hielt sich immer hartneckig die These, es läge an der VIC-II Version oder Revision oder Baujahr, aber das ist es wohl nicht. Der Clock Chip scheint viel kritischer, nach allem was man so sagen kann.

    In meinem Fall sieht es aber eher so aus als wenn das eine Cartridge tatsächlich einen Defekt hätte.

    Klar, kann natürlich auch absolut sein.

    Falls es noch weitere Quellen mit Sources für den C64 gibt, kann man diese hier ja im Thread sammeln.

    Geht es dabei primär/nur um originale Sources von jeweiligen Entwicklern, oder auch um Rekonstruiertes, Disassemblies, Reengineering, etc.?