Grafikkarte für den Hive

[PIC18F2550]

Ok,
dann wiederufe ich meine Aussage und behaupte das Gegenteil.

Stell doch mal was von dem Teil zusammen.
Linksammlung reicht.

Kennt jemand den "XC3S200A"?

[TuxFan]

Hallo!
Hmmmmmm...............wenn ich das so lese wollt ihr den Hive mit einer super Grafikkarte beglücken, das ist ja zunächst nichts schlimmes aber seit ihr alle auch mit dem Programmieren schon so fit daß sich das lohnt?
Gruß
TuxFan

[Hauke]

OK
Hersteller ist X Engineering Software Systems kurz XESS
https://xess.com/
Auf der URL findet man auch Schaltpläne Tutorials die Software usw.
Die stellen auch andere FPGA Sache her aber die sind mir ein wenig ZU hochpreisig.

Ein deutscher Anbieter ist Trenz-Elektronik
http://shop.trenz-electronic.de/catalog ... ts_id=1049
Preis 53.06EUR inkl. MWSt

Die Platine misst 51 x 25 mm
Die Hauptsignale können durch zwei zwanzigpolige Kontaktlochreichen erreicht werden.
Wenn man Stiftleisten einlötet, dann wird das Ding im Prinzip zu einem DIP40 Bauteil

Auf der Platine findet man:
- einen 200.000 Gatter FPGA von Xilinx
(1,2V Kerspannung)
(3,3V IO Spannung)

- 8 MByte SDRAM
(eigentlich sind es 16MB aber durch ein, wie ich finde, etwas unglückliches Routing stehen nur 4Mx16 zur Verfügung)
(Durch entsprechende Programmierung des FPGA ließe sich das SDRAM wie normales SRAM ansprechen)

- 2 MBit Flash
(zum speichern der FPGA config)

- einen PIC 18F14K50
(als Bootloader/Programmer)

sowie ein Mini-USB-Port und 1,2V & 3,3V Spannungsregler

Am PIC sind leider nur noch zwei Pins unbelegt, aber wenn man ein wenig trickst, dann müsste sich der Prop-Programmer von PIC18F2550 evt. auch über den Xula realisieren lassen.
Ein weiterer nettes Detail wäre auch das man einen relativ großen RAM Speicher bei 3,3V in DIP hat. Dann könnte man sich Widerstands-Krücken für das 5V RAM sparen. (Sorry an die HIVE Entwickler aber leider ist das mit Widerständen nicht sehr elegant). Das Adresslatch kann man dann auch gleich weglassen.

cu
Hauke

P.S.
Ich bin habe weder mit dem Hersteller noch einem der Distributoren etwas zu tun. Ich finde nur dass knapp 55Euro für das Gebotene ein SEHR faires Angebot sind (zumindest im Vergleich zu anderen CPLD oder FPGA Adapterboards).

[Hauke]

@Tuxfan
Es muss ja keine SUPER Grafikkarte sein.
Es reicht schon eine wo der Speicher reicht um den kompletten Bildschirminhalt vorrätig zu halten.
Damit man nicht jeden Frame das Bild neu zusammen stricken muss.
Bei letzterem muss man sich nämlich weit besser mit dem Programmieren auskennen.
So kenne ich es zumindest aus meiner Heimcomputerzeit.
Irgendetwas in den Speicherbereich des Bildschirms zu poken und das wurde dann angezeigt konnte jeder Noob.
Sachen in Echtzeit so zwischen den Rasterzeilen in die Steuerregister rein zu manipulieren, das war die hohe Kunst.

cu
Hauke

[drohne235]

Gibt es aber auch schon eine interessante fertige Lösung, welche man nur assimilieren müsste:

http://excamera.com/sphinx/gameduino/


Wobei ich TuxFan aber ein wenig recht geben muß: Wir haben Tiles/Sprite- und Vektorgrafik auf dem Hive ferfügbar. Was fehlt ist einzig die Software. Frei skalier- und drehbare Vektorgrafik mit Sprites und Vektorobjekten; Tilesgrafik mit Softscrolling für das Playfield, massig Sprites und mit der maximalen Farbzahl (96 Farben/Pixel) - hey, alles soweit nutzbar! Fehlt eigentlich nur die Software.

Was nicht geht ist hochauflösende Rastergrafik, aber schauen wir nur mal auf der EUzebox, was trotzdem möglich ist, da gibt es so viele coole Games und wenn man mal die Indiegame-Scene ein wenig beobachtet, sieht man, was alles für coole Ideen mit begrenzten Möglichkeiten realisierbar sind. Da ist schon im blanken Hive noch viel ungenutztes Potential für viel Spaß.

