TUI programmieren [C]

[oDOSseus]

Ist aber beruhigend, dass du das bildschirm-löschen genauso programmiert hast (aber wirklich genauso) wie ich =)
Den header "ASCIIVID.H" werde ich in den kommenden Tagen veröffentlichen. Es steht nicht viel drin, aber es ist schon mal ein Teil des gesamt projektes.

---===<<<EDIT_1>>>===---

Auf meiner Seite http://hobbycoder.ho.ohost.de/browser.php kann man nun unter DOS\ASCIIVID diesen Header runterladen. ist natürlich nciht die ganze TUI, weil die ja noch lange nicht fertig ist, sondern nur die library für die Bildschirmmanipulation. Ich fänds schön, wenn hier ein paar leute, die C gut lesen können (Assembler hab ich nur minimal eingesetzt) sich den mal angucken und sagen, was sie davon halten.

ich freu mich auf eure Antworten =)

---===<<<EDIT_2>>>===---
Dabei fällt mir ein, hier programmiert glaube ich kaum einer C oder?

[freecrac]

Ist aber beruhigend, dass du das bildschirm-löschen genauso programmiert hast (aber wirklich genauso) wie ich =)
Den header "ASCIIVID.H" werde ich in den kommenden Tagen veröffentlichen. Es steht nicht viel drin, aber es ist schon mal ein Teil des gesamt projektes.

---===<<<EDIT_1>>>===---

Auf meiner Seite http://hobbycoder.ho.ohost.de/browser.php kann man nun unter DOS\ASCIIVID diesen Header runterladen. ist natürlich nciht die ganze TUI, weil die ja noch lange nicht fertig ist, sondern nur die library für die Bildschirmmanipulation. Ich fänds schön, wenn hier ein paar leute, die C gut lesen können (Assembler hab ich nur minimal eingesetzt) sich den mal angucken und sagen, was sie davon halten.

ich freu mich auf eure Antworten =)

---===<<<EDIT_2>>>===---
Dabei fällt mir ein, hier programmiert glaube ich kaum einer C oder?

Mir gefällt es sehr gut. Es ist sehr kompackt geschrieben und aussagekräftig dokumentiert, ganz so wie ich es mag.
Aus Mangel an genühender Kenntnis über C kann ich aber kein wirkliches Urteil abgeben, es wirkt jedoch gut gegliedert und aufgeräumt.

Dirk

[oDOSseus]

Mit der textarea gehts in großen schritten voran. Nur wenn ich neue RAM alloziiere gibts immer stress. Aber das bekomme ich auch noch hin =). Enter drücken kann man auch noch nicht xD. Aber immerhin kann man mit den cursortasten darin rum-navigieren.

Und eins vorweg:
Es wird in TUI keine copy+paste funktion geben. Die begründung ist, dass ich keine lust habe sowas zu programmieren xDxD

mfG

[oDOSseus]

kurzer Zwischenstand:

Texteingabe....check
Entfernen...check
Backspace...check
cursortasten...check
neue ram anfordern...failed =(
enter drücken...unversucht

Da kommt noch einiges auf mich zu.

[wobo]

Ausgehend von Deiner Diskussion mit DosFeratu auf Seite 4 dieses Threads habe ich versucht (unter TP 7.0) einen (ganz, ganz) simplen Textviewer zu programmieren.

Über das Ergebnis war ich ein wenig enttäuscht, konnte ich doch im Textmode (80x25) beliebig große Textausschnittsfenster auf meinem 386sx16 - unter ausschließlicher Verwendung des TP-Befehls write/writeln - nicht ausreichend schnell scrollen, ohne dass während des Scrollens immer der Tastaturpuffer übergelaufen ist.

a) Kann es sein, dass die TP-Befehle so langsam sind? Ich dache eigentlich, dass writeln - sofern die Standardeinstellung directvideo=true nicht geändert wird - direkt in den Bildschirmspeicher schreibt und eigentlich mit der Stringausgabe-Routine der IDE (von TP) identisch ist. Und die IDE ist (nicht nur verdammt gut, sondern auch) verdammt schnell. Auf meinem 386sx16 kann ich jedes PAS-File, ja sogar die ASM86FAQ rauf- unter runterscrollen, ohne dass der Tastaturpuffer überläuft.

