Moin, ich habe hier eine knifflige Aufgabe und suche hierfür nach einer Lösung - wer hat Ideen/Tipps/Vorschläge hierzu? Ich möchte für einen 8-Bit Computer mit einem krummen Grundtakt von 1,77 MHz eine Art "Erweiterungsmodul" entwickeln. Auf diesem kommen 2 GALs, eine Batterie EProms, SRAMs und Flash-Bausteine sowie ATmega32 zum Einsatz. Ganz wichtig: Es darf/soll kein Eingriff in die Grundhardware (dann wäre es ja einfach...) nötig sein. Meine Schaltung wird in den Parallelen Anschluß gesteckt und muß ohne Änderungen des Computers funktionieren. Der ATmega muß synchron zum Takt des Computer laufen, allerdings - damit Zeit für Rechenoperationen ist - mindestens viermal so schnell. Optimal wäre es, den ATmega mit 14,187 MHz laufen zu lassen. Das wäre dann ein Verhältnis 1:8 und damit ausreichend Luft bei Assemblerprogrammierung. Soweit, so gut. Es nützt nur nichts, den ATmega einfach mit einem eigenen Takt zu versorgen, weil dieser nie synchron zum Taktsignal der 8-Bit Gurke läuft - dies ist für mein Projekt notwendig. Ich suche also nach Lösungen, dies zu bewerkstelligen. Erste Idee: Den Grundtakt von 1,77 MHz zu verachtfachen - nur wie? Da fehlt mir eine sinnige Idee - sofern das überhaupt machbar ist. Andere Idee wäre es, einen Takt mittels Quarz & Co. zur Verfügung zu stellen und diesen dann irgendwie mit dem Grundtakt zu synchronisieren. Hat jemand hier sowas schon mal gemacht? Eine Idee dazu? Danke & Gruß, Jürgen
Muß wirklich der ganze AVR synchron zum bestehenden System laufen oder würde es auch reichen, nur die Kommunikation zwischen den beiden zu synchronisieren, den AVR selbst aber asynchron, z.B. mit 20MHz laufen zu lassen?
R. Max schrieb: > Muß wirklich der ganze AVR synchron zum bestehenden System laufen oder > würde es auch reichen, nur die Kommunikation zwischen den beiden zu > synchronisieren, den AVR selbst aber asynchron, z.B. mit 20MHz laufen zu > lassen? Moin, hmm... theoretisch nicht. Praktischer wäre es jedoch, da ich ja ansonsten vor jedem Befehl & I/O Abfrage einen Flankenwechsel des Grundtakts abfragen müßte. Dies wollte ich mir natürlich ersparen, da es sonst mit den Ausführungszeiten knapp wird. Der µP soll eingesetzt werden, recht komplexe Addressdekodierungen, Bankswitching usw. vorzunehmen - wofür sonst mindestens 5 GAL 22V10 nötig wären. Gruß, Jürgen
Vielleicht kannst Du beide Seiten mit einem Dual-Clock-FIFO entkoppeln?!
Jürgen Van radecke schrieb: > hmm... theoretisch nicht. Praktischer wäre es jedoch, da ich ja > ansonsten vor jedem Befehl & I/O Abfrage einen Flankenwechsel des > Grundtakts abfragen müßte. Das leuchtet mir so erstmal nicht ein, aber um mehr sagen zu können, müßte ich noch mehr über die Aufgabenstellung wissen. > Der µP soll eingesetzt werden, recht komplexe Addressdekodierungen, > Bankswitching usw. vorzunehmen - wofür sonst mindestens 5 GAL 22V10 > nötig wären. Hmm - Adreßdekodierer brauchen doch eigentlich gar keinen Takt, sie müssen nur schnell genug sein, sprich eine möglichst enge Schleife, die permanent die Eingänge liest und auf die Ausgänge abbildet.
Jürgen Van radecke schrieb: > vorzunehmen - wofür sonst mindestens 5 GAL 22V10 nötig wären. Mal mit einem aktuellem CPLD versucht? Die aktuellen XC95xxxXL sind immerhin 5V kompatibel an den I/Os und stecken eine ganze Menge logik weg...
Jürgen Van radecke schrieb: > Hat jemand hier sowas schon mal gemacht? Eine Idee dazu? Freilich, für sowas wurde u.a. die PLL erfunden. Nimm einen 74HC4046 (der CD4046 schafft die Frequenz nicht) und einen 1:8-Dividierer, damit baust Du einen spannungsgesteuerten Oszillator mit den gewünschten 14MHz. Das Signal wird durch 8 geteilt und geht zusammen mit den 1,77 MHz in den Phasenkomparator, wo es die Nachführspannung für den VCO erzeugt. Schon hast Du den phasenstarren 8-fach Takt. Im Philips-Datenblatt ist eine Beispielschaltung und die nötigen Dimensionierungsangaben drin. Michael
Angehängte Dateien:
-
PPL8.png
5,7 KB
74HC4046 und ein :8 Teiler sind deine Freunde. Damit kannst du deinen Takt von 1.77MHz * 8 nehmen. Gruss Helmi
Michael H. schrieb: > [...] und einen 1:8-Dividierer, Den kann im Grunde sogar der AVR selbst liefern, sofern ein Timer und der zugehörige Ausgang noch frei sind. Eine andere Variante ohne zusätzliche Hardware könnte noch sein, den internen Oszillator des AVR per OSCAL auf ein Vielfaches des Master-Takts zu ziehen und immer wieder nachzuregeln.
Aber du musst bei der Ausgabe dann halt auch das Signal zum Richtigen Zeitpunkt wechseln. Das ist denke ich schwieriger. Um was für einen 8-Bit Computer handelt sich es denn? Und was für eine Schnittstelle willst du benutzen. C64?
Moin Helmut & Michael und auch alle anderen, die Idee mit dem 4046 und der Schaltung sieht super aus. Vorallendingen dürfte der Gleichlauf damit gut möglich sein. Ich denke, zusammen mit den anderen Tipps werde ich das mal in Angriff nehmen. Vielen Dank! Gruß, Jürgen
Kannst Du nochmal ein bißchen mehr zur Aufgabenstellung schreiben? Ich halte eine Taktsynchronisierung bei einem (wenn auch komplexen) Adreßdekoder nach wie vor für overkill, denn ein hardwaremäßiger Adreßdekoder bekommt ja auch nur die Adreß- und Steuerleitungen, aber keinen Takt. Aber vielleicht übersehe ich ja was...
R. Max schrieb: > Kannst Du nochmal ein bißchen mehr zur Aufgabenstellung schreiben? Moin, nee, kein C64, sondern Atari 8-Bit Serie. Es geht darum, mittels eines µP oder auch CPLD (wobei das Neuland für mich wäre...) zum Einen eine Unmenge an TTL/GAL Gräbern zu entsorgen und zum Anderen die Emulation mehrerer vorhandener Schaltungen zusammenzuführen. Sinn und Zweck ist es, eine Erweiterung zu haben, die z.B. verschiedene Spielmodule und dessen Bankswitching-Methoden zu emulieren. Die Cartridges werden im Flash mittels Information, welches Schema nötig ist, gespeichert. Ein Menü erlaubt dem Nutzer das Auswählen. Anschließend wird der nötige Algorithmus durch den µP simuliert, anstelle dafür z.B. ein oder 2 GALs einzusetzen. Die Daten werden aus dem Flash in das SRAM kopiert und die oberen Adressleitungen des SRAMs durch den µP und der hinterlegten Matrix gesteuert, währenddessen die unteren Adressleitungrn A0-A12 direkt von der CPU bedient werden - klassisches 8 KB Bankswitching halt. In einigen Sonderfällen (z.B. Tool-Module) auch nur 4 KByte, das sind aber nun Feinheiten. Desweiteren soll es möglich sein, das SRAM als als externe RAM-Disk zu nutzen und viele Spielereien mehr. Es gibt alle diese Lösungen in der Fangemeinde, aber immer nur "Einzeln" - und vieles gibt es nur vergossen als Block, währenddessen ich einen Großteil bereits in Handarbeit dechiffriert habe. Das Endprodukt wird dann die "eierlegende Wollmilchsau" werden und dank µP/CPLD auch für künftige Sachen erweiterbar. Langt das als grober Überblick? Gruß, Jürgen
Hallo, das Problem ist: du brauchst 2 Synchronisationen. Bisher wurde nur die erste besprochen, damit hast du einen Atari-Takt und einen Atari x 8-Takt. Aber für den Ablauf muss deine Logik sich nach dem Atari-Takt richten, z.B. wann ein Read-Zyklus anfängt. Im Prinzip musst du den Achtfach-Takt also durchnummerieren von 1 - 8 mit 1 = Start eines Atari-Taktes, so dass die Logik immer weiss, wo sie sich im Atari-Zyklus befindet. Sonst gibt es 8 verschiedene "Phasenlagen". Du könntest dazu die Teilerbits verwenden (wäre meine Lösung) oder zumindest den Subzyklus 1 mit einem zusätzlichen Signal kennzeichnen. Gruss Reinhard
Jürgen Van radecke schrieb: > Langt das als grober Überblick? Ja, danke. Klingt nach einem interessanten Projekt. Auf den ersten Blick habe ich da aber jetzt nichts entdecken können, was eine genaue Taktsynchronisierung nötig machen würde. Falls der AVR im freilaufenden Betrieb für den Wost-Case (Eingang ändert sich einen AVR-Takt nachdem er gelesen wurde) wirklich zu langsam ist, reicht eine Ausrichtung der Schleifendurchläufe am Atari-Takt, was gleichzeitig auch den Jitter verkleinert. Die Hauptschleife würde also auf die Atari-Taktflanke warten, die Eingänge lesen, die Ausgänge schreiben und wieder zum Anfang springen. [Edit:] Andererseits könnte das bei 8..9 (bei 16MHz) AVR-Takten pro Atari-Takt schon ein bißchen eng werden, je nach dem, wie komplex die Dekodierlogik ist. Wieviele Systemtakte braucht denn der Atari, z.B. für einen Read aus dem Speicher?
Reinhard Kern schrieb: > Du könntest dazu die Teilerbits verwenden (wäre meine Lösung) oder > zumindest den Subzyklus 1 mit einem zusätzlichen Signal kennzeichnen. Moin, jop, da hast Du recht. Ich werde es mit dem Start des Zyklus probieren. Ich werde - das kann etwas dauern, alles rein privat und in Freizeit - mal sehen, die ganzen Tipps mit meinem ersten Design aufzubauen und zu schauen, was bei ´rumkommt. Danke, Jürgen
R. Max schrieb: > wirklich zu langsam ist, reicht eine > Ausrichtung der Schleifendurchläufe am Atari-Takt, was gleichzeitig auch > den Jitter verkleinert. Die Hauptschleife würde also auf die > Atari-Taktflanke warten, die Eingänge lesen, die Ausgänge schreiben und > wieder zum Anfang springen. Jop, das hatte ich auch vor, daß Atari-Taktsignal liegt natürlich auch am µP an und wird abgefragt. Ich werde die ganzen Tipps nochmal zu Hause in Ruhe sortieren und prüfen, ob ich wirklich eine Synchronisität benötige - evtl. habe ich mich da gedanklich auch einfach nur verrant. > Andererseits könnte das bei 8..9 (bei 16MHz) AVR-Takten pro Atari-Takt > schon ein bißchen eng werden, je nach dem, wie komplex die Dekodierlogik > ist. > Wieviele Systemtakte braucht denn der Atari, z.B. für einen Read aus dem > Speicher? Also ein Zugriff auf den I/O Bereich (beim Atari im Segment $D0xx-$D7xx eingeblendet) benötigt für einen Lese- oder Schreibzugriff mindestens 6 Takte (6502-Takte), d.h. der AVR hätte mit Sicherheitsreserve mindestens 40 Takte (AVR-Takt bei 8 * Atari-Takt) Zeit, entsprechende I/O Ports zu programmieren. Das sollte langen, wenn ich mit Tabellen arbeite, in denen die Bitkombinationen vorher abgelegt sind. Und in der Realität funken ja Interrupts usw. dazwischen, so daß es eher unwahrscheinlich ist, daß massive sequentielle Änderungen erfolgen. Dennoch wird das natürlich genau geprüft :) Danke & Gruß, Jürgen
öha ... ich denk das wird beim 8-fachen takt haarig vom Timing her. er hat dann zwischen den Takten maximal 8 Systemtakte Zeit bei 13 i/o die zu verwursteln sind, also 2 Ports in Register laden, verwursteln und wieder ausgeben. Ich denk das wird mit dem Timing eng, da der Atari wahrscheinlich auch nicht auf den nächsten Takt zum Einlesen warten wird. Empfehle CPLD oder FPGA Das CPLD-Board von Pollin hab ich grad in der Mache, ist nicht ohne was dass Ding so leisten kann. Soweit ich das als Einsteiger beurteilen kann natürlich.
Jürgen Van radecke schrieb: > Also ein Zugriff auf den I/O Bereich (beim Atari im Segment $D0xx-$D7xx > eingeblendet) benötigt für einen Lese- oder Schreibzugriff mindestens 6 > Takte (6502-Takte), d.h. der AVR hätte mit Sicherheitsreserve mindestens > 40 Takte (AVR-Takt bei 8 * Atari-Takt) Zeit, entsprechende I/O Ports zu > programmieren. So viel Zeit hat der AVR nicht. Der Output des Dekoders muß ja schon ziemlich am Anfang des Zugriffs zur Verfügung stehen, denn der angesprochene Speicher- oder I/O-Baustein braucht ja auch nochnal Zeit für seine interne Adreßdekodierung und das Übernehmen oder Bereitstellen der Daten.
Fhutdhb Ufzjjuz schrieb: > Empfehle CPLD oder FPGA > > Das CPLD-Board von Pollin hab ich grad in der Mache, > ist nicht ohne was dass Ding so leisten kann. > Soweit ich das als Einsteiger beurteilen kann natürlich. Schicke doch mal bitte die Artikel-Nr. (per PN, damit´s kein Ärger hier wegen Werbung gibt, bitte) von Pollin. Ich habe bisher nichts gemacht mit CPLD... zum Einen, weil es da nichts Vernünftiges in DIL gibt und ich natürlich die ersten Prototypen auf Lochraster mache. Bin halt auch nur Hobbyist mit chronischem Geldmangel für teure Hobby-Projekte :-) Zum Anderen gibt es keine/kaum aktuelle CPLD, die auf 5V TTL Pegeln sauber arbeiten. Von anderen Bastlern und dessen Projekten weiß ich, daß z.B. die Xilinx-CPLD (die kleinen), die laut Datenblatt "5 Volt tauglich" sind und mit 3,3 Volt betrieben werden, in der Praxis sehr oft Probleme z.B. mit SRAMs (5 Volt Typen) oder anderen Gatterbausteinen haben. Solchen Problemen würde ich natürlich gern aus dem Wege gehen. Gruß, Jürgen
Jürgen Van radecke schrieb: > Schicke doch mal bitte die Artikel-Nr. (per PN, damit´s kein Ärger hier > wegen Werbung gibt, bitte) von Pollin. Einfach im Suchfeld "CPLD" eingeben, es gibt genau einen Treffer.
R. Max schrieb: > So viel Zeit hat der AVR nicht. Der Output des Dekoders muß ja schon > ziemlich am Anfang des Zugriffs zur Verfügung stehen, denn der > angesprochene Speicher- oder I/O-Baustein braucht ja auch nochnal Zeit > für seine interne Adreßdekodierung und das Übernehmen oder Bereitstellen > der Daten. Nee, das ist eben nicht erforderlich. Der "Trick" dieser Bankswitching-Module (nur bei diesen ist das Timing kritisch, beim Rest liefere ich sowieso die "Treibersoftware" mit und kann daher Rücksicht auf evtl. Timings nehmen) ist, daß ein Lese- und/oder Schreibzugriff auf den I/O Bereich z.B. Bank 15 eines 512 KByte EPROMs aktiviert. Die Bänke werden immer im gleichen Speicherbereich der CPU eingeblendet. Es ist technisch garnicht möglich, ein Bankswitching etc. zu adressieren und im gleichem Atemzug schon Code auszuführen bzw. Daten aus der neu selektierten Bank zu holen. Von daher hat der AVR immer mindestens 6 Takte 6502-Zyklen Zeit, die gewünschten Änderungen vorzunehmen, bevor der nächste Zugriff erfolgen kann. Das sollte eigentlich langen - ich werd´s merken :) Gruß, Jürgen
Ich hatte Dich am Anfang so verstanden, daß der AVR außerdem auch sozusagen "live" als Adreßdekoder arbeiten soll, sprich bei jedem Zugriff auf den entsprechenden Adreßbereich die Finger im Spiel hat. Wenn er aber wirklich nur bei Dummy-Zugriffen auf bestimmte Adressen reagieren soll, und Du dafür dann sogar 40 Takte Zeit hast, weil die Daten aus diesem Zyklus gar keine Rolle spielen, sollte es wirklich kein Problem sein, selbst ohne jegliche Synchronisation, einfach nur durch schnelles Pollen der Adreß- und ggf. Steuerleitungen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.