Laufwerk der 1541 emulieren

WOW... hier gehts aber rund... da sind meine ansprüche ja verschwindend klein...

Ich hatte ja schon mal angefragt ob es eien möglichkeit gibt die Mechanik der 1541 (II) so auszutauschen wie beim amiga mit dem gotek.

Mir persönlich würde das ja schon reichen ( bei der sd2iec lösung gehen manche Spiele nicht stichwort nachladeprogramme und ne ultimate ist mir persönlich zu teuer, da mach ich zu wenig mit den ganzen teilen)

Auserdem finde ich es gut die alten Laufwerke weiterbenutzen zu können, wenn die dazu noch blind weiterlaufen würden nur um den sound zu produzieren wäre das ein traum... aber das nur als spinnerei von mir.

Gruß

Stones

Zitat von stones73

Auserdem finde ich es gut die alten Laufwerke weiterbenutzen zu können, wenn die dazu noch blind weiterlaufen würden nur um den sound zu produzieren wäre das ein traum...

War das nicht der Hauptgrund für dieses Thema? Wer nur eine Emulation will, hat ja inzwischen einige Geräte zur Auswahl. Es ging ja darum, die echte Hardware weiter zu verwenden, ohne sich auf die alten Disketten verlassen zu müssen.
Daß sich so eine Modifikation gut eignet, um perfekte G64-Dateien zu erstellen, ist doch eher nur ein angenehmer Nebeneffekt.

Zitat von LogicDeLuxe

War das nicht der Hauptgrund für dieses Thema? Wer nur eine Emulation will, hat ja inzwischen einige Geräte zur Auswahl. Es ging ja darum, die echte Hardware weiter zu verwenden, ohne sich auf die alten Disketten verlassen zu müssen.Daß sich so eine Modifikation gut eignet, um perfekte G64-Dateien zu erstellen, ist doch eher nur ein angenehmer Nebeneffekt.

Hauptgrund? Nee, nicht für mich.
Also ich bin froh wenn die Mechanik NICHT mitläuft!

Aber das kann ja dann gerne jemand erforschen ...

Mir geht es dabei um:

• Fun bei der Entwicklung
• alte Laufwerke wiederbeleben wo die Mechanik defekt ist.
• Eine preisgünstigere Variante zur 1541u (wobei ich habe zwei u)
• und die ganzen "Nebeneffekte"

Aber ganz was anderes ...

Diese Speed Einstellung, - ist die eigentlich relevant in Bezug auf Kopierschutz?

Eigentlich ändert sich im Grunde ja "nur" die Tracklänge, denn den Takt gibt ja sowieso der Atmega an.

Prüft irgendein Kopierschutz ob der Takt "zu schnell" kommt oder "zu langsam"?
Vermutlich nicht, denn damals war das ja kein Thema, ein Fake Laufwerk zu erkennen.

Wenn man den Takt maximiert, dann funktioniert die Übertragung "schneller".

Das ist gut für Speeder aber schlecht für normalen Zugriff.
Denn der normale Zugriff schafft den Interleave nicht mehr, wenn man "zu schnell" taktet.
Die DOS Software ist einfach nur schlecht, - igitt.

============
Mir schwebt eine modifizierte Version von SpeedDos vor ...

• Der Atmel verhält sich wie ein Laufwerk
• Auf ein Signal hin geht der Atmel in einen "Speed Modus"
• Das Signal sendet der modifizierte SpeedDos Kernel

Ich erwarte mir eine Geschwindigkeit, wie es sonst nur ein Professional-DOS schafft.

Zum Preis eines SD2IEC plus einer defeklten 1541 plus einem Parallelkabel

Zitat von stones73

WOW... hier gehts aber rund... da sind meine ansprüche ja verschwindend klein...

Ich hatte ja schon mal angefragt ob es eien möglichkeit gibt die Mechanik der 1541 (II) so auszutauschen wie beim amiga mit dem gotek.

Deine Ansprüche sind wirklich gering. Das funktioniert jetzt schon so la la. Aber es muss noch sehr viel optimiert werden.

