DOS-Forum

oDOSseus hat geschrieben: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?

oDOSseus hat geschrieben:neue ram anfordern...failed =(

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

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

wobo hat geschrieben: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 hat geschrieben:

wobo hat geschrieben: ... einen (ganz, ganz) simplen Textviewer ...
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.
...
Bei mir bleibt der Text unverändert im Speicher. Ein ARRAY mit ASCIIs lege ich nicht an.

Dirk

wobo hat geschrieben:

freecrac hat geschrieben:

wobo hat geschrieben: ... 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

oDOSseus hat geschrieben: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 hat geschrieben: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*