Suche EF9366 Grafik-Controller

Karlheinz Linder schrieb:

[EF9366]

Das muß nicht mal sein.

Dieser Chip wurde grundsätzlich im Betrieb sehr warm und das Timing dabei hier und da etwas kritisch. Ich habe noch eine alte ECB-Grafikkarte damit, bei der habe ich damals auf den CRTC einen Kühlkörper geklebt, da es sonst bei längerem Betrieb auch zu Pixelfehlern kam. Ich erinnere mich nicht mehr an die Details, aber irgendein Timing lief temperaturabhängig aus dem Ruder und das war so am einfachsten zu beheben.

Bei Deinem Gerät könnte eine Alterung anderer Teile hinzukommen, so daß nun kritisch wird, was vorher noch keine Auswirkungen hatte.

Versuch doch erstmal, das Teil besser zu kühlen (aufgeklebter Kühlkörper und evtl. kleiner Lüfter dazu). Abgesehen davon, daß damit der Fehler vielleicht schon behoben ist, ist das auch der weiteren Lebendauer des Bauteils zuträglich...

Tilmann

Reply to
Tilmann Reh
Loading thread data ...

Interesse daran, einen Grafikcontroller zu implementieren, hätte ich schon. Habe hier noch ein paar von diesen 1 $ QVGA Sparkfun Displays herumliegen, mit Backlight (die Displays gibt es leider nicht mehr zu kaufen und sind scheinbar auch nicht mehr in Produktion), die ich gerne mal zum laufen bringen würde. Antiquarische Bausteine nachzuprogrammieren finde ich aber nicht so interessant. Also ein paar unsinnige Sachen rauslassen, wie Lightpen in Zeiten von TFT-Displays, und ein paar modernere Sachen reinbringen, wie Bitblitting, wäre schön.

Hier meine Idee:

- Einsatzgebiet: kleine Microcontroller ohne Grafikcontroller, die auf normalen VGA Bildschirmen, OLEDs, Playstation Portable Displays usw., Text und Grafik darstellen möchten, z.B. Display einer Heizungssteuerung, Wetterstation, Messgerät, VGA-Testbildgenerator, PacMan-Spiel usw.

- generische Auflösung: da es VHDL ist, kann man es einfach für seinen jeweiligen Anwendungszweck neu synthetisieren und braucht daher nicht aufwendige Logik verschwenden, um das dynamisch änderbar zu machen. Um das Design nicht allzu komplex zu machen, würde ich auch die Bittiefe generisch vorgeben. Da keine Entity was über RGB wissen braucht (bis auf FBAS-Generierung), reicht hier die Angabe von Bits per Pixel. Damit wäre dann z.B. ein 6:5:6 Modus machbar, wenn man einfach die Ausgänge entsprechend auf DA-Wandler schickt, oder auch schwarz/weiß, oder 2:2:2, was man dann extern sogar mit einem einfachen R2R-Netzwerk in analoge Signale konvertieren kann.

- modularer Aufbau: die einzelnen Funktionen werden als einzelne Entities entwickelt, damit man die auch möglichst unabhängig in anderen Projekten einsetzen kann. Folgende Entities erscheinen mir sinnvoll:

- Framebuffer: kann internes Blockram sein, oder z.B. auch externes SDRAM. Erstmal nur Blockram, da das einfacher in der Ansteuerung ist, weil man beliebige Bittiefen direkt angeben kann.

- Ausgabeeinheit: liest den Framebuffer aus, ggf. mit Caching und generiert das Ausgangssignal, z.B. VGA oder FBAS. VGA Ausgabe habe ich vor ewigen Zeiten mal in Verilog implementiert, siehe hier:

formatting link
, lässt sich aber recht leicht in VHDL umschreiben

- Grafikbeschleuniger: ein einfacher Move-Blitter, also Zielpunkte werden durch Quellpunkte ersetzt. Man kann aber eine Farbe angeben, die nicht kopiert wird, um transparente Bereiche auszusparen. Außerdem: Linien zeichnen und Rechtecke füllen.