Aber es wird, gut Ding braucht Weile ...

Zitat von Diddl

Eigentlich ändert sich im Grunde ja "nur" die Tracklänge, denn den Takt gibt ja sowieso der Atmega an.

Beim Lesen? Nein, da müssen der Takt des Datenseperators in der Floppy und der Takt des Atmega übereinstimmen sonst wird Müll gelesen. Also musst du schon dafür sorgen, daß der Atmega weiss welcher Takt von der Floppy erwartet wird. Kostet dich 2 Portbits.

Zitat von Diddl

Prüft irgendein Kopierschutz ob der Takt "zu schnell" kommt oder "zu langsam"?

Zumindest was unterschiedliche Geschwindigkeiten auf einer Spur betrifft, scheint dies wohl nicht praxisrelevant zu sein. Ich meine jedenfalls gelesen zu haben, daß die gängigen Emulatoren das nicht unterstützen, und trotzdem keine Kopierschutzprobleme aufgetreten sind, die damit im Zusammenhang stehen könnten.
Wenn die Trackpositionen zueinander abgefragt werden, kann der Takt durchaus relevant sein, aber halt dann immer für die ganze Spur.

Was die Lesbarkeit allgemein angeht, so muß auch das Laufwerk beim Lesen den Takt anpassen. Bei einer Einstellung daneben kann die 1541 in der Regel zwar noch problemlos lesen. Bei einer Abweichung von 2 wird es aber kritisch und Lesefehler sind wahrscheinlich. Sicher spielen da auch Laufwerkstolleranzen eine Rolle. Mit Disk Demon kann das jeder mit seinen eigenen Laufwerken rausfinden, wo da die Toleranzgrenzen liegen.

Zitat von Gerrit

Beim Lesen? Nein, da müssen der Takt des Datenseperators in der Floppy und der Takt des Atmega übereinstimmen sonst wird Müll gelesen. Also musst du schon dafür sorgen, daß der Atmega weiss welcher Takt von der Floppy erwartet wird. Kostet dich 2 Portbits.

Nee, davon bin ich schon lange abgekommen.

Der Atmega gibt den Takt vor und auch die Daten.

Zitat von LogicDeLuxe

Zumindest was unterschiedliche Geschwindigkeiten auf einer Spur betrifft, scheint dies wohl nicht praxisrelevant zu sein. Ich meine jedenfalls gelesen zu haben, daß die gängigen Emulatoren das nicht unterstützen, und trotzdem keine Kopierschutzprobleme aufgetreten sind, die damit im Zusammenhang stehen könnten.Wenn die Trackpositionen zueinander abgefragt werden, kann der Takt durchaus relevant sein, aber halt dann immer für die ganze Spur.

Ah danke, gut zu wissen

Zitat von Diddl

Diese Speed Einstellung, - ist die eigentlich relevant in Bezug auf Kopierschutz?

Beim Lesen bestimmt sie wie schnell vom Laufwerk "Byte Ready" kommt. Außerdem, wie lange das Laufwerk ein "0" Bit liest, solange kein Flusswechsel vom Lesekopf kommt. Das können ja maximal 2 mal 0 in Folge sein, dann kommt 1.
Das ganze interessiert Dich also nur, wenn Du ein Datenformat als Input hast, bei dem nicht fertig codierte GCR Bytes drin sind, sondern die Flusswechsel und die Tracklänge. Dann würde nämlich abhängig von der eingestellten Speedzone und der Drehgeschwindigkeit ein möglicherweise verschiedenes Gcr Muster pro Umlauf entstehen können (falls da gar keine Flusswechsel im Track sind oder eben künstlich oft 0). Aber wie schon gesagt wurde: Sowas ist vermutlich nie als Kopierschutz verwendet worden.

Zitat von Diddl

Der Atmega gibt den Takt vor und auch die Daten.

Dann musst du aber deutlich mehr in der Floppy umbauen als dich nur zwischen Gate Array und VIA hängen.

Zitat von Gerrit

