Hive-GUI

[Cromax]

Mir ist noch eine Idee gekommen man könnte doch die Rendering Engine mit dem Parser fest auf jedem HIVE installieren. Alle Programme generieren dann nur den XML Code für die Ausgabe und der HIVE kümmert sich dann um Ausgabe. Über das HiveNet könnten darüber dann auch die Ausgaben von Programmen recht einfach übertragen werden. In dem XML Code der Ausgabe ist dann ein Wert hinterlegt, auf welchem HIVE die Software läuft und wo die Ausgabe ist. Das betriebsystem ist eigentlich nur ein Browser, der Inhalte von Programmen oder statischen Seiten von lokal oder aus dem HiveNet anzeigt. Somit Verarbeitung und Ausgabe strickt getrennt und die Ausgabe für alle HIVE's in einer XML Definition standartisiert. Ich hoffe ich konnte meine Idee verständlich beschreiben

[Janaha]

Also ich sehe das alles noch relativ entspannt, was den Bildspeicher angeht.

Alles PAL/NTSC:
In der Horizontalen Austastlücke von 12µs (10,9 µs NTSC) kann der Mauszeiger verarbeitet und dargestellt oder anderer Kram gemacht werden.
In der Vertikalen Austastslücke von 3,2ms ( 2,08ms) kann man durchaus 32kB aus dem eRAM in Bellatrix laden. Das dauert ~1,6ms (~0,8ms im Burstmodus (rechnerisch)).
Vll. kann man sogar in der Zeit über Regnatix nach Bellatrix laden, dann muß man Bellatrix keinen direkten eRAM-Zugriff geben.

Bei VGA ist alles ein bischen enger, aber sollte trotzdem machbar sein.
Im eRAM ist genug Platz für Bildschirmpuffer. Andere COGS arbeiten halt immer in den "unsichtbaren" Bildschirmpuffern (was den Bus natürlich weiter auslastet).

Ich teile da Janaha's Zuversicht. Das werden wir hinkriegen.

Hallo Rainer,

also das eRam hab ich für die direkte Grafikerzeugung so gut wie abgeschrieben.

Soweit ich das sehe handelt es sich bei dem eRam um zwei ganz "normale" statische Rams mit je 512KB von Reichelt. Die besten Reichelt Rams lassen sich mit 55ns latenz ansprechen. Das reicht um sie mit 18Mhz "Takten" zu können, schneller gehts nicht. Bei jedem Tackt können sie genau ein Byte liefern. Einen Burstmode haben diese statischen Rams meines wissens nach auch nicht. Für ein VGA Signal 640*480 bei 60HZ brauchen wir einen Pixeltakt von 25,175 Mhz. Wenn ich die Austastlücke rausreche, und einen Zeilenpuffer verwende, brauche ich immer noch 20,16 Mhz. Da wir aber nur 6 bit pro Pixel brauchen und nicht 8, können wir noch ein bissel weiter runter gehen, so auf ungefähr 15,12 Mhz. Damit ließe sich das eRam gerade so eben für die Standard- VGA auflösung als Puffer nutzen. Das ganze Timing wird dabei ziemlich haarig würd ich sagen. Und die e-Rams werden dann eigentlich nur noch für den Bildpuffer gut. Sie stehenen dann nur noch beim vertiaklen retrace zur Verfügung.

Mal schauen wie wir das dann machen, erstmal den Baustatz zusammenbauen
Grüße
Janaha

[laserjones]

ist eigentlich gar nicht so ein grosser unterschied, wenn man mal drueber nachdenkt .. fuer bewegliche fenster muss halt nur ein handler her, der die position des fensters aendert und dann den bildaufbau neulaedt, um es mal ganz vereinfacht auszudruecken .. ob ich jetzt auf einen tab klicke und sich das fenster in kompletter groesse neu aufbaut oder ob ich einfach ein fenster an einer anderen stelle anzeigen lassen, ist ja kein grosser unterschied .. muessten halt nur entsprechend ein paar events und handler her

Das wäre aber eine ganz andere "Logistik" als mit (mehr oder weniger) statischen Bildschirmen. Insbesondere muss ja der Teil des Hintergrundes, der hinter einem Fenster liegt, ausgeblendet werden, und dieser Teil ist keine logische Einheit, also kein fest definierter Block von Inhalten, sondern ist allein durch die Fensterposition bestimmt, die dann zeichenweise oder gar pixelweise verschiebbar sein muss. Wie willst du das in XML darstellen? Man kann ja nicht einfach einen Teil des XML-Codes rausnehmen, der dann nicht angezeigt wird (das Fenster durchschneidet den Hintergrund ja an beliebiger Stelle ohne Rücksicht auf logische Blöcke). Wenn du die Fensterverwaltung mit in das XML integrieren willst, hieße das, dass die XML-Datei, die den aktuellen Bildschirm beschreibt, eigentlich mehrere Inhaltsblöcke enthalten muss: einen für den Hintergrund und je einen für jedes Fenster, das davor liegt. Dazu die Positionen aller Fenster. Der Parser müsste das dann auswerten und das Ganze zeichnen - und während ein Fenster verschoben wird, müsste die XML-Datei zigmal pro Sekunde geändert und komplett neu geparst werden. Das kommt mir unergonomisch vor. Meines Erachtens wäre es - auch im Sinne der logischen Trennung der Ebenen - sauberer, wenn das Grafik-Framework die Fensterpositionen verwaltet (wie ein Window-Manager unter Linux) und pro Fenster eine eigene XML-Datei existiert, die den Inhalt beschreibt. Solange sich dann nicht tatsächlich etwas am Inhalt eines Fensters oder des Hintergrundes ändert, muss dann auch kein XML neu ausgewertet werden, sondern das Framework behandelt das Ganze als reine Grafikinformation.