- Microcontroller Zugriff: hier würde ich erstmal eine SPI-Schnittstelle implementieren, da viele Microcontroller sowas heute anbieten. Realtime-Anwendungen, z.B. flackerfrei Videos darstellen, sind sowieso nicht möglich mit dem System und kleinen Microcontrollern, daher ist das keine große Einschränkung und es spart Pins. Einen extra VSync-Ausgang für Interrupts würde ich aber noch spendieren.

Da die Architektur recht einfach ist, braucht man nicht viel Register, sondern könnte ein Kommando-Interface nehmen, wie man es von seriellen Flashs her kennt: Erst ein Kommandowort, dann die Daten. Hier ein Vorschlag, was man aber später noch leicht erweitern kann, leichter als wenn man Register festlegen würde:

Kommando setFramebufferStart Parameter: 24 Bit Wert. Legt den Start des Framebuffers fest, wie er von der Ausgabeeinheit verwendet wird. Wird erst mit dem nächsten VSync übernommen.

Kommando setFramebufferPitch Parameter: 16 Bit Wert, der beim Bildaufbau zur aktuellen Framebuffer-Adresse jeweils hinzuaddiert wird, um die Adresse der nächsten Zeile zu ermitteln. Damit kann man ein Fenster innerhalb eines virtuellen größeren Bereichs darstellen.

Kommando setDestinationStart Parameter: wie setFramebufferStart, aber für alle Zeichenoperationen für den Zielbereich. So kann man z.B. in einen Offscreen-Bereich schreiben, während der aktuelle Framebuffer dargestellt wird, um Artefakte während des Updates zu vermeiden.

Kommando setDestinationPitch Parameter: wie setFramebufferPitch, aber für alle Zeichenoperationen für den Zielbereich.

Kommando setSourceStart Parameter: wie setFramebufferStart, aber gilt nur für die bitblit-Funktion, um den Quellbereich auszuwählen.

Kommando setSourcePitch Parameter: wie setFramebufferPitch, aber gilt nur für die bitblit-Funktion, um die Zeilenlänge des Quellbereiches festzulegen.

Kommando setColor Parameter: setzt die Farbe für alle nachfolgenden Operationen. Entsprechend der Bittiefe Anzahl Bytes, wobei zuviel gesendete Bits einfach ignoriert werden.

Kommando drawLine Parameter: Start und Endpunkt, jeweils als 16 Bit Koordinaten.

Kommando fillRect Parameter: Start und Endpunkt, jeweils als 16 Bit Koordinaten.

Kommando bitblitSize Parameter: Breite und Höhe der Bitblitting-Operationen, jeweils als 16 Bit Werte. Damit kann man z.B. bei Zeichensätzen mit fester Größe für alle Buchstaben einmal die Größe setzen und spart sich einiges an Datenübertragungen bei den Bitblit-Funktionen.

Kommando bitblit Parameter: jeweils linke obere Koordinaten im Startbereich und im Zielbereich als 16 Bit Werte.

Kommando bitblitTransparent Parameter: wie bitblit. Die aktuell per setColor gesetzt Farbe wird als Transparent angenommen, also Pixel im Quellbereich in dieser Farbe werden im Zielbereich nicht geschrieben.

Kommando writeFramebuffer Parameter: 24 Bit Adresse, gefolgt von einem Bitstrom der Daten, die ab dieser Adresse geschrieben werden sollen. Damit könnte man z.B. Zeichensätze in einem Offscreen-Bereich laden.

Alle Koordinaten und Adressangaben beziehen sich auf Pixeladressen. Daher braucht man für den Framebuffer-Start auch 24 Bit, da man z.B. 307.200 Pixel bei einer 640x480 Auflösung hat. Die Bittiefe legt dabei nur fest, welche Bitbreite das Blockram hat, was mit der Pixel-Einheit als Adresse direkt adressiert wird, sofern möglich. Zumindest bei Altera kann man problemlos Blockrams mit 1, 2, 3... Bits Datenbus definieren, sodaß also auch 1 Bit schwarz/weiss Daten direkt bitweise adressierbar wären.

