Beiträge von markusk

Hallo,

Hier mal ein Bild wie das am TFT Monitor aussieht und die Typenschilder des EGA Monitors.

Lg, Markus

Ok, dann lass ich es lieber, so wichtig ist es nun auch wieder nicht. Notfalls werde ich mich nach einem monochromen Röhrenmonitor umschauen. Die Röhrenmonitore sind mir sowieso irgendwie lieber, da authentischer und das Bild auch irgendwie besser ist meiner Meinung nach. Müsste halt einer sein den man auch länger laufen lassen kann ohne dass er zu Müffeln beginnt. Das ist bei dem EGA-Monitor beispielsweise der Fall. Wenn der 5 Minuten läuft, muss man den Raum schocklüften.

Hallo,

ich werde heut nach der Arbeit mal schauen was das für ein EGA-Monitor ist bzw. ein Bild vom Typenschild posten. Kann ich es grundsätzlich mal ausprobieren wie die Anzeige am EGA-Monitor mit der MDA-Karte ist oder kann da was an der Karte / am Monitor kaputt gehen?

lg, Markus

Hallo,

ich hab gestern eine MDA-Karte bekommen und hab sie in meinem Commodore PC 20 II ausprobiert, sie funktioniert soweit auch grundsätzlich, allerdings hab ich im linken Bereich Unregelmäßigkeiten in der Darstellung der Zeichen, manche Pixel sind hell, manche etwas dunkler, aber nicht schwarz, d.h. man kann die Zeichen als solche erkennen.

Kann natürlich an der Karte liegen, aber ich bin mir nicht sicher ob es nicht vielleicht eher am TFT-Monitor liegt. Hab mir den letztes Jahr auf Ebay geholt und es wurde da vom Verkäufer ein externes Panel mit DIP-Schaltern hinzugefügt mit dem man zwischen monochrom und EGA umschalten kann. Mit meiner Hercules-Karte (wegen der ich mir den Monitor eigentlich geholt hab) funktioniert die Darstellung auch gut, aber wenn ich den Monitor testhalber auf EGA umschalte und an meinem Atari PC 3 mit EGA-Karte anschließe ist die Darstellung auch nicht gerade berauschend, d.h. der Verdacht in Bezug auf den TFT-Monitor könnte durchaus berechtigt sein.

Ok, nun meine Frage: Kann ich einen EGA-Monitor an eine MDA-Karte anschließen?

Hab da nämlich noch einen EGA-Röhrenmonitor von dem ich weiß dass er am Atari PC3 einwandfrei funktioniert, aber ich weiß eben nicht ob die Kombi MDA-Karte mit EGA-Monitor funktioniert.

lg, Markus

Sehe ich auch so, das Thema an sich ist sehr interessant und technisch eine große Herausforderung. Würde den Fortschritt ebenfalls gerne mitverfolgen!

Ich selbst hab nur noch zwei größere GW-Basic Programme, die aber nicht in Verwendung sondern eher Erinnerungen an meine Anfangszeiten mit dem PC sind.

Viel Erfolg Peter! 😀

Genau, das kommt ja noch hinzu, dass man den generierten Code ja auch erstmal verstehen muss bevor man auf Fehlersuche geht. Das nimmt auch wieder viel Zeit in Anspruch die man wiederum viel besser bei der Neuimplementierung investieren kann.

Von der Zeit die hier für's Testen draufgeht ob die maschinell portierte Version nach den ganzen Nacharbeiten dann auch wirklich dasselbe macht wie die BASIC-Version reden wir hier noch gar nicht.

Aber um wieder auf die GW-Basic zu Pascal Portierung zurückzukommen:

Machbar ist mehr oder weniger sicher (fast) alles mit entsprechend viel Programmier- und Zeitaufwand und gerade bei größeren Programmen wünscht man sich die nicht nochmal neu in einer anderen Sprache umsetzen zu müssen, aber aus meiner Sicht ist das die einzig wirklich brauchbare Lösung. Ein Neuschreiben nimmt da glaub ich weniger Zeit in Anspruch als den Code den die Portier-Software erzeugt hat von Fehlern zu befreien und an seine persönlichen Vorstellungen anzupassen.

Zumal man dadurch ja zusätzlich die Möglichkeit hat im Zuge der neuen Umsetzung auch gleich Verbesserungen / Korrekturen einzubauen.