Ich weiß ja, dass Du in C++ (?) programmierst, aber an ggf. mitlesende TP-ler: Muß ich writeln in ASM umsetzen?

b) Andere Alternative, die ich mir überlegt und dann auch umgesetzt habe, wäre die Daten nicht als ARRAY of CHAR (=Buchstabenbytes) zu speichern, sondern bereits zeilenweise aufbereitet, also mit allen Leerzeichen. Das geht dann ganz schnell und einfach, weil ich ja nur die fertigen Zeilen auf den Bildschirm klatschen muß. Um Zeilenumbrüche muss ich mich ja dann nicht mehr kümmern. Auch das Hochscrollen ist viel einfacher, weil ich nicht den richtigen Zeilenanfang rückwärts suchen muß. (So richtig kompliziert dürfte das ARRAY of CHAR werden, wenn mein Text die 64k-Grenze übersteigt. Aber soweit bin ich noch nicht.)

Wenn ich also die Textzeilen beim Einlesen der Textdatei schon auf die Zeilenbreite aufbereite, ist das Scrollen durch den Text kein Problem. Allerdings graut mir schon, sollte ich mal die ASM86FAQ - ein ca. 1 MB großes Textdokument - laden wollen. Bei meiner Methode wären ja dann vielleicht 3 MB mit Leerzeichen verbraten...

Hast Du Deinen Text als Buchstaben-Reihe (ARRAY of ...) gespeichert und berechnest dann für jede Textausgabe den Zeilenumbruch neu, oder liegt bei Dir der Text schon fertig im RAM?

wobo

[freecrac]

