Ein Betreibssystem ohne SPIN- Code support ?

[digger]

@Rainer

Also mein absoluter Traum und Favorit wäre eine monochrome GEM-like GUI in 640x400, aber da wird wohl wieder das RAM Problem zuschlagen.

[Rainer]

@Rainer

Also mein absoluter Traum und Favorit wäre eine monochrome GEM-like GUI in 640x400, aber da wird wohl wieder das RAM Problem zuschlagen.

Och, Bella kommt glänzend klar mit 640x240-Treiber ... vll. geht auch 640x400 .... muß man sich halt u.U. mit Farben einschränken .. aber GEM hatte in der hohen Auflösung auch nur b/w ... und ich konnte gut leben damit ( vor allem wegen dem exzellenten SM124).

[Janaha]

Halloe.

Ja Rainer genau sowas wie du da aufgeschrieben hast planen Namin und ich umzusetzen. Um eine höhere Auflösung hinzubekommen werden wir evtl. auf einen Tile- basierten Grafiktreiber setzen und die Farbzahl warscheinlich auf 4 begrenzen. Ähnlich dem alten Amiga- Os was ja bis Kickstart 1.3 auch nur 4 Farben (Blau,Weiss,Schwarz,Organge) brauchte. Evtl. werden wir auch ein paar andere Auflösungen zur Wahl stellen, also etwa sowas wie mehr Farben bei kleinerer Auflösung oder so. Anwendungen können aber jederzeit einen Vollbildmodus aufmachen und die volle Kontrolle über die Grafik übernehmen. Ähnlich wie es DirectX unter Windows so gerne macht. Vom Amiga-OS wollen wir das konzept der nachladbaren Librarys übernehmen. Die Libs möchte ich am libsten so klein wie möglich halten und dann dafür lieber ein paar mehr zur Aufwahl anbieten. Wenn eine Anwendung z.B. keinen Netzwerkcode braucht, so wird die entsprechende Lib auch nicht geladen. Ebenso beim Sound, da wird es einfach ein paar Libs zur wahl geben, je nachdem welche Art von Soundausgabe gewünscht wird. Alles möglichst Modular, damit man es wie einen Baukasten zusammenstöpseln kann. Was die feste zuordnung von Dateinamensänderungen zu Anwendungen geht, setze ich eher auf das Amiga Konzept der kleinen ICON- Dateien. Da kann eine Anwendung nicht nur ablegen, das eine gewisse Datei mit ihr zu öffnen ist sonder auch gleich noch eventuelle Startparameter und eine eigene ICON- Grafik hinterlegen. Was die eigentlichen Programme angeht, denke ich werden wir jedem Cog einen kleinen Teil seines Platzes klauen um ihm das dynamische Nachladen von Codefragmenten zu erlauben. Jeder Cog wird nen eigenen kleinen Stack bekommen für die Paramterübergaben zwischen den Subroutinen. Nach möglichkeit wollen wir den Stack "Swap"-fähig machen, so das im Hub immer nur die obersten X- Elemente zu sehen sind und der rest ausgelagert werden kann. Zumindest Regantix hätte ja für sowas ziemlich viel Platz für's swappen frei. Ach ich komme mal wieder ins schwärmen.. erstmal sehn das ich den Hive überhaupt komplett mit den beiden Addon-Boards ans laufen bekomme, dann kanns so richtig losgehen.

Grüße
Janaha

[DJLinux]

Wie soll das gehen eine GUI 640 x 400 = 256,000 monochrome bits / 8 = 32,000 Bytes im Hubram und dann?

Wenn überhaup mit Tricks bzw. gemogelt in dem man z.B. Oben unt unten je 32 Pixelreihen durch Tills ersetzt (die aber nur Sachen aus dem ROM darstellen könnten)

Dann wäre es eine GUI mit 640 x 336 = 215,040 Pixel / 8 = 26,880 Bytes

Fragende Grüsse

Joshy