So ist es, da muss man echt aufpassen, vor allem wenn allokierte Ressourcen im Spiel sind die dann durch das direkte Rausspringen möglicherweise nicht sauber freigegeben werden.

Aber wie gesagt, hab dann nachher bessere Möglichkeiten gefunden weil ich eben in genau diese Probleme gelaufen bin die ich nicht im Blick hatte als ich das umgesetzt habe.

Genau, wirklich gebraucht und angewendet hab ich das dann nur in einer Handvoll Fällen weil ich mit der Zeit dann immer mehr darauf geachtet habe solche tieferen Verschachtelungen zu vermeiden und somit auch das Error-Handling einfacher wurde.

Zitat von struuunz

Aus meiner Sicht ist ein GOTO der Abgrund der Programmierung

Persönlich habe ich noch nie auch nur ein einziges GOTO in einem Programm geschrieben oder benötigt. Und das obwohl ich fast nur strukturiert Programmiere ( COBOL ).

Im Gegenteil: GOTOs werden aus den Programmen systematisch entfernt.

Hallo!

Da stimme ich Dir voll und ganz zu, aus meiner Sicht gibt es nur eine einzige Situation in der ein GOTO sinnvoll ist, und zwar als schneller Ausstieg aus tiefer verschachtelten Konstrukten wenn beispielsweise ein Fehler auftritt den man ansonsten jeweils an die nächsthöhere Ebene weiterreichen müsste.

Wobei man in solchen Fällen darüber nachdenken sollte ob es nicht eine bessere Lösung gibt als solche unschönen tiefen Verschachtelungen.

Wie dem auch sei, ich hab mir in Pascal mal sowas gebaut, ein prozedurübergreifendes GOTO dem man beim Aufruf auch gleich Detailinformationen zum Fehler mitgeben kann. Also eine Art Exception Handling wie man es beispielsweise von Java her kennt.

Darüber hinaus wird beim Ausstieg auch gleich der Stack aufgeräumt denn es kann ja sein dass sich zum Zeitpunkt des Fehlers noch viele Parameter und lokale Variablen von den übergeordneten Aufrufen auf dem Stack befinden die ansonsten dort verbleiben und der Stack irgendwann überlaufen würde.

Bin dann irgendwann später draufgekommen dass ich da exakt das abgebildet habe was es in C bereits gab (setjmp und longjmp)

Umgesetzt hab ich das in Assembler weil man dann einfach besser versteht was da passiert. Zumal man da ja an diversen Registern rummanipuliert die man ansonsten nicht direkt angreift (z.B. CS, IP und SP)

lg, Markus

Hallo!

Und wieder eine kleine Idee umgesetzt 😀 Diesesmal ging’s darum kleine Grafiken auf den Bildschirm zu bringen obwohl man sich im Textmodus befindet. Klappt wunderbar, einfach das Punktmuster in einem Texteditor festlegen und meine Turbo Pascal Unit macht daraus eine Grafik die man beliebig oft überall am Textbildschirm anzeigen kann.

Natürlich sind auch mehrere unterschiedliche Grafiken möglich wie auf dem Bild zu sehen ist. Ist eine reine Phantasiegrafik die ich da erstellt hab, ging mir nur darum ein größeres Muster mit allerhand Ecken und Kanten für Tests zur Verfügung zu haben.

Lg, Markus

Zitat von mac-daniel

Ich persönlich möchte weder auf einem alten noch auf einem modernen System mit einem Computer sprechen aber interessant ist es auf jeden Fall dass jemand sich die Mühe gemacht hat da was zu programmieren.

Ich auch nicht, höchstens in Form von Programmcode und bisher lebt es sich ohne Chat GPT ganz gut. Es gibt einfach Sachen die brauch ich nicht in meinem Leben und Chat GPT ist eine davon. KI ist grundsätzlich ja eine interessante Sache, auch alles was in Sachen Programmierung dahintersteckt, aber ich kann den ganzen diesbezüglichen Mega-Hype der da gerade um sich greift ehrlich gesagt nicht nachvollziehen.

Hallo!

Bei mir hat sich die Frage einer automatisierten Portierung von GW-Basic nach Pascal zwar noch nie gestellt, aber der Sachverhalt welcher Dich zu dieser Frage geführt hat würde mich interessieren.

