cursety vs. curgety

[U-Held]

Hallo,

beim "Basteln" in Spin mit reg-ios bin ich über ein paar Ungereimtheiten gestolpert.

Im VGA-Modus wird in der ersten Zeile das Logo angezeigt. Mit normalen Print-Funktionen kann man dort nicht schreiben (siehe sline in belflash). Curgety ignoriert diese Beschränkung und liefert nach curhome eine 1. Cursety hingegen beachtet die Beschränkung. Es ist also nicht ganz einfach, an eine gemerkte Cursorposition zurückzuspringen.

Wenn man das letzte Zeichen auf dem Bildschirm beschreibt, wird weitergescrollt. Das lässt sich leider auch nicht mit curoff unterdrücken - es wird in belflash immer pchar gerufen. Oder?

Der TV-Modus passt nicht zu reg-ios, weil die Kommandos (cursetx...) mit anderen Codes aufgerufen werden müssen als im VGA-Modus. Ist der G0-Modus eher zum VGA-Modus kompatibel? Hintergrund ist es, Textmodus-Programme (dir, more...) zu schreiben, die in allen Textauflösungen an der richtigen Stelle umbrechen und mit Scrollen aufhören.

Ist es erlaubt, das Trios anzupassen? Wenn ja, welches Verhalten darf ich im konkreten Fall ändern?


Grüße vom U-Held

[PIC18F2550]

Das Problem ist hier auch schon Thema: http://hive-project.de/board/viewtopic.php?f=7&t=760
Es gibt aus entwicklungsgeschichtlicher Entwicklung verschiedene Versionen von schnittstellen zu den jeweiligen treibern.
z.Z. Löst das drohne235 über "reg-ios" wo die Varianten abgelegt sind.

Die richtige zuordnung Treiber/Aufruf bleibt dir überlassen.
Bedenke das die Treiber gegen fehlaufrufe nicht geschützt sind und sie versuchen diese Befehle oder deren Fragmente auszuführen.(im Z80 gab es ein M1 Signal zur Syncronisation)

Im reg-ios kannst du ändern wenn du willst aber bedenke das reg-ios unter umständen nachher nicht mehr kompartiebel sein kann.

du kannst sie erweitern ohne bedenken aber an bestehenden Routinen rumfummeln bringt nichts.

das beste ist du baust dir eine eigene my-reg-ios aus der alten reg-ios.

[drohne235]