Man kann jeweils nur ein Kommando schicken. Eine weitere Busy-Leitung zeigt an, wann das Kommando fertig ist. Wir kommen also mit nur 5 Anschlüssen aus und somit können auch noch sehr kleine Microcontroller den Grafikcontroller verwenden:

SPI Chipselect SPI Data (es wird nur die Richtung CPU->Grafikcontroller gebraucht) SPI Clock VSync Busy

Könnte man noch ein Pin einsparen, wenn man auch einen SPI Data Anschluss in die andere Richtung spendiert, aber dann müsste man VSync und Busy pollen. Viele Anwendungen brauchen VSync wohl sowieso nicht, sodaß sich das also nicht lohnt.

Auf der Ausgabeseite für VGA gibt es folgende Pins, hier als Beispiel für eine Ausgabe mit 64 Farben:

rot[2] grün[2] blau[2] HSync VSync

Das ganze läuft alles synchron mit dem Pixelclock. Es wird Dual-Port Blockram verwendet, sodaß man ohne viel Aufwand gleichzeitig blitten und den aktuellen Framebuffer anzeigen kann, also zwei Read-Ports und ein Write-Port. Ich hoffe das Xilinx-Teil kann das auch, sonst müsste man es höher takten oder einen breiteren Datenbus zum Blockram nehmen (Vielfaches der Bittiefe) und ein wenig mehr Logik programmieren.

Für diese in einigen Teilen abgespeckte Variante wie eben beschrieben, würde ich vielleicht 2 Wochenenden brauchen. Den genauen Funktionsumfang können wir aber noch diskutieren, falls noch einer Wünsche hat, was unbedingt mit rein sollte. Falls das Modul SDRAM hat, wären höhere auflös

Wenn du mir ein Muster des GODIL48 schickst, dann kann ich das dafür programmieren (Adresse gibt es auf meiner Firmenseite). Den VHDL-Quelltext würde ich dann unter der BSD-Lizenz zur Verfügung stellen, also frei verwendbar für alles, wenn mein Name irgendwo erwähnt wird. Ich habe hier auch ein Original Xilinx Platform Cable USB II, womit ich das Flash programmieren kann, falls das Modul ein JTAG-Anschluss hat.

--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Reply to
Frank Buss

Projekt

Hallo, den VHDL Code k=F6nnt ihr haben wenn ihr wollt. Aber als "plug in replacement" f=FCr einen Original GDP ist die VHDL- Implementierung nicht geeignet da ich nur auf funktionale Kompatiblit=E4t geachtet habe. Das original DRAM-Speicherinterface habe ich NICHT implementiert. Bei mir wird ein simpler SRAM (128kx8, 10 ns) als Video-Ram verwendet.

Gru=DF Andreas

Reply to
avg

Me2, aber ef9365

Wenn der OP einen TSA/SNA - 1/2 hat: da hab' ich ein Service-Manual davon. Ist aber viel Papier und schwer zu kopieren/scannen.

Ein anderes lohnenswertes Ziel wäre der TI TMS9914A GPIB/HP-IB/IEEE488-Controller. Die Statemaschinen aus dem Handbuch sind heute leicht verdauliche Kost für den VHDL-Compiler.

Gruß, Gerhard

Reply to
Gerhard Hoffmann

In article , "M.Randelzhofer" writes: |> |> Demnaechst gibts ein sehr preliminarymaessiges User Manual.

Dabei wäre ein "sehr vorläufiges Handbuch" doch viel weniger zu tippen gewesen.

Rainer

Reply to
Rainer Buchty

"Rainer Buchty" schrieb im Newsbeitrag news:h5pgil$i2s$ snipped-for-privacy@news.lrz-muenchen.de...

