Posts by fook42

Quote from Plastix

Was muss da denn alles für umverdrahtet werden um ein I2C Display mit der 1.4.0 Platine zu betreiben?

hab mal beide Schaltpläne nebeneinander gelegt...

bis auf PORT B muss man alle anderen neu verdrahten - das ist notwendig, da der I2C-Anschluss leider nur über PORT C vom Atmel herausgeführt wird und die 1.4.0er Platine hier die VIA-Signale liegen hat.

Deshalb hatte ich mir die Mühe gemacht, eine neue Platine zu entwerfen/zu routen und auch die Software dafür anzupassen (denn die Portbelegung ist ja nun anders und die I2C Routinen sind auch neu).

Quote from FrankyByte

...nun das Problem mit dem Display, leider habe ich "nur" die 1.4 Platine

erstmal finde ich deinen Umbau schon sehr gelungen!!

für das Display mit I2C-Anschluss (z.B. so ein OLED) benötigst du in der Tat eine andere 1541rebuild-Platine (1.4.2 hätte das, was du brauchst)

alternativ könntest du natürlich auch die Platine selbst "umverdrahten" (https://github.com/fook42/1541…v_1.4.2/I2C_handwired.jpg)

Der Vorteil der I2C-Displays wird da auch ersichtlich; man kann kleinere Displays nutzen, muss nicht so viele Leitungen von der Platine dorthin legen und es gibt einfach mehrere Display-Typen.

Leider fällt mir auch nichts besseres ein, als dein Ansatz, wenn man die originale Front der 1541 behalten will. (https://github.com/fook42/1541…OLED_in_1541-II_Front.jpg)

Quote from sebos

Hello.

Firmware 1.3.0 is final wersion ?

I usually loaded 1541 Rebuild demos that couldn't be read on Pi or 1541 U. However, I found a demo that won't work only with 1541 Rebuild - Esira 2 by Arise. Such a curiosity...

latest firmware can be found here: https://github.com/ThKattanek/1541-rebuild/releases

it's 1.3.7 ...

once i've setup my C64 again, i'll check that demo .. but to be honest, i'm currently working on a different approach by using Pi-Pico as a replacement for the Atmel .. but thats far from release now.

und nochmal eine kleine Information, damit wir alle wissen, wo die Zeit beim Zugriff auf die Images auch noch versteckt ist:

Vorweg; die Zeiten variieren aufgrund der Zugriffs-Geschwindigkeit der SD-Karte, der Zeit fürs Öffnen der Datei, wie lange das "Suchen" nach dem Offset im Image-File benötigt (seek) und natürlich wieviele Sektoren pro Track geschrieben werden müssen [21,19,18 oder nur 17]

(Angaben pro Track-Zugriff - als gemessene Werte per Osziloskop)

Lesen:

- G64-Modus: 24 - 28 ms

- D64-Modus: 32 - 44 ms (inklusive GCR Enkodierung)

Schreiben

- G64 Modus: 36 - 60 ms

- D64 Modus: 100 - 140 ms (inklusive GCR Dekodierung und Track-Aufbau)

Das ist alles nicht so richtig "schnell", aber noch besser als eine echte Diskette, die mit 300 rpm dreht und somit mindestens ~200ms pro Track (lesen oder schreiben) benötigt.

Also sollten wir es theoretisch doch schaffen auch mit dem Atmel hier den Datenstrom einer Diskette zu immitieren, wenn da nicht die Verzögerung für den Zugriff und die Konvertierung der SD-Kartendaten wäre.

okay, das kommentiere ich mal nicht.

aber zurück zum Kopieren von Disketten mit dem 1541rebuild.

Ich habe nun das FCopy 2.9 benutzt um eine Diskette zu kopieren (FC III zeigt zwar etwas an, aber meine Eingaben werden ignoriert)

Sowohl im D64 als auch G64 Format sehe ich nun einen Fehler im Ziel-Image : die Tracks 10 und 21 sind nicht kopiert worden - da wurde scheinbar der ganze Track übersprungen. alle anderen stimmen 1:1 überein.

Nun kopiert FCopy scheinbar jeweils 12 Tracks pro Durchgang, bei dem dann zunächst von der QuellDiskette gelesen und anschliessend diese 12 Tracks auf eine ZielDiskette geschrieben werden. Das wiederholt sich dann noch 2 mal ( für die Tracks 0-11, 12-23, 24-35)

Kann mir jemand sagen, ob FCopy hier eigentlich verlässlich ist, oder ob das ein bekannter Fehler ist?

Bin nicht der C64-held... deshalb; gibt es eigentlich einen Track-reader/editor, bei dem ich gezielt 1 Track von Diskette auslesen und schreiben kann ? mit Floppy-Kommandos geht das wohl eher nicht, oder?

es wird der ATMEL ATmega1284p benutzt:

- 16 KB RAM

- 4 KB EEPROM

- 128 KB Programm Flash

und hier sieht man, dass die 16KB auf keinen Fall ausreichen um ein ganzes Image (170 KB D64 bzw. 271 KB G64) im Ram zu behalten

einen einzelnen Track bekommen wir gerade so noch hin.

Hallo leute..

ja, ist ein wenig ruhig geworden um das Thema; ich hab ein gebrauchtes Häuschen gekauft und bin das ganze Jahr neben der Arbeit nur am Renovieren/Erneuern ... das frisst viel Zeit.

zum D64 support; ja, ich hatte die Routinen noch fertiggestellt und auch mit Thorsten Kattanek s Hilfe in die originale Firmware integriert (1.3.7) - so dass man dort grundsätzlich D64 Files auch beschreiben kann.

Grundsätzlich, da es eben mit Speedern und anderen "Tricks" noch Probleme beim wirklichen Zurückschreiben auf die SD-Karte gibt.

Man hat leider nur wenig Zeit, einen Track vom GCR zu dekodieren und an die passende Stelle ins D64-File der FAT32 SD-Karte zu schreiben. Hierbei ist nicht nur die SD-Karte ansich, sondern auch das Filesystem (FAT32) und der SPI-Bus ein Bottleneck.

Einfache Schreibübungen funktionieren .. sogar eine Diskette konnte ich formatieren und neue Dateien draufkopieren.. aber ein FastCopy funktioniert eben nicht

mit dem G64 sollte das allerdings etwas besser laufen - hier entfällt die GCR dekodierung, jedoch bleibt auch hier der SD-Kartenzugriff eine zeitkritische Komponente.

Thorsten hatte für die SD-Kartenroutinen eine vorhandene Bibliothek von Roland Riedel benutzt - evtl. könnte man diese noch etwas beschleunigen .. aber dafür habe ich noch keine gute Alternative gefunden.

Zu den Image-Features:

das Erzeugen eines leeren Images kann ich kurzfristig einbauen - das ist nicht schwer, zumal ich hierfür ja nicht auf die Floppy warten muss, sondern nur die SDKarte beschreiben sollte.

muss dafür noch ein bisschen "Menu"-führung einbauen, damit man auch den Filenamen und das Format (D64/G64) auswählen kann.

Quote from greg64

manchmal kommt die Meldung: Diese ... wird nicht unterstützt.

hmm.. das sollte eigentlich nur dann passieren, wenn die Endung der Datei nicht ".g64" oder ".d64" lautet oder die Datei nicht gelesen werden konnte.

evtl. sind die noch gezippt? oder anderweitig gepackt?

Quote from Bubblebobble

vielleicht äußern sich ja die beiden Experten nomma, ob die überhaupt noch aktuell sind

bin zwar nicht der Experte, aber zu den "aktuellen" Platinen:

- es gibt die originale Platine von Thorsten Kattanek ... Platinen version 1.4.0 - mit LCD Display-Anschluss -> https://github.com/ThKattanek/1541-rebuild

- und es gibt eine Erweiterte Platine von mir .. Version 1.4.2 - an welcher auch I2C Displays angeschlossen und genutzt werden können. -> https://github.com/fook42/1541-rebuild

Neben den unterstützen Displays gibt es sonst keine Unterschiede - beide Varianten funktionieren in jeder 1541 (I oder II).

Bei der Software existiert nur eine Version:

- 1.3.7 .. vom Dezember 2021 .. hier wurde noch eine rudimentäre D64-Write Funktionalität implementiert .. hat aber Probleme bei Fast-Copy Programmen.

man muss bloss darauf achten, die "Richtige" Software für die "Richtige" Platine zu flashen ... deshalb hat Thorsten an "seine" Firmware noch den Zusatz "for pcb 1.4.0" angehängt, damit das einfacher wird.

Quote from Snocksman

baue aktuell meinen Amiga 2000 wieder auf

diese Information ist dabei wichtig : der A2000 hat keinen nativen Festplattenanschluss - weder IDE noch SCSI

Von daher wirst du wohl deine CF-Karte über eine Kontroller-Karte angeschlossen haben, die ansich ihr eigenes Device mitbringt.

Manchmal (meistens) haben diese Karten (z.B. der ATBUS-Clone) einen Gerätetreiber (=Device), welcher sich ebenfalls als "scsi.device" anmeldet.

Das ist natürlich verwirrend, weil für diese Treiber der Maxtransfer-Fix aus dem >= 3.1.4 OS nicht greift.

-> deshalb, wie der DigitalKeeper schon schreibt; lieber einmal mehr eintragen, als einmal zu wenig.

ich hab diese Erweiterung im Einsatz ... bietet 4MB, lässt genug Platz für die PCMCIA-Erweiterung und ist auch preislich gut

https://amigastore.eu/en/762-amiga-600-4mb-fast-ram.html

Ich danke euch erstmal für die vielen Ideen - finde es gut, wenn wir hier eine gemeinsame Linie und Erwartungshaltung an die künftige 1541-rebuild-Software bekommen!

Also; euch würde eine reine G64-basierte Emu ausreichen?

-> auf der SD-Karte kann man dann eben nur die G64 Dateien auswählen

-> Für dieses Format soll Lesen und Schreiben unterstützt werden

-> evtl. Löschen/Erstellen und Kopieren (ist ja dann nur auf der File-System Ebene der SD-Karte nötig)

-> Support für 84 Tracks : G64-Dateien können bis zu 42 Tracks (+42 Halftracks) beherbergen

-> SD-Kartenroutinen optimieren (hier geht viel verloren aktuell durch Update des Direktories nach jedem Track etc.)

hab ich was vergessen für die Wunschliste?

Quote from stones73

Das erstellen einer disk geht noch nicht oder? Zumindest passiert bei mir nichts wenn ich den punkt auswähle.

nee..

weder Erstellen, noch Löschen, noch Kopieren ist implementiert..

da wäre auch die Frage, in welchem Format eine neue Disk angelegt werden sollte...

so wie ich es nun lese, wird sich ein G64 (wie auch immer es heisst) dann doch durchsetzen - ist auch bezüglich der Emulation deutlich angenehmer, weil Thorstens Routinen eben kaum Zeit für das Lesen/Speichern davon benötigen - wir kämen damit den Fastloadern näher.

Quote from stones73

Fastformat

tja.. das hatte ich schon befürchtet.. diese Schnell-Lade und Speicher-Routinen warten eben nicht lange genug ab und manchmal "messen" sie auch nicht, wie groß die Spur nun wirklich ist.. sondern da werden einfach zack-zack die Sync-Marken geschrieben und evtl. nichtmal der Inhalt gelöscht ...

das werden wir wohl auch mit dem jetzigen Ansatz nicht leicht lösen können - eben weil wir dann die aufwändige GCR-Kodierung trotzdem machen müssen.

Eine Alternative könnte es aber sein, dass wir selbst vom 1541-rebuild eine FORMAT-Option anbieten, die einfach eine "leere" D64 bzw. G64 Datei anlegt oder die alte Datei überschreibt... das kann dann ja unabhängig vom Takt der 1541 passieren, so dass unser "Format" in ~1 Sekunde durchaus fertig wäre.

Ich würds mal auf die To-Do-Liste packen und falls Thorsten oder ich wieder viel Zeit und Muse haben, wäre das sicher machbar...

das Gleiche gilt auch für eine Kopier-Routine... mit dem Atmel eine D64/G64 Datei auf der SD-Karte zu kopieren ist eigentlich kein Thema und 100mal schneller als per C64.

Nochmal zum Thema Dokumentation:

ich habe bei mir im Repo die Dokumentation inzwischen erweitert um die fehlenden Teile zum Schreiben/Lesen von GCR-Daten bzw den Datenformaten. Neben einem Hinweis auf die anderen Platinenversion ist das aber auch alles, was ich hier gegenüber des originalen PDFs von Thorsten erweitert hatte

-> https://github.com/fook42/1541…ster/doc/1541-rebuild.pdf

Quote from Thorsten Kattanek

Danke fook42 nochmal für deine Mühe

gern .. nur dank dir habe ich ja überhaupt eine Floppy-Lösung mit der ich arbeiten kann ...

Quote from stones73

baut ihr die Platine aus oder kann die auf der Floppyplatine bleiben?

so wie Thorsten Kattanek schon schrieb; du kannst beides machen -..die Platine ausbauen und einzeln auf dem Tisch betreiben, wenn dein Programmer die 5V-Spannung ausgibt (was der oben gezeigte durchaus macht),

oder du lässt alles zusammengesteckt auf der Floppy-Platine und programmierst sie dort - dann solltest du aber die Spannungsversorgung vom Laufwerk benutzen, denn rückwärts über die 1541rebuild den Rest der Floppy zu versorgen, kann schiefgeben.

Quote from stones73

wie ich das auf meinen Atmega bekomme.

Das wird die nächste hürde für mich werden.

Ist avrdude ein teil von ubuntu oder muss ich das erst noch installieren? Und muss ich die fuses nochmal setzten wenn der schonmal programmiert war, also beim update?

Den progger habe ich mir schon abgeschafft aber noch nie benutzt, den atmega hatte ich damals schon fertig programmiert bekommen?

zum Programmieren hatte Thorsten in dem PDF schon eine kleine Anleitung mit dem "avrdude" eingestellt, jedoch fehlte mir damals auch einiges um zu Verstehen, wie es funktioniert.

Zu deiner Frage: im Ubuntu ist das avrdude nicht automatisch enthalten.. man muss es installieren, was aber kein Hexenwerk sein sollte:

sudo apt-get update -y

sudo apt-get install -y avrdude

Allerdings ist die Bedienung über die Konsole nicht jedermans Sache.. In der Anleitung stand aber auch ein Hinweis auf diese Seite:

https://blog.zakkemble.net/avrdudess-a-gui-for-avrdude/

und dort wird eine Windows/Linux-Oberfläche für das AVRDUDE gezeigt, so dass man sich nichtmehr mit der Komandozeile rumärgern muss.

Wie es installiert wird steht auch dort - und das hat bei mir auch unter Ubuntu 21.10 gut funktioniert.

Beim Programmer sollte man nur wissen, welchen Typ man nutzt - es gibt diese "Günstigen", welche sich mit avrdudess als "USBasp" ganz einfach ansprechen lassen:

https://www.ebay.de/itm/324775919486

Hilft das schonmal weiter?

Quote from greg64

... aber genau auf die Schreibroutinen warte ich ...

sag mal, greg.. ist das normal hier, dass man nur fordert und sich nicht die Mühe macht, auch zu sagen, was genau denn nicht geht?

Ich hab dir eine Platine geschenkt - ein "Dankeschön" hier im Forum kam dafür auch nicht

ist nicht so, dass ich es unbedingt haben will.. aber dann dieser Ton, dass du etwas haben "WILLST".. finde ich nicht so dolle.

Zumal die Software (sprich: dein HEX-File) oben verlinkt wurde und du nur lesen müsstest, was du damit machen musst.

Dass ich die Dokumentation (das PDF) noch nicht aktualisiert habe, kannst du mir nicht vorwerfen - angesichts von wenigen Stunden seitdem ich die Routinen erst implementiert hatte.

Ausserdem; GitHub und openSource lebt vom Mitmachen ... wenn dich also fehlende Dokumentation stört (- obwohl ich versucht habe, euch hier mit meinen Postings ausgiebig zu erklären, was gemacht wurde und warum und wie-) dann schreib doch bitte selbst die Datei um, lade sie auf das GitHub hoch und freu dich, wenn andere dann rummeckern, dass sie es nicht finden ...

Sorry, dafür hab ich kein Verständnis und ich bereuhe es fast schon, dass du eine von den wenigen Platinen bekommen hast und nicht jemand, der sich darüber gefreut hätte.

Denk mal darüber nach.

wenn man etwas klickt, findet man auch das HEX-File in einem ZIP dort im github

-> https://github.com/fook42/1541-rebuild/releases/tag/SW1.3.7

und auch das PDF mit der Anleitung findet man dort, wenn man etwas klickt:

-> https://github.com/fook42/1541…ster/doc/1541-rebuild.pdf

(hier habe ich aber noch kein Update zu den Schreibroutinen und der Software 1.3.7 gemacht... )

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