Posts by fook42

    Hallo fook42 wie ist deine Lösung beim Pico 2 mit den IOs auszukommen benutzt du einen Extender oder hast du ein Board wie das PGA welches ausreichend GPIOs nach aussen führt.

    Ein Extender könnte auch das gleichzeitig das Levelshifting übernehmen.

    gute Frage.. ich hatte so gerechnet:

    das Board des Pico2 hat 26 GPIOs nach aussen geführt... (https://www.raspberrypi.com/do…ages/pico-2-r4-pinout.svg)

    ich benötige

    - 17 für die VIA6522 Verbindung (PA0-PA7, BRDY, SYNC, SOE, SOE_GA, WP, MTR, STP0, STP1, OE)

    - 2 fürs Display (nur per I2C angeschlossen)

    - 3 für den Drück-Dreh-Schalter

    - 4 für die SD-Karte (SPI)

    in summe 26 :D

    Also ich möchte mir jetzt nicht aneignen hier eine Idee gehabt zu haben.
    Ich habe lediglich einige Fakten mit meinem nicht sehr umfangreichen Verständnis zusammengefasst und eine Frage gestellt.
    Es hätte ja auch andere Gründe geben können durch die eine Änderung am System nicht gewünscht sind.

    hab ich auch so verstanden... deshalb Danke für deine Gedanken und die Ideen zur Verbesserung des 1541rebuild sind natürlich immer willkommen!

    Mit der M2SSD könnte man evtl. etwas herausholen (da war ich nicht drauf eingegangen) - allerdings hat die nochmal ein anderes Hardware-Interface als die jetzige SD-Karte, soweit ich das sehe.


    Die Levelshifter alleine sind schonmal gut, jedoch muss eben auch ein anderer MikroController eingesetzt werden ... dh. neue Programmierung (und sei es nur, dass die Port/Pin-Belegungen nicht stimmen) und neues Layout einer Platine.

    Bei der Platine hatte Thorsten Kattanek ja schon viel Zeit investiert um die Größe möglichst universell für alle 1541er (1 oder 2) zu gestalten.. hier neu anzufangen, dauert eben und erzeugt wieder Herausfoderungen (wie ich auch schon gemerkt hatte) ... dazu kommt noch, dass die meisten hier noch ihre alte Platine weiter nutzen wollen, und dann ist das ganze Thema "rework" eh vom Tisch, sondern es wird eher eine Neuentwicklung.

    kannst ja mal vergleichen was sich alles zwischen der "originalen 1541rebuild" und meiner variante getan hat und trotzdem bleibt man dabei und portiert die Software dann für die alte Karte zurück ;-)

    Könnte hier ein größerer ATMega Abhilfe schaffen?

    Oder die Nutzung einer M2SSD von wegen der Geschwindigkeit, die sind heutzutage ja auch schon für Kleines zu haben.

    Interessant wäre für mich die Funktionalität mit Speedern die ein Paralleles Kabel nutzen oder gar mit dem MegaloDos von Tommi_nrw


    Zum Thema "alternative zum aktuellen AtMega": ich habe schon einen Pico2 hier liegen und der wartet nun dieses Wochenende (oder die kommenden) darauf, endlich mal ein bisschen Code zu sehen.

    Die Idee ist in der Tat, dass wir im RAM des Chips (das ist der limitierende Faktor) ein komplettes Disk-Image (G64-format, 42 Tracks - 318KB) unterbringen können. Nur dann ist es mit Sicherheit möglich, schnelle Spurwechsel und Floppy-Speeder-routinen auch in echtzeit bedienen zu können - mit der SD-Karten Lösung hatte man hier immer einen Zugriff per Filesystem, eine Übertragung über SPI und dann evtl. ein Dekodieren von D64 in G64...

    Das klappt meistens - aber leider nicht immer...

    meine Code Verbesserungen hier und da, waren schonmal hilfreich und haben einige Demos und Spiele erst lauffähig gemacht, die vorher noch abgebrochen waren... aber den Hardware-Pfad und das Problem ansich, hat das nicht lösen können.. und spätestens bei FastCopy-Routinen wo auch das Schreiben in eine Disk-Image-Datei möglichst ohne Verzögerungen stattfinden muss, führt zu Problemen.


    Lange Rede kurz; ich möchte gern den Pico2 einsetzen (der ist wohl gerade noch so 5V tollerant und wenn nicht, dann halt ein Levelshifter dazwischen), wodurch eben der Zugriff komplett umgestellt wird - allerdings hilft das nur, wenn ich eine gute Aufteilung auf die 2 Kerne des Picos finde, so dass sich die Signalverarbeitung&Kommunikation zum 6502 und die Image-Datei Verwaltung&Dekodierung nicht in die Quere kommen.


    Nur nochmal zur Erinnerung; wir wollen nicht die 1541 komplett emulieren, sondern _nur_ den analog-Teil ersetzen, so dass alle Speeder/FloppyMagic weiterhin funktionieren "müsste".

    Danke schon mal für die Links.


    Frage: was macht / kann der Amiga den ohne all die Karten? Läuft er ohne Festplatte wieein A500?


    Der A2000 funktioniert grundsätzlich wie ein Amiga 500 - sind beide vom Ur-Amiga 1000 abgeleitet.

    Du kannst also den 2000er genauso zum Zocken benutzen, wie alle A500er Besitzer :)


    Die Besonderheit liegt jedoch genau in den Steckkarten, die hierbei mithilfe eines zusätzlichen Controllers (Buster) verwaltet werden und die durch den "ZORRO-2"-Bus direkten Zugriff auf den gemeinsamen Speicherbereich haben (DMA).


    Ausserdem besitzt er einen Video-Slot, der die rohen RGB-Signale sowohl Analog als auch Digital bereitstellt .. damit konnte dann sowas wie deine ScanDoubler-Karte gebaut werden, die als Ausgang ein VGA kompatibles Signal (31 Khz) erzeugt.

    Damit war der 2000er sehr nah an der PC Welt und deren Peripherie (Monitor, Laufwerks-Schächte etc) ... und als i-Tüpfelchen gab es die sogenannten Brückenkarten, welche dir einen x86 PC bereitstellen, der direkt auf die Amiga-Resourcen zugreifen konnte (Maus, Tastatur, Serieller/Paralleler Port, Festplatte).

    (Die Wertvollste Karte in dem Konvolut)

    nicht ganz. - ich schätze, dass die Brückenkarte deutlich seltener und damit wertvoller ist.


    A) die erste Karte ist eine 2286 Brückenkarte - erkennt man am Huckpack.

    https://amiga.resource.cx/exp/a2286at


    B) A2630 CPU-Karte mit Ram-Erweiterung (Access32)

    https://amiga.resource.cx/exp/a2630

    https://amiga.resource.cx/exp/access32


    C) Makrosystem Evolution SCSI-Karte

    https://amiga.resource.cx/exp/evolution2000


    D) De-Interlacer Karte (Scandoubler) von MacroSystem

    https://amiga.resource.cx/exp/deinterlacecard

    created a first version to support PCB 1.4.0 with my updated firmware 1.3.8

    -> https://github.com/fook42/1541…tag/SW1.3.8_HW1.4.0-alpha

    (2 binary versions availble: for "small" 16x2 LCDs and for "big" 20x4 LCDs )

    würde mich noch über Feedback freuen :thumbdown::thumbup: .. falls jemand eine "alte" Platine (1.4.0) hat und gern die neuen Features nutzen möchte:

    - 40 Tracks

    - G64+D64 File-formate

    - Lese & Scheib-Routinen (für D64.. G64 nicht zuverlässig)

    most of us have the 1.4.0 board

    actually you are right.. it needs some manual work to merge my changes back to the official repository from Thorsten Kattanek ...

    we tried this for the "write"-routines, but it was not really good for long-term maintenance ...


    better approach; find all hardware-changes between PCB 1.4.0 and PCB 1.4.2 .. and adopt the PORT-assignments

    some things will not work though: I2C-Displays can not be used on 1.4.0 and maybe some small changes for input/output ports are necessary...

    let me see... (may take some time)


    main problem for me: i can not contribute directly to Thorstens repository and can not make commits there.. so i would have to take care of backporting for PCB 1.4.0 within my 1.4.2 fork (which kind-of breaks the whole relation chain)

    hast du das ganze auch mal mit Disk-Images im G64 Format vom Wonderland probiert?

    G64 spart bei der EMU die ganze konvertierung in den GCR Datenstrom und das Laden des Images geht damit auch ein bisschen flotter...

    warum nimmst du unter Windows <10 nicht eine Virtual-Box oder VMware mit Linux als "Gast"?

    ab Win10 hast du doch das Linux schon dabei (WSL) ... da kannste dann auch den avr-gcc nehmen .. der sollte dann das gleiche liefern wie meiner


    im Anhang hier noch die 20x4 LCD version .. dann brauchste es nicht selbst zu übersetzen.

    aber auch dabei gilt: ich habs nicht getestet (hab nichtmal ein 20x4 Display da)

    P.S.: hast Du von der 1.3.8 ggf auch Sourcen? Ich bräuchte die lcd.h wieder für ein Display 20x4

    du findest den aktuellen Software-Stand hier:

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


    das oben angehängte 1.3.8beta ist genau dieser Stand (beta deshalb, weil ich eben keinen Release gemacht habe - dafür fehlt eine wirklich verlässliche Schreibroutine, die jetzige geht, aber nicht immer).


    ich compiliere übrigens unter Windows mit dem avr-gcc .. evtl. macht der etwas anderes als der WinAvr ? ...

    Hi John,

    wenn du willst, kannst du gern mit deinem Setup auch eine leicht aktualisierte Firmware testen (1.3.8beta)

    da hatte ich mal an den GCR/D64 Routinen gedreht und auch ein paar 1ms herausgeholt .. ob das bei den Demos hilft, weiss ich nicht - da ich auch meinen 64er nicht mehr aufgebaut habe :(


    irgendwie überholt mich das Leben und die Arbeit gerade.

    ich habe festgestellt, dass die Routinen der 1541rebuild auch stark von der SD-Karte bzw. den Zugriffen drauf abhängen.

    Es kann so vorkommen, dass das Lesen einer Disk-Image-Datei unterschiedlich lange dauert, je nachdem, wie fix die SD-Karte die Daten bereit stellt.


    Versuch bitte einmal, die Daten nochmals drauf zu kopieren (anderer Name z.B.) oder eine andere SD-Karte zu benutzen.


    Manche Demos nutzen allerdings auch Fastloader und andere Floppy-Tricks, für die die Routinen im Atmel leider doch noch zu langsam sind, bzw. sich nicht so verhalten, wie bei einer echten Diskette.

    z.B. gibt es Loader, die sehr schnell durch die Tracks steppen und jedesmal nur ein bisschen lesen um beim nächsten Durchgang den 2ten Teil zu erfassen... das bekommen wir so nicht hin in der 1541rebuild, die ja immer die gesamte Spur einliesst und ausgeben möchte... dabei hängt die Zeit für dieses Einlesen der Spur natürlich auch von der Spurnummer ab (innen oder aussen) und dann auch, wie schnell das FAT-Filesystem auf der SD-Karte innerhalb des Disketten-Images die richtigen Daten bereitstellen kann.


    Ergo: ob eine Demo läuft oder nicht, hängt von vielen Faktoren ab und ich habe zumindest nicht alles getestet, was es da draussen gibt ... :(

    Könnte man das Ganze auch für eine 1571 nutzbar machen?

    ich denke, dass das mit dem jetzigen Ansatz eher nichts wird - Speichermangel und Geschwindigkeit sind ein großes Limit des Atmels.

    Meine Versuche mit Speicherroutinen und Speedloadern waren alle nicht sooo ergiebig - es geht ja, aber man kommt schnell an die Grenzen.


    Für eine Weiterentwicklung würde ich (bzw. versuche ich) eher einen anderen Chip zu nutzen - der RP2040 auf einem RaspiPico-Board ist sowohl speichermässig als auch von der Geschwindigkeit um einges attraktiver.

    Aber ja, auch dafür wird eine neue Platine benötigt (was kein großes Ding ist, wenn man es erstmal auf mit Kabeln zusammengesteckt hat).

    Aktuell habe ich aber noch andere, wichtigere Baustellen und bin nicht über ein mini-Programm für den RPi rausgekommen

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

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

    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.