Meine bevorzugte Lösung wäre aber nach wie vor, auf bewegliche Fenster ganz zu verzichten. Ein gutes GUI kriegt man ohne so etwas auch hin - oder sogar besser, weil übersichtlicher. Und es spart erheblich Performance (siehe oben).

[Rainer]

...Das ganze Timing wird dabei ziemlich haarig würd ich sagen. Und die e-Rams werden dann eigentlich nur noch für den Bildpuffer gut. Sie stehenen dann nur noch beim vertiaklen retrace zur Verfügung.....
Grüße
Janaha

Umm.. ich weiß jetzt nicht ob ich Dich, oder Du mich falsch verstehst.

Die eRAM's stünden genau eben NICHT beim vertikalen Rücklauf zur Verfügung. In dieser Zeit kopieren wir die 32 KB (oder weniger) in den HUB-RAM, damit der Prob was zum Anzeigen hat nach dem Rücklauf.
Daß das bei VGA knapp wird, ist klar. Da der Propeller aber ein Abbild in seinem Hub-RAM hat, wäre ein anderes Timing auch möglich. Das Bild muß sich ja nicht nach jedem vertikalem Rücklauf ändern. Wenn das RAM nicht mitkommt, zeigt er halt das "alte" Bild nochmal an (oder ein Teil des Neuen und den Rest des Alten). Habe ich jetzt nicht wirklich durchgedacht .. nur so eine Idee.
Wir reden ja hier von Millisekunden. Stark fällt das nur in Spielen auf, denke ich.
Bei einem kleineren Bildschirmpuffer könnte man ja vll. immer nur eine hälfte abwechselnd aktualisieren. Bei Spielen doof, aber bei allen anderen Anwendungen wohl egal.

Das mit dem "Burst-Modus" war etwas falsch ausgedrückt von mir. Der RAM hat keinen, das ist richtig.
Meine Idee war, die beiden Bänke abwechselnd anzusprechen. Damit wäre die Zugriffszeit insgesamt (bestenfalls) halbiert.
Ob das wirklich so klappt ist nur eine Vermutung. So tief stecke ich da nicht drin. Muß ich erst probieren.

Wir werden sehen wenn wir alle einen haben

Gruß.
Rainer

[Bushmills]

Auf meiner Platte fand ich noch ein paar ältere test/demoprogramme von ein paar libraries die ich mal zusammengesetzt habe. Dieses sind DOS programme, und sowohl Maus- als auch Tastaturinteraktiv, laufend in Textmodus. Quellcode ist dabei (das ist Forth). Leider kann ich diese hier nicht laufen lassen, darum habe ich den ganzen Satz in den Downloadbereich kopiert. Einige davon dürften wohl weniger gelungen sein, andere mehr. Erstellt wurden diese zum Testen von Speichermanagement-Routinen, und um deren Funktion auch visuell kontrollieren zu können, baute ich ein Text-Windowssystem dazu, welches für Windows und Hintergrund Funktionen dieses Speichermanagements benutzt.
Diese Programme machen Ausgabe, je nachdem wie sie kompiliert wurden, mittels direkt zum Videobuffer schreibend, BIOS-Funktionen aufrufend, oder ANSI-Sequenzen generierend (durch DOS und ANSI-Treiber) aus, und benutzen komplett maximal 64 kb (code, stack und daten, für z.b. Speichern der Fensterhintergründe und -Inhalte). Andere Ausgabe-"Treiber" wären denkbar.
Da auf dem Hive evenfalls Forth zum Laufen gebracht werden soll, wäre es wohl nicht ausgeschlossen, diese Routinen für den Hive zu adaptieren (ein paar davon in den libs sind in assembly geschrieben), und zum Erstellen eines windowed Text-Interface zu benutzen.
In ein paar der Tests scheint es, als ob die Windows auch graphische Informationen anzeigen - dies wird allerdings lediglich durch Neudefinieren des Benutzten Fonts erreicht - die Pixelroutinen plotten in die Fontdefinitionen, und die "graphischen" Windows zeigen diese übermalten Zeichen an, ähnlich der Graphic auf dem Sinclair Spectrum. Für schnelle 3D-Anwendungen ist diese Form von Graphic absolut unzureichend. Allerdings sind die Routinen potentiell multi-tasking geeignet (und Forth Interpreter kommen auch oft mit kooperativem Multitasking, bzw ist ohne großen Aufwand zufügbar), womit eigentlich auch ein friedsames Nebeneinander von bildschirmausgebenden Programmen möglich wäre.
Ich glaub die Win6...8 sind die besten Demos, was mit Win9 war weiß ich nicht mehr. Entstanden sind diese um 1993 oder 94 rum.
Testen geht im Moment nicht, da dosemu oder wine vm86-modus benutzen wollen, der von der Atom-CPU in meiner Box nicht unterstützt wird. Ich könnte wohl in freedos booten um diese zu starten - bloß ist dann Internet weg.
Kopiert nach und runterladbar von http://forthfreak.net/textgui/ . Unbekannte Taste sollte eine Befehlsübersicht anzeigen. Ich vermeine, mich zu erinneren, daß die eine oder andere Demo nach kurzer Zeit von fehlendem Input anfängt, in eine Art Animationsmodus zu wechseln. Nicht ausgeschlossen, daß auch Kompilate, welche diese TextFenster im grafischen Modus (VGA/EGA) malen wollen, dabei sind.