[TuxFan]

Ich wollte jetzt niemanden ärgern, aber diese oder ähnliche kritische Fragen stelle ich mir auch selber, um mich manchmal selber aus hochfliegenden Plänen auf den Boden zu holen. Ich kann den Traum nach einer besseren Grafik oder mehr Grafikspeicher durchaus verstehen aber ich frage mich tatsächlich ob der Hive schon zur Gänze ausgereizt ist. Wir haben ja 1MB Speicher zur Verfügung, den aber das Gro der User bestimmt nicht nutzt, mich eingeschlossen. Ich selber fange gerade mal an die rudimentären Funktionen im PASM zu verstehen und auch das Zusammenspiel zwische den Cogs, CogRAM und HubRAM nimmt für mich nun nach Einstieg in PASM viel verständlichere Formen an. Und für die meisten ist das Zusammenspiel der drei Propeller wahrscheinlich auch ein Rätsel. Ohne Frage kann man eine zusätzliche bessere Grafikkarte entwerfen aber diese läßt sich nur an den Bus des HIVE anschließen und daran hängt auch ?

Nur in Einem sollte man sich im Klaren sein, der Hive ist kein PC und der Propeller ist ein Microcontroller, nicht mehr und nicht weniger, dh. seine Resoucen sind nun mal beschränkt. Wenn man sich in Regionen begeben will die in Richtung PC gehen oder gleichwertig sind, ist man mit den neuen ARM-Platinchen besser bedient.

Gruß
TuxFan

[Hauke]

Ich zumindest fühlte mich nicht verärgert.
Meine Vorstellung dieser Idee war halt nur, das es einfacher ist, einen Teil des Speichers als Framebuffer für "hochauflösende" (<VGA) Rastergrafik zu haben.

[TuxFan]

Der Wunsch ist Vater der Entwicklung !

Ein erster Gedanke ist Hardware des Hive besser ausnutzen.
Was ist dagegen einzuwenden z.B. einen Chip (512kB) des RAM-Speichers als Bildspeicher zu benutzen, dessen Inhalt von einem Regnatix-Cog ständig an Bellatrix verschoben wird. Das ganze mit einem PASM-Programm damit das auch flott geht.
Der andere RAM-Chip dient einem anderen Regnatix-Cog als Speicher, z.B. für Z80-Emulation mit CPM etc.
Das ist so ein Gedankenansatz meinerseits für CPM o.ä. auf dem Hive. Ob das funktioniert steht für mich aber noch in den Sternen. Zumal hier die BUS-Zugriffe synchronisiert werden müssen.
3,3V RAM Speicher gibt es zumeist als SMD. Hier könnte man eine Adapter-Platine entwickeln incl. 3,3V Regler um den 5V Anschluß zu nutzen. Die Chips können aufgelötet sein da es als Modul gelten würde. Die oberen Widerstände des Spannungsteilers werden überbrückt die unteren ausgelötet.

Zweiter Gedanke wäre neue optimierte Hardwareentwicklung abseits des Hive.

Gruß
TuxFan

[Hauke]

Der Wunsch ist Vater der Entwicklung !

Ein erster Gedanke ist Hardware des Hive besser ausnutzen.
Was ist dagegen einzuwenden z.B. einen Chip (512kB) des RAM-Speichers als Bildspeicher zu benutzen, dessen Inhalt von einem Regnatix-Cog ständig an Bellatrix verschoben wird. Das ganze mit einem PASM-Programm damit das auch flott geht.

Würde vermutlich den Bus ziemlich vollkleistern.
Zweite Frage wäre ob man überhaupt genügend Bandbreite für ein Videosignal hat. Das Regnatrix die Daten aus dem Speicher holt (mitsamt Adress-Generierung usw.) und dann nach Bellatrix verschiebt (hier wieder mit Bus-Sync und Handshake usw.) ist ziemlich umständlich.
Ich hatte mir mal nen Pseudo-DMA-Modus für Adminstra und Bellatrix überlegt. Hierbei übernimmt Regnatrix nur die Adress- und Steuersignale. Die Daten jedoch werden direkt vom Slaveprop generiert (bzw. entgegengenommen)

z.B. Adminstra ließt per PseudoDMA aus dem Speicher:
- Adressgenerierung wie beim normalem RAM-Lesen durch Regnatrix
- Regnatrix gibt per Busclock Bescheid das Daten bereit liegen
- Adminstra holt sich die Daten
- Adminstra bestätigt mit Handshake
- Regnatrix generiert die nächste Speicheradresse
- usw.

