last post from Stephan Scheuer at the
Upgrade einer 1541 Disk
- muffi
- Thread is Unresolved
-
Dann haben wir hier also zusammen mehr Zeit zum Dinge ins Forum tippen gebraucht, als das Erweitern einer Disk mit herkömmlichen Methoden dauert.
-
...oder aber der Jagdinstinkt ist geweckt
Ich hab halt von der 1571-Programmierung überhaupt keine Ahnung, sonst wäre das mal interessant, das zu probieren. -
Dann haben wir hier also zusammen mehr Zeit zum Dinge ins Forum tippen gebraucht, als das Erweitern einer Disk mit herkömmlichen Methoden dauert.
...und ich hatte beim Mitlesen mit dieser Erkenntnis bereits gerungen
-
So ein "1541-Disk-auf-1571-Format-erweitern"-Programm steht schon seit Ewigkeiten auf meiner "irgendwann schreib ich das mal"-Liste.
Es ist tatsächlich auch nicht weiter schwierig, im DOS-ROM ist der Code ja eh schon vorhanden, man muss nur einen Teil davon extrahieren.
Leider kann man nicht einfach per Memory-Execute-Befehl die richtige (Teil-)Unterroutine aufrufen, denn im 1571-DOS stehen immer nur "komplette" Routinen:
Die 1541-Format-Routine formatiert die erste Diskseite und schreibt dann BAM und Dir.
Die 1571-Format-Routine formatiert die erste Diskseite, dann die zweite, dann schreibt sie BAM und Dir. Das Formatieren der zweiten Seite ist keine separat aufrufbare Unterroutine - und wenn man mitten in die Routine hineinspringt, werden am Ende BAM und Dir überschrieben, was man nicht haben will.
-
Es ist tatsächlich auch nicht weiter schwierig, im DOS-ROM ist der Code ja eh schon vorhanden, man muss nur einen Teil davon extrahieren.
Leider kann man nicht einfach per Memory-Execute-Befehl die richtige (Teil-)Unterroutine aufrufen, denn im 1571-DOS stehen immer nur "komplette" Routinen
Das ist beim Speichern auch so.
Der übliche Weg ist, etwas eigenen Code per M-W/M-E im Laufwerk laufen zu lassen, der dann die relevanten ROM-Routinen ins RAM kopiert und so modifiziert, dass er sie einzeln aufrufen kann.
-
Bist Du Dir sicher, 8 (acht) Spuren, das wären ja über 20%, das klingt mir schon brutal viel ?!?
Sind natürlich Halbspuren. Aber ich frage mich schon lange, warum das überhaupt gemacht wird. Verschenkt man da nicht den besten Bereich am äußeren Rand?
Wenn ich in einer 1541 eine Diskette herumdrehe und formatiere, dann ändert sich doch auch die Richtung in der sie sich ursprünglich dreht im Gegensatz zur einer Disketten die in einer 1571 beidseitig formatiert und dabei eben nicht gedreht wird - oder bin ich da gerade auf dem falschen Dampfer ?
Grundsätzlich sollte es kein Problem sein, ein Programm zu schreiben, welches rückwärts formatiert. Aber wozu, wenn man ohnehin vor hat, eine 1571 zu verwenden?
-
Grundsätzlich sollte es kein Problem sein, ein Programm zu schreiben, welches rückwärts formatiert. Aber wozu, wenn man ohnehin vor hat, eine 1571 zu verwenden?
Ist eigentlich off-topic.
Aber rückwärts zu formatieren/schreiben und das dann fehlerfrei vorwärts zu lesen... klingt jetzt nicht sehr zuverlässig oder trivial.
-
Verschenkt man da nicht den besten Bereich am äußeren Rand?
Ich bin der Meinung, dass das zwei Gründe hat:
1) Kopf direkt über Kopf, das würde zu gegenseitiger elektromagnetischer Beeinflussung führen
2) Spur 0 auf Seite A enthält bei den meisten Betriebssystemen der damaligen Zeit den Urlader, Bootsektor, MBR oder wie man es nennen möchte. Daher macht es Sinn, davon etwas Abstand zu halten, ob es so viel Abstand braucht, das sei dahingestellt, aber man wollte vermutlich auf Nummer sicher gehen...
Platzverlust: NEIN, oder "Jein", bestenfalls indirekt, wenn man extrem weit aussen anfängt, könnte man vielleicht mehr als 40 Spuren rausquetschen, aber man kann zwar (wie es Commodore und Apple ja auch machten) mit variabler Sektoranzahl den Vorteil weit aussen nutzen, aber man kann NICHT dichter schreiben, sprich Viertelspuren etc. Insofern ist es aber nur ein fixes "delta", um das es sich nach innen verschiebt und sowohl C= als auch die Apfel-Fraktion hatten ja eh nur wenige Abstufungen, d.h. um die paar Spuren ganz aussen voll auszunutzen, hätte es einer feineren Abstufung bedurft...
-
Aber rückwärts zu formatieren/schreiben und das dann fehlerfrei vorwärts zu lesen... klingt jetzt nicht sehr zuverlässig oder trivial.
Klar. Formatieren ist eine Sache. Beim Lesen werden dann natürlich schon ganz andere Ansprüche gestellt. Dazu müßte man erstmal den ganzen Sektor durchnibbeln und dann rückwärts per Software das Sync-Ende suchen. Das würde zu Datenrettungszwecke, wenn keine 1571 oder andere geeignete Hardware zur Hand ist, durchaus Sinn machen.
aber man kann zwar (wie es Commodore und Apple ja auch machten) mit variabler Sektoranzahl den Vorteil weit aussen nutzen
Müßte man dann nicht streng genommen auch die Speedzones um 4 Spuren verschieben?
-
Müßte man dann nicht streng genommen auch die Speedzones um 4 Spuren verschieben?
Die Äussere müsste eigentlich um 4 Spuren kleiner ausfallen, deshalb mein "Jein" oben zu der Frage, ob da Speicherplatz verloren geht.
In Wirklichkeit wurde aber genügend Platz zw. Ende letzten Sektor und Spuranfang gelassen, dieser Platz schrumpft halt ein wenig und die Floppy-SW braucht (aufgrund des engeren Timings dann) eventuell mal ne Umdrehung mehr, bis die den Spuranfang korrekt findet...
-
Aber rückwärts zu formatieren/schreiben und das dann fehlerfrei vorwärts zu lesen... klingt jetzt nicht sehr zuverlässig oder trivial.
Klar. Formatieren ist eine Sache. Beim Lesen werden dann natürlich schon ganz andere Ansprüche gestellt. Dazu müßte man erstmal den ganzen Sektor durchnibbeln und dann rückwärts per Software das Sync-Ende suchen. Das würde zu Datenrettungszwecke, wenn keine 1571 oder andere geeignete Hardware zur Hand ist, durchaus Sinn machen.
Klar, Formatieren und Schreiben, ohne es jemals wieder zurückzulesen, ist natürlich trivial. Wie ein Packer, der ALLES kleiner macht, aber für den kein funktionierender Depacker exisitert.
-
Nene, eine 1571 hat auf der Unterseite die Tracks 1-35, auf der Oberseite die Tracks 36-70 (übrigens: lese mal das Dir einer 1571-formatierten Disk in einer 1541 - am besten leer. 664 Blocks free). Im Prinzip braucht man halt ein Tool, dass nur die 2. Seite formatiert und die BAM anpasst. Aber ob das wirklich so einfach ist?
Ja, ist es. Ich habe das dieses Jahr mal mit D64 nach D71 Umwandlung gemacht. Funktioniert einwandfrei. Bei echter Hardware statt Images macht man im Prinzip ja das selbe:
1) Image vergrößern wird einfach zu Rückseite formatieren mit dem zweiten Schreib-/Lesekopf.
2) BAM anpassen - kann unverändert übernommen werden.
Auf Imageebene kann g64conv das - müsste nachschauen, ob nur im aktuellen Snapshot oder auch im aktuellen Release.
Das Standardokument (ECMA-70) schreibt lustigerweise im Text ausdrücklich "8 tracks", aber beim Nachrechnen komme ich auf vier Spuren Unterschied. Möglicherweise hat damals jemand das Dokument für 96 tpi (80 Spuren) genommen und beim Umschreiben für 48tpi zwar die Formel, aber nicht den Text angepasst.
Deine Interpretation passt schon: Mit einer PC HD Floppy und GreaseWeazle/Kryoflux sehe ich im Dump tatsächlich den Versatz von 8 Tracks, die man im Commodoreumfeld aber 8 Halftracks nennt. Und 8 Halftracks sind halt 4 Commodore-Tracks.
-
2) BAM anpassen - kann unverändert übernommen werden.
Das Flag für zweiseitig sollte auf der Vorderseite aber schon gesetzt werden.
-
Verschenkt man da nicht den besten Bereich am äußeren Rand?
Ja, tut man. Ich habe ja eine umgebaute PC Floppy, welche den Kopf bis auf Track -8 bewegen kann. Wenn ich das mache, kann ich problemlos die Tracks -8 bis 83 beschreiben, also 89 Tracks. Was zeigt, das man hätte mehr nutzen können von der Diskette.
Und auf einer Commodorediskette kommt fast der gesamte Range vor: 0 bis 39 für eine Vorderseite mit 40 Tracks (das schaffen einige 1541) dowie -8 bis 71 wenn man die Rückseit der Diskette liest, ohne diese umzudrehen. Zusammen macht das schon fast den gesamten Bereich, den meine PC Floppy anfahren kann. Wenn man bedenkt, dass eine 1541 auch onch über Track 40 hinaus kann, dann kommt da noch etwas drauf.
Es stellt sich heraus, dass man auch auf der Vorderseite die Tracks -8 bis -1 beschreiben kann, nur kann eine normale Floppy die so egschriebenen Tracks nicht erreichen. Da könnte der Hersteller der Disk ein Watermark aufbringen und sich für damalige Verhältnisse sicher sein, dass er daran das echte Original ziemlich treffsicher maschinell erkennen kann - selbst wenn die Diskette überformatiert ist.
Allerdings wollte man mit dem Versatz wohl konkrete Probleme lösen (welche, darüber gibt es hier im Forum ja Vermutungen). Aber für einseitige Laufwerke verschenkt man da wirklich was...
-
Das Flag für zweiseitig sollte auf der Vorderseite aber schon gesetzt werden.
Ach was, da haben wir aneinander vorbei getredet. Nicht die BAM unverändert lassen, sondern die Änderungen, die an der BAM im Image vorgenommen werden durch g64conv so wie sie sind vom C64 schreiben lassen.
-
Ich weiß, Perl kann nicht jeder lesen, aber hier ist das, was am Image geschrieben werden muss - abgesehen von der Vergrößerung:
-
Ich habe das gerade mal Quergelesen und vielleicht wurde ähnliches schon geschrieben. Aber wäre es nicht viel sinnvoller, statt viel Zeit und Gehirnschmalz in so eine Sonderlösung zu stecken, stattdessen ein universelles Kopierprogramm zu schreiben, mit dem man zuverlässig alle Dateien von einem Format auf ein anderes kopieren kann kann (also z.B. inkl. REL-Dateien). Das würde dann nicht nur für 1541 und 1571 funktionieren, sondern für alle Floppyformate.
Mir ist der Anwendungszweck für diese 1541 nach 1571 Erweiterung nicht klar. Wer wird denn in großem Stil 1541 Disketten nach 1571 kopieren wollen?
Das braucht doch kein Mensch. Und wenn, dann will man die doch neu zusammenstellen und nicht einen ganzen Stapel halbleerer Disketten.
-
Wenn das so ein Problem ist mit Köpfen auf gleicher Höhe, hätte man die dann nicht auch seitlich versetzen können?