Möchtest Du zukünftig von GW-Basic auf Pascal wechseln und würdest Deine GW-Basic Programme gerne "mitnehmen" ohne sie (mehr oder weniger) aufwändig neu in Pascal implementieren zu müssen?

Ehrlich gesagt bin ich mir nicht sicher ob das maschinelle Portieren von GW-Basic nach Pascal ohne große Nacharbeiten so einfach funktioniert weil sich die Sprachen im Aufbau ja doch sehr unterscheiden.

Bei einfachen Programmen mag das ja vielleicht noch funktionieren, aber bei komplexeren Programmen wird das schwierig glaub ich.

Aber wie gesagt, ich stand noch nie vor dem Problem und hab mich daher auch nie tiefer mit diesem Thema beschäftigt was vermutlich auch daran liegt dass ich eine tiefe Abneigung gegen alles habe das Code generiert. Ich schreib den Code lieber selber, d.h. ich würde meine GW-Basic Programme in Pascal neu schreiben anstatt sie durch einen automatisierten Portierer zu jagen.

Ich kann mir vorstellen dass ich vermutlich mehr Zeit brauchen würde den generierten Code an meine Vorstellungen anzupassen als das Programm in Pascal neu zu schreiben.

Und weil oben Chat GPT erwähnt wurde: Auch wenn's vielleicht noch so gut funktioniert, eher friert die Hölle zu als dass ich mir von einer KI Code für meine Programme generieren lasse. Das verstößt einfach gegen den Programmierer-Ehrenkodex

lg, Markus

Hallo!

Der Thread ist schon recht alt, aber mich würde interessieren wie Deine Assembler Story weitergegangen ist. Gerade bei Assembler ist es oft so dass man begeistert anfängt aber dann oft leider nicht so richtig dran bleibt.

Vor allem dauert es ja ein wenig bis man sichtbare Ergebnisse erzielt für die man in einer Hochsprache nur wenige Zeilen benötigt, das fängt schon bei einfachen Ausgaben auf dem Bildschirm an, z.B. bei Zahlen, Text allein geht ja noch recht einfach.

Seitdem ich mich in Sachen Programmierung voll und ganz auf den DOS Bereich konzentriere ist Assembler mehr oder weniger regelmäßig im Einsatz und es macht echt viel Spaß weil man nur durch Beschäftigung mit Assembler erst so richtig erkennt wie die Dinge unter der Motorhaube ablaufen.

Lg, Markus

Zitat von Mr Vain

Hatte auch mal so eine Textmode GUI angefangen, weil ich mit Turbo Vision nicht so recht warm werde...

Hallo!

Mit Turbo Vision hab ich mich nie beschäftigt, bin weniger der Anwendungs-Programmierer sondern interessiere mich eher für Systemprogrammierung bzw. für das Erstellen eben genau solcher Toolboxen mit denen andere dann Anwendungen erstellen können.

Mit Turbo Pascal hab ich ehrlich gesagt auch nie objektorientiert programmiert und möchte es auch in Zukunft nicht obwohl ich beispielsweise viel und gerne in Java programmiert habe bevor ich mein Hauptaugenmerk auf die DOS-Programmierung gerichtet habe.

Weiß nicht, das prozedurale Programmieren macht für mich irgendwie einen Teil des Charmes der DOS-Welt aus.

lg, Markus

Hallo!

Ich hab gestern auch eines meiner Ziele bezüglich Programmierung erreicht, eine Fensterverwaltung, geschrieben hab ich sie in Turbo Pascal, ist einfach mein Favourite.

Hab sie auch schon auf meinem 486er System ausprobiert, läuft echt gut und vor allem performant.

Was ich noch testen muss ist wie sich die Sache mit einer Monochrom-Karte verhält, denn da ist die Umsetzung des Schattens beispielsweise ja anders.

Sollte auch mit benutzerdefinierten Textmodi funktionieren (z.b. 90 x 30 Zeichen) weil ich die aktuellen Einstellungen aus dem BIOS Variablenbereich auslese. Muss ich noch ausprobieren.

Steckt eine ganze Menge Code dahinter, vor allem das Verschieben der Fenster in alle Richtungen und das Hervorholen eines beliebigen Fensters in den Vordergrund ist nicht ganz so einfach wie es vielleicht auf den ersten Blick aussieht. Da muss man ganz schön im Videospeicher rumfuhrwerken.

