Posts by Diddl

    Ja das geht.

    Mit 40V Gleich- und auch mit 220V Wechsel-Spannung.


    Allerdings ist der Aufwand beträchtlich.

    Die Module kosten ganz schön was.


    Ich empfehle eine freie Frequenz.

    Diese Module mit 443MHz kosten nur ein paar Cent, die guten mit Superhet kosten etwas über einen Euro.

    Da gibt es auch gute Arduino Libs dazu.


    Wenn du wirklich viel Daten senden möchtest, dann bietet sich ein LoRa Modul an.

    Da gibt es auch preiswerte Router die viele LoRa Knoten autonom versorgen und mit dem Internet verbinden.

    Bei mir geht mit dem originalen Zoomfloppy jedes D64, auch mit 42 Spuren (sofern die Diskette so weit magnetisierbar ist).

    Es geht alles was mit einem parallelen XA-1541 Kabel lief, inklusive MNIB und andere kritische Sachen!


    Mit dem selbstgebauten Zoom Floppy auf U32 Basis geht alles, was mit dem originalen Zoomfloppy geht.

    Allerdings habe ich mit dem IEC Kabel ziemlich herumspielen müssen bis es lief.

    Speziell bei Nibble Copy braucht es da ein sehr kurzes IEC Kabel (25cm) bzw. das Teensy eingebaut in der Floppy.


    Die Länge des USB Kabel hingegen ist total unproblematisch.

    Die Final Expansion wäre prädestiniert für den VC20 da es Speichererweiterung und SD2IEC kombiniert. Platinen habe ich dafür hier allerdings keine Bauteile und entsprechend habe ich auch noch keine Platine als Testaufbau zusammengebrutzelt. Das SD2IEC ist lediglich ein beschränkter Floppy-Ersatz.

    Die Bauteile müsste man aber heute noch leicht kriegen.


    Vielleicht hapert es an den ATF1504?
    Im Keller müssten noch etliche herum liegen.



    Schlimmstenfalls kann man das Final Expansion auf Lochraster aufbauen.


    Das erste FE2 und das erste FE3 habe ich noch per Hand gefädelt. :D

    Das ist ja ganz nett.
    Nur muss man da halt die DIP switch umstellen, je nach Demo das man laufen läßt.


    Die Final Expansion kann man so konfigurieren, dass alle Demos in eine Liste kommen (samt memory config) und sich die Karte dann automatisch umstellt.
    Das ist Komfort.


    Zudem kann man mit dem Final Expansion noch zusätzlich jede erdenkliche Software und jedes Spiel laufen lassen.

    I'm astonished About this Problems with 407 boards …


    The timing of a 6510 is not very critical and for a modern FPGA it is really slow.



    I'm sure you do, so excuse my Question …
    Do you combine Clock with PHI2 correctly?
    Do you react correctly on Signal BA and DOT Clock from VIC?


    Only an idea ...

    Auslöten, einlöten???!


    Ähm …
    Mal abgesehen dass ich dazu nicht in der Lage wäre ...
    … ich wäre nicht mal auf eine derartige Idee gekommen. :D



    Ich würde es einfach mit meinem Galep auslesen und gut. :)


    Optional müßte doch fast jeder andere Programmer mit allen gängigen Flash Chips umgehen können.

    @Tommi_nrw , @Diddl : Habt ihr euch schon mal das pi1541 Projekt angeschaut? Klick mich


    Man könnte evtl. das irgendwie mit benutzen in der 1541.
    Das Floppy ROM läßt sich austauschen ...
    Da wäre evtl. Lan, W-Lan, SD-Karte, Touch Screen und USB vom Raspberry mit nutzbar. Zusammen mit der 5 1/4 Zoll Floppy. Floppy cachebar über Softwarelösung ...


    Schwebt mir irgendwie so vor.

    Klar kenne ich das Pi1541.
    Hab auch eines laufen hier bei mir.



    Es geht nicht darum, eine noch perfektere Lösung zu finden.
    Sonst muss man einfach nur VICE auf einem schnellen PC verwenden mit einem USB Competition Pro. ;)



    Es geht darum, Retro Legenden am Leben zu erhalten (so wie Prof-DOS) und logische Weiterentwicklungen zu treiben.

    @Diddl, Tommi_nrw : Welche Organisationsart des Caches wollen wir umsetzen?


    -direkt abgebildet
    -vollassoziativ
    -satzassoziativ bzw. mengenassoziativ

    Bei einem mechanischem Speichermedium wie Floppy Disk sind die größten Kosten beim Spurwechsel, wegen der Trägheit des Kopfes.
    Vor allem beim Wechsel der ersten und letzten drei Spuren, weil der Kopf erst beschleunigen muss.


    Zudem sind die Kosten bei Zugriff auf einen Sektor exzessiv, weil man warten muss, bis der richtige Sektor am Kopf vorbei läuft …
    Zugriff ist verzögert um bis zu 200ms.


    Und letztlich ist die Zeit zum hochfahren des Drive selbst schon sehr teuer


    ==


    Die Organisation im RAM ist faktisch egal, denn selbst wenn man es schlecht macht, ist es noch um Faktor 1000 schneller.



    Wir buffern in erster Linie eine ganze Spur.
    Und zwar die aktuelle Spur.


    Und in zweiter Linie die restlichen Spuren, also die ganze Diskette


    ==


    Die Organisation des Buffer beschäftigt mich schon eine ganze Zeit lang.
    Man hat folgende Möglichkeiten:

    • wir buffern native Daten, also GCR kodiert, exakt so wie es von der Diskette kommt
    • wir buffern GCR dekodierte Sektor Daten (Header + datanblock)
    • wir buffern überhaupt nur Sektor Daten



    Im Fall 2 sind wir schneller als im Fall 1. Die Floppy kann direkt die gewünschten Daten zum C64 senden.


    Im Fall 1 sind wir kompatibler. Die Floppy kann auch Lesefehler exakt wieder geben, dadurch funktionieren auch simple Kopierschutz Techniken weiterhin.


    Im Fall 3 sind wir am schnellsten. Aber es funktioniert nur mit Disketten die nicht manipuliert worden sind.



    Da wir genügend Flash Speicher haben, neige ich dazu, beide Varianten zu implementieren.
    Man kann die Floppy umschalten in den gewünschten Modus.


    ====


    Natürlich gibt es auch andere Möglicheiten:

    • wir buffern beides, GCR Daten und auch dekodierte Daten
      Man könnte sich für jeden Sektor merken, ob er lesbar ist oder einen Lesefehler hat.
    • wir Buffern nur dekodierte Daten und merken uns, welche Sektoren lesbar sind.
      Bei Zugriff auf Sektoren mit Lesefehler verwenden wir die normalen Leseroutinen und lesen direkt von Diskette
      Dann läuft das Laufwerk halt immer an, wenn ein Kopierschutz gelesen wird.



    ====


    Wenn es uns gelingen würde, die GCR Dekodierung direkt im CPLD zu machen, dann gäbe es nur netto Daten für uns und wir sparen uns die Rechnerei am 6502.


    Auch der Code in der Floppy Firmware wäre dann am einfachsten.


    ====


    Gedanken könnte man sich auch machen, ob man evt. die System Disk Buffer direkt einblendbar macht …


    | $0300-$03FF/768-1023 Puffer 0
    | $0400-$04FF/1024-1279 Puffer 1
    | $0500-$05FF/1280-1535 Puffer 2 (User-Puffer)
    | $0600-$06FF/1536-1791 Puffer 3
    | $0700-$07FF/1792-2047 Puffer 4
    | $0800-$08FF/2048-2303 Puffer 5
    | $0900-$09FF/2304-2559 Puffer 6



    Wenn man die Sektor Daten direkt buffert, dann könnte man diese 7 Bereiche direkt einblenden, beim lesen.
    Beim Schreiben allerdings wäre dies gefährlich.



    Mir fällt dazu keine Lösung ein …
    … wir werden wohl weiterhin die Sektoren per CPU in die System Buffer kopieren.



    Wobei man die CPU natürlich unterstützen könnte, eine Art DMA:

    • ein Register im CPLD für die Lese Adresse (ein Pointer)
    • ein Register im CPLD für lesen eines Byte + Inkrement des Pointer

    Der 6502 bräuchte nur den gewünschten Sektor setzen und 256 mal ein Register lesen







    @Diddl können wir denn schon mal bei den Spezifikationen weitermachen?

    Mein PC läuft, und Internet!! :)


    Ja können wir schon.
    Teilweise.



    Reden wir jetzt von einer allgemeinen Lösung, die als 6502 Ersatz funktioniert?
    Quasi DIL-40 Mikrocomputer mit Flash, SRAM, CPLD und 6502?
    Also ein FE3 artiges Ding für 6502 Systeme?



    Oder reden wir von einer 1541 Lösung, die gängige Speeder Hardware emuliert?

    Sorry, bin gerade beim übersiedeln.
    Der PC ist jetzt zwar aufgebaut, aber ich habe noch kein Internet.


    Am Tablet ist es etwas mühsam, aber es geht.


    Keine Ahnung ob wir ihn unterstützen könnten?


    Denn Kernel anpassen wird klappen, aber auch etwas Zeit beanspruchen.
    Zudem kann man erst wirklich anfangen, wenn die Spec fix und fertig ist.
    Und erste tests natürlich erst, sobald die Hardware funktioniert.