Dann musst du aber deutlich mehr in der Floppy umbauen als dich nur zwischen Gate Array und VIA hängen.

Wieso muss man da mehr umbauen? Beim Lesen kommt der Takt übers Gate Array von der Diskette (je nachdem wie schnell das Laufwerk eingestellt ist und auf welcher Spur man sich befindet). Dann liefert der Atmega die Daten direkt an den VIA und somit gibt er den Takt vor. Beim Schreiben auf Diskette wird der Takt vom Gate Array generiert, je nachdem welche Zone über den VIA ausgewählt ist und dies kann nun auch der Atmega übernehmen. Die verschiedenen Speedzonen sollten sich über dem Timer vom Atmega gut regeln lassen.

Ja das sehe ich genau so wie @zschunky

Was die Speedzonen angeht, klar kann man das sehr easy mit dem Timer des Atmega regeln.
Das war nicht meine Frage.

Die Frage ist, ob es denn relevant ist?

Für die 6502 ist es kaum feststellbar, ob der Takt passt.
Die CPU wartet sowieso nur ständig auf SYNC oder BYTEREADY.

Außer jemand misst "absichtlich" die Zeit zwischen zwei Bytes!
Wenn kein Kopierschutz das tut, dann kann man genauso immer mit schnellem Takt fahren.

Nur die Tracklänge, die ist variabel.
Und das ist auch nur relevant beim formatieren einer Spur ...

Zitat von Diddl

Die Frage ist, ob es denn relevant ist?

Ich denke schon dass evt. einige Speed-Loader auf diesen Zonen aufsetzen. Es gibt einige Speedloader, die sich nicht auf jeden byte-ready syncronisieren und falls hier unterschiedliche Implementierungen von (Anzahl Zyklen im Code) pro Zone verwendet werden, könnte es ein Timing-Problem geben.

Zitat von Diddl

Wenn kein Kopierschutz das tut, dann kann man genauso immer mit schnellem Takt fahren.

Es gibt Kopierschütze, wo die Länge der Syncmarken gemessen wird. Da muß der Takt dann schon stimmen.
Verzichtbar ist es erfahrungsgemäß lediglich, innerhalb einer Spur den Takt umzuschalten.

Edit: praktischerweise hier schön dokumentiert: http://c64preservation.com/dp.php?pg=rapidlok

Zitat von zschunky

Ich denke schon dass evt. einige Speed-Loader auf diesen Zonen aufsetzen. Es gibt einige Speedloader, die sich nicht auf jeden byte-ready syncronisieren und falls hier unterschiedliche Implementierungen von (Anzahl Zyklen im Code) pro Zone verwendet werden, könnte es ein Timing-Problem geben.

Beim Lesen bestimmen die Speedzonen wirklich nur wie lange kein Flusswechsel auftreten darf um eine "0" ins Schieberegister zu schieben. "0" wird ja durch das Ausbleiben des Wechsels auf der Diskette realisiert. Sobald ein Flusswechsel kommt, wird sowieso eine "1" reingeschoben und der 74LS193 der den Takt für die Speedzonen realisiert wird neu geladen. Also so lange ein "Speedloader" gültigen GCR Code von der Diskette lädt, werden die Speedzonen beim Lesen keine praktische Rolle spielen. Da wird immer das selbe gelesen werden. Damit kann der Atmel den Lesetakt einfach aus der Tracklänge bestimmen. Die Anzahl und der Takt des Byte Ready wird nur durch die Datendichte auf dem Track bestimmt.

Anders sieht es eben aus, wenn da kein gültiger GCR Code auf dem Track ist, nämlich wenn zu lange kein Flusswechsel kommt ...nur dann hängt das Ergebnis theoretisch von den Speedzonen und vom Gleichlauf des Laufwerks ab.

Zitat von Diddl

lesen eines G64 Image File auf der SD Karte und schreiben aller 84 Halbspuren in 22 Sekunden (bitgenau)

Das würde ich gerne mal in einer realen Umsetzung sehen.

