Laufwerk der 1541 emulieren

Super, dass ihr Euch so kümmert. Danke

Zitat von kinzi

root42 Das mit den zwei BINs abhängig von der Hatrdware ist ja gar kein Problem, wird beim SD2IEC ja auch so gemacht. Wäre die beste und flexibelste Idee

Was? Wie? Wo? Warum bin ich jetzt hier drin? Aber sieht spannend aus da Projekt!

Zitat von root42

Was? Wie? Wo? Warum bin ich jetzt hier drin? Aber sieht spannend aus da Projekt!

Argh ... fook42 != root42 ...

Was müsst ihr euch auch so ähnliche Nicknames überlegen.

Meine restlichen 1.4.2er Platinen (mit I2C-Support) gehen an:

- Thorsten Kattanek (klar, wer wenn nicht er sollte eine bekommen)

- greg64

- znarF

könnt ihr beiden mir noch eure Adressen per PM hier schicken?

mehr hab ich leider nicht.

Dann werde ich mal weiter geduldign warten bis di Firmware fertig ist... Danke schonmal an Thorsten und fook42.

Wäre es evtl. auch möglich da mal einen Bootloader einzubauen um das firmwareupdate für die zukunft einfacher zu gestalten? Ich hab mir zwar schon so nen Programierer zugelegt aber noch nie in Benutzung gehabt.. damit muss ich mich dann auch mal beschäftigen.

Auf alle fälle ist das bisher richtig gute arbeit und hat bei mir 2 Floppies vor dem nutzloswerden bewahrt.

Danke und Gruß

so.

heute mal was neues zum D64-Schreibsupport:

ich hatte mir die vorhandenen Routinen etwas näher angeschaut und versucht zu verstehen, warum einzelne Tracks durchaus schreibbar sein können im D64.. aber z.B. ein Format einer Diskette dann nicht zu einem gültigen D64 führt.

1. Ansatz: verstehen, warum gehts im G64 format?

-> G64 ist ja nichts anderes, als GCR-codierte Rohdaten direkt vom Laufwerk auf die SD-Karte in die Datei geschrieben, wobei je nach Track ein bestimmter Bereich/Offset benutzt wird.

Hierbei ist es aber wichtig zu verstehen, dass die Daten beim Ablegen nicht weiter verändert/korrigiert oder anderweitig bearbeitet werden.. was da reinkommt, geht auch so 1:1 in die G64-Datei. Das Laufwerk (bzw. die CPU des Laufwerks) erzeugt dabei Header-Informationen und Füllbytes in diesem Datenstrom - so wie es auch für die "echte" Diskette nötig ist um genau 1 Umlauf der Scheibe vollzuschreiben.

2. D64 benutzt ein strukturiertes Format für die einzelnen Tracks.

Nicht nur, dass die GCR-Daten konvertiert werden müssen (aus 5Bit mach 4), sondern hierbei ist auch festgelegt, dass ein Block genau 256 Bytes lang ist und die Blöcke auch schön aufsteigend entsprechend ihrer SektorenNummer abgespeichert sein müssen - ist auch klar, da die Sektor- und TrackNummern ja im Gegensatz zu G64 nicht in einem Header gespeichert werden.

Hier haben wir nun den Salat; nach Analyse der geschriebenen G64-Daten aus dem 1541-rebuild, kann man sehen, dass die Sektoren garnicht der Reihe nach im Puffer stehen, sondern teilweise verschoben oder umsortiert abgelegt werden.

Will ich nun ein D64-File schreiben, so heisst das, dass ich mir Sektor-für-Sektor zusammensuchen muss und so diese entsprechend sortiert in die Datei schreiben muss - andernfalls wird z.B. das Directory nicht in Track18-Sektor 0/1 abgelegt, sondern z.B. Track18 Sektor 5 oder irgendwo.

