Wo ist der BWS im FreePascal :-)

[alfware17]

Kann mir jemand sagen, wie man in Free Pascal den Bildwiederholspeicher
ansprechen kann (lesen, schreiben)?
In Turbo Pascal war es mit so einem netten MEM[] Feld einfach über
MEMW[screenseg:offset]. Leider war das wie so manches ein nur Borland
Standard und es geht in Free Pascal nicht. In meiner Anlage sind jeweils
eine 16bit und eine konvertierte 32bit Version meines Programmes - nur
daß letztere fehlerhaft ist, weil die CloseWindow nicht funktionieren da
in dem VideoBuf Feld zu dem Zeitpunkt "Schrott" drin war.
Ausgangspunkt in der Unit Fenster waren die netten MEMW[] Anweisungen.
Da wo sie sich nur auf den Stack bezogen, habe ich sie hoffentlich alle
repariert, nur beim Zugriff auf den Bildwiederholspeicher habe ich keine
Idee.
Ich habe die Unit Video probiert. Leider fehlen da ein paar ganz wichtige
Befehle so wie das WINDOW, ohne dem geht es natürlich nicht (Rechteck
festlegen, Attribute und ClrScr oder Write) - um das zu umschreiben müßte
man die komplette Logik ändern und es erschiene mir total umständlich
und rückschrittlich. Den Ersatz der CRT für die Tastatur mittels der
Unit Keyboard bekomme ich ja noch hin, aber so ohne WINDOW?!
Also nahm ich trotz Warnhinweis die Unit CRT hinzu. Soweit sogut - nur
leider wirken sich die "normalen" Ausgaben per Write, Window, ClrScr usw.
überhaupt nicht auf das VideoBuf Feld aus (nur die direkten Speicherungen
darein) - so daß VideoBuf und angezeigtes Bild natürlich total auseinander
laufen. Das kleine Analyse-Programm zeigt im Debug-Modus ganz klar dieses
Verhalten, die "normalen" Writes usw. kommen im VideoBuf nicht an.
Wenn man nur CRT benutzt, muß doch das Bildschirmbild auch unter Windows 32bit
auch noch einen Speicherbereich als Entsprechung haben? Nur wie kommt man da
ran? Meine Pointer-Versuche (siehe auch die IN_MEMW und OUT_MEMW) waren irgend-
wie nicht von Erfolg gekrönt. Aber vielleicht hat schon jemand das Problem
gelöst?
a) nur mit CRT (eigentlich fehlt nur der Zugriff BWS)
b) nur mit Video? Aber dann bräuchte man wohl weitere Units? Denn daß es
überhaupt kein WINDOW mehr geben sollte, will mir nicht in den Kopf
c) mit Video und CRT (vielleicht gibt es einen Trick wie man Bildschirm
und VideoBuf synchronisieren muß)?
d) oder hat jemand eine ähnliche Window/Menue Verwaltung?
Ich bin schon reichlich verwirrt und verzweifelt...

By the way: Rufe ich die Free Pascal Version des Tollzeit auf (egal ob
an meiner 8 Jahre alten XP Kiste oder dem eigentlich superschnellen
großen PC unter Vista), braucht er bald eine Ewigkeit für die Ausgabe des
Anfangsbildes (die 1840 Writes $178). Ich wollte mich doch verbessern?!

[marcov]

Kann mir jemand sagen, wie man in Free Pascal den Bildwiederholspeicher
ansprechen kann (lesen, schreiben)?

In Turbo Pascal war es mit so einem netten MEM[] Feld einfach über
MEMW[screenseg:offset]. Leider war das wie so manches ein nur Borland