Na klar kann das TriOS geändert werden! Wir müssen uns nur über die Modalitäten einigen. Du kannst in dich in der Versionsverwaltung bei google-code (http://code.google.com/p/hive-trios/) mit einklinken oder das halt manuell ändern und die markierte oder notfalls dokumentierte (bei umfangreicheren Sachen evtl. nötig) Änderung hier im Forum posten, dann ändere ich das in der nächsten Version.

Ich denke das Verhalten von gety/sety sollten wir anpassen. Ich tendiere fast dazu, die zeile 0 von gety ebenfalls auf sline zu setzen. Zumindest scheint mir das die sinnvollste Variante. Was denkst du?

Code: Alles auswählen

    $05:                                                'gety
      bus_putchar(row[wscrnr] / 2 + sline[wscrnr])

Zum Scrolling kann ich grad nichts sagen, müsste ich genauer anschauen, aber es wird für ein Ausgabezeichen immer pchar aufgerufen.

TV: Der TV-Modus ist dringend renovierungsbedürftig!

Was auch eine schöne Änderung wäre (habe ich schon in mental so realisiert): Die Funktionsnummern und diverse andere Konstanten könnten in eine getrennte Datei (bzw. in ein Objekt) ausgelagert werden, welche dann in den Quelltexten von allen drei Chips verwendet wird. So kann man die Nummern in einer zentralen Datei verwalten und nach einer kompletten Neuübersetzung von TriOS sind automatisch alle Komponenten geändert. Ist aber einiges an Schreibarbeit...

[U-Held]

Hallo Drohne235,

1. gety/sety

Meiner Meinung nach sollte gety nicht lügen und sety nicht bevormunden. Gety sollte immer die absolute Zeile zurückgeben und nicht relativ zu sline. Stattdessen würde ich einen Window-Mechanismus in Anlehnung an das KC CAOS einbauen (mehr dazu später in einem eigenen Thread).

2. Scrolling

Ich habe mir belflash.spin vorgenommen und mit Hilfe einer Variablen (needs_nl[]) einen verzögerten Zeilenumbruch bei abgeschaltetem Cursor realisiert. Bevor ich irgendetwas in die Codeverwaltung einchecke, will ich mir erstmal das Konzept vom Chef bestätigen lassen. Geänderter belflash-Code (vgb.spin) und Testprogramm siehe Anhang. Zur Verdeutlicheung sollte man das Testprogramm mit dem aktuellen Trios starten, dann vgb.bel laden und das Testprogramm noch einmal laufen lassen.

Wirkungsweise:

Ist der Cursor angeschaltet, verhält sich die Zeichenausgabe wie bisher: Nach Ausgabe eines Zeichens wird, etwas vereinfacht, immer ein Zeichen zusätzlich geschrieben, um den Cursor dazustellen. Setzt man also ein Zeichen in die rechte untere Ecke des Bildschirms, wird eine Zeile nach oben gescrollt.

Neu ist bei abgeschaltetem Cursor, dass der ggf. notwendige Zeilenumbruch (und damit das Scrollen) nur vorgemerkt wird. Die Ausgabe des nächsten Zeichens holt den Zeilenumbruch nach. Jegliche Cursorpositionierung setzt die Notwendigkeit des Zeilenumbruchs zurück. Ob das beim Wechsel zwischen den Screens auch noch sauber funktioniert, habe ich nicht getestet.

3. renovierungsbedürftiger TV-Modus

Davon lasse ich erstmal die Finger.

Grüße vom U-Held

[drohne235]

Scrolling:

Ich habe das mal getestet und es funktioniert korrekt. Auch mit beltest sind keine Unregelmäßigkeiten sichtbar. Im Prinzip könnte man das also so machen. Auch mit mehreren Screens unter PropForth funktioniert es. Du kannst ja selbst testen, wenn du Forth installiert hast:

- Umschaltung Screens in Forth:

ESC 1 Screen 1, Cog 1
ESC 2 Screen 2, Cog 2 (nach Umschaltung einmal RET!)
ESC 3 Screen 3, Cog 3

- Navigation auf SDCard: ls, cd

- Spincode (t_scroll) starten:

"spin t_scroll.bin"


(beltest ist leider zwar etwas unübersichtlich vom Code. Bzgl. der Funktion soll es aber ein Testprogramm für die Funktionen des Texttreibers sein. t_scroll könnte also da auch irgendwo einfließen. Ideal wäre es natürlich, wenn man beltest sowohl für VGA als auch für TV verwenden könnte, aber das ist Zukunftsmusik. Bei admtest habe ich die einzelnen Tests schon in ein kleines Menü gebracht, um gezielt eine Funktion zu testen.)

Hab mir den Code angeschaut und sehe auch keine Möglichkeit, dass noch irgendwie zu "straffen". Ist zwar ein wenig schade um die einfache Version von pchar, aber ich sehe keine andere Möglichkeit, wenn wir das Scrolling korrekt gestalten wollen. Ich denke mal, dass machen wir so.


gety/sety:

Meiner Meinung nach sollte gety nicht lügen und sety nicht bevormunden. Gety sollte immer die absolute Zeile zurückgeben und nicht relativ zu sline. Stattdessen würde ich einen Window-Mechanismus in Anlehnung an das KC CAOS einbauen (mehr dazu später in einem eigenen Thread).

Das ist ein Argument. Wobei die Funktionen CLS & HOME immer noch ihre Funktionen auf das Scrollfenster beziehen. Eine andere Variante wäre die Einführung von einer Modusvariable zur Umschaltung zwischen relativer und absoluter Adressierung. Dann müsste diese Variable aber konsequent bei den verschiedenen Funktionen umgesetzt sein. Irgendwie macht aber auch ios.screeninit etwas ähnliches.

Im Prinzip ist dieses Scrollfenster nur für kommandozeilenähnliche Anwendungen wie Regime und seine Tools interessant. Nehmen wir mal an, wir hätten eine Anwendung wie einen Hive-Commander, dann würde dieser ja mit Sicherheit mit ios.screeninit(0,0) die volle Kontrolle über den ganzen Screen übernehmen, also quasi das Scrollfenster maximieren. In diesem Fall würde ein per se "relatives" sety/gety ja wieder stimmen. Eine andere Frage ist, ob man gety/sety in einer kommandozeilenähnlichen Anwendung mit einem begrenzten Scrollfenster/Logscreen überhaupt sinnvoll benutzen kann?

[Wenn man jetzt eh Änderungen konsequent einbringt, müsste man auch screeninit(stradr,sline) in screeninit(stradr,sline,eline) ändern.]