Zwischenbericht zum Experiment "open1541"

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

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.

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

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

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.

Zitat

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.

Zitat

Habe heute Nacht schon eine halbfertige Version erschaffen

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

Zitat

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.

Zitat

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.

Zitat

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.

Zitat

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.

Zitat

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?

Zitat

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?

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.