Ich habe zwar die GCR-Dekodierung weitestgehens optimiert (keine Schiebebefehle und nur einfaches Lookup in einer Tabelle), jedoch dauert das Suchen der Sektoren dann einfach sehr lange, zumal ich jeden Header der Sektoren erst dekodieren muss, die entsprechende Nummer auslesen und vergleichen muss, bevor ich die Sektordaten dann ansich umsetze und speichere... d.h. alle 17-21 Sektoren pro Track benötigen diesen zusätzlichen Aufwand. Das wird beim Atmel nun langsam knapp mit der Zeit, da ich eben nur während des Trackwechsels die alten Daten wegschreiben muss, bevor schon neue anliegen und evtl. die ersten alten Sektoren "überschreiben"... das fällt gerade beim Formatieren auf

Noch habe ich dafür keine Lösung - Thorsten versucht einen anderen Weg, aber ich weiss nicht, ob er mehr Erfolg hatte.

PS: ich würde mich über etwas Feedback zu den verschenkten Platinen freuen - insbesondere, ob es mit der jetzige Firmware noch große Probleme mit besonderen SD-Karten und Displays gibt?

Ein Problem wurde mir schon berichtet mit den 1,1" OLED Displays, auf denen ein etwas anderer Controller arbeitet - an einer Erkennung dessen arbeite ich noch.

Schon mal riesen Dank für die Mühe.

Wenn es klappt, wäre es super toll.

Die viele Arbeit kann man gar nicht genug würdigen

Danke fook42 für deine Bemühungen, somit wissen wir, das das live schreiben als D64 so nicht funktioniert. Ja der Ansatz war gut aber für den Atmel doch etwas zu viel. Mein Ansatz geh da einen anderen Weg. Ich habe sogar noch 2 Ideen. Ich habe zwischen Weihnachten und Neujahr Urlaub und werde dort das mal umzusetzen und schauen ob das Erfolg bringend ist. Jetzt vor Weihnachten hat man leider immer viel um die Ohren. Ich halte euch auf den laufenden. Meine Variante mit dem OLED wollte ja auch nicht wirklich, zumindest ging ja dann kein laden vom Image nicht mehr. Hatte leider keine Zeit das weiter zu testen, das mache ich dann auch im Urlaub.

Freue mich schon auf die freie Zeit dann kann ich wieder rum friemeln.

hallo,

man muss es doch nicht in echtzeit machen?

man wandelt doch später einfach die g64 in d64 um?

dann hat man doch keine zeitprobleme.

am besten, nach dem booten, wenn keine befehle vom rechner kommen,

die sd-karte automatisch durchsuchen nach g64 dateien.

wenn keine passende d64 dazu vorhanden dann wird eine angelegt.

und optional kann man dann sogar die g64 datei danach löschen. so gibt es dann auch keine g64 mehr.

optional könnte man sogar, mit einem led-zwischenadapter, die power oder die laufwerks led, blinken lassen,

solange nach dem einschalten, die g64 dateien in d64, vom atmega umgewandelt werden.

gruß

helmut

edit....

man könnte ja auch die sd-karte mit den g64 dateien nachträglich auf einem pc auf d64 umwandeln.

Zitat von axorp

g64 dateien nachträglich auf einem pc auf d64 umwandeln.

Das Thema ist eher andersrum.. D64-Images auf dem PC müssen in G64 konvertiert werden.

aber dein Ansatz ist durchaus eine Überlegung wert! also alles in einem Format zu speichern (hier bietet sich G64 an) statt jedesmal zu live konvertieren zu wollen.

Ich denke jedoch, dass D64 das verbreiteste Image-Format darstellt und es deshalb aus Bequemlichkeit schon zu unterstützen ist, sonst meckern wieder alle.

Nur G64 hatte Thorsten bzw. die Vorgänger schon recht früh hier im Thread demonstriert.

Gefährlich wird die Umwandlung auf dem Atmel nur dann , wenn man wärend eines SD-Karten-Schreibzugriffs den Strom abstellt oder die Karte zieht, weil man denkt, das System ist fertig.

