Hallo, ich bin kein E-Techniker, habe aber eine (viel zu starke) Neigung zu Oldschool Elektronik / Computer, etc. Ich habe auf einem ATmega328 @ 20 MHz ein VGA-Signal erfolgreich generieren können und erzeuge verschiedene Pixel-Muster in 64 Farben. Das VGA-Signal geschieht im timer interrupt, so dass der Prozessor eigentlich frei ist und vor sich hin springt. Um den nächsten Schritt zu gehen benötige ich RAM, um pixel strukturiert (x,y) setzen/lesen zu können. Die Idee ist, ein oder zwei SRAM Bausteine als VRAM einzusetzen. Damit möchte ich den VGA Signalgenerator vom eigentlichen Pixel-Geschehen entkoppeln, um eigene Grafiken zu erzeugen. Diese würden sonst im timer interrupt viel zu viele Zyklen benötigen. Eine Alternative wäre, mehrere ATmega328 einzusetzen. Einer kümmert sich um h/vsync und generiert interrupts, die an einen weiteren ATmega328 gesendet werden. Dieser kümmert sich um das treiben und beschreiben der SRAMs. Ziel ist, halbwegs schnelle Grafiken zu erzeugen, d. h. Echtzeit. Die Auflösung ist aktuell so ca. 256x256. Alles soll weiterhin auf einem Steckbrett laufen. Aufgrund mangelnder Lötfähigkeiten, bin ich leider auf DIPs beschränkt... Es handelt sich um ein reines Vergnügungsprojekt - ich will damit einfach nur Spass haben und weiter in die Tiefe gehen, was Signale, Busse, usw. betrifft. Evtl. hat jemand schon Erfahrungen mit so etwas gesammelt und kann ein paar Ratschläge geben ?!?! Danke und Gruss
Beschränkung auf DIL ist natürlich blöde... Ich würde in Richtung dual-port-RAM nachdenken, einer erzeugt unbelastet von der Ausgabe die Bilder, der andere holt sie sich und bastelt daraus das VGA-Signal. Ist die Frage, mit welchem Aufwand man sich ein dual-port-RAM aus Standardteilen zusammenbauen kann. Nach dem Sinn frage ich jetzt mal lieber nicht. Was du bis jetzt erreicht hast, ist doch schon nicht schlecht.
Der Sinn ist einfach nur purer Spass, Verständnis erlangen und ein guter Ausgleich. Sobald ich die RAM-Thematik und ein paar weitere Themen im Griff habe, möchte ich mit CLPDs, evtl. FPGAs anfangen und das Ganze dort übertragen. Aber erstmal will ich durch die basics durch. Ich schätze, dass ich meine Lötfähigkeiten verbessern muss, damit ich geeignetere ICs verbauen kann - z. B. finde ich keine dual port SRAMs in DIL.
Mit zwei AVRs gleichzeitig auf einen RAM-Baustein zugreifen ist schwierig. Du könntest aber zwei SRAMs umschaltbar an zwei AVRs anschließen. Also ein AVR liest aus "seinem" AVR die Daten aus und erzeugt das Bild, während der andere AVR das nächste (oder übernächste...) Bild im anderen SRAM erzeugt. In der VSync-Zeit kannst du - wenn das Bild fertig ist - dann das SRAM umschalten, um Tearing zu vermeiden. Nachtrag: Du könntest auch Dual-Port DRAM benutzen. Den Refresh kannst du dir sparen, weil dein Bildgenerator den Inhalt sowieso ständig ausliest.
:
Bearbeitet durch User
Gute Idee, die ich mir vorstellen kann. Eine Sache macht mir jedoch gerade Sorgen: bei 256x256x8 bit = 65.536 px @ 20 MHz benötige ich bei utopischen 1-cycle Schreibzugriffe 3,2768 ms um ein volles frame zu zeichnen. Da wird aber noch mehr kommen, denn die Zeichenroutinen (auch wenn es nur Kopien aus anderen Speicherbereichen sein sollten) werden ebenfalls ein paar cycles benötigen und das 'durchschieben' der Werte vom Prozessor ins externe RAM erst recht. Folglich ist es kaum möglich mit den gewählten Bausteinen so etwas umzusetzen, richtig gedacht ?! Könnte man nicht eine Art "DMA" basteln ? Mir ist klar, dass ich ein ARM7TDMI einbauen könnte und alle Probleme wären gelöst, aber genau um diese Art Nüsse knacken geht es mir hier..
Dualport-RAM wird man wohl schwerlich in der erforderlichen Geschwindigkeit und Größe finden. Meines Erachtens ist es einfacher, nur einen Controller zu verwenden und den Geschwindigkeitsverlust durch geschickte Programmierung auszugleichen. Das Videobeispiel basiert auf einem Mega1284P (25MHz), 128K RAM und einem simplen 8-Bit-Register mit Tristate. Dargestellt werden entweder 320x240 Pixel (256 Farben, 1 Screen) oder 160x120 Pixel (256 Farben, 4 Screens). Im Beispielvideo nutze ich zwei Screens als Bildpuffer, die wechselseitig beschrieben werden und die anderen beiden Screens als Z-Buffer. Angesteuert wird das Ganze seriell mit max. 250KBit/s, wobei ich bisher nur 115K genutzt habe. Die Figuren werden intern in einer Liste von Dreiecken gespeichert, zum Zeichnen/Drehen/Skalieren müssen nur kurze Befehlssequenzen geschickt werden. Jörg
Joerg W. schrieb: > Das Videobeispiel basiert auf > einem Mega1284P (25MHz), 128K RAM und einem simplen 8-Bit-Register mit > Tristate. Das ist ziemlich gut! Hat der Mega128 jedoch nicht ein ext. Memory-Interface ? Damit werden doch die 128K RAM direkt vom Prozessor adressiert. Seriell bedeutet, dass die einzelnen bytes nacheinander in das Register geschoben werden, richtig ? Wird dafür die MCU SPI Schnittstelle verwendet ?
Die interessanten Dual Port SRAMs gibt es leider nicht in DIL, aber ich sehe gerade, dass es Adapter dafür gibt. Könnt ihr sowas empfehlen ? Das würde alles dramatisch vereinfachen...
Wenn du dich vor diskreter Logik nicht schreckst, ließe sich so eine "Grafikkarte" relativ leicht implementieren. Man nehme: - Einen AVR mit externem Speicherinterface (z.B. ATMega8515) - Einen Cache-RAM - Zeilen- und Spaltenzähler - Eine Logik, die den Zugriff auf den RAM im richtigen Moment umschaltet - Ein paar Multiplexer und ein Register Wenn die Zugriffe des AVR auf den VRAM deutlich länger dauern, als ein Zugriff der Grafikkarte selbst, lässt sich das relativ einfach (ohne Latches) multiplexen. Und das ist meistens der Fall. Dann können AVR und Graka abwechselnd auf den RAM zugreifen, ohne sich dabei in die Quere zu kommen. Man muss nur darauf achten, die Setup- und Hold-Anforderungen des RAMs nicht zu verletzen. Jonathan
OK, ich habe erstmal genug input zum Nachdenken, vielen Dank an alle.
Nein, der Mega1284P hat kein externes Speicherinterface. Die Adressleitungen werden von I/O-Pins angesteuert. Es geht auch ohne Übertakten mit 16MHz, aber die Geschwindigkeit ist dann ungefähr noch reichlich die Hälfte. In der Ursprungsversion war ein Mega644 drin, der hatte mir dann aber zuwenig RAM für frei definierbare Zeichensätze. Wenn man bei den aktuellen 25MHz nur 256 Pixel benutzt und rechts/links einen scharzen Rand lässt, kann man die Geschwindigkeit auf fast das Doppelte steigern. Allerdings braucht es dann noch ein wenig Zusatz-Hardware, damit alle Pixel gleich breit sind. Ohne die haben das erste und das letzte Pixel eine andere Breite. Angesteuert wird per UART mit 256 Bytes FIFO, wobei im "Normalbetrieb" der TX-Pin als CTS-Signal fungiert. Im Screenshot-Modus (über Kommando) wird über TX gesendet und RX dient als RTS Signal. Das kommt von daher, dass einfach keine Pins mehr frei waren. Für das RAM (IDT71024S15) musste ich mir auch einen SOJ->DIL Adapter bauen, da ich keine schnellen RAMs in DIL gefunden hatte.
Hast du das schon gesehen? Beitrag "Mini-Computer mit BASIC" Beitrag "AVR-ChipBasic2 - BASIC-Computer mit ATMega 644" Joerg hat da einen kompletten Basic Interpreter laufen UND der Mega erzeugt nebenher auch noch ein PAL Signal. OK, er hat einen Mega644 genommen und hat damit mehr SRAM. Und genau dasselbe würde ich dir auch empfehlen. 2 Controller mit Dual Ram zu koppeln ist um einiges aufwändiger als ein einzelner Prozessor der über genügend Speicher verfügt. Und wegen Geschwindigkeit. Wenn Jörg es schafft, da einen Interpreter 'nebenher' noch in passabler Geschwindigkeit laufen zu lassen, dann kann ich mir nicht vorstellen, dass deine Grafiken da ein allzugrosses Problem darstellen.
Anhand der genannten Infos und meiner Bauteil-Recherche habe ich mich entschieden: - Eine MCU einsetzen, allerdings nicht den 328P. - ATMega8515 soll es werden. Dieser bietet ein SRAM-Interface, so dass ich den RAM Baustein darüber ansteuern werde. Damit spare ich sicher ein paar Zyklen und die MCU kümmert sich weiterhin um das VGA-Signal. Allerdings werde ich diesen auf 20 MHz Übertakten müssen, da ich nur einen 20 MHz Oszillator da habe. - Als SRAM habe ich mich gegen Dual Port entschieden, da diese entweder zu wenig Platz bieten oder aber deutlich aufwendiger zu löten sind. Ähnliches gilt für Cache RAMs. Deshalb habe ich ein paar einfache 32Kb(yte) 8-Bit SRAMs mit unterschiedlichen Zugriffs-Zeiten bestellt (alles so zwischen 20 ns und 55 ns). Bis alles ankommt, werde ich jedoch mit dem 328P auf den Speicher über die serielle Schnittstelle zugreifen. Mal sehen wie flott bytes rein- / rausgeschrieben werden können. Bei den Grafikroutinen geht es mir eigentlich nur um Kopier-Operationen (-> um Sprites zu zeichnen), weniger um Füll-, Linien-, Kreis-Routinen, o.ä. Die Basic-Geschichte auf AVR ist schon beeindruckend!
Walantis G. schrieb: > Ähnliches gilt für Cache RAMs. Diese Cache-RAMs kommen meistens in DIP mit Größen von 8kB bis 64kB und Zugriffszeiten um 15ns. Die sind ganz nett für Basteleien. Vermutlich ist der RAM mit 32kB und 20ns genau so ein Cache-RAM. Bezüglich Pixel-Ausgabe: Mit dem ATMega8515 kannst du dir eine Art schnelles DMA basteln. Häng den DAC direkt an den Bus des RAMs, aktiviere vor der Ausgabe einer Zeile den DAC und führe dann jede Menge Lesezugriffe vom RAM aus. Deine Ausgaberoutine sieht dann so aus (Pseudoassembler):
1 | LD Z, FirstPixelAdr |
2 | SBI PORTD, DACEnable |
3 | LD r16, Z+ |
4 | LD r16, Z+ |
5 | LD r16, Z+ |
6 | ... |
7 | LD r16, Z+ |
8 | CBI PORTD, DACEnable |
Ich glaube, das habe ich bei ELM-Chan mal gesehen. Viel Erfolg Jonathan
Du solltest vielleicht eher mit dem Parallax Propeller spielen. Der ist für solche Sachen aufgrund seiner ungewöhnlichen Architektur besser geeignet. Schau mal hier http://www.yourwarrantyisvoid.com/2010/11/19/guidemo-a-full-vga-library-for-the-propeller/ http://learn.parallax.com/propeller-c-simple-devices/vga-text-display fchk
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.