Posts by fook42

    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 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?

    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.

    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

    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.

    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?

    ... 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.

    :(

    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




    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).

    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.

    Wegen einer GVP-Karte (IoExtender) hatte ich mal mit einem ehemaligen GVP-Entwickler gesprochen (der war im AmiB*y unterwegs) ... von ihm hatte ich den Tipp, dass zumindest die Bridge-Chips von GVP (Dual-Ported Ram-Controller = DPRC) immer mal Probleme machen.


    Diese hat GVP fast auf jeder Karte genutzt um den Zorro-Bus an ihre internen Ram-Busse anzubinden - den Chip konnte ich damals recht "günstig" von ihm kaufen und seitdem rennt auch die IO-Karte wieder.

    Kernschrott!

    naja.. hier "zuckt" die Karte ja noch - zumindest möchte ich das mal glauben. :rolleyes:


    Vielleicht finden wir ja den Übeltäter doch noch ausserhalb der Logik-ICs .. dann könnte man es reparieren.

    Speicher ist ja wohl auch so ein Sonderthema bei den GVPs.


    DigitalKeeper , hast du denn schonmal eine Karte gehabt, die zumindest die erste Hürde vom Kickstart nimmt, dann aber nicht weitermacht? und was würdest du unternehmen ?


    PS: ja.. immer in 2 Foren nachzugucken, wo welche Informationen dazu stehen, ist auf Dauer mühsam, jedoch wollen/können nicht alle F64er im A1K sein und umgekehrt...


    hier wäre der A1K-Link: https://www.a1k.org/forum/inde…reads/81845/#post-1542707 (den müsste man auch sehen, wenn man nicht angemeldet ist, oder?)

    es geht ja nicht darum, wer Recht hat oder so.. ich wollte es eben nur einmal sagen, dass wir mit diesem Hinweis schon einen Schritt weiter an der Lösung sein können.

    Am Ende wollen wir doch dem drerich helfen und er soll eine funktionsfähige Karte haben...

    Und dass sie oben beschriebenes Verhalten "zeigt", macht mir nun etwas mehr Hoffnung.


    PS: wo ist die Karte denn inzwischen? wieder zurück bei erich? oder hast du sie noch, muellerarmack ?

    nun muss ich mal schimpfen...

    ich hatte diese Frage gestellt und die entsprechende Antwort vom muellerarmack bekommen

    Quote

    - wechselt der Bildschirm von dunkel auf grau? oder macht etwas ähnliches? (kurzes Aufblitzen, etc..)

    => Nein


    drerich schreibt im A1K-Forum aber, dass der Bildschirm durchaus von dunkel-grau auf hell-grau wechselt.


    Beim Amiga ist das ein riesen Unterschied, weil es mehrere Aussagen zulässt:

    1. Die CPU arbeitet Befehle ab, die den Farbwechsel erzeugen.. diese kommen aus dem Kickstart-ROM

    ergo: Takt okay, Spannungsversorgung ausreichend, Buszugriff von TK auf Mainboard okay


    2. Vor dem Wechsel werden üblicherweise alle Bootroms der Erweiterungskarten (auch die der Turbokarte) ausgeführt

    ergo: zumindest "stört" das die Kickstartroutine nicht, was dort drin steht - also wären auch die Bootroms (GuruRom) in Ordnung


    3. nach dem hellen Bildschirm folgt ein RAM-Test (Detektion von Chipram und Fastram-Bereichen) mit anschliessendem Umbiegen der exec-base auf den Fastram.

    da es zu keinem weiteren Farbwechsel kommt (es folgt ein "schnee-weiss"), muss der Fehler zu diesem Zeitpunkt stattfinden

    ergo: Zugriff auf den Turbokarten-RAM fehlerhaft(defekter Riegel, defekte Leitungen) oder Burstmode problematisch oder falsche RAM-Größe erkannt/eingestellt, defekter Bustreiber auf der Karte auch möglich.

    Du hast ja Recht; es gibt viele Fehlerquellen bei einem alten Computer und natürlich sind auch EPROMs verdächtig mal auszufallen - ist zwar selten, aber könnte sein... ein Guru-Rom hätte ich hier in meinem GVP-Controller..


    Durch den Test von muellerarmack haben wir ja schon gelernt, dass ansich der 2000er nicht die Ursache deines Problems ist - denn es wäre unwahrscheinlich, dass sein 2000er die gleichen "defekte" hat wie deiner.


    Ein Problem, welches sich - zumindest bei anderer Amiga-Hardware - herausgestellt hat, sind alternde Elektrolyt-Kondensatoren, die ihre Kapazität verlieren und dadurch gerade Versorgungsspannungen nichtmehr störfrei puffern.

    Auf der Karte sind aber - zumindest was ich auf den Referenz-Bildern gesehen habe, eher Tantals.. also auch das könnte man ausschliessen.


    Was noch sein könnte, wären Kontaktprobleme bei den gesockelten Chips (sowohl die Fat-Packs als auch die "normalen" ICs..) - wenn du einen "größeren" Akkuschaden hattest, dann kann es durchaus vorkommen, dass die Akkudämpfe sich auch dort niedergeschlagen haben ... evtl. könnte man die Chips einmal herausnehmen und neu einsetzen? Etwas Vorsicht ist geboten, weil gerade die großen Sockel aufgrund des Alters leicht brechen können. (oder evtl. schon sind?)

    das Diag-Rom

    das wäre zumindest eine Möglichkeit, evtl. Probleme, auf die die Kickstart-Initialisierungsroutine trifft, auszuschliessen.

    Es ist komplett frei von Treibern oder Voraussetzungen des Amigas - das würde sogar etwas auf der Seriellen Schnittstelle ausgeben, wenn dein Grafik-Teil problematisch ist..

    aber inwiefern es bei einer kaputten (so siehts halt aus) CPU-Karte zurechtkommt, weiss ich auch nicht :(


    Nur noch eine Frage zur Funktion der Turbokarte: muss man dafür die originale 68000er CPU aus dem Sockel nehmen oder bleibt sie im Rechner?

    Ich hatte einmal hier eine neue Turbokarte (TerribleFire) im CPU-Slot und die wollte garnicht anlaufen, wenn der 68000er noch gesteckt war.

    Drück Dir selbst die Daumen, dass es die Oszis sind

    sorry.. hier bin ich nicht der Meinung, dass das die Ursache für die beschriebenen Probleme sein wird.

    - wechselt der Bildschirm von dunkel auf grau? oder macht etwas ähnliches? (kurzes Aufblitzen, etc..)

    - Hast du ein DiagROM für den Amiga?

    - Hast du einen Rev4 oder einen Rev6 des Amiga 2000 ? selbst laut Handbuch ist das ein riesen Unterschied für die GVP Karte.

    - Hast du einen Ersatz-Prozessor da? - die 68040er können schon auch einmal sterben.. jedoch sollte man dazu evtl. mit einem Osziloskop (nicht Oszilator) durch die üblichen Signale gehen -

    - Was macht denn der Bus auf dem Mainboard des 2000ers ? ist dort Aktivität festzustellen? ...

    - Wenn möglich: Ich würde die Karte einmal "abschalten" per Jumper und sehen, ob dann der restliche Rechner überhaupt läuft - wenn nicht, dann hast du ganz einfach ein Problem mit den Bustreibern oder Pull-up/Pull-down Widerständen... .. ob diese Möglichkeit eines "Fallbacks" auf den 68000er besteht, weiss ich nicht - evtl. steht dazu etwas im Handbuch?

    Bei einer 2630 kann man durch drücken der Maustasten beim Boot ein Bios der Karte starten um sie dort abzuschalten... hat das die GVP auch?


    Bei den 2000er-Typen, dem Prozessor und dem DiagRom könnte ich aushelfen (hab alles hier).. aber das verschicke ich nicht.