Zitat

Das schreiben von G64 kann perfekt gemacht werden, und in maximaler Geschwindigkeit (was die Mechanik her gibt).

Das lesen ist schwieriger, denn wenn die Freuqenz non standard ist, oder gar mitten im track geändert wird, - das ist kaum perfekt zu schaffen. Außer wenn zumindest der Blockaufbau standard ist. Dann kann man es durch probieren raus kriegen.

Nö, genau umgekehrt - Lesen ist einfach, Schreiben ist schwierig. Wie gehst du damit um, dass die zeitliche Länge der Daten in der G64-Datei nicht bis aufs letzte Bit exakt zu der Zeit passt, in der die Diskette eine Rotation ausführt? Schon die normale Formatierroutine der 1541 misst erstmal aus, wie viele Daten in eine Spur passen bevor die leeren Sektoren geschrieben werden, damit sie die Gaps zwischen den Sektoren gleichmässig lang machen kann!

Die Leserichtung ist dagegen simpel, man muss lediglich die Zeiten zwischen zwei Pegelwechseln auf der Leseleitung (d.h. hinter dem ganzen Analogzeugs, aber vor der Seriell-Parallel-Wandlung für den VIA-Port) mit ausreichender Auflösung ausmessen und kann damit ohne Rumprobieren beliebige Speed-Änderungen erfassen.

Zitat von Unseen

Nö, genau umgekehrt - Lesen ist einfach, Schreiben ist schwierig. Wie gehst du damit um, dass die zeitliche Länge der Daten in der G64-Datei nicht bis aufs letzte Bit exakt zu der Zeit passt, in der die Diskette eine Rotation ausführt? Schon die normale Formatierroutine der 1541 misst erstmal aus, wie viele Daten in eine Spur passen bevor die leeren Sektoren geschrieben werden, damit sie die Gaps zwischen den Sektoren gleichmässig lang machen kann!

Das Schreiben benutzt ja die "alte" Schreibelektronik. Insofern habe ich auf den Takt ja kaum Einfluss, wenn man von der Speedzone absieht.
Die Speedzone ist ja aus dem G64 vorgegeben, die kann auch theoretisch nach jedem Byte wechseln.

Der Track muss gar nicht exakt auf die Disketten Spur passen???

Der Track darf nur niemals "zu lang" sein.

Ist er zu kurz, füllt man den Rest mit FF

Ist er zu lange, dann geht es gar nicht, außer man macht es wie früher: man regelt die Geschwindigkeit des Drive Motor etwas höher.

Sollte sich wirklich ein Kopierschutz um die Anzahl FF am Ende des Track scheren, dann hilft nur (so wie früher) die Geschwindigkeit des Drive Motor zu drosseln.

Schön wäre natürlich, wenn man die Frequenz frei bestimmen könnte und zusätzlich ein Indexloch da wäre.

Zitat von Diddl

Der Track muss gar nicht exakt auf die Disketten Spur passen???

Wenn man auf Kompatibilität zu einigen Kopierschutzverfahren verzichtet stimmt das natürlich.

Zitat

Ist er zu kurz, füllt man den Rest mit FF

Kopierschutz durchgefallen: Zusätzlicher Sync auf der Spur oder unerwartetes Gap-Byte (GEOS!) oder falsche Länge des Sync-Pulses.

So ein Teensy++ v2.0 ist schon ein schönes Stück Hardware. Es ist gerade mal so groß wie der VIA und kann mit ganz kurzen Verbindungen direkt huckepack auf dem VIA liegen. Es dürfte die günstigste Variante sein mit gerade mal 14€.

Das super schnelle USB überträgt eine ganze Spur noch bevor der Schrittmotor fertig ist.

Leider ist der SRAM etwas mager. Die SD Karte wird sich nicht ausgehen, wenn man den ganzen Trackbuffer haben möchte. Aber als Lösung mit einem PC als G64 "Server" ist es schon super genial. Und zum "mithören" was die Floppy gerade so macht, ist es ebenfalls eine schöne Lösung.