Der andere RAM-Chip dient einem anderen Regnatix-Cog als Speicher, z.B. für Z80-Emulation mit CPM etc.
Das ist so ein Gedankenansatz meinerseits für CPM o.ä. auf dem Hive. Ob das funktioniert steht für mich aber noch in den Sternen. Zumal hier die BUS-Zugriffe synchronisiert werden müssen.

Leider lassen sich die beiden Speicherchips nicht gleichzeitig einsetzen. Die hängen doch beide am selben Adress- und Datenbus. Dadurch könnte man genauso gut auch nur einen Anteil eines Speicherchip für den Framebuffer verwenden.

3,3V RAM Speicher gibt es zumeist als SMD. Hier könnte man eine Adapter-Platine entwickeln incl. 3,3V Regler um den 5V Anschluß zu nutzen. Die Chips können aufgelötet sein da es als Modul gelten würde. Die oberen Widerstände des Spannungsteilers werden überbrückt die unteren ausgelötet.

Ist mir klar das 3,3V Speicher wie Sand am Meer gibt. Nur leider hab ich bisher keine zu einem vernünftigen Preis bereits fertig aufgelötet auf einem Modul gefunden.
Der Xula bot sich halt an, weil man mit dem FPGA noch viele schöne Sachen machen kann.
Z.B. durch das Toggeln vom Busclock-Signal die Adresse um eine Speicherstelle weiterzuschalten.
Dadurch ließen sich reichlich Taktzyklen einsparen die sonst bei der immer zu wiederholenden Adressgenerierung drauf gegen.

Zweiter Gedanke wäre neue optimierte Hardwareentwicklung abseits des Hive.

Ich glaube wenn wir jetzt mit nem Hive 2.0 antanzen, dann stehen bald vor einem Lynchmob aus Leuten mit Ihrem gerade fertig gelötetem Hive 1.0

cu
Hauke

[drohne235]

Würde vermutlich den Bus ziemlich vollkleistern.
Zweite Frage wäre ob man überhaupt genügend Bandbreite für ein Videosignal hat. Das Regnatrix die Daten aus dem Speicher holt (mitsamt Adress-Generierung usw.) und dann nach Bellatrix verschiebt (hier wieder mit Bus-Sync und Handshake usw.) ist ziemlich umständlich.
Ich hatte mir mal nen Pseudo-DMA-Modus für Adminstra und Bellatrix überlegt. Hierbei übernimmt Regnatrix nur die Adress- und Steuersignale. Die Daten jedoch werden direkt vom Slaveprop generiert (bzw. entgegengenommen)

z.B. Adminstra ließt per PseudoDMA aus dem Speicher:
- Adressgenerierung wie beim normalem RAM-Lesen durch Regnatrix
- Regnatrix gibt per Busclock Bescheid das Daten bereit liegen
- Adminstra holt sich die Daten
- Adminstra bestätigt mit Handshake
- Regnatrix generiert die nächste Speicheradresse
- usw.

Die Adressgenerierung könnte man vielleicht noch vereinfachen, wenn man die niederwertige Adresse direkt am Ausgaberegister inkrementiert. Der höherwertige Teil der Adresse definiert die Zeilennummer. Während des Zeilensynchronimpulses hat man ja genug Zeit dann das Adresslatch für die nächste Zeile zu setzen. Mit entsprechenden Anfangswerten könnte so auch ein Softscrolling in beiden Achsen realisiert werden.

Der Bus ist je nach Auflösung damit ziemlich belastet, was es dann schwierig macht, die Grafikdaten auch zu bearbeiten. Aber das ist ja dann erst der nächste Schritt. Denkbar wäre aber, direkt in Bella Sprites in den COGs überzublenden. Genug Speicher als Spritepuffer ist ja dann verfügbar, wenn der Hintergrund selbst aus dem eRAM kommt.

Sinn und Unsinn der Sache ist dabei eine andere Frage. So ein Mechanismus über zwei Chips hinweg in PASM wäre schon ein ziemliches Mordsding und vielleicht ergibt sich noch die eine oder andere Idee. Für den TV-Modus hatte ich schonmal sowas angefangen (funktioniert aber noch nicht), bei Interesse könnte ich die Quellen hier mal posten. Der reine Bellacode (ohne Streaming aus dem eRAM) mit 8Bit/Pixel aus dem Bella-hRAM funktioniert aber:

http://youtu.be/sb7Lz3ExEjA