Posts by fook42

    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.

    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.