neue ram anfordern...failed =(

Wir müssen zuerst den übrigen Speicher wieder freigeben. Dafür ermitteln wir wie groß unser Programm ist und reservieren zunächst nur diese Größe.

Code: Alles auswählen

mov   bx, ss     ; zunächst die beiden Segmentadressen
mov   ax, es     ; voneinander abziehen. Das ergibt die
sub   bx, ax     ; Anzahl der Paragraphen vom PSP bis
                 ; zum Anfang des Stack
mov   ax, sp     ; da sich der Stackpointer am Ende des
add   ax, 0Fh    ; Stacksegments befindet, gibt sein
shr   ax, 4      ; Inhalt die Länge des Stacks an
add   bx, ax     ; zur bisherigen Länge hinzuaddieren
mov   ah, 4Ah    ; neue Größe an das DOS übergeben
int  21h

RBIL->INTERRUP.G->inter61b.zip
--------D-214A-------------------------------
INT 21 - DOS 2+ - RESIZE MEMORY BLOCK
AH = 4Ah
BX = new size in paragraphs
ES = segment of block to resize
Return: CF clear if successful
CF set on error
AX = error code (07h,08h,09h) (see #01680 at AH=59h/BX=0000h)
BX = maximum paragraphs available for specified memory block
Notes: under DOS 2.1-6.0, if there is insufficient memory to expand the block
as much as requested, the block will be made as large as possible
DOS 2.1-6.0 coalesces any free blocks immediately following the block
to be resized
SeeAlso: AH=48h,AH=49h,AH=83h
-----------------------------------------

Danach fordern wir Speicher an und bekommen die Segmentadresse des Speicherblocks in AX.

Code: Alles auswählen

mov   bx, 2000h  ; 128 KB
mov   ah, 48h    ; anfordern:  BX = Anzahl/16
int  21h

RBIL->INTERRUP.G->inter61b.zip
--------D-2148-------------------------------
INT 21 - DOS 2+ - ALLOCATE MEMORY
AH = 48h
BX = number of paragraphs to allocate
Return: CF clear if successful
AX = segment of allocated block
CF set on error
AX = error code (07h,08h) (see #01680 at AH=59h/BX=0000h)
BX = size of largest available block
Notes: DOS 2.1-6.0 coalesces free blocks while scanning for a block to allocate
.COM programs are initially allocated the largest available memory
block, and should free some memory with AH=49h before attempting any
allocations under the FlashTek X-32 DOS extender, EBX contains a protected-mode
near pointer to the allocated block on a successful return
SeeAlso: AH=49h,AH=4Ah,AH=58h,AH=83h
-----------------------------------------

Beim Beenden des Programms wird der Speicher wieder freigegeben.

Dirk

[freecrac]

Ausgehend von Deiner Diskussion mit DosFeratu auf Seite 4 dieses Threads habe ich versucht (unter TP 7.0) einen (ganz, ganz) simplen Textviewer zu programmieren.

Über das Ergebnis war ich ein wenig enttäuscht, konnte ich doch im Textmode (80x25) beliebig große Textausschnittsfenster auf meinem 386sx16 - unter ausschließlicher Verwendung des TP-Befehls write/writeln - nicht ausreichend schnell scrollen, ohne dass während des Scrollens immer der Tastaturpuffer übergelaufen ist.

a) Kann es sein, dass die TP-Befehle so langsam sind? Ich dache eigentlich, dass writeln - sofern die Standardeinstellung directvideo=true nicht geändert wird - direkt in den Bildschirmspeicher schreibt und eigentlich mit der Stringausgabe-Routine der IDE (von TP) identisch ist. Und die IDE ist (nicht nur verdammt gut, sondern auch) verdammt schnell. Auf meinem 386sx16 kann ich jedes PAS-File, ja sogar die ASM86FAQ rauf- unter runterscrollen, ohne dass der Tastaturpuffer überläuft.

Ich weiß ja, dass Du in C++ (?) programmierst, aber an ggf. mitlesende TP-ler: Muß ich writeln in ASM umsetzen?

b) Andere Alternative, die ich mir überlegt und dann auch umgesetzt habe, wäre die Daten nicht als ARRAY of CHAR (=Buchstabenbytes) zu speichern, sondern bereits zeilenweise aufbereitet, also mit allen Leerzeichen. Das geht dann ganz schnell und einfach, weil ich ja nur die fertigen Zeilen auf den Bildschirm klatschen muß. Um Zeilenumbrüche muss ich mich ja dann nicht mehr kümmern. Auch das Hochscrollen ist viel einfacher, weil ich nicht den richtigen Zeilenanfang rückwärts suchen muß. (So richtig kompliziert dürfte das ARRAY of CHAR werden, wenn mein Text die 64k-Grenze übersteigt. Aber soweit bin ich noch nicht.)

Wenn ich also die Textzeilen beim Einlesen der Textdatei schon auf die Zeilenbreite aufbereite, ist das Scrollen durch den Text kein Problem. Allerdings graut mir schon, sollte ich mal die ASM86FAQ - ein ca. 1 MB großes Textdokument - laden wollen. Bei meiner Methode wären ja dann vielleicht 3 MB mit Leerzeichen verbraten...

Hast Du Deinen Text als Buchstaben-Reihe (ARRAY of ...) gespeichert und berechnest dann für jede Textausgabe den Zeilenumbruch neu, oder liegt bei Dir der Text schon fertig im RAM?

wobo

Wenn ich mich mal dazwischen mogeln darf, Ich mache es etwas anders.
Mein Textbetrachter(*.asm) durchsucht die Textdatei noch vor der Ausgabe nach Carriage Return(0Dh)-Bytes und legt eine Tabelle mit den Offsetadressen der Zeilenanfänge und der Zeilenlänge der jeweiligen Zeile an.
Ist die Zeile zu lang (> 50 Spalten), dann zerlege ich die Zeile und beginne mit dem Rest der Zeile eine neue Zeile, bzw. ein weiterer Offset-Eintrag +Zeilenlängen-Eintrag kommt in die Tabelle.
Vor der Ausgabe einer Textzeile wird die jeweilige Bildschirmzeile gelöscht. Leerzeichen innerhalb der Textzeile werden wie andere ASCIIs einfach mit ausgegeben.
Schon vorhandene Leerzeichen am Ende einer Zeile werden mitgescrollt. Wird bei der Ausgabe ein TAB(9) gefunden, dann setze ich den Ausgabezeiger 5 Spalten weiter nach vorne.
Bei mir bleibt der Text unverändert im Speicher. Ein ARRAY mit ASCIIs lege ich nicht an.

Dirk

[wobo]

... einen (ganz, ganz) simplen Textviewer ...
wobo

Wenn ich mich mal dazwischen mogeln darf, Ich mache es etwas anders.

Ja, bitte!

Mein Textbetrachter(*.asm) durchsucht die Textdatei noch vor der Ausgabe nach Carriage Return(0Dh)-Bytes und legt eine Tabelle mit den Offsetadressen der Zeilenanfänge und der Zeilenlänge der jeweiligen Zeile an.
...
Bei mir bleibt der Text unverändert im Speicher. Ein ARRAY mit ASCIIs lege ich nicht an.

Dirk

Sehr schöne Idee. Für meinen simplen Textviewer gerade das richtige. Benötigt ja allenfalls 2 words pro Zeile. Und macht das Hoch- und Runterscrollen extrem einfach. Werde ich auf jeden Fall umsetzen. Eine Frage - die sich jetzt und absehbar für mich noch nicht stellt - wäre nur, ob das ganze auch noch geht, wenn die Texte mal extrem lang sind. Dann könnte die Tabelle wohl schon an die 64k-Grenze gehen (was aber immer noch besser ist, als 3 MB an Leerzeichen). Allerdings gibt's da schon Lösungsansätze. Eine Möglichkeit wäre imho die Tabelle als Ringpuffer anzulegen. Unter Berücksichtigung von PageUp/PageDown dürfte man dann nicht mehr als 3*maximale Zeilenanzahl an Tabelleneinträgen brauchen. Sehr schöne Idee. Werde mich gleich an die Umsetzung machen.

Mit Array of Buchstaben meinte ich übrigens das unveränderte Einlesen der Daten in den Speicher. Array of char/Buchstaben ist dabei nur die Interpretationsanweisung an den Compiler, die unveränderten Daten eben als ASCIIs, d.h. genauer als Verweise auf die ASCII-Tabelle, zu verstehen.

wobo

[freecrac]

... einen (ganz, ganz) simplen Textviewer ...
wobo

Wenn ich mich mal dazwischen mogeln darf, Ich mache es etwas anders.

Ja, bitte!

Mein Textbetrachter(*.asm) durchsucht die Textdatei noch vor der Ausgabe nach Carriage Return(0Dh)-Bytes und legt eine Tabelle mit den Offsetadressen der Zeilenanfänge und der Zeilenlänge der jeweiligen Zeile an.
...
Bei mir bleibt der Text unverändert im Speicher. Ein ARRAY mit ASCIIs lege ich nicht an.

Dirk

Sehr schöne Idee. Für meinen simplen Textviewer gerade das richtige. Benötigt ja allenfalls 2 words pro Zeile. Und macht das Hoch- und Runterscrollen extrem einfach. Werde ich auf jeden Fall umsetzen. Eine Frage - die sich jetzt und absehbar für mich noch nicht stellt - wäre nur, ob das ganze auch noch geht, wenn die Texte mal extrem lang sind. Dann könnte die Tabelle wohl schon an die 64k-Grenze gehen (was aber immer noch besser ist, als 3 MB an Leerzeichen). Allerdings gibt's da schon Lösungsansätze. Eine Möglichkeit wäre imho die Tabelle als Ringpuffer anzulegen. Unter Berücksichtigung von PageUp/PageDown dürfte man dann nicht mehr als 3*maximale Zeilenanzahl an Tabelleneinträgen brauchen. Sehr schöne Idee. Werde mich gleich an die Umsetzung machen.

Ich gehe mal davon aus das nicht jedes Zeichen eine eigene Zeile belegt und wenn man nur jeweils 64KB grosse Teile der Textdatei einläd, dann bleibt die Tabelle mit den Offsets der Zeilenanfänge+Zeilenlänge ganz bestimmt kleiner als 64KB pro Teilblock der Textdatei.

Mit Array of Buchstaben meinte ich übrigens das unveränderte Einlesen der Daten in den Speicher. Array of char/Buchstaben ist dabei nur die Interpretationsanweisung an den Compiler, die unveränderten Daten eben als ASCIIs, d.h. genauer als Verweise auf die ASCII-Tabelle, zu verstehen.

wobo

Ach so.

Dirk

[oDOSseus]

Ich komme mal eben zum Thema zurück, obwohl ich eure diskussion echt interessant finde.

@wobo
Ich nutze C mit ein bisschen ASM. C++ is auf DOS nich so klug. Zu große .exe und zu viel ressourcen werden verbraucht.

@freecrac
Das hast du mir schonmal geschrieben =).
Ich hole mir neue RAM mit den C-funktionen. Das klappt auch glaub ich. Nur ich scheine da zu viel reinzuschreiben oder ihn zu spät zu holen, denn ich scheine in bereiche rein zu schreiben, die mir nicht gehören. So kackt schonmal das ganze Programm ab und der Maus-Zeiger lässt sich nicht mehr bewegen oder ich schreibe in DOSs RAM-Tabelle, weil DOS nacher meint, es wäre nicht genug RAM da, um COMMAND.COM auszuführen. Dabei braucht mein text nur ca. 400Bytes. Ich muss da n bisschen basteln...