[Rainer]

Wie soll das gehen eine GUI 640 x 400 = 256,000 monochrome bits / 8 = 32,000 Bytes im Hubram und dann?

Wenn überhaup mit Tricks bzw. gemogelt in dem man z.B. Oben unt unten je 32 Pixelreihen durch Tills ersetzt (die aber nur Sachen aus dem ROM darstellen könnten)

Dann wäre es eine GUI mit 640 x 336 = 215,040 Pixel / 8 = 26,880 Bytes

Fragende Grüsse

Joshy

Btw: Tile-Treiber können nicht nur Zeichensätze aus dem ROM darstellen. Du kannst Benutzerdefinierte Zeichen basteln.

Wo ein Wille, da ein Weg

Bubble Shooter := 1024x768x8 Farben --> Tile + Benutzerzeichensatz. Maus und Sprites, die Pixelweise bewegt werden können. 2712 longs frei in Bell
SFX-Helper := 1024x768x8 Farben --> Tile + Benutzerdefinierter Zeichensatz(64 Zeichen). 4555 longs frei in Bell
Regime := 1024x768x8 Farben --> Tile. 5658 longs frei in Bell. Eine Palm-Ähnliche Oberfläche kann man auch mit Regime basteln ohne große Probleme.
Vectron braucht noch weniger, da ohne Puffer. 512x384. Bell hat da irgendwas um die 8000 longs frei glaube ich. Mag zwar archaisch aussehen, aber eine GUI in einer Vectormaschine (mit Puffer) wäre mal was anderes
Wobei ich mir vorstellen könnte daß bei 50 mehr oder weniger komplexen Objekten das Ding in die Knie geht, egal wie man optimiert.

Klar kommt das jetzt alles an OSX, Windows 7 oder KDE nicht ran .. aber das war ja schon klar, als wir den Kleinen aufgebaut haben.

Was jetzt da noch mit Spezialtricks insgesamt möglich ist (Overlays aus dem eRAM, whatever) kann ich noch nicht beurteilen.
Außerdem kann man auch 2 verschiedene Auflösungen auf einem Bildschirm benutzen .. was immer das bringt ... aber es geht.
Man kann auch noch "on the fly" Benutzerdefinierte Zeichen anlegen bis der Arzt kommt .. die brauchen kaum Platz .. für Icons sollte es reichen.

Pixel-Engines habe ich nur für TV-Auflösungen .. klar daß die zuviel Speicher brauchen.

Gruß.
Rainer

[laserjones]

Wie soll das gehen eine GUI 640 x 400 = 256,000 monochrome bits / 8 = 32,000 Bytes im Hubram und dann?

Dann wären noch 768 Bytes im Hub-RAM übrig. Nicht viel, aber vielleicht reicht es, wenn man Cog-RAM und ext. RAM geschickt mitnutzt.

Trotzdem denke ich, dass ein Tile-basierter Ansatz mit höherer Auflösung für ein monochromes GUI geeigneter wäre. In 640 x 400 würden gerasterte Graustufen doch sehr körnig aussehen ...

[Janaha]

Wie soll das gehen eine GUI 640 x 400 = 256,000 monochrome bits / 8 = 32,000 Bytes im Hubram und dann?

Dann wären noch 768 Bytes im Hub-RAM übrig. Nicht viel, aber vielleicht reicht es, wenn man Cog-RAM und ext. RAM geschickt mitnutzt.

Trotzdem denke ich, dass ein Tile-basierter Ansatz mit höherer Auflösung für ein monochromes GUI geeigneter wäre. In 640 x 400 würden gerasterte Graustufen doch sehr körnig aussehen ...