Dabei hatte ich mir schon auf die Finger gebissen und nicht "sehr preliminaryundoberconfidentialmaessiges User Manual " geschrieben.

Kein Interesse an so einem Board ?

MIKE

--
www.oho-elektronik.de
OHO-Elektronik
 Click to see the full signature
Reply to
M.Randelzhofer

In article , "M.Randelzhofer" writes: |> |> Dabei hatte ich mir schon auf die Finger gebissen und nicht "sehr |> preliminaryundoberconfidentialmaessiges User Manual " geschrieben.

Gib's zu, Du willst, daß mein Sprachzentrum implodiert.

|> Kein Interesse an so einem Board ?

Paßt noch ein Geriatronik-Interface drauf, daß ich das direkt an

5V-Logik klöppeln kann?

DIL40 und groß genug, daß z.B. der System09-Core draufpaßt, würde mich durchaus reizen.

Rainer

Reply to
Rainer Buchty

Wieso, ganz normales Denglish, und überhaupt: GLOBALISIERUNG !!!.

Welches Interface ? RS232 ? 5V tolerante treiber sind drauf. 48 bits. USB auch, nur der Treiber ist noch in der Mache.

Maximal ein XC3S500E sollte fuer die CPU alleine reichen, das Original hatte sicher weniger gates.

MIKE

--
www.oho-elektronik.de
OHO-Elektronik
 Click to see the full signature
Reply to
M.Randelzhofer

Aber dann klassisch mit einem Loetstift fuer jedes Bit :-)

--
SCNR, Joerg

http://www.analogconsultants.com/
 Click to see the full signature
Reply to
Joerg

Das sollte gehen:

formatting link

Da steht, es passt in ein 300K Gates Spartan IIe. Auf Mikes Board ist ein Spartan 3E mit 250K Gates. Also notfalls ein wenig abspecken, aber dann sollte es passen.

Interessanter finde ich aber einen eigenen Displaycontroller für den Anschluss an einen fertigen Microcontroller, da die CPU vom System09 ja nicht gerade die aktuellste ist und z.B. kein USB bietet. Was moderne Microcontroller alles bieten, passt in keinen bezahlbaren FPGA rein, sodaß die Kombination aus beiden optimal ist.

In Verbindung mit einem TFT-Display kann man schon einige schöne Dinge machen, wobei es aber gar nicht so einfach ist, ein kleines preiswertes Display zu bekommen. Neu gibt es z.B. ein 19" Display schon für 111 Euro:

formatting link

Will man dagegen ein schönes kompaktes 5" Display o.ä. kaufen, ist man gerne mal das doppelte los:

formatting link

Alleine so ein Display, mit weniger Auflösung und was kleiner, und wo man dann erstmal was zu basteln muß, gibt es zum Glück preiswerter:

formatting link

--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Reply to
Frank Buss

In article , "M.Randelzhofer" writes: |> |> Wieso, ganz normales Denglish, und überhaupt: GLOBALISIERUNG !!!.

Denglish ist böse. Wenn Du dann noch anfängst, Krawatten zu tragen, kann das ganz übel enden :)

|> Welches Interface?