[digger]

Ich bin ja nicht so Wild auf Fenster und grafische GUIs, und beim Parallax Object Exchange bin ich auf genau das richtige für mich gestoßen .. eine Textmode-GUI. Sind alle wichtigen Bedienelemente realisiert, braucht wenig Ressourcen und bietet viel Kompfort.

http://obex.parallax.com/objects/413/

[Janaha]

Ich bin ja nicht so Wild auf Fenster und grafische GUIs, und beim Parallax Object Exchange bin ich auf genau das richtige für mich gestoßen .. eine Textmode-GUI. Sind alle wichtigen Bedienelemente realisiert, braucht wenig Ressourcen und bietet viel Kompfort.

http://obex.parallax.com/objects/413/

Ja, sowas in der Art hatte mir eigentlich auch schonmal vorgeschwebt.

Allein deswegen, weil es deutlich weniger Resourcen braucht. Ich denke für den Anfang würde eine derartige GUI sicher vollkommen ausreichen. Das müsste sich eigentlich auch viel schneller Realiesiren lassen als eine Grafische GUI mit Fentserverwaltung und allem Drum und Drann. Gerade bei wenig Hauptspeicher brauchen später sonst die Controllstrukturen für die GUI nur unnötig viel Platz. Ich glaube der Zeichensatz vom Propeller internen ROM ist da auch nicht all zu schlecht ausgelegt, der hat meines wissens nach alle Zeichen definiert um auch schöne Fensterränder machen zu können. Uns hindert ja auch niemand daran, ein paar eigene Zeichen zu definieren, die da evtl. noch fehlen würden.

Wenn man das ganze geschickt aufbaut, könnte man es auch von vorn herein so designen, das man erstmal Textbasiert anfängt und später auf eine grafische Ansicht wechseln kann, ohne das man die ganze GUI und die Basisroutinen neu schreiben muss. Dann könnte man später je nach vorlieben beliebig zwischen den beiden Modi ( Textbasiert / Grafisch ) wechseln ohne das es für die Programme oder den Anwender einen großen Unterschied macht. Sowas in der Art wie das alte GEOS auf dem C64 hatte ja auch schon so seinen Charme....


Grüße
Janaha

[digger]

Nur mal so am Rande, weil hier auch schon mal das Wort Atari gefallen ist ... die Monochrome-GUI von den Ataris fand ich auch schon immer recht nice ... aber braucht wohl bei VGA-Auflösung auch schon wieder zuviel Speicher.

[drohne235]

Kennt wahrscheinlich eh jeder aber doch nochmal gleich in einer angepassten Version die GUIDemo aus dem Obex. Ich habe gleich mal die angepasste BIN-Datei angehängt, start mit "bload guidemo.bin" - Maus nicht vergessen anzuschließen! Bei dem Demo ist Bella übrigens nichtmal halb ausgelastet...

Link zum OBEX-Eintrag: http://obex.parallax.com/objects/413/

[Rainer]

Kennt wahrscheinlich eh jeder aber doch nochmal gleich in einer angepassten Version die GUIDemo aus dem Obex. Ich habe gleich mal die angepasste BIN-Datei angehängt, start mit "bload guidemo.bin" - Maus nicht vergessen anzuschließen! Bei dem Demo ist Bella übrigens nichtmal halb ausgelastet...

Link zum OBEX-Eintrag: http://obex.parallax.com/objects/413/

Yo, das ist die "GUI", aus der ich mir Funktionen "ausgeliehen" habe für Regime.
Stelle Dir jetzt noch Icons im Benutzerzeichensatz vor, und Du hast die "Grafikversion" von Regime, wie ich das für die Zukunft geplant habe.
Ein paar Sachen sind im jetzigen Regime schon drin, wie Messageboxen, usw. Allerdings muß ich noch was am "Redraw"-Mechanismus arbeiten ... da bleiben ab und zu Artefakte zurück ... aber werdet ihr ja am Sonntag bein Regime-Release sehen.

Ist übrigens auch eine geile Basis für Textadventures, da die Fenster selbstständig auf Umbrüche, usw. reagieren.

Gruß.
Rainer