Hi!
Ich baue bzw. Plane derzeit eine kleine, einfache Spielkonsole zum
Anschluss an den Fehrnseher (SNES, SEGA..).
Damit der Hauptprozessor (ATMega644) genug Zeit hat, sich mit Aufgaben
wie Abfragen der Gamepads oder weiterleiten der Grafik/Audio Anweisungen
vom Spielmodul zu beschäftigen, soll ein weiterer Controller
(ATMega16-16) das Bild auf dem Fehrnseher über S-Video erzeugen.
Als Grafikspeicher möchte ich gern zwei 628512-55 SRAM Module (512kB,
55ns) benutzen, in dem dann alle benötigten sprites vorgeladen sind.
Noch dazu soll eine Art Liste mit X,Y,Breite,Hoehe,Teilung und ID
Vorliegen.
Diese Liste Arbeitet der Grafikprozessor dann jede X Frames pro Sekunde
ab und gibt alles auf dem Bildschirm aus.
Soweit kein Problem. Ich habe mir nun schon viele Beiträge zu SRAM und
deren Verwendung durchgesehen, sogar meinen gefunden
([[Beitrag "externes SRAM"]]) - nun wäre es aber
Sinnfrei, wenn der Hauptprozessor nun erst die Daten an die GPU sendet
und der GPU diese dann in den SRAM schifft. Sinnvoller wäre es, wenn die
"CPU" den SRAM direkt beschreibt bzw. die Liste Löscht und Erneuert -
während die GPU nur ausliest und die Daten auf dem Bildschirm ausgibt.
Meine Frage also - reicht es, wenn die Leitung READ ENABLE vom GPU auch
an die CPU angeschlossen wird, und solange READ ENABLE Aktiv ist,
schreibt die CPU nichts neues in den Speicher - wird sie Deaktiviert,
Aktiviert die CPU WRITE ENABLE, schreibt die neuen Daten, und gibt den
SRAM dann wieder frei ?
Demnach müssten alle Datenleitungen an beiden Microcontrollern anliegen
- funktioniert das ganze dann mit XMEM?
z.b. so:
1
void XMEM_config(void)
2
{
3
/* XMEM Interface konfigurieren:
4
* aktivieren, no-wait-state, alle Adressbits werden verwendet
5
*/
6
MCUCR = _BV(SRE);
7
// SFIOR = _BV(XMM2); // wenn JTAG angewendet wird müssen die Bits PC7…4 released sein!
8
}
9
void write_data(void)
10
{
11
/* Zugriff auf externen Speicher
12
* Um auf externen Speicher zugreifen zu können wird lediglich ein Pointer benötigt
@ Denis Germ (lunatix)
>Meine Frage also - reicht es, wenn die Leitung READ ENABLE vom GPU auch>an die CPU angeschlossen wird, und solange READ ENABLE Aktiv ist,>schreibt die CPU nichts neues in den Speicher - wird sie Deaktiviert,>Aktiviert die CPU WRITE ENABLE, schreibt die neuen Daten, und gibt den>SRAM dann wieder frei ?
Alles nicht ganz so einfach. Der Datenzugriff durch die beiden uC muss
gesteuert werden. Das kann man sinnvollerweise so machen wie die
Spielkonsolen von damals. Feste Zuteilung. Spich, Controller 1 darf bei
jedem 1. Takt zugreifen, Controller 2 bei jedem 2. Damit ist die
Bandbreite gerecht aufgeteilt. Alles andere wird eher kompliziert.
>Demnach müssten alle Datenleitungen an beiden Microcontrollern anliegen>- funktioniert das ganze dann mit XMEM?
Da hab ich meine Zweifel. Man könnte ggf. die Controller soweit
sychronisieren, dass das so wie oben beschrieben klappt. Braucht
wahrscheinlich einen CPLD und Knoff HoFF.
Deutlich einfacher ist die Verwendug eines Dual Port RAMs, dort kann
jeder uC wahlfrei auf den Speicher zugreifen. Cypress macht die Dinger.
MFG
Falk
Hey, danke für die schnelle Antwort =)
Nun, die Variante jeder erste/zweite Takt ist Interressant, und sicher
auch Kostengünstiger - und eigentlich sollte es nicht auf die
Geschwindigkeit gehen, denn man sollte Bedenken, das Nintendo das damals
mit ca. 3,5... Mhz realisiert hat und wir hier von 16-20Mhz reden =).
Da tut sich eine andere Frage auf: gibt es eine Methode, ohne den oft
erwähnten XMEM auf dem SRAM zu schreiben/Lesen? Bisher habe ich überall
von XMEM gelesen, jedoch nicht, wie man das ganz ohne realisiert - denn
dann müsste ich eigene Befehlsroutinen schreiben, die Speicher auf dem
SRAM zuweisen und Verwalten.
Ich werde in den nächsten Tagen denke ich mal ein paar kleine Prototypen
aufbauen, TV Ansteuerung und Speicherverwaltung, mit IC Sockeln lässt
sich da eventueller Schaden ja leicht minimieren =)
Grüße, Lunatix
@ Denis Germ (lunatix)
>Geschwindigkeit gehen, denn man sollte Bedenken, das Nintendo das damals>mit ca. 3,5... Mhz realisiert hat und wir hier von 16-20Mhz reden =).
Eben. Und man denke an den guten, alten AMIGA (RIP), der mit aus
heutiger Zeit schnarchlangsamen 7MHz eine Supermaschine war.
>Da tut sich eine andere Frage auf: gibt es eine Methode, ohne den oft>erwähnten XMEM auf dem SRAM zu schreiben/Lesen?
Sicher, durch einfaches Bitwackeln an den Ports. Wird aber deutlich
langsamer.
>Ich werde in den nächsten Tagen denke ich mal ein paar kleine Prototypen>aufbauen, TV Ansteuerung und Speicherverwaltung, mit IC Sockeln lässt>sich da eventueller Schaden ja leicht minimieren =)
Vor dem Aufbauen sollte man nachdenken und planen. Denk amal drüber nach
wie man die AVRs synchronisieren könnte.
MfG
Falk
Hallo,
kann man die zwei prozessoren nicht aus einer Taktquelle versorgen, also
einen Quarz der dann den externan Takteingang bedient.
Bei einem Prozessor mit negiertem takt, so dass dieser seine Signale
entgegen gesetzt zu dem anderen Prozessor verwendet. Beide müssten dann
allerdings auf einem gleichen (oder teilbarem von dem 1., Die GPU könnte
ja eventuell mit dem halben) Takt laufen.
Ich weis allerdings nicht ob nicht noch eine Sysncronisation notwendig
ist, weil eventuell nicht garantiert ist das die Reset-Rouetinen gleich
"schnell" ab laufen.
In dem Fall könnte das Thema zwei Latches und eventuell etwas
zusätzlicher Logik gelöst sein. Die Latches brauchst Du ja sowieso für
den Anschluss des externen Speichers.
Auf jeden fall musst Du dazu mal die Timing Diagramme im Datenblatt
studieren.
Schreib bitte nachher mal wie Du das gelöst hast ...
Wolfgang
Ah noch ein Idee,
weil ich jetzte erst den Kommentar mit dem Token und "fairness" gelesen
habe. Ich glaube das muss gar nicht fair sein. Wenn man davon ausgeht
dass die GPU zeitkritisch für die Erzeugung des Video Signal ist, dann
kann man der den Vorrang geben. Man könnte sogar mittels Logik, den
Hauptprozessor an halten sobald die GPU zu greift. Das bringt dann
natürlich Probleme mit Timern im Hauptprozessor.
Hier http://www.rickard.gunee.com/projects/video/pic/pong.php ist
übrigens ein Beispiel für eine schmale Lösung eines einfachen
Videospiels. Das ist auf Deine Anforderungen natürlich nicht wirklich
übertragbar, gibt Dir aber eventuell Hinweise.
Was spricht eigentlich dagegen eine echte GPU zu verwenden? Zu Teuer?
Eine GPU bringt normalerweise Lösungen für das Synchroonisationsproblem
gleich mit.
Was spricht denn gegen ein Dualported RAM, so haben es früher doch die
meisten Guten Graphikkarten gemacht?
Gruß
Tom
P.S: Verkaufe immer noch 4 XBee Pro Module
@ Wolfgang Heinemann (frickelkram)
>Was spricht eigentlich dagegen eine echte GPU zu verwenden?
IMO nix.
> Zu Teuer?
Kaum ;-)
>Eine GPU bringt normalerweise Lösungen für das Synchroonisationsproblem>gleich mit.
Könnte man in einen mittleren CPLD packen, der synchronisiert sich auf
den AVR und greif "in den Lücken", wenn der AVR gerade keinen Zugriff
macht. Oder der AVR darf nur währen der horizontalen und vertikalen
Austastlücke zugreifen. Hmmm, jetzt wo ich das so sage kann man das auch
mit zwei AVRs machen ;-). Dann reicht ein normaler SRAM und bissel
TTL-Kram.
MFG
Falk
Es gab hier mal ein Projekt für eine Platine zur Anstererung großer
Grafik-LCD-Panels, das auch VGA erzeugen konnte, auf Basis eines
SeikoEpson S1D13700. So etwas könnte man als GPU ansehen - verwaltet den
Videospeicher allein und hat einen Datenbus zur CPU. Ist aber vielleicht
schon zu aufwendig, wenn man nur ein Fernsehbild erzeugen will. Es hat
auch schon jemand eine CPLD-Grafikarte gebaut, findet man im Netz.
Hi Falk,
also ich bin mir sicher das es simple geht. Der gute alte Apple ][
konnte das auch
http://mirrors.apple2.org.za/Apple%20II%20Documentation%20Project/Computers/Apple%20II/Schematics/Addendum%20to%20the%20Apple%20II%20Reference%20Manual.pdf
.
Die Frage ist halt in wie weit man die GPU braucht. Pixelgrafik ... eher
nicht. Vektorgrafik ... ok, dann könnte man über die GPU nach denken.
Das sehe ich aber nur dann wenn man wirklich viele Verktoren zeichnen
möchte und die Main-CPU zu sclapp dafür ist. Dann denke ich, das es aber
unter umständen mehr Sinn macht einen größeren Main Prozessor zu wählen,
der das Thema dann locker mit erledigt. Ich glaube fast das solch eine
Lösung günstiger kommt ... die Dual-Port RAMS sind auch nicht wirklich
billig, oder?
Die Usebox ist an der Stelle ein guter Hinweis, der zeigt das es mit
wenig Hardware Aufwand geht.
In irgendeinem Posting hier habe ich eben die Frage gesehen, warum denn
zwei Prozessoren nötig wären,
Meine Überlegung ist folgende: nach Berichten/Aufbauten von anderen
Programmierern hat die CPU eine Auslastung von 60% - und bei Spielen wie
z.b. RPGs wie ... Secret of Mana (nicht, das ich es programmieren will,
aber die Möglichkeit wäre trotzdem schön) braucht man dann doch etwas
mehr Leistung denke ich.
Allerdings möchte ich das System auch nicht so aufbauen, das der
Hauptprozessor das Spiel steuert - das Spiel soll seperat auf einem
ATMega sitzen, welcher Grafikanweisungen, Audio und Spieldaten an den
Prozessor sendet, welcher danach alles Verteilt.
Ich werde nun ersteinmal eine VGA Lib schreiben und meinen Fehrnseher an
mein Steckbrett "mounten" ;)
Grüße, Denis
Thread beobachten
Seitenaufteilung abschalten