Natürlich benötigt der Atmel keine Sekunden für das Umwandeln eines Images (insbesondere mit effizienten GCR-Routinen)... jedoch könnte das schon mal passieren - gerade bei vielen Images auf der SD-Karte -, dass der Schreibzugriff nicht ganz abgeschlossen wurde -> Ergebnis wäre eine korrupte SD-Karte ..

Anderes Thema warum man G64-Images auch noch auf der Karte haben wollte, wären besondere Trackloader oder Kopierschütze, die man im D64 eben nicht abbilden kann (Stichworte: fehlende HeaderInformationen, Sync-Marken, GAP-Bytes etc).

Zitat von fook42

Natürlich benötigt der Atmel keine Sekunden für das Umwandeln eines Images (insbesondere mit effizienten GCR-Routinen)... jedoch könnte das schon mal passieren - gerade bei vielen Images auf der SD-Karte -, dass der Schreibzugriff nicht ganz abgeschlossen wurde -> Ergebnis wäre eine korrupte SD-Karte ..

dann nicht sofort die umwandlung von g64 auf d64 starten, sondern erst nach einer tasten bestätigung.

und mit einer blinkenden led als warnung. der es startet weis nun das er erst nach dem blinken,

die floppy ausschalten oder benutzen darf.

Zitat von fook42

Anderes Thema warum man G64-Images auch noch auf der Karte haben wollte, wären besondere Trackloader oder Kopierschütze, die man im D64 eben nicht abbilden kann (Stichworte: fehlende HeaderInformationen, Sync-Marken, GAP-Bytes etc).

Zitat von fook42

Das Thema ist eher andersrum.. D64-Images auf dem PC müssen in G64 konvertiert werden.

dann sogar die g64 auf der sd-karte immer mit drauf lassen.

wenn die g64 auch woanders besser benutzt werden können.

wenn die umwandlung von d64 auf g64 öfters benötigt wird,

dann werden nach einem tastendruck grundsätzlich die vorhandenen g64 zu d64 umgewandelt

und die d64 zu g64, wenn jeweils nur in dem anderen format auf der sd-karte vorhanden.

platz ist wohl auf einer sd-karte genug vorhanden und wenn dann nimmt man eine zweite.

so hätte man immer, von den programmen auf der sd-karte die im g64 und im d64 format.

auch eine umwandlung in weitere formate wäre dann so möglich.

solange es der atmega schafft, egal wie lange er dafür benötigen würde.

denn er müsste es ja nur einmal machen, danach ist die umgewandelte datei immer schon vorhanden.

wer die umwandlung in andere dateiformate nicht möchte,

muss ja nach dem einschalten der floppy nicht die taste drücken.

gruß

helmut

Ich würde es nicht beim Booten. sondern beim unmounten des aktuellen Images machen.

Genau das ist mein Ansatz. Ich will es so machen das die 1541-rebuild Grundsätzlich intern g64 verarbeitet. Wird jedoch ein d64 gemountet wird dieses in eine temporäre g64 gewandelt und entspr. flags im eeprom gesetzt. Wird das Image manuell ausgeworfen wird es sofort zurück gewandelt wenn auch wirklich drauf geschrieben wurde. Sollte die 1541-rebuild einfach ausgeschaltet werden, erkennt man anhand der Flags das eine d64 gemountet war und wird dann wieder zurückgweandelt von g64 nach d64. Werde das in meinem Urlaub umsetzen. Werde auch nichts in meinem Repo an der Anzeige ändern, so das fook42 das dann in seinem fork übernehmen kann. Das dopellt anlegen von d64 + g64 images halte ich für unnötig.

und es geht doch...

Nachdem ich nun noch weiter probiert habe, konnte ich das Problem mit den "verschobenen" Sektoren im GCR-Ringpuffer beseitigen.

Etwas trickreich war das Problem zu lösen, dass der letzte Sektor eines Tracks ja durchaus genau auf der hinteren Kante des Puffers liegen konnte und so nach vorn ge"wrap"t ist, dass ein Teil davon wieder am Anfang des GCR-Puffers lag.

Zum Vorgehen: ich suche ja aktiv nach den Sektoren-Markern (FFFF52 als Folge im GCR-Strom, die so nicht durch "normale Daten" codiert werden können).