Das Problem ist das das nicht ein Borland oder TP feature ist, aber eine reine DOS feature.
In zb Borland Delphi (TP's Nachfolger) gibts nicht, weil es (32-bit) Windows ist. (16-bit Windows Versionen sind Dos basiert)

Standard und es geht in Free Pascal nicht.

Es funktioniert auch mit Free Pascal, aber nur in modus "TP", UND auf Dos (Go32v2)

In meiner Anlage sind jeweils
eine 16bit und eine konvertierte 32bit Version meines Programmes - nur
daß letztere fehlerhaft ist, weil die CloseWindow nicht funktionieren da
in dem VideoBuf Feld zu dem Zeitpunkt "Schrott" drin war.

Keine Ahnung, aber unit Video initializiert videobuf nur wenn das OS das kann.

Ausgangspunkt in der Unit Fenster waren die netten MEMW[] Anweisungen.

Das ist das ersten Mal das ich "nett" und "mem[]" in einer Satz gesehen habe

Ich habe die Unit Video probiert. Leider fehlen da ein paar ganz wichtige
Befehle so wie das WINDOW, ohne dem geht es natürlich nicht

Video ist nicht für Crt konzipiert, aber für TV (Turbo Vision). Der Textmodus-IDE ist ganz TV basiert, und macht windowing

Mann konnte aber technisch ein Crt für KVM machen, aber bis heute hat keiner das gemacht. Nicht extrem schwierig, aber man muss dafür Video und Crt Konzepte völlig (intern) verstehen.

Zb auf Unix gibts es mehrere "crt" units (crt,ncrt,pcrt usw), und die sich unterscheiden in welcher Bibliothek oder API sie nutzen für die Ausgabe.

(Rechteck
festlegen, Attribute und ClrScr oder Write) - um das zu umschreiben müßte
man die komplette Logik ändern und es erschiene mir total umständlich
und rückschrittlich.

Den Ersatz der CRT für die Tastatur mittels der
Unit Keyboard bekomme ich ja noch hin, aber so ohne WINDOW?!
Also nahm ich trotz Warnhinweis die Unit CRT hinzu.

Ich warne nochmal. Das hat kein Zweck. Entweder Crt, oder Keyboard+Video+Mouse. (Mouse gehoert auch dabei, von hier an aus werde ich das KVM nennen)

Wenn man unbedingt Crt benoetigt soll man anfangen ein Crt auf Video Basis zu implementieren. Insgesamt das abfangen von Write usw.

Den Textmode IDE (FP) setzt den Standard was möglich ist mit KVM

Wenn man nur CRT benutzt, muß doch das Bildschirmbild auch unter Windows 32bit
auch noch einen Speicherbereich als Entsprechung haben?

Nein. Weil

1) 32/64-bit Windows initializiert hardware (memory mapped) textmode nicht eben.
2) Eben wenn es wurde, es gibt nur eins, und man kann mehrere Dos-prompts Öffnen

Unter Windows ist es aber möglich der Konsole Speicherbereich mit Funktionen zu lesen, aber es gibt da allerhande Problem (zb mit Encodings, also umlaute sind raus oder schwierig)

Aber vielleicht hat schon jemand das Problem
gelöst?

Die meisten habe ihre Kode ganz modernisiert. Ein paar habe sich begnügt mit was Crt gibt. Ein paar haben endlich sich mal richtig an TV/FV an gesetzt.

Das Signalwort ist "nur". Wenn das in einer Post ist, dann gibt es Probleme Das heißt das man denkt das etwas einfach ist, und man mag nicht hart daran arbeiten, und bleibt immer hoffen auf ein Schnellen Lösung der es nicht gibt.

Es gibt drei Lösungen:

• Das Dos basierter Konzept vergessen, und entweder Lazarus oder Turbo Vision nutzen.
  Dos ist 15 Jahre Tot, las es in ruhe rotten
• Crt + windows specifische API kodierung.
  Vorteile:
  1. wenn nur sehr wenig gelesen wird kann es relativ einfach sein.
  Probleme:
  1. Windows Crt ist komplexer dann man denkt. Es ist schon eine teilweise Dos emulierung.
  2. Als Konzept schon nicht Portabel, weil manche OSen lesen nicht unterstützen
  3. schwierig da später mehr Funktionalität hineinzulegen, oder das jemand anders die Erfahrung wieder gebrauchen kann.
  4. Crt auf Windows ist noch Relativ gut. Auf zb Linux oder OS X ist Crt in viele Details anders.
  5. hat noch nie jemand gemacht. Es gibt immer ein Risiko das man etwas findet das ein großes Problem darstellt.