Im Moment hole ich neue RAM, sobald ich 2 Zeichen vorm Ende meines Puffers bin. Dann hole ich 64Bytes und erhöhe meine Variable "nBuffSize" um 64. Dann setze ich ab dem letzten Zeichen im String 64 Zeichen (halt die neuen) = 0, denn 0 zeigt das ende des Strings an. und ich glaube bei dem letzten Schritt mach ich fehler.

[oDOSseus]

Hey jetzt klappts.

Habe einfach beim "memset" die 64 durch "nBuffSize-nTextLength" ersetzt. Ich weiß nich ob das verständlich ist xD Aber seit dem gabs keine Errors mehr =). Jetzt freu ich mich erstmal =)

EDIT:
HEy mein 100ster Beitrag *tröööööööt*

[freecrac]

Ich komme mal eben zum Thema zurück, obwohl ich eure diskussion echt interessant finde.

@wobo
Ich nutze C mit ein bisschen ASM. C++ is auf DOS nich so klug. Zu große .exe und zu viel ressourcen werden verbraucht.

@freecrac
Das hast du mir schonmal geschrieben =).

Ach ja, jetzt wo du es sagst, da fällt es mir auch wieder ein.

Ich hole mir neue RAM mit den C-funktionen. Das klappt auch glaub ich. Nur ich scheine da zu viel reinzuschreiben oder ihn zu spät zu holen, denn ich scheine in bereiche rein zu schreiben, die mir nicht gehören. So kackt schonmal das ganze Programm ab und der Maus-Zeiger lässt sich nicht mehr bewegen oder ich schreibe in DOSs RAM-Tabelle, weil DOS nacher meint, es wäre nicht genug RAM da, um COMMAND.COM auszuführen. Dabei braucht mein text nur ca. 400Bytes. Ich muss da n bisschen basteln...