Dieses Suchen beginnt am Anfang des GCR-Puffers und beim Erreichen jedes Sektors wird dann die Sektor-Nummer extrahiert und entsprechend dieser in die D64-Datei an einem bestimmten Offset die folgenden Daten dekodiert abgelegt.

Nach 256 Bytes fange ich wieder von vorn an und suche den nächsten Sektor... und so weiter. Dabei ist es mir dann egal, in welcher Reihenfolge die Sektoren vorkommen.. geschrieben wird entsprechend ihrer, im Sektor-Header abgelegten Nummer.

Komme ich nun ans Ende unseres GCR-Puffers und habe dort einen Track, der zwar vorher anfängt, jedoch dann seine restlichen Daten wieder am Anfang des Puffers liegen hat, so ist das ein Problem (siehe Zeichnung).

Zur Lösung habe ich nun einfach alle Daten, die mir am Anfang beim Suchen des ersten Markers (hier vom Sektor 19) unterkommen, direkt hinten ans Ende des GCR-Puffers geschrieben (dort wo nun etwas "extra Space") zur Verfügung steht - da hatte Thorsten Kattanek dankensweiser den Puffer schon etwas großzügig angelegt

Und dann war da noch die Floppy-Disk-ID .. man erinnere sich; das ist eine 2-Stellige Zahl, die z.B. beim Formatieren mitgegeben werden kann und die fortan in die Sektoren-Header und auch in das Direktory geschrieben wird.

D64 kennt das aber garnicht und kann somit diese Header-Daten auch nicht ablegen bzw. bereitstellen, wenn die Format-Routine nochmals zurückliest, ob diese ID auch wirklich auf der Disk angekommen ist.

Gelöst habe ich es nun so, dass die ID als globale Variable beim Speichern abgelegt wird und beim Rücklesen dann genau diese Zahlen wieder in den erzeugten GCR-Datenstrom eingebaut werden.

Das Ergebnis : es Formatiert, es schreibt, es liest .. D64-Files.

[x] D64-Write support done.

-> https://github.com/fook42/1541-rebuild

Sehr cool!

Super, ich hoffe, dass ich meine fehlenden Bauteile noch dieses Jahr bekommen, dann kann ich das endlich testen ( Hatte das Projekt erst einmal zu Gunsten der 1581 rebuild beiseite gelegt, weil noch kein Schreibsupport implementiert war und damit kein wirklicher 1541-Ersatz da war - aber jetzt...)

Schaue mal, was ich heute noch so zusammenbekomme...

Super fook42. Na dann kann ich mich ja um andere Sachen kümmern . Kannst du einen Pullrequest machen nur mit den Sachen die für das schreiben nötig sind Dann kann ich das die Tage mit in meinem Repo hinzufügen. So können die Besitzer der "alten Hardware" das auch gleich testen. Auf alle Fälle Daumen hoch.

Einfach galaktisch super.

Sowas möchte ich auch können

Vielen Vielen Dank

Mit Github stehe ich für das finden der downloaddateien immer auf Kriegsfuß.

Aber wenn es die 1.37 Firmware ist, habe ich es geschafft sie down zu loaden

Doof ist, dass ich den Programmer auf Arbeit habe.

Muss ich dann wohl mal hin, sonst komme ich erst am 17.Januar wieder da hin

Ich sage ja, dass ich mit github auf Kriegsfuß stehe

Ich suche eigentlich die doc, wo die Fuses stehen für den Atmega1284

Weiß die hier jemand auswendig?

Müste hier sonst den ganzen Thread durchsuchen

EDIT: Habe die Beschreibung bei Github gefunden und mich zum download
hingehangelt

Steht im PDF Seite 8 : 1541-rebuild.pdf (alte FW)

Neuer Build Seite 12 : 1541-rebuild.pdf

Die Fuses des Controllers müssen wie folgt gesetzt werden.
• LFUSE: 0xD0
• HFUSE: 0xD3
• EFUSE: 0xFF