• ein neues Crt machen, die sich basiert auf Crt units hin.
  Vorteile
  1. KVM units sind besser multi platform gedebugged, und haben mehr Funktionalität
  2. TV stresst fast alles in unit Video/KVM was nötig ist. Mehr Arbeit, aber keine Überraschungen
  3. ein Paar mehr Personen möchten daran interessiert sein, und/oder Rat geben.
  4. funktioniert auch auf Systemen die das Screen nicht lesen können.
  5. Video ist konzipiert um batch-updates nach Speicher zu machen, und das Speicher dann
     so effizient möglich an das OS an zu bieten. Also zb mit nur einen einzigen Write, oder
     gar mit mehrere, aber so klein Mögliche, gleich was das OS wünscht
  6. Maus Support integriert.
  Probleme:
  1. mehr Arbeit, viel davon bevor man überhaupt etwas sieht, aber, ärger,
  2. man muss wissen wie Crt und KVM funktionieren.
  3. Mehr eben wenn man das mit FPC's Qualitätsansprüche machen will.

Sehe auch zb flist.pas (in die FPC demoes, "lister/" verzeichnis), und zb das Prozedur "textout" und "textclear". Lister versucht auch Unit Video zu nutzen für fullscreen textmode Applikationen.

Ein Problem ist auch das Crt Windowing nur ein bisschen dabei macht, und TV da _alles_ machen will, und das Problem ganz anders löst. (zb event-driven). Es sind die einige zwei in Free Pascal, aber dazwischen gibst mehrere Ebenen. Weil es mehrere Beispiele gibt für TP in SWAG, hat der Lösung in Modula2 (Pascal's nachfolger) standard unit "Window" oder "textwindow" mich am meisten gefallen, speziell die von "Topspeed". (dieser Bibliothek ist Prozedurel, aber mit OOP Konzepte. (handle based). Also man kann da Windows herstellen, verbergen, wieder sichtbar machen usw)

d) oder hat jemand eine ähnliche Window/Menue Verwaltung?

Nein, die meisten gehen dann ganz für das TV Konzept (wo die Menüs der Textmode IDE mit gemacht sein),
aber das ist Eventdriven und schwer OOP, und das mögen die meiste CRT Liebhaber nicht. Die wollen nur ein bisschen basteln.

By the way: Rufe ich die Free Pascal Version des Tollzeit auf

Was ist Tollzeit? M ein Deutsch ist nicht so gut.

(egal ob
an meiner 8 Jahre alten XP Kiste oder dem eigentlich superschnellen
großen PC unter Vista), braucht er bald eine Ewigkeit für die Ausgabe des
Anfangsbildes (die 1840 Writes $178). Ich wollte mich doch verbessern?!

Siehe das Punkt zu den KVM units über das virtualisiertes Speicher so effizient möglich an das OS anzubieten. Ich glaube das Win32 Textmodus schnell sein kann, aber da muss man ein paar Dinge machen. Video macht das. Und wieder den Hinweis das den Textmode IDE da demonstriert was möglich ist. (und das ist schnell genug, eben auf mein P-II 233MHz). Dass ist alles für Crt's Konzept schwieriger, weil Crt Output immer direkt schreiben muss, und Video zb writes aufhalten kann.

