Hello, Guest the thread was called100k times and contains 1748 replays

last post from Hoogo at the

Neuer Retro-Computer im 8-Bit Style

  • Der ARM-Prozessor kann also wie beim MiSTer auf dem Board mitverbaut sein, aber er gehört praktisch trotzdem zur Peripherie, und welche Prozessoren in der Peripherie stecken, kann dem Retrorechner ziemlich egal sein.

    So in der Art habe ich mir das auch vorgestellt. Den edlen Retro-Rechner, der auf dem FPGA läuft, muss es doch nicht interessieren, wie der ARM die hässliche Peripherie verwaltet.


    Die Sache hat aber leider einen Haken. Zwar lassen sich mittels einer Multiplikation mit 4 die 480 Pixel sauber auf 1920 Pixel strecken, doch handelt es sich hierbei bereits um eine FullHD-Auflösung, die mit einfachen elektronischen Mitteln nicht zu erzielen ist. Zur Zeit sieht es eher so aus, als würde bereits die niedrigste HDMI-Auflösung von 640 Pixeln die Grenze dessen darstellen, was man mit dem FPGA erzielen kann.

    Warum sollte das beim Output/Display so viel anders sein als bei der restlichen Peripherie – also dem Input. Der Retrorechner gibt irgendeine Low-Res-Auflösung (bis maximal 640 Pixel) aus – und der ARM bzw. dessen Grafikeinheit macht daraus 2K (meinetwegen mit ein paar Effekten, wie Scanlines) und schickt das auf den HDMI-Port.


    Sollte jemand wissen wie das (zu einem tragbaren Preis) geht, möge er/sie gerne vortreten.

    Was ist mit dem von RexRetro vorgeschlagenen Vidor 4000? Der hat doch laut Specs alles, was man sich wünschen kann. Für rund 70 Euro. Es wurde sogar vorgeschlagen (und von mir unterstützt), dir so ein Ding zu besorgen – wenn das zielführend für das Projekt sein sollte.

  • Man kann sich daher jetzt weiterhin gerne BASIC als Sprache wünschen, weil man das von früher halt so kennt, als man noch ein Kind war. Man kann aber auch realistisch sein und erkennen, daß dies keine sonderlich gute Idee ist aus all den oben genannten Gründen. Hinweis am Rande: Auch der Pico-8 arbeitet nicht mit BASIC, sondern mit einer Sprache, die von ihrem Aufbau sehr an Pascal erinnert. Und das ist kein Zufall.

    Bei mir rennst du damit seit einiger Zeit offene Türen ein. Ich bin ja durchaus mit Pascal-ähnlichen Sprachen aufgewachsen und habe damit keine Berührungsängste. Es kommt ja ohnehin eher auf das drumherum an – und wenn man das so angenehm gestaltet, wie beim Pico-8, dann ist das weitaus besser, als ein nackter CBM-Basic-Editor/Interpreter. Auch und gerade für Anfänger.

  • Warum sollte das beim Output/Display so viel anders sein als bei der restlichen Peripherie – also dem Input. Der Retrorechner gibt irgendeine Low-Res-Auflösung (bis maximal 640 Pixel) aus – und der ARM bzw. dessen Grafikeinheit macht daraus 2K (meinetwegen mit ein paar Effekten, wie Scanlines) und schickt das auf den HDMI-Port.

    Leider ist es nicht so einfach, wie es aussieht. :( Damit dies funktioniert, müßte ein Coprozessor (ARM oder sonstwas) in Echtzeit sich in absolut genauen, regelmäßigen Abständen die Bilddaten vom RGB-Port des Videocontrollers holen und diese dann entweder direkt an den HDMI-Port weitergeben (wobei 4 Pixel wiederholt geschrieben werden) oder alle Daten zunächst in einen (sehr) großen Speicher schreiben, von wo aus sie ein weiterer Videocontroller ausliest und mit seinem HDMI-Port ausgibt. Dazu braucht man aber halt zusätzlich einen zweiten Videocontroller sowie ein paar Megabyte Speicher, also ein drastischer Mehraufwand. Und letztendlich wird das Problem nur verlagert: Wie soll dann der zweite Videocontroller die Daten über HDMI ausgeben?

    Abgesehen davon liegt das Problem gar nicht am ARM. Der ist im Grunde völlig überflüssig. Relevant ist nur, ob der HDMI-Port überhaupt in der Lage ist, die Übertragungsgeschwindigkeit von FullHD zu erreichen. Leider findet ich über diesen wichtigen Punkt nichts in den Datenblättern.

    Vidor 4000

    Dazu kann ich leider zu wenig sagen, da ich die nötigen Informationen im Internet bisher nicht auftreiben konnte. Unklar ist mir z. B. a) wie schnell der HDMI-Port ist, b) wie der FPGA auf das eingebaute SDRam zugreift.

    Der von Maik gebastelte Shield, den wir verwenden, verfügt über schnelles SRam mit einer Zugriffsgeschwindigkeit von 20ns (= 50 Mhz) beim Lesen und 40ns (= 25 Mhz) beim Schreiben. Da sich Prozessor und Videocontroller das Ram teilen und alle irgendwie gleichzeitig darauf zugreifen müssen, ist es von enormer Wichtigkeit, daß das Ram diese Zugriffe schnell erledigen kann. SDRam (wie bei dem Vidor 4000) hat jedoch den Nachteil, daß es mehrere Takte dauert, bis man an die eigentlichen Daten kommt. Es ist somit viel langsamer als das SRam, was das System stark ausbremst und dafür sorgt, daß einige höhere Auflösungen gar nicht mehr dargestellt werden können, da das Ram die Daten einfach nicht schnell genug liefern kann. Dieser Vorgang läßt sich in bezug auf den Videocontroller auch nicht mit einem Cache abfedern wie beim Prozessor, da der Videocontroller die Daten nur einmal pro Frame liest und die Datenmenge der Bitmap jeden Cache sprengt. Hinzukommt, daß ein Zeichensatzmodus anders als ein reiner Bitmapmodus seine Daten nicht nacheinander aus dem Speicher holt, sondern wild verstreut. Ein Zeichen im Zeichenpuffer ist ja nichts anderes als ein Zeiger auf eine Zeichenmatrix in einem Zeichensatz, der irgendwoanders im Speicher liegen kann.

    Beim Mega65 hat man das Problem so "gelöst", daß das ganze Ram des Retrorechners aus dem internen Blockram des FPGA besteht. Man verwendet also von vornherein gar kein externes Ram mehr und geht damit den Problemen mit den langsamen Ramzugriffen aus dem Weg.

    Der Mega65 hat dafür einen sehr teuren FPGA verbaut mit 256 kb Blockram. Der Vidor 4000 hingegen kommt auf gerade einmal 56 kb, was nicht ausreicht für z. B. ein DoubleBuffering einer 320x200x16 Grafik (oder wie bei meinem System aus zwei Bitmaps, eine für den Hintergrund und eine für den Vordergrund). Zum Vergleich: Unser System hat dank des SRams 512 kb Videospeicher, also doppelt soviel wie der Mega65.

    Zuletzt gibt es beim Vidor 4000 noch die Frage, mit welcher Datenbusbreite das Ram angebunden ist. Auch darüber habe ich bisher nichts gefunden. Bei Maiks Shield gibt es einen 16 Bit Bus, was z. B. der CPU zugute kommt, da die meisten Befehle aus 16 Bits bestehen. Es kann also pro Speicherzugriff direkt ein neuer Befehl geladen werden. Wäre die Datenbusbreite jedoch nur 8 Bits breit, würde allein schon das Befehlladen doppelt solange dauern. Und natürlich reduziert es auch gleichzeitig die Bandbreite für die Videodaten.

    Zusammengefaßt lautet das Problem also: Noch weiß ich überhaupt nicht, wo und wie man mit dem Vidor 4000 eine Bitmap speichern kann, und ob die Videodaten schnell genug zum HDMI-Port gelangen und dort wiederum schnell genug als FullHD ausgegeben werden. Einfach viel zu viele Fragezeichen für den Moment. RexRetro wird sich aber wohl ausführlicher mit dem Vidor 4000 beschäftigen. Vielleicht kann er uns dann später irgendwann eine genauere Analyse mitteilen.

  • Man kann sich daher jetzt weiterhin gerne BASIC als Sprache wünschen, weil man das von früher halt so kennt, als man noch ein Kind war. Man kann aber auch realistisch sein und erkennen, daß dies keine sonderlich gute Idee ist aus all den oben genannten Gründen. Hinweis am Rande: Auch der Pico-8 arbeitet nicht mit BASIC, sondern mit einer Sprache, die von ihrem Aufbau sehr an Pascal erinnert. Und das ist kein Zufall.

    Bei mir rennst du damit seit einiger Zeit offene Türen ein. Ich bin ja durchaus mit Pascal-ähnlichen Sprachen aufgewachsen und habe damit keine Berührungsängste. Es kommt ja ohnehin eher auf das drumherum an – und wenn man das so angenehm gestaltet, wie beim Pico-8, dann ist das weitaus besser, als ein nackter CBM-Basic-Editor/Interpreter. Auch und gerade für Anfänger.

    Wäre es aus Akzeptanzgründen nicht dennoch besser, auf strukturiertes Basic (QBasic) aufzubauen? Natürlich kompilierfreundlich modifiziert. (So wie C++, Java, PHP, JavaScript, ... aus demselben Grund die C-Syntax verwenden.)

  • Wäre es aus Akzeptanzgründen nicht dennoch besser, auf strukturiertes Basic (QBasic) aufzubauen?

    Hatte ich anfangs auch gesagt. Aber ehrlich, wenn man 5 Minuten im PICO-8-Editor (mit Lua) verbracht hat und sich das erste Männchen über den Bildschirm bewegt, gibt es eigentlich keinen Grund, zu Basic (und den Editoren von 1980) zurückkehren zu wollen. Nun, man wird sicherlich ein paar Befehle nach Basic-Manier benennen können, um es den Altgedienten etwas wohliger zu gestalten – aber ansonsten lässt man den alten Kram eigentlich gerne zurück. Letztendlich ist eine Schleife eine Schleife – wie die nun genau aufgebaut wird, ist doch fast egal – Hauptsache man versteht das Prinzip.


    Es geht ja auch darum, nicht nur auf dieser Maschine Spiele zu schreiben – man soll ja auch was lernen. Und ich denke, Basic ist da eher eine Sackgasse. Und "strukturiertes" Basic ohne Zeilennummern – ist das überhaupt noch "Basic" (wie es ein Alt-C64-User erwarten würde)?

  • Was genau ist denn jetzt eigentlich im Sinne dieses Threads? Geht es hier jetzt nur noch um den Lern-Computer?

    Ich glaube dass dies hier de facto nach wie vor der "Sammelthread aller Parteien" ist

  • Vieleicht sah ich bisher einen zu starken Retrobezug hier.

    Jeder hat ja anscheinend sein eigenes Retro. Mir ist vor allem das "richtige Gefühl" wichtig, anderen die CPU oder die Schnittstellen oder das BASIC oder was auch immer. Und ich würde (wenn man sich die "Personas" anguckt, wird das klar) AUCH die Retro-Gemeinde ansprechen wollen – aber nicht NUR. Wenn man es vom Markt her betrachtet, ist der Hardcore-Retro-Bereich doch sehr klein – im Vergleich zum gesamten Consumer-IT-Markt.


    Sowas wie ein Mega65, zudem noch bei dem Preis, spricht ein paar Tausend Leute an. Der C256 Foenix hat noch weniger User, würde ich annehmen. Was die Software-Versorgung und den Support angeht, steht und fällt alles mit der User-Anzahl. Daher würde ich immer empfehlen, dass man sich möglichst breit aufstellt und auch Zielgruppen außerhalb der reinen (Ex-)Commodore-User zu suchen. Apropos Commodore: Es ist auffällig, dass ein Großteil der Retro-Rechner (Mega65, Commander X16, C256 Foenix, The64 mini/maxi, The VIC20, The A500 mini) auf Commodore-Fans abzielt. Die waren natürlich eine sehr starke Gruppe in den 80ern (und damit auch heute) aber beileibe nicht die komplette damalige Computer-Szene (in den USA z.B. war der Markt recht gleichmäßig auf Commodore, Atari, Apple und TRS-80 aufgeteilt). Schon alleine, um nicht in die selbe Kerbe zu schlagen und den gleichen Markt zu bedienen, würde ich den Retro-Ansatz allgemeiner halten und nicht auch wieder "blauer Screen und CBM-Basic" anbieten.


    Mir (als Grafiker) ist bei einem Retro-Homecomputer natürlich wichtig, dass vor allem die Grafik einen starken Retro-Touch hat. Deswegen bin ich an der Stelle auch besonders "diskussionsfreudig" und pingelig. Der Sound gehört natürlich genau so dazu – auch der sollte ganz klar "retro" sein. Wie das genau zu bewerkstelligen ist, würde ich den Fachleuten für Retro-Musik überlassen, da kenne ich mich kein Stück mit aus.


    Was die Innereien, wie die CPU angeht (und ob die emuliert wird oder in einem FPGA umgesetzt), bin ich eher leidenschaftslos und finde es klasse, wenn sich "Auskenner", wie M. J. da reinhängen und eine tolle Retro-CPU erfinden (die einerseits noch retro/einfach ist, andererseits aber viel typischen Coder-Ärger von früher zu vermeiden versucht). Wenn andere der Meinung sind, eine 68K- oder RISC-V CPU wäre die bessere Lösung, dann sollen die sich alle untereinander die Köppe einhauen. ;)


    Was mir aber wieder wichtig ist, ist, dass darauf am Ende eine klasse IDE und Programmiersprache läuft, die es ermöglicht, kleine Action-Games ohne den Einsatz von Assembler zum Laufen zu bekommen (und zwar komfortabel, also mit Sprite-Editoren etc). Wie schnell dafür die CPU getaktet sein muss? Keine Ahnung – ausreichend halt. ;) Wenn 8 MHz reichen, toll, wenn 32 nötig sind, auch OK – und wenn es 100 sein müssen – dann eben 100. Und wenn man herumtricksen muss und zum Kompilieren des Spiele-Codes nicht nur die Retro-CPU verwendet, sondern den herumliegenden ARM, wäre mir das auch egal. Mir kommt es letztlich auf das Ergebnis, das Gefühl, an.


    Und sollte Hard- und Software doch nicht zusammenpassen (das ist ja leider immer noch nicht klar), dann wären das halt zwei getrennte "Projekte".


    Was wäre an so einem angedachten Rechner retro? Nun, im Optimalfall CPU, Grafik, Sound usw. – Und auch das Kaufen-auspacken-einschalten-loslegen-Gefühl (entweder (gemeinsam) Spielen oder coden/pixeln/soundbasteln) und der favorisierte Anschluss an den Fernseher. Was wäre nicht retro? Moderne Schnittstellen, kein Zeilennummern-Basic, "moderne" IDE/Editoren (sofort nach dem Einschalten – ansonsten ähnlich Pico-8-Software).


    Aber wir hatten einiges natürlich schon im Detail besser geklärt, daher wäre es wahrscheinlich sinnvoll, wenn ich mir irgendwann doch mal der Ärger antue und den ganzen Thread nach Info-Bröckchen (für einen "Hauptstrang"-Retro-Rechner) absuche und eine Zusammenfassung schreibe.

  • Was genau ist denn jetzt eigentlich im Sinne dieses Threads? Geht es hier jetzt nur noch um den Lern-Computer?

    Immer gerade, was kommt. ;) Wenn es der Übersichtlichkeit dient (wurde ja gewünscht), kann ich für den FPGA-Hardware-Teil (ab hier) einen extra-Thread starten – ich werde aber nicht den ganzen Thread durchgehen und aufsplitten.

  • Wäre es aus Akzeptanzgründen nicht dennoch besser, auf strukturiertes Basic (QBasic) aufzubauen? Natürlich kompilierfreundlich modifiziert.

    Ich wüßte nicht, wie man Basic und auch QBasic kompilerfreundlich gestalten sollte, denn kompilerfreundlich bedeutet Single-Pass-Compiler. Da man aber z. B. Unterprogramme hinter ihrem Aufruf definieren kann, sehe ich dies von vornherein als nicht gegeben an.


    Desweiteren gefällt mir an QBasic die Beschränktheit nicht. Von einer programmierfreundlichen Sprache erwarte ich, daß sie zumindest die Möglichkeit anbietet, eigene Datentypen und Structs (bzw. RECORDs) zu gestalten. Das scheint mir bei QBasic nicht der Fall zu sein.


    Wäre es nicht besser, eine Sprache zu haben, die einem Neuling schrittweise anbietet, mehr in die Programmierung einer Hochsprache einzusteigen, so daß er/sie am Ende dann ohne große Mühe auch nach C++ oder Java etc wechseln kann? Im Nachhinein bin ich ganz froh, daß wir damals an der Schule Pascal gelernt haben, denn die Konstrukte, die wir da lernen konnten, habe ich später nicht nur in anderen Hochsprachen wie C oder Java fließend übernehmen können, sondern selbst in Assembler eingesetzt. Basic mag ja eine Anfängersprache sein, bleibt aber leider auch auf diesem Niveau stehen.


    Wichtig: Die Lernsprache sollte nicht vorschreiben, wie man programmiert so nach dem Motto "Alles hat gefälligst ein Objekt zu sein. Also programmierst Du jetzt nur noch OO!!1elf!!" Wer keine Structs/Records, Datentypendeklaration, call-by-reference etc einsetzen will, mag das gerne so tun. Das ist völlig jedem überlassen. Es gibt hier ausdrücklich keine Ideologie, die irgendwas vorschreibt. Aber persönlich möchte ich ohne solche (simplen) Datentypen nicht mehr programmieren, weil sie einem die Entwicklung doch ziemlich erleichtern.


    Ehrlich gesagt, kann ich das Festhalten an Basic auch nicht richtig nachvollziehen. Was ist so besonders an Basic, daß man es unbedingt einsetzen muß? Jedes um Strukturbefehle erweiterte Basic, das ich bislang gesehen habe, sieht doch fast schon aus wie eine Pascalsprache. Warum dann nicht direkt auf eine kompilertaugliche moderne Sprache aus der Pascal-Familie zurückgreifen, die ähnlich aussieht, darüberhinaus aber viel mehr Möglichkeiten bietet?


    Um es noch einmal ganz deutlich zu machen: Mein Vorschlag für eine Sprache entspricht nicht Pascal, sondern lediglich einer Sprache, die so ähnlich aussieht. So gibt es zahlreiche Unterschiede zu Pascal:

    - keine lästige BEGIN END - Klammerung bei Schleifen oder IF-Anweisungen. Alle Schleifen (mit Ausnahme von REPEAT) und IF-Anweisungen werden immer mit END abgeschlossen. BEGIN entfällt bzw. findet sich nur noch als Trennung zwischen Deklaration und Programmteil.

    - keine Ausschnittstypen wie z. B. "zahl : 32..63". Es gibt nur zwei Datentypen für Zahlen: INTEGER und BYTE.

    - kein PRED und SUCC mehr.

    - zusätzlicher ELSIF-Zweig bei IF-Anweisungen, z. B.

    IF a = b THEN

    ...

    ELSIF c = d THEN

    ...

    ELSE

    ...

    END

    - keine Case-Varianten-Records. Stattdessen UNION, wenn man möchte, daß alle Elemente eines Records den gleichen Speicher belegen.

    - WITH-Anweisung erzeugt einen temporären Zeiger auf ein Element zur Vereinfachung des Programms und gleichzeitig zur Beschleunigung, z. B.

    WITH element = einarray[4, i].record_offset.noch_ein_array[j] DO

    element.name := 'name';

    element.zahl := 1234;

    END;

    - explizite Operatoren für Bitoperationen wie in C: <<, >>, >>>, &, | und ^.

    - zusätzlicher Operator XOR für boolsches Exklusiv-Oder.

    - keine Zuweisung des Rückgabewertes einer Funktion auf den Namen der Funktion. Stattdessen Rückgabe des Funktionswertes über RETURN.

    - BREAK und CONTINUE, um Schleifen abzubrechen oder vorzeitig fortzuführen.

    - zusätzliche LOOP-Schleife für bedingungslose Schleifen, die mit BREAK oder RETURN abgebrochen werden.

    - vollständige Bezeichner (= sprechende Namen) für Labels bei GOTO-Sprüngen anstelle von Zahlen.

    - Einfache Erzeugung von neuen Namensräumen mittels LIBRARY ... END.

    - Ebenso einfache Deklaration von public-Elementen einer LIBRARY mittels *, z. B. "PROCEDURE aussen*;"

    - Prozedur-/Funktionsdatentypen

    ...


    Das oben genannte halte ich für das Mindestniveau, das eine Lernsprache aufbringen muß, und besonders dann, wenn man sie auch produktiv zum Schreiben von Spielen einsetzen will. "Retro" mag ja bedeuten, daß man sich in der Hardware beschränkt, aber es bezieht sich definitiv nicht auf die Sprache. Schließlich haben genug Leute auch damals[tm] schon auf 8 Bittern komfortabel programmiert. Dahinter zurückzufallen macht für mich persönlich keinen Sinn.

  • Von einer programmierfreundlichen Sprache erwarte ich, daß sie zumindest die Möglichkeit anbietet, eigene Datentypen und Structs (bzw. RECORDs) zu gestalten. Das scheint mir bei QBasic nicht der Fall zu sein.

    Doch, das geht. Hier ein Auszug aus der Online-Hilfe:



    Und "strukturiertes" Basic ohne Zeilennummern – ist das überhaupt noch "Basic" (wie es ein Alt-C64-User erwarten würde)?

    Die Programme mit Zeilennummern bleiben ja weiterhin gültig, weil Sprungziele auch Zahlen sein können.


    Mein Punkt ist: Falls der Unterschied zwischen modernem BASIC und Pascal nur kosmetischer Natur ist, dann wäre es vielleicht der Überlegung wert, der vertrauteren Syntax den Vorzug zu geben.

  • Ich habe mal den aktuellen Hardware-Teil (Arduino MKR Vidor 4000 bzw. Arduino allgemein – und im Speziellen die Video-Ausgabe auf HDMI) in einen eigenen Thread ausgelagert. Ich denke, das fördert die Übersichtlichkeit.


    Hier geht's lang: Arduino (FPGA/ARM) als Basis für einen Retro-Computer

  • Doch, das geht. Hier ein Auszug aus der Online-Hilfe:

    Danke für den Hinweis. Was mich hier aber irritiert: "Normale" Variablen erhalten ihren Datentypen durch Anhängen eines besonderen Zeichens wie % oder $, wohingegen in dem Beispiel die Stringvariable 'Farbe' als solche deklariert und fortan ohne $ angesprochen wird. Unschön auch, daß man anschließend diese Verbundstruktur als Array erzeugen muß. Wie soll man dann z. B. eine einzige Variable (also 1 Element des Arrays) als Parameter an eine Unterroutine übergeben?

    Man kann sich des Eindrucks nicht verwehren, daß die Syntax zur Deklaration einer Verbundstruktur bei Pascal abgeguckt worden ist, inklusive dem '.' zwischen Variablennamen und Element. Das ergibt automatisch die Frage, warum man auf eine inkonsistente Kopie zurückgreifen soll, wenn man doch das Original haben kann?

    Die Programme mit Zeilennummern bleiben ja weiterhin gültig, weil Sprungziele auch Zahlen sein können.

    Was gleich zwei Dinge zunichte macht:

    1.) Kein Single-Pass-Compiler. Kompilation wird aufwendiger und langsamer. Schlecht, wenn der Compiler auf dem Retrorechner selbst laufen und dabei möglichst wenig Speicher verbrauchen soll.

    2.) Keine Stackframes möglich, da Programme direkt in eine Unterroutine hinein- und wieder herausspringen können. Das bedeutet z. B. daß Rekursion nicht möglich ist, aber auch, daß es zu Überschreibungen von lokalen Variablen kommen kann, sofern diese den gleichen Speicherplatz belegen. (Was eigentlich bei lokalen Variablen der Fall sein sollte, denn ansonsten kann man sie ja gleich global definieren.)


    Falls der Unterschied zwischen modernem BASIC und Pascal nur kosmetischer Natur ist, dann wäre es vielleicht der Überlegung wert, der vertrauteren Syntax den Vorzug zu geben.

    Wenn sich die Formulierung "vertrauterern Syntax" auf QBasic beziehen soll, lautet die Antwort: "Öhm... Pascal dürfte definitiv die vertrautere Syntax sein." Nicht umsonst werden bis heute Beispiele für Algorithmen in einer Pseudosprache beschrieben, die aussieht wie Pascal und nicht (Q)Basic. Und nein, die Unterschiede sind eben nicht nur kosmetischer Natur. Ich habe oben schon eine Menge an Sprachfeatures beschrieben, die ich so in (Q)Basic nicht wiederfinde. Eine Pascal ähnliche Programmiersprache bietet viel mehr, und das auf eine sehr elegante und konsistente Art und Weise.


    Bezüglich der Syntax von QBasic hätte ich mal eine Frage: Ich habe mir ein paar Seiten im Internet angesehen, auf denen die Sprache einigermaßen beschrieben wurde, fand aber bisher komischerweise nirgendwo einen Hinweis darauf, wie man eine einfache Konstante z. B. zur Festlegung der Größe eines Arrays definiert. Könntest Du vielleicht ein Beispiel geben?


    Allgemein muß ich sagen, daß mich das Beispiel von QBasic nicht überzeugt. Es handelt sich um einen von vielen Basic-Dialekten, bei denen versucht wurde, die aus anderen Hochsprachen (wie Pascal) bekannten Konstrukte in Basic zu integrieren. Bei QBasic hat sich man dann entschlossen "END IF" zu schreiben anstelle von "ENDIF" oder "FI" und "ENDW" anstelle von "ENDWHILE" oder sonst irgendwas. Ein Programmierer, der nicht mit diesem besonderen Basic-Dialekt vertraut ist, müßte also zunächst diesen Unterschied zu anderen Sprachen aber auch zu anderen Basic-Dialekten lernen. Da halte ich meinen Vorschlag eines "END" für alle (IF, CASE, WHILE, LOOP, FOR, WITH) außer REPEAT (weil REPEAT ... UNTIL) für einfacher und sauberer.


    Im Grunde genommen fällt QBasic wie viele andere Dialekte sowieso raus, weil es sich einfach nicht gut kompilieren läßt. Gründe wurden mehrfach genannt. Wenn man aber möchte, daß ein Programm in Basic auf dem Retrorechner schnell ablaufen kann, hat man gar keine andere Wahl, als entweder einen Compiler zu nehmen oder einen irrsinnig schnellen Prozessor, den man aber mit dem Begriff "retro" nicht wirklich in Verbindung bringen kann. Nun ist beides aber offensichtlich keine gute Lösung. Warum also auf Basic beharren?

    Hinzukommt, daß die Basic-Dialekte im Vergleich zu anderen Lernsprachen der damaligen Zeit nicht wirklich mächtig sind. Daher stellt sich weiterhin die Frage: Wozu Basic? Nur weil man damals[tm] auf dem ersten Homecomputer als Kind eine Sprache verwendete, die "Basic" hieß? Ich denke nicht, daß dies ein guter Grund sein sollte, Basic zu bevorzugen, sondern halte es für besser, nach echten, praktischen Kriterien auszuwählen.


    Aber wir können gerne die Probe aufs Exempel machen:

    Wer mag, kann bitte ein (nicht zu langes, aber auch nicht zu kurzes) Programmbeispiel in einem Homecomputer-Basic-Dialekt vorbringen, das ich dann in eine andere Oberon ähnliche Sprache umschreibe. Danach können wir genau schauen, wo die Unterschiede sind und wo die jeweiligen Stärken und Schwächen der Sprachen liegen. Ich gehe allerdings jetzt schon davon aus, daß sich niemand die Mühe machen wird, diesem ernstgemeinten Aufruf zu folgen.

  • Vorab: Bin kein großer (Q)Basic-Crack. War halt wie bei den meisten wohl meine erste Sprache. Vieleicht mag sich auch BastetFurry hier einschalten.


    wie man eine einfache Konstante z. B. zur Festlegung der Größe eines Arrays definiert. Könntest Du vielleicht ein Beispiel geben?

    Es gibt die CONST-Anweisung:



    Habe mal als Anhang die grob in HTML konvertierte QBasic Online-Hilfe eingebunden. (Stammt noch aus der Zeit vor HTML5 und UTF-8.)

  • Und natürlich gehen auch User Defined Types, hierbei müssen Strings allerdings eine feste Größe zugewiesen werden. FreeBASIC und, soweit ich informiert bin, QB64 heben dieses Limit auf. Allerdings hat nur noch FreeBASIC (32-Bittigen-)DOS Support wenn das wichtig ist.


    qb_003.png

  • Dank an ogd und BastetFurry für die Erklärungen.

    Es scheint, daß die Deklaration von Konstanten ebenfalls von Pascal abgeguckt worden ist. :/ So kommen wir wohl nicht weiter. Um die Frage nach einer Programmiersprache auf einem Retro-Computer mal ausführlicher diskutieren zu können, daher hier noch einmal:


    Aufruf an Alle, die auf einem neuen Retro-Computer programmieren wollen



    Bitte postet hier ein kleines Programm oder auch nur einen Programmauschnitt in einer Sprache wie Basic oder auch in Pseudocode, damit wir mal konkret schauen können

    a) was auf einem Retrorechner programmiert werden soll,

    b) welcher Stil sich dafür am besten eignet.


    Es gibt bereits viele Wünsche und Vorschläge wie "Die Sprache soll schnell genug sein, um darin Actionspiele schreiben zu können" oder "Man muß mit der Sprache Grafiken erstellen können", doch weder das eine, noch das andere sind tatsächlich sprachspezifisch. In jedem Basic oder Pascal oder C lassen sich natürlich Grafikroutinen ergänzen. Sie gehören ja nicht zu den fest eingebauten Schlüsselwörtern wie "FOR" oder "IF". Geschwindigkeit wiederum hängt davon ab, ob der Quelltext interpretiert wird oder kompiliert wurde und wie schnell der Prozessor ist. Die Kernfrage ist jedoch: Wie sieht das Programm an sich aus? Daher wäre es nett, wenn hier einige ein paar Beispiele geben könnten. Danke im Voraus.