Bus. Also nackige Signale. Idealerweise jeder Pin bidirektional ausgeführt, so daß man für beliebige DIL40-Altlasten ein Drop-in-Replacement (da! jetzt mach ich's auch schon...) draus stricken kann.

|> Maximal ein XC3S500E sollte fuer die CPU alleine reichen, das Original |> hatte sicher weniger gates.

Beim 6502 redet WDC ja von 3500 Gates, was der 6809 offiziell mal hatte, weiß ich nicht.

Rainer

Reply to
Rainer Buchty

Was sind für dich Gates? Ich hatte mal angefangen, den 6502 selber zu implementieren, dann aber keine Lust gehabt, das zuende zu programmieren. Gibt auch bereits mehrere fertige Implementierungen. Eine der kleinsten, das T65-Projekt, braucht 797 LEs. Hier eine Diskussion von mir dazu vor ein paar Jahren:

formatting link

--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Reply to
Frank Buss

In article , Frank Buss writes: |> |> Was sind für dich Gates?

Eigentlich NANDs, d.h. 1 Gatter = 4 Transistoren als Faustregel.

Aber in der realen Welt eher Marketinggefasel, speziell wenn's dann um FPGAs geht und deren ganz eigene Methoden, die Logikkapazität in Gatteräquivalente umzuformen.

Rainer

Reply to
Rainer Buchty

Rainer Buchty schrieb:

Das habe ich auch als erstes gesucht: einen 6809 Core für das FPGA Board :-) Aber im Prinzip tuts auch ein kleiner RISC Core. Interessant wird es ja, was man an Peripherie herumbaut. So ein kleiner LCD Controller mit Sprite Engine. Mal sehen...

M.Randelzhofer schrieb:

Dein Board hat aber einen XC3S250, oder? Wie viel SRAM sind noch mit dabei? Das "kleinere" GOP_XC3S200 hat ja schon 512 KB.

--
  Klaus Rotter * klaus at rotters dot de * www.rotters.de
Reply to
Klaus Rotter

Hallo Klaus,

auf dem neuen low cost GODIL48 Board ist kein SRAM, nur die 48 I/O's mit oder ohne Levelshifter (Bestückungsoption) und ein 16 bzw 32 MBit SPI Flash. Das FPGA hat einfach zu wenig pins. Die genauere Beschreibung kommt am WE mit dem vorlaufigen Manual.

Der Hauptzweck des Boards ist einen "legacy" chip im DIL .6" Raster zu ersetzten, oder einfach ein simples FPGA Board mit 48 I/O's und 2 input onlies im .1" Raster. Ein kleiner Trick ermoeglicht es, an fast beliebigen DIL pins GND oder VCC zu jumpern. Einen 6909, 6502, Z80, 8085, 8088, 8086, V20, V30, MC68008, AM2901, AM2903 oder dem besagten EF936x sollte man damit ersetzten können - der entsprechende core vorrausgesetzt.

Ach ja, eine langsame USB Anbindung ist auch vorgeseen, war zwar urspruenglich nicht geplanr, hat aber noch draufgepasst (auch Bestückungsoption auf der Unterseite). Diese Option ist aber wahrscheionlich erst gegen Ende des Jahres verfügbar.

Und als FPGA steht ein pinkompatibles XC3S100E oder XC3S250E oder XC3S500E zur Wahl. In dieser kleinen Werbeaktion gibts nur 250k. Damit sollte man allerdings auch alle oben genannten Teile jeweils reingekommen. Ausser man hat vorher bei Microsoft programmiert :-) Wenn ich mir vorstelle, dass einer der Enzwicker der oben genannten Chips so ein FPGA als Zielhardware gehabt haette, waere er wohl mit 10-50k Gatterequivalenten oder weniger ausgekommen - Steve Wozniaks Optimierungstrieb vorrausgesetzt.

Ein im selben mechanischen Formfaktor zukünftiges Modul mit Spartan6 hat dann auch mehr I/O's, USB2 und RAM. Welches genau ist nocht nicht endgültig geklaert.

MIKE

--
www.oho-elektronik.de
OHO-Elektronik
 Click to see the full signature
Reply to
M.Randelzhofer

Einer drüben in comp.arch.embedded meint, so einen Grafikcontroller könne man locker in ein kleines CPLD quetschen. Grafikbeschleunigerfunktionen sind dann natürlich nicht enthalten.

Da du ja schon einiges Erfahrung damit hast: Wieviel Watt braucht so ein Spartan-3 oder später Spartan-6 ungefähr, wenn da eine typische Konfiguration drauf läuft, nicht allzu schnell getaktet? Leerlaufangaben beim Spartan-3 von ca. 100 mW sehen nicht sehr batteriefreundlich aus.

--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Reply to
Frank Buss

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.