Grafikmodus G1

[drohne235]

Analog zum Grafikmodus G0 für Vektorgrafik, wird G1 eine auf Tiles basierender
TV-Modus mit Unterstützung von Sprites werden. Mit entsprechenden Funktionen
im IOS-Objekt sicher gut für Games geeignet.

Eigenschaften:

- Auflösung: 376x240 pixel
- Farben: 1 Byte per Pixel (bedeutet: 96 gleichzeitig nutzbare Farben!)
- Tiles: 8x8 Pixel
- Playfield: 47x30 tiles, Softscrolling horizontal + vertikal
- Sprites: ca. 20 16 x 16 Sprites (möglich 4/8/16/32 px)
- Cogs: 1 x Interface
1 x Keyboard
1 x vCog - Videoausgabe
5 x lCog - jede Cog rendert alternierend eine Zeile
- Ohne Keyboardcode (wenn zum Beispiel an Administra ein Gamepad angeschlossen wird), kommt
noch eine Cog für Spezialeffekte (automatische Tiles/Spriteanimationen) hinzu.

[PIC18F2550]

Ist die schnittstelle zum G0 gleich?

[drohne235]

Hmm, die Funktionalität ist ja völlig verschieden, wie sollte das gehen? Der eine Treiber bietet Vektorfunktionen, der andere Treiber Funktionen um Tiles und Sprites zu steuern und zu manipulieren. Das alles auch noch mit verschiedener Auflösung und Farbanzahl. Ich sehe da ehrlich kaum Anknüpfungspunkte.

[PIC18F2550]

Ich denke da an sowas was alle treiber gemeinsam haben wie z.B. die Textausgaben.
Oder die Abfrage von Parrametern, Maus, Keybord, ...

[drohne235]

Jo, solche Funktionen kommen auf die gleiche Funktionsnummer. Im momentanen Status sind das gerade mal die Managment-Funktionen wie reboot usw.

[PIC18F2550]

Moin,

Ideales Businterface: z.B. Bellatrix

Code: Alles auswählen

$1..$255   Text und Steuerteichen

$0         Einleitung erweiterte Steuercodes

$0, $0..$3F Standart Schnittstelle 

$0, $40..$BF Schnittstelle des Treibers

$0, $C0..$FF Experimentelle Erweiterungen vom USER/optionen

in den jeweiligen erweiterte Steuercodes Blöcken wird der untere Teil zum Empfang von Daten und der obere zur rückgabe von daten genutzt.
das vereinfacht die schnittstelle in der Variantenvielfalt(ein Grundgerüst zum Daten Senden)

Dieser Aufbau ermöglicht dem Treiber auch ein Treiberfalschen Befehl in länge und Aufbau richtig zu erkennen ohne gleich das programm zu gefährten.

z.Z. merke ich das im HBASIC-Modul.

[drohne235]

Das ist aber nur sinnvoll bei einem textbasierten Treiber. Dabei werden Textzeichen $001..255 vorrangig und schnell behandelt, seltene Steuerzeichen mit einer $000 als Escape-Sequenz definiert. Ein Grafiktreiber aber wie G0/1 braucht die Geschwindigkeit bei den Steuerfunktionen. Wenn diese dann erst noch eine $000 vorangestellt brauchen, belastet das signifikant die verfügbare Bandbreite und verringert damit die Geschwindigkeit (Geschwindigkeit halbiert sich mindestens!). Text ist bei den G0/1-Treibern eine Spezialfunktion und wurde ja auch bei G0 schon so behandelt.

[PIC18F2550]

Aus der sicht hast du recht.
Vieleicht kann mann aus 8 bit 9 machen

[drohne235]

Naja, an sich hast du auch recht und wenn der Bus per PASM laufen würde, hätte man mehr als genug Bandbreite um das genau so systematisch aufzubauen wie du schreibst. Leider ist der per Spin bediente Bus aber doch sehr langsam, da muss man haushalten.

[PIC18F2550]

Was nützt Bandbreite wen der COGRam so winzig ist.

Der Hindergrund der Strucktur ist das in reg-ios verschiedene BUS-Befehle den selben aufbau haben und ich damit eigendlich am knapen COGRam Speicherplatz sparen könnte.

Der gedanke das sich keiner mit dem Busbefehlen in Hexformat rumärgern muß ist ansich eine gute Idee leider geht es zu lasten des Speicher's währe aber wesendlich Komfortabler wenn alle treiber ein gemeinasames grundprofiel hätten was sich ja aufgrund der verschiedenen Treiber varianten nicht kompartiebel machen läst.

Frage: in wie weit wird der G0 und der G1 busmäßig kompartiebel sein?

Der eine Treiber bietet Vektorfunktionen, der andere Treiber Funktionen um Tiles und Sprites zu steuern und zu manipulieren

Gleiche funktionen auch wenn es nur eine ist sollte gleichen Aufruf haben neue kommen auf einen bereich wo sie mit dem anderen treiber nicht ins gehege kommen.