Im Moment hole ich neue RAM, sobald ich 2 Zeichen vorm Ende meines Puffers bin. Dann hole ich 64Bytes und erhöhe meine Variable "nBuffSize" um 64. Dann setze ich ab dem letzten Zeichen im String 64 Zeichen (halt die neuen) = 0, denn 0 zeigt das ende des Strings an. und ich glaube bei dem letzten Schritt mach ich fehler.

Wenn es geht, dann würde ich es grob einschätzen wie viel Speicher ich insgesamt brauche und dann gleich zu Beginn alles zusammen anfordern.

Dirk

[freecrac]

Hey jetzt klappts.

Habe einfach beim "memset" die 64 durch "nBuffSize-nTextLength" ersetzt. Ich weiß nich ob das verständlich ist xD Aber seit dem gabs keine Errors mehr =). Jetzt freu ich mich erstmal =)

EDIT:
HEy mein 100ster Beitrag *tröööööööt*

Glückwunsch.

Dirk

[oDOSseus]

Ab ner ungewissen Anzahl von Zeichen macht er immernoch stress. Vllt. habe ich aber auch einfach eine taste zu lange gedrückt gehalten. bei 877MHz können solche Programme ja schonmal probleme verursachen. Ich muss noch ein paar tests machen.

Habe rausgefunden, dass wörter nicht 2 Zeilen lang sein dürfen... Das muss ich ändern =)

Habe auch rausgefunden, dass ich sehr produktiv bin, seit mir mein analog-sat-receiver runtergefallen ist und die flimmerkiste aus ist xD

[oDOSseus]

Könnte den fehler gefunden haben.
Lag wahrscheinlich an nur einem operator (> statt >=).
Is ja immer so. Muss aber noch ein paar test durchführen.

Jap er wars. Jackpott, Juhu und Hurra xD