Crt wird auch genuzt fuer normale Zeilen basierter aufgabe (zb ein normales terminal program mit ein download

[af0815]

Es hat sich viel zwischen DOS und den aktuellen BS geändert. Das spiegelt sich auch in den Behandlungen des Zugriffes auf externe Komponenten wieder. Weg von 'direct' Zugriffen hin zur (zwingenden) Benutzung von APIs.

Zu den units VIDEO und CRT - Hinweis aus der Doku

Code: Alles auswählen

Remark: 	The video unit should not be used together with the crt unit. Doing so will result in very strange behaviour, possibly program crashes.

Eine generelle Frage ist, ob bei dem Code sich nicht die Umstellung auf ein aktuelleres Design lohnen würde.

[alfware17]

Vielen Dank für die prompte und umfangreiche Antwort.
Das muß ich genau studieren. Aber den Compile wollte ich gleich probieren.
Leider mault der FP noch (siehe Screenshot). Wie bringe ich ihm die fehlende Unit bei?

"Was ist Tollzeit? M ein Deutsch ist nicht so gut."

Mein 8-Buchstaben-Versuch für einen Datei/Programmnamen von damals...
"toll" müßte es im Niederländischen auch geben? Hier ist aber eher das gemeint,
was im Englischen "fine" oder "great" ist, nicht etwa "wild" oder "crazy".

[marcov]

Vielen Dank für die prompte und umfangreiche Antwort.
Das muß ich genau studieren. Aber den Compile wollte ich gleich probieren.
Leider mault der FP noch (siehe Screenshot). Wie bringe ich ihm die fehlende Unit bei?

FP hat eine eigene Version von der Compiler, und deshalb auch ein eigene Konfiguration:

Options -> Directories, und da unter "unit directories" dies eingeben

c:\fpc\$FPCVERSION\units\$FPCTARGET
c:\fpc\$FPCVERSION\units\$FPCTARGET\rtl
c:\fpc\$FPCVERSION\units\$FPCTARGET\*

(annehmend das FPC in c:\fpc installiert wurde).

Aber ich meinte der IDE meistens als eine Demonstration was alles möglich ist mit Turbo Vision und Textmodus programmieren in FPC in generellen . Ihres Program wird gleich so funktionieren als ohne IDE.

"Was ist Tollzeit? M ein Deutsch ist nicht so gut."

Mein 8-Buchstaben-Versuch für einen Datei/Programmnamen von damals...

Ich habe schon verstanden das es den Projektnamen ist. Ich dachte "xx des Tollzeits" wäre eine Redensart für "damals" (oder Prähistorisch) oder so.

"toll" müßte es im Niederländischen auch geben? Hier ist aber eher das gemeint,
was im Englischen "fine" oder "great" ist, nicht etwa "wild" oder "crazy".

Ich weiß natürlich was "toll" ist aufs Deutsch, ich hatte nur mehr dahinten gesucht.

Und nein, ein ähnliches Wort gibst nicht im Niederländischen. "geweldig" (Gewaltig oder Großartig aufs Deutsch) oder "fantastisch" (wie in Deutsch) deckt das am Besten.
Vielleicht kommt "toll" mehr vom Alemannischen Bereich. (spezifisch Hoch-Deutsch).

Auch ins Platt kennt ich es nicht (das lokalen (Limburgischen) Platt ist ähnlich wie im Aachen/Ruhrpott, und hört sich Deutscher an als reines Niederländisch. zb "ich" statt "ik" usw)

[theo]

Vielleicht kommt "toll" mehr vom Alemannischen Bereich. (spezifisch Hoch-Deutsch).

http://de.wiktionary.org/wiki/toll" onclick="window.open(this.href);return false;

[marcov]

Vielleicht kommt "toll" mehr vom Alemannischen Bereich. (spezifisch Hoch-Deutsch).

http://de.wiktionary.org/wiki/toll" onclick="window.open(this.href);return false;

Ah, also vielleicht doch. Es gibt "Dol", aber das wird anders genutzt, mehr als "wild/aufgeregt", "verrückt" oder schwindlig (von drehen).

Das Diminutiv (dolletjes, das wurde "toll-e-chen" oder so etwas sein auf Deutsch) wird in der Tat wie das Deutsche "toll" genutzt, aber nicht oft. Es hört sich auch ein bisschen Flower Power (siebziger Jahre) an, und ist heute oft mehr sarkastisch gemeint als nicht.