Hello, Guest the thread was viewed14k times and contains 122 replies

last post from skoe at the

Zwischenbericht zum Experiment "open1541"

  • Der LPC2148 gefällt mir auch gut wegen dem SD Slot. Den werd ich mal gleich bestellen.


    Das WinArm sieht auch gut aus. Allerdings ist da seit über 2 Jahren nix mehr geschehen ...



    Naja jetzt bin ich ja nur noch nächste Woche da und dann über 3 Woche weg. Das werde ich wohl erst nachher angehen.

  • >Der LPC2148 gefällt mir auch gut wegen dem SD Slot.
    >Den werd ich mal gleich bestellen.
    Wenn Du das tust, bestell ich das gleiche Board. Dann können wir zwei gleiche Schaltungen aufbauen. Ich muss sowieso demnächst was unternehmen, weil mein Aufbau noch keine SD-Karte und noch kein IEC hat. Da kommt das Board genau richtig.


    >Das WinArm sieht auch gut aus.
    >Allerdings ist da seit über 2 Jahren nix mehr geschehen ...
    Doch, die letzte Version ist 20080331. Die Seite ist nur sehr unübersichtlich. Die 20080331 ist aber etwas "zu neu", da müsste man etwas mehr anpassen.


    Ich werde mir heute abend mal die 20070505 ziehen, die scheint am dichtesten an meiner Toolchain zu sein.


    >Naja jetzt bin ich ja nur noch nächste Woche da und dann über 3 Woche weg.
    Ist ja ein Zufall, exakt wie ich. Vorher lohnt sich das Bestellen echt nicht, sonst geht's womöglich wieder zurück zum Empfänger.

  • Ist die VIA Emulation voll ausgeführt auf richtige IO? Könnte man bitte auch die Emulation von parallel Speeder unterstützen? Man bräuchte dazu die 10 freien IO Leitungen des VIA ($1801 + CB2 +SP2).


    Die parallel Speeder haben den Vorteil eines sauberen Handshake und müssen daher auch nicht Taktgenau sein.


    Ich beschäftige mich schon einige Zeit mit den üblicheren Speedern. Jetzt mehr mit den spezielleren (Prologic und Professional), da müsste man auch noch 8KB RAM emulieren ...


    -------


    Übrigens wie machst du das mit der GCR Kodierung / Dekodierung? Wie emulierst du den Disk Controller? Da du das original ROM emulierst wirst du wohl ALLES emulieren müssen: Umdrehungszahl, Syncbytes, fillbytes, Header, GCR ...


    Das bedeutet einen großen Nachteil zu SD2IEC da hier der ganze Wahn mit der 5 aus 4 GCR Kodierung von vornherein obsolet ist.


    Die wirklich guten parallel Speeder, und da gibts meines Wissens nur 2 bedienen sich hier einer Hardwarehilfe ...



    Wenn du wirklich alles emulierst samt Sync und Header ist D64 nicht das optimale Format. Eher wird es auf G64 raus laufen? Dafür gibt es dann nichts mehr was nicht geht (doppelte Negierung :( ) - wollte sagen es geht dann WIRKLICH ALLES. :D

  • Die folgenden Antworten beziehen sich auch ungelegte Eier und sind deshalb mit Vorsicht zu genießen:


    > Ist die VIA Emulation voll ausgeführt auf richtige IO?


    Was draußen gebraucht wird, ja.


    > Könnte man bitte auch die Emulation von parallel Speeder unterstützen?


    Guck mal weiter oben im Thread oder in den Schaltplan. Oder kurz: Ja, es ist angedacht.


    > Die parallel Speeder haben den Vorteil eines sauberen Handshake
    > und müssen daher auch nicht Taktgenau sein.


    Allerdings wird für das Handshake IMHO ein Latch benutzt, der nachgebildet werden muss.


    > da müsste man auch noch 8KB RAM emulieren ...


    Oder haben ;-) Mal sehen, ob man noch 8k vom Controller-RAM dafür abknapsen kann.


    > Übrigens wie machst du das mit der GCR Kodierung / Dekodierung?
    g64: Einfach nehmen
    d64: Spurweise umkodieren, voraussichtlich während sich der Kopf "bewegt".


    > Da du das original ROM emulierst wirst du wohl ALLES emulieren müssen:
    > Umdrehungszahl, Syncbytes, fillbytes, Header, GCR ...


    So sieht der Plan aus. Deshalb läuft die CPU- und VIA-Emulation so aufwändig im "Hintergrund". Damit man im "Vordergrund" alles Richtung Mechanik, lesen der Daten von SD-Karte, Bereitstellen der GCR-Daten einer Spur, die dann virtuell (in Form eines Zeigers auf einen Ringpuffer) am Kopf vorbeirauschen.


    Wie man sowas machen kann, sieht man ganz gut (oder nicht so gut) im Vice. Bis jetzt habe ich aber noch keinen Code von da übernommen, weil die Randbedingungen doch etwas anders aussehen.


    > Das bedeutet einen großen Nachteil zu SD2IEC da hier der
    > ganze Wahn mit der 5 aus 4 GCR Kodierung von vornherein obsolet ist.


    Der Nachteil, dass mehr Code drinstecken muss. Der Vorteil, dass potentiell sowohl den direkten Modus des sd2iec als auch eine 1541 Emulation benutzt werden können.


    > Wenn du wirklich alles emulierst samt Sync und Header ist D64 nicht das optimale Format.
    > Eher wird es auf G64 raus laufen?


    Hoffentlich beides.


    > Dafür gibt es dann nichts mehr was nicht geht (doppelte Negierung ) -
    > wollte sagen es geht dann WIRKLICH ALLES.


    Naja, seien wir mal vorsichtig mit solchen Aussagen :-) So genau wie eine FPGA-Lösung wie in der 1541U wird's wohl nie werden. Aber vielleicht 99% kompatibel plus ein paar anderer Vorteile. Die 1541U ist ein bemerkenswertes Stück Arbeit - und vor allem ein fertiges Stück Arbeit :-)

  • Ach ja, hier war ja noch was: Also im Moment liegt das Teil auf Eis. Es gibt mehrere Gründe dafür: Wenig Bedarf an einem solchen Gerät, bin kein Einzelkämpfer, andere Projekte.


    Wegschmeißen werde ich natürlich nichts davon. Steht ja auch verewigt im Internet. Vielleicht packt's mich mal wieder, interessant war es ja allemal.


    git ist übrigens die Versionsverwaltung des Projekts. Vorher hab ich Subversion verwendet. Unseen hat mir dann git empfohlen, was mir beim näheren Hinsehen dann auch als die bessere Lösung erschien.

  • Wenig Bedarf an einem solchen Gerät


    Bitte??!! :@1@:



    Die CeVi Welt wartet genau auf sowas. Der Bedarf wäre 100%-ig da, sonst würde niemand eine 1541u haben wollen. Im Prinzip würde jeder sowas wollen, wenn es leistbar ist. Beim Preis der 1541u ist natürlich nur noch ein harter Kern dabei.

  • Ich fände es extrem schade wenn beim OpenCBM nix mehr weitergehen würde!!



    Übrigens habe ich nachgedacht über Zyklus Genauigkeit:

    • Nicht jeder Befehl muss Zyklus genau sein. Es würde langen, wenn bestimmte IO Operationen Zyklusgenau erfolgen.


    • Im Falle der 1541 Emulation würde es langen, wenn der Bus IO zyklusgenau erfolgen würde!


    • Alle anderen Operationen sind unproblematisch und können ungefähr synchronisiert werden. Dazu läßt man einen Timer laufen im µs Takt. Jeder Befehl hat eine definierte Ausführungszeit zwischen 3 und 9µs. Man verzögert die Ausführung eines Befehl demensprechend (Befehl darf nicht vor Timerstand x starten).


    • Richtig kritisch sind nur die IO Befehle die den IEC Bus betreffen. Das ist auch der einzige Befehl den man sinnvolleweise im Interrupt ausführen könnte.


    • Die CPU legt die Daten in das VIA nicht sofort sondern erst nach dem 3 Takt. Man müsste sich nur ausrechnen, in welcher µs (ab welchem Timerstand) die Daten im VIA Port sind.
  • Hi Diddl,


    > Ich fände es extrem schade wenn beim OpenCBM nix mehr weitergehen würde!!
    Falscher Thread oder falscher Name?


    > Nicht jeder Befehl muss Zyklus genau sein. Es würde langen, wenn bestimmte IO Operationen Zyklusgenau erfolgen.
    Deine Erklärungen klingen auf den ersten Blick plausibel. Ich glaube, dass die hier im Thread auch schon besprochen wurden.


    Ich habe auch schonmal angefangen, was in der Richtung zu implementieren. Dabei sollten im ersten Schritt alle "unkritischen" Opcodes (dex, inx u.v.m.) einfach hintereinander weg emuliert werden und dabei die Zyklen aufaddiert. Es gab dabei noch ein paar kleine Haken in der Implementierung. Außerdem ist mir dabei aufgefallen, dass noch mehr daran hängt.


    An Einzelheiten erinnere ich mich nicht mehr. Ganz grob lief es wohl darauf hinaus, dass das Timing des Gesamtsystems stimmen muss (z.B. externe IRQs und Timer müssen zwischen den richtigen Instruktionen kommen). Ist sicher alles lösbar, aber da es (noch) kein Performance-Problem gab, hab ich mich dafür entschieden, das Design erstmal so einfach wie möglich zu lassen.


    > Man verzögert die Ausführung eines Befehl demensprechend (Befehl darf nicht vor Timerstand x starten).
    Das war auch mein Ansatz.


    > Das ist auch der einzige Befehl den man sinnvolleweise im Interrupt ausführen könnte.
    Also ein paar im Hauptprogramm und ein paar im IRQ wäre wohl etwas unhandlich, falls Du das so gemeint hast. Ich wollte alle im IRQ machen, aber ggfs. halt ein paar in einem Rutsch. Das Hauptprogramm sollte ja auch frei bleiben, um den Rest des Laufwerks im quasi-Multitasking emulieren zu können.


    Wenn Du Interesse hast, dass Projekt mit aktiver Beteiligung wiederzubeleben, schick einfach eine PN. Ich wäre dabei. :-)


    /Thomas

  • > Ich fände es extrem schade wenn beim OpenCBM nix mehr weitergehen würde!!
    Falscher Thread oder falscher Name?


    Was schreibe ich bloss fürn Quatsch??!! Natürlich wollte ich Open1541 schreiben!!



    Wenn Du Interesse hast, dass Projekt mit aktiver Beteiligung wiederzubeleben, schick einfach eine PN. Ich wäre dabei. :-)


    Ja der erste Versuch an meinem PC ging ja schief wegen der Memory Leaks ... Aber inzwischen habe ich einen neuen PC, allerdings dieses mal mit Vista. Vielleicht funktioniert der PC besser mit dem Cygwin?


    Allerdings sehr aktiv wird diese Beteiligung wohl nicht sein. Ich komm ja mit dem XS-1541 schon nicht recht weiter ... :roll:

  • Meiner Meinung nach könnte es gaaanz knapp mit einem Atmega 644 funktionieren. Das würde bedeuten man könnte die SD2IEC Hardware missbrauchen.



    Ich habe einen ultra simplen 6502 Emu gefunden. Arbeitet mit statischen Variable, kein Pointer keine Struct - nix, also nur eine CPU emulierbar. Aber dafür ist das Teil abartig schnell.


    Ein 4,88 MHz 8086 emuliert eine 1MHz 6502 und ist noch zu schnell. Der 16MHz Atmega schafft ungebremst locker eine 4MHz 6502. Es müsste also eine Reserve da sein um "den Rest" zu emulieren ...


    ... vorausgesetzt man kommt mit der ROM Größe aus. Denn 16KB verschlingt allein das DOS.



    .

  • Tach Diddl,


    > Aber dafür ist das Teil abartig schnell.


    Also um ehrlich zu sein sieht der alles andere als abartig schnell aus, sondern eher durchschnittlich implementiert. Die Emulation im open1541 arbeitet fast ausschließlich aus Hardware-Registern und benutzt nur eine handvoll Assembler-Instruktionen pro emuliertem Opcode.


    > Ein 4,88 MHz 8086 emuliert eine 1MHz 6502 und ist noch zu schnell


    Mhhh, bei der Implementierung hätte ich eher auf mindestens 1:8 getippt.


    In der README steht:


    "All in all, it runs at about 2.5-3MHZ emulated on a 486/100 when all
    stack probes are removed."


    Nanu?


    Wie in diesem Thread schon diskutiert, schafft man es problemlos auf dem Atmega 644 einen 6502 in Echtzeit zu emulieren (nicht mit dieser Implementierung). Aber kein ganzes, zyklengenaues Laufwerk mit I/O, VIAs (Timer, IRQs etc) u.s.w.


    > ... vorausgesetzt man kommt mit der ROM Größe aus. Denn 16KB verschlingt allein das DOS.


    Wenn Du dass DOS in's ROM packst, denk an die Harvard-Architektur des AVR. Die Emulation muss dann aus ROM und RAM lauffähig sein.


    Und dank auch an RAM. Du brauchst 2k für das Drive-RAM, ein paar k für FAT und ca. 8k für eine Spur in GCR.


    Ich will Dich nicht bremsen, probier's ruhig mal auch einem AVR. Aber ich wundere mich ein bisschen, dass Du die Themen nochmal durchkaust, die in diesem und anderen Threads schon vor Monaten diskutiert wurden.


    Gruß,
    Thomas

  • Wenn Du dass DOS in's ROM packst, denk an die Harvard-Architektur des AVR. Die Emulation muss dann aus ROM und RAM lauffähig sein.


    Natürlich läuft das Programm auch im RAM.


    Habe heute Nacht schon eine halbfertige Version erschaffen mit RAM ($0000-$7FFF), ROM ($C000-$FFFF) und 2 VIA ($1800/$1C00) und dieser simpel Implementation. Die VIA Schreibzugriffe sieht man schön am Terminal protokolliert, also das DOS läuft im Prinzip!


    Der 644er jetzt bereits ziemlich zu (40% Flash und 83% RAM), allerdings kann man da noch viel optimieren weil die ganzen Emu Tabellen noch im RAM liegen.


    Die VIA muss man ja nur soweit emulieren, wie sie in der Floppy benutz werden, also nur lapidar.


    Wenn ich die Bus VIA auf einen Mega Port umleite und einen CeVi anschliesse kann ich bestimmt bereits den Fehlerkanal auslesen. :freude



    Und dank auch an RAM. Du brauchst 2k für das Drive-RAM, ein paar k für FAT und ca. 8k für eine Spur in GCR.


    Der Mega1284 hat 16K.


    Aber es muss nicht unbedingt eine ganze Spur gelesen werden. Man kann auch laufend von der MMC lesen, SPI ist schnell. Aber natürlich wird man die Spur buffern wenn man kann.



    Ich will Dich nicht bremsen, probier's ruhig mal auch einem AVR. Aber ich wundere mich ein bisschen, dass Du die Themen nochmal durchkaust, die in diesem und anderen Threads schon vor Monaten diskutiert wurden.


    Hab wohl die Beiträge nicht genau gelesen ... :rotwerd:

  • Wie in diesem Thread schon diskutiert, schafft man es problemlos auf dem Atmega 644 einen 6502 in Echtzeit zu emulieren (nicht mit dieser Implementierung). Aber kein ganzes, zyklengenaues Laufwerk mit I/O, VIAs (Timer, IRQs etc) u.s.w.


    Ich bin inzwischen überzeugt dass Zyklus genau gar nicht notwendig ist. Es muß ausschliesslich das Via 1 Port B in Echtzeit emuliert werden. Und das bringt man schon hin wenn man brav 6502 Zykluse mit zählt ... :)


    Für Timer nimmt man die Atmega eigenen Timer, wenn Zugriffe auf den VIA erfolgen muss halt der Atmega Timer demensprechend angepasst werden. Solche Zugriffe erfolgen nur höchst selten und nur von ganz speziellen Floppy Programmen, also kann man erst mal sogar darauf verzichten.


    Der 644er ist nur vom RAM her zu schwach, aber es wäre ja zum Glück der 1284 in den Startlöchern. Zur Not könnte man auch einen 2561 nehmen ...

  • Also nochmal um Missverständnisse zu vermeiden: Ich bin der letzte, der Dich ausbremsen möchste. Du kennst mich hoffentlich als ziemlich sachlich. Es wäre super, wenn aus der Idee open1541 sogar was mit einer weit verbreiteten Hardware wie dem sd2iec werden könnte. Selbst wenn das ein paar (kleine) Abstriche bei der Kompatibilität bedeuten würde. Sicher wäre es aber nur sinnvoll, wenn mehr oder weniger viele Fastloader funktionieren würden, sonst könnte man auch bei der Original-sd2iec-SW bleiben, die ja viel mehr kann als eine 1541.


    Es ist gut, dass Du das Thema nochmal unvoreingenommen durchleuchtest, manchmal verrennt man sich ja in eine falsche Richtung. Aber: Ich möchte mit den richtigen kritischen Fragen eventuell vorhandene Lücken finden.


    Quote

    Die VIA muss man ja nur soweit emulieren, wie sie in der Floppy benutz werden, also nur lapidar.


    Also die Timer werden definitiv benutzt, wenn auch nicht alle Ausprägungen (s.u.). Ansonsten sind die VIAs natürlich kein Hexenwerk.


    Quote

    Habe heute Nacht schon eine halbfertige Version erschaffen


    Oh, halbfertig schon. Dann müsste es ja rechnerisch kommende Nacht ganz fertig werden :-)


    Quote

    Wenn ich die Bus VIA auf einen Mega Port umleite und einen CeVi anschliesse kann ich bestimmt bereits den Fehlerkanal auslesen.


    Es gibt auch noch einen anderen ganz einfachen Test. Wenn Du die Drive-LED richtig versorgst, was nicht schwierig sein sollte: http://forum64.de/wbb3/index.p…&postID=260336#post260336
    Genaueres erkennst Du im ROM-Listing. Wenn Du also diese Adressen manipulierst (oder das Lesen von ihnen...), sollte die LED anfangen zu blinken. IIRC geht das sogar schon ohne Timer, weil es im main-loop gemacht wird. Wenn Deine Aussagen zur Geschwindigkeit stimmen, blinkt die LED ohne Emu-Bremse wahscheinlich viel zu schnell, aber das macht ja nichts.


    Quote

    Der Mega1284 hat 16K.


    Also wenn das im Prinzip geht, würde ich ja ganz hart die sd2iec-HW anstreben. Selbst, wenn das kleine Abstriche bedeutet. Wenn man sowieso eine neue HW bräuchte ist ja der geniale Vorteil weg, es doch mit einem Atmega zu schaffen.


    Quote

    nicht unbedingt eine ganze Spur gelesen werden. Man kann auch laufend von der MMC lesen, SPI ist schnell. Aber natürlich wird man die Spur buffern wenn man kann.


    Auch das Thema wurde hier oder in der Mailing-Liste schon besprochen. Eine Annäherung wäre, das berühmte "hier: BVC hier" als Trigger zum Lesen eines Blocks zu benutzen.


    Quote

    Ich bin inzwischen überzeugt dass Zyklus genau gar nicht notwendig ist. Es muß ausschliesslich das Via 1 Port B in Echtzeit emuliert werden. Und das bringt man schon hin wenn man brav 6502 Zykluse mit zählt ...


    Und die Vorgänge zwischen "Lesekopf" (VIA $1C01) und CPU-Emu sollten einigermaßen sinnvoll emuliert werden. Für die meisten Speeder aber definitiv nichts zyklengenau.


    Und vergiss nicht, dass die CPU-Emu für IRQ-Loader auch in engen Schleifen jederzeit "da" sein muss. Wenn man z.B. im sd2iec mit Dreamload-Emu auf den Diskwechsel-Taster gedrückt hat (=> IRQ) wärend es gerade einen Block übertragen hat, ging der Transfer in die Hose. Haben wir dann durch Sperren der IRQs wärend Transfers behoben. Aber es gibt sicher sinnvolle Stellen zum Aussteigen aus der Emu.


    Im Timer-IRQ möchtest Du die CPU-Emu im Atmega sicher nichtmal teilweise machen, aufgrund nicht vorhandener Banked Register ist das sonst mit ziemlich viel Overhead verbunden.


    Quote

    Für Timer nimmt man die Atmega eigenen Timer, wenn Zugriffe auf den VIA erfolgen muss halt der Atmega Timer demensprechend angepasst werden. Solche Zugriffe erfolgen nur höchst selten und nur von ganz speziellen Floppy Programmen, also kann man erst mal sogar darauf verzichten.


    Ist das 1541-DOS ein ganz spezielles Programm?


    Quote

    Der 644er ist nur vom RAM her zu schwach, aber es wäre ja zum Glück der 1284 in den Startlöchern. Zur Not könnte man auch einen 2561 nehmen ...


    Kein Kommentar :-)


    Du hast jedenfalls mein Interesse geweckt :-) Hast Du noch meine email-Adresse? Kannst Du die momentanen sourcen mal schicken?

  • Vielleicht eine Alternative: Mikrocontroller.net


    @Edit: Ach sehe gerade im Atmeg8SID Thread, dass Diddl sich den schon angeschaut hat...

  • Jetzt wo du's sagst, über den Thread bin ich letztes Jahr bei meinen Recherchen auch mal gestolpert. Ich bin auch der Meinung, dass ein SID-Player wahrscheinlich nie zyklengenau sein muss, sondern nur im Mittel. Bis auf ein paar SpezialproblemSIDs vielleicht.

  • Sehe ich auch so. Das Timing wird eh durch die Hauptschleife gesteuert und die kann man auch mit dem Timer synchronisieren.