Hm also so schön die Auflösung auch wäre, es würde aber teuflisch flackern, was euch sicher keinen spass macht. Alle heutigen Grafikkarten arbeiten eigentloch immer im Doublebuffer-Modus. Im Doublebuffermodus gibt es immer 2 gleich große Bildspeicher. Wärend ein Bild aus dem 1. Speicherblock gezeigt wird, wird gleichzeitig im 2. Speicherblock das Bild neu gezeichnet. Ist der Bildneuaufbau beendet, werden die Anzeige auf den 2. Block umgeschaltet und das neu erzeugen der Grafik finden dann im 1. Block statt. So werden die Blöke bei jedem Bildaufbau gewechselt. Macht man das nicht, kann man den Zeichenroutinen beim Neumalen der Grafik zusehen. Und ganz erlich, bei der Auflösung ist das echt übel am Flakern und absolut Augenkrebsgefährdet so wie wir WOW spieler gern mal sagen. Also würde für mich diese Auflösung als Basisauflösung für eine GUI erstmal wegfallen, weil es keinen spass machen wird damit zu arbeiten.

Ich würde nur eine Chance sehen, das etwas besser zu lösen. Wenn Regnatrix das neue Bild im externen RAM aufbauen würde und man die Übertragung des gesammten Bildinhalts so schnell hinbekommt, das man mindestens genauso Schnell ist, wie die Ausgabe eines Bildes durch Belatrix. Dann könnte man auch diese Auflösung Flackerfrei hinbekommen. Dafür muss natürlich das Timing absolut stimmig sein. Hm, da muss ich mich mal näher mit beschäftigen, wenn ich an meinem Betriebssystem bastle. Machbar müsste das eigentlich sein, jedoch wird es wie so üblich ne Menge an Bandbreite des Busses fressen.

Grüße
Janaha

p.s. Mit dem 55ns Ram müssten Theoretisch sogar noch viel höhere Auflösungen möglich sein. Muss ich nacher mal in meine Liste schauen, wenn ich wieder zu Haus bin. Ich meine 800*600 bei 256 Farben könnte das RAM Theoretisch maximal Leisten. ( 1 Byte pro Pixel Mode, wobei der Hive ja nur 6 Bits Pro Pixel ausgeben könnte. )

[laserjones]

Stimmt, an den Double Buffer hab ich nicht gedacht - der ist natürlich Pflicht, wenn es auch bei einem GUI weniger flimmern würde als bei einem Spiel, weil ja der Bildinhalt größtenteils gleich bleibt (und der Mauszeiger wäre ja ohnehin ein Sprite "über" dem Bildspeicher).

Wenn Regnatrix das neue Bild im externen RAM aufbauen würde und man die Übertragung des gesammten Bildinhalts so schnell hinbekommt, das man mindestens genauso Schnell ist, wie die Ausgabe eines Bildes durch Belatrix.

Hmm, ich denke, bei einem GUI müsste die Buffer-Umschaltung nicht unbedingt so schnell sein wie die Bildwiederholrate. Ich schätze, 15 Bilder pro Sekunde reichen für eine halbwegs flüssige Bewegung der Fenster (viele Trickfilme haben auch nicht mehr Frames/s).

[Janaha]

Hmm, ich denke, bei einem GUI müsste die Buffer-Umschaltung nicht unbedingt so schnell sein wie die Bildwiederholrate. Ich schätze, 15 Bilder pro Sekunde reichen für eine halbwegs flüssige Bewegung der Fenster (viele Trickfilme haben auch nicht mehr Frames/s).

Ja das Stimmt, der eigentliche Bildaufbau darf bei double Buffer durchaus langsamer sein. Nur die Übertragung der Daten vom ext. Ram an den Belatrix Chip muss mindestens genauso schnell sein, wie die Ausgabe des Bildes zum Monitor. Sonst sieht man auf dem Schirm nacher einen Versatz in der Grafik zwischen dem teil der noch "alt" ist und dem Teil der gerade vom ext. Ram an den Bildpuffer des Belatrix gesendet wird. Ist nicht ganz so schlimm wie das Flackern, wenn man das Bild im vordergrund neu Zeichnet, aber immer noch zu sehen.

Grüße
Janaha