Werde sicher noch das eine oder andere Feature hinzufügen, aber mit den aktuellen Möglichkeiten gefällt es mir schon ganz gut.

Hab ja vor einiger Zeit ein Hackprogramm für Red Baron geschrieben, vielleicht verschönere ich das mit der Fensterverwaltung ein wenig.

Lg, Markus

Zitat von H.EXE

Wir haben schon Mai! Und, wie ist euer Zwischenstand?

Bei mir: 0%.

Hallo!

Also ich bin eigentlich ganz zufrieden, wollte mich 2023 wieder mehr der Programmierung widmen und das hat soweit recht gut funktioniert obwohl es Phasen gab in denen wenig Zeit dafür übrig geblieben ist.

Hab mir wieder mal das Buch "Turbo Pascal intern" von Michael Tischer geschnappt und einige interessante Kapitel durchgearbeitet wobei ich dann wie immer versucht habe basierend auf dem erworbenen Wissen meine eigene Lösung für das jeweilige Thema zu finden.

Diese waren:

- Prozedurübergreifendes Goto (wobei ich meine Lösung dann in Assembler anstatt in Turbo Pascal umgesetzt habe)

- Fensterverwaltung

- Konfigurieren von Programmen ohne Konfigurations-Datei, sondern über direkte Manipulation der .exe Datei

Das Kapitel über TSR-Programmierung hab ich schon vor einiger Zeit erfolgreich absolviert.

Das Thema hat mich am meisten interessiert und es war eine ziemliche Herausforderung weil viel Hintergrundwissen erforderlich ist und man um Assembler nicht wirklich herumkommt.

Aber gerade in Assembler kann man die Abläufe am besten nachvollziehen und lernt viel dabei.

lg, Markus

Zitat von Stefan307

Auch wenn hier völlig OT, es bleibt also dabei, wenn man nur eine Sprache lernen will und damit möglichst alles machen, dann C oder?

Hallo!

Tja, das ist die uralte religiöse Frage

Was verstehst Du im Detail unter "alles machen"?

Jede(r) hat da ja so seine eigenen Ziele und Vorstellungen die man gerne in einem Programm abbilden will.

Ich beispielsweise hab bis vor 2 Jahren privat viel in Java / C# programmiert, hab aber dann sämtliche Programmier-Aktivitäten vollständig nach DOS verlagert weil mir das viel mehr Spaß macht. Allein schon deswegen weil ich in bezug auf die hardwarenahe Programmierung völlig freie Hand habe. Vieles muß noch von Hand erledigt werden und das ist es was mich irgendwie reizt.

Meine hauptsächlichen Themen bei der Programmierung sind:

• Hardwarenahe Programmierung, z.B. direkte Programmierung der Grafikkarte
• Systemprogrammierung (z.B. TSR-Programme)
• Anwendungsprogrammierung, z.B. auf Basis von einer selbstgeschriebenen Fensterverwaltung

Bis jetzt konnte ich alles wunderbar mit Turbo Pascal / Turbo Assembler abdecken. Klar könnt ich das alles genauso gut in C machen, aber Pascal gefällt mir irgendwie besser.

Aber das spielt sich wie gesagt alles im DOS-Universum ab, in der modernen Welt spielen da ganz andere Kriterien bei der Wahl der Sprache mit rein.

Die Diskussion ist jedoch wie Du schon geschrieben hast Off Topic, geht am Thema Rust vorbei und sollte daher in einen anderen Bereich verschoben werden.

lg, Markus

Hallo,

Wieso stürzt mir das folgende Programm ab? Wenn ich es starte muß ich die DOSBOX bzw. die VM neu starten weil das Ding nicht mehr reagiert, ich seh aber den Fehler nicht.

lg, Markus

program test;
uses crt;

type PROCTYPE = procedure (i : integer);

     PROCPTRTYPE = ^PROCTYPE;

var p : PROCPTRTYPE;

procedure test1 (i : integer);
begin
  writeln('test1');
end;

procedure test2 (j : integer);
begin
  writeln('test2');
end;

procedure test3 (k : integer);
begin
  writeln('test3');
end;

begin
  clrscr;
  p:=@test1;
  p^(200);
  readln;
end.

Aber wie krieg ich das Virusprogramm dann ans Ende der .COM Datei?