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

last post from Hoogo at the

Neuer Retro-Computer im 8-Bit Style

  • Von daher sollte man auch die Erwartungen an einen Compiler nicht zu hoch schrauben, am besten gar nicht hoch, also keine Optimierungen usw. Im Vergleich zu professionellen Compilern heutzutage (oder halt sowas wie gcc oder LLVM) wäre der Compiler ein Witz, aber immer noch besser als gar nichts.


    Macht es dann überhaupt einen Sinn, auch einen nativen Kommandozeilencompiler anzubieten? Ich meine, ein nur in den Editor integrierter Compiler hätte auch den Vorteil, dass während der Eingabe die Syntax überprüft und die Schlüsselwörter tokeniziert werden können, was beim abschliessendem Übersetzungsprozeß auch Zeit sparen hilft.


    ... Da ich oft Strings an Assembler als Zeiger übergebe, hatte ich bisher C-Strings verwendet, obgleich ich oft gelesen habe, daß die Verwendung von \0-terminierten Strings ein Fehler sein soll. Was wäre denn Deine Meinung dazu?


    Gute Frage, bin ja auch eher auf der C-Schiene unterwegs. Was wird an C-Strings kritisiert? Ok, Buffer-Overflows sind wohl eher möglich, wenn das Stringende nicht von Anfang an festgelegt ist.


    Meinetwegen. Wenn Dir das Spaß macht. Ich habe damals[tm] bei meinem Betriebssystem auch zunächst eine Shell eingebaut, weil ich dachte, das bräuchte man. Schließlich machen das doch alle so. Dann muß es doch auch richtig sein. Tatsächlich gebraucht habe ich es nie, weswegen es auch später rausflog.


    Wie hast du dann Dateioperationen zugänglich gemacht? Nur grafisch?

  • Ich glaube nicht, daß Menschen daran scheitern, write statt print schreiben zu müssen.

    Nein, aber es wäre wahrscheinlich ein Marketing-GAU. Und noch weniger sehe ich ein Problem darin, statt write in der Sprache print zu verwenden. Man sollte halt Kompromisse eingehen (zumal es überhaupt nicht relevant ist), wenn man etwas "verkaufen" will. Verkaufen im Sinne von "andere überzeugen, es doch mal zu auszuprobieren". Ich würde also an deiner Stelle gucken, welche Schlüsselbegriff und Konstrukte von Basic (auch mit der Gefahr, dass die Sprache weniger straight wirkt) man retten kann, ohne die Kompilierfähigkeit einzubüßen.


    Das wäre allerdings eine ziemliche Mogelpackung. [...] So oder so dürften die meisten sehr schnell mitkriegen, daß es sich nicht um "ihr" Basic handelt. Dafür sind die Unterschiede von Anfang an zu gravierend, sowohl in der Benutzerführung (echter Editor) als auch in der Syntax.

    Es wird doch immer gesagt, VB hätte mit Basic nichts mehr großartig zu tun. MS war aber schon immer eine Marketing-getriebene Firma und es gab sicherlich nicht-technische Gründe, die Sprache Basic zu nennen. Ich würde es hier halt ähnlich handhaben – natürlich nur, wenn man die Sprache nicht ohne Not von Basic entfernt.


    Wie gesagt, ich glaube, dass die Erwähnung von Pascal in den Specs so einem Rechner bzgl. der Akzeptanz das Genick brechen würde (wenn man ihn als Programmier-Rechner anpreisen wollte) – aber eben in erster Linie in Bezug auf die Bezeichnungen. Wenn man es allerdings nur als Hobby-Projekt ansieht und sich um die Marktfähigkeit eines möglichen Endprodukts nicht scheren muss/möchte, dann ist es natürlich vollkommen ok (bis egal), welche Sprache auf der Kiste läuft. Man muss halt wissen, ob man so was für sich selbst (wie das ja viele FOSS-Programmierer von sich behaupten) entwickelt oder ob man sich über viele Interessenten an dem Endprodukt freut.


    Mir ist es lieber, wenn bei dem System Pascal dabei ist als wenn es gar kein System gibt. Das habe ich wohl klar gesagt. Also mach mal, wie du meinst. Aber ich habe weiterhin die Befürchtung, dass die Nennung der Sprache (wenn sie nicht Basic heißt) für die Verbreitung nicht gerade förderlich ist. Aber vielleicht hilft ja als Kompromiss-Vorschlag ein neuer Name für die neue Sprache. BASALT, BASILISK, BASIS, BRASIL, BANANA ...? ;)

  • Kann man ja dann PasBASIC nennen.

    Alles, was zum Zeitpunkt unserer Geburt bereits vorhanden war, wird als Bestandteil der natürlichen Ordnung empfunden.
    Alles, was in der Zeit zwischen dem 15. und 35. Lebensjahr erfunden wurde, ist aufregend, revolutionär und fördert vielleicht sogar die eigene Karriere.
    Alles, was nach unserem 35. Geburtstag erfunden wurde, verstößt gegen die natürliche Ordnung der Welt und wird abgelehnt.
    - Douglas Admas -

  • Macht es dann überhaupt einen Sinn, auch einen nativen Kommandozeilencompiler anzubieten? Ich meine, ein nur in den Editor integrierter Compiler hätte auch den Vorteil, dass während der Eingabe die Syntax überprüft und die Schlüsselwörter tokeniziert werden können, was beim abschliessendem Übersetzungsprozeß auch Zeit sparen hilft.

    Damals[tm] hatte ich in meine Assembler (6502 und 68000) eine Tokenisierung während der Eingabe vorgenommen, weil es tatsächlich hilft, Speicherplatz und Übersetzungszeit einzusparen. Bei Hochsprachen verhält es sich etwas anders. Die Schlüsselwörter sind in der Anzahl gering, und selbstdefinierte Bezeichner in der Überzahl. Zudem ergeben sich dadurch, daß moderne Hochsprachen nicht zeilenorientiert sind, automatisch Probleme bei einem Test auf syntaktische Korrektheit.
    Beispiel:

    Für eine Syntaxüberprüfung fehlt es an Kontext. Es sei denn, man verlangt, daß immer gleich die gesamte Prozedur/Funktion, in der sich die Zeile befindet, auf Korrektheit überprüft werden soll. Aber was ist, wenn der Schreiber absichtlich zunächst eine unvollständige Zeile schreibt, die er nachher ergänzen will? Soll dann der Editor jedes Mal meckern?
    Realistisch bleibt also nur die Tokenisierung von Schlüsselwörtern, doch real bringt die bei einem Ein-Pass-Compiler nicht viel. Anders sieht es aus, wenn man auf dem Text direkt einen Interpreter aufbauen würde, doch auch hier würde ich eher dazu raten, vor der Ausführung den gesamten Text in einen Tokencode zu überführen, wobei - wie schon weiter oben beschrieben - gleichzeitig weitere Maßnahmen durchgeführt werden wie z. B. Zahlen übersetzen, Schlüsselzeichen wie ":=" oder "(" umwandeln, Bezeichner zählen usw..

    Ok, Buffer-Overflows sind wohl eher möglich, wenn das Stringende nicht von Anfang an festgelegt ist.

    Definiert man für Strings eine feste Länge und sorgt dafür, daß die Stringkopieraktionen nie mehr Zeichen als durch die Länge bestimmt kopieren, ist auch das kein Problem. Der Fehler bei C ist die stdlib, die bei strcpy keine maximale Länge als Parameter vorsieht (vermutlich aus damaligen 70er-Jahre Gründen der Effizienz).
    Vorteil der Pascal-Strings sind das schnellere Testen auf Länge bei Stringadditionen als auch Test auf Gleichheit. (Strings ungleicher Länge sind halt nie gleich. Da kann man sich den Rest sparen.)

    Wie hast du dann Dateioperationen zugänglich gemacht? Nur grafisch?

    Die einfachste Möglichkeit ist, ein Auswahlmenü anzubieten wie z. B. beim Filer des UCSD-Systems. Möchte man eine Datei löschen, tippt man "r"(emove) oder "d"(elete). Dann wird man gefragt, welche Datei man löschen möchte. Man tippt den Namen ein, bestätigt sicherheitshalber noch einmal mit "y", und die Datei ist weg.
    Dieses Verfahren kann man jetzt in ein Popupfenster packen (Textschirm oder Grafik ist egal), wenn man möchte. Man kann auch anstelle den Namen einzutippen, die Datei in einem Dateirequester heraussuchen lassen... Es gibt viele Möglichkeiten. Der Aufwand ist für den Benutzer nicht höher als bei einer Kommandozeile, kann je nach Geschmack dafür aber komfortabler sein.

    Ich würde also an deiner Stelle gucken, welche Schlüsselbegriff und Konstrukte von Basic (auch mit der Gefahr, dass die Sprache weniger straight wirkt) man retten kann, ohne die gute Kompilierfähigkeit einzubüßen.

    Außer "print" ist da nichts. Wie gesagt, Basic hat kaum Schlüsselbegriffe, und "print" oder "write" oder ... sind nicht Teil der Sprache. In der Sprache selbst gibt es nur sehr wenige fest eingebaute Funktionen zur Datentypen-Konvertierung und für mathematische Operationen. Alles andere sind sekundäre Definitionen, außerhalb der Sprachdefinition. Wer gerne print, mid, left, right... haben möchte, kann das gerne tun. Üblicherweise definiert man Systemroutinen und solche Operationen in einer gesonderten Datei, die dann per include eingebunden wird, also:

    Code
    1. PROGRAM hallo;
    2. @include 'basicstil'
    3. BEGIN
    4. print('Hallo')
    5. END hallo.

    Erwähnung von Pascal in den Specs

    Was ich hier beschreibe, ist kein Pascal, genausowenig wie LUA Pascal ist oder Comal Pascal ist. Da gibt es zig Unterschiede, von denen ich einige aufgelistet habe. Jeder, der versuchen würde, Pascalcode zu kompilieren, würde mit Fehlermeldungen überhäuft. Bereits die offizielle Definition von Oberon von Wirth persönlich, hat mit dem damaligen[tm] Pascal nicht mehr viel gemein, und mein Vorschlag entfernt sich nochmals weiter von Oberon.

    neuer Name für die neue Sprache

    Namensgebungen sind schwierig. Man könnte sich an realen Personen der Informatik orientieren und die Sprache ihnen zu Ehren z. B. "zuse" nennen, auch wenn dann vielleicht einige an Plankalkül denken. Oder "chomsky", aber der lebt noch. Und Wirth, Knuth oder der bereits verstorbene Dijkstra dürften keinen Gefallen daran finden, da ihnen die Sprachdefinition nicht sauber genug erscheint. Ist gar nicht so einfach, was Passendes zu finden. Falls jemand einen ernstgemeinten Vorschlag hat, kann er den ja nennen. (Nein, :choplifter: ist kein ernstgemeinter Vorschlag.)


    Ansonsten können wir auch gerne mal auf die Hardware zurückkommen. Ich habe nämlich keine Lust, hier den Thread mit Überlegungen über eine Hochsprache zu kapern.

  • @M.j.T
    Sage mal, wie lange würdest du die Entwicklungszeit schätzen, wenn hier Hardware und Software als Hobby so in der Freizeit entwickelt werden müsste? Also jetzt nicht an Typen wie mich gemessen, der von allem so ein bisschen was weiß, aber nirgends wirklich fest im Sattel sitzt, sondern eher Entwickler deiner Sorte, also die wirklich auch schon Erfahrung in diesem Bereich haben.

    Alles, was zum Zeitpunkt unserer Geburt bereits vorhanden war, wird als Bestandteil der natürlichen Ordnung empfunden.
    Alles, was in der Zeit zwischen dem 15. und 35. Lebensjahr erfunden wurde, ist aufregend, revolutionär und fördert vielleicht sogar die eigene Karriere.
    Alles, was nach unserem 35. Geburtstag erfunden wurde, verstößt gegen die natürliche Ordnung der Welt und wird abgelehnt.
    - Douglas Admas -

  • @M.j.T
    Das würde mich auch mal interessieren. Ach ja... Und herzlichen Glückwunsch zum Geburtstag.


    @ckoe
    Falls Du mich meinen solltest, kann ich Dir auf die Frage leider keine Antwort geben, denn Entwickler meiner Sorte haben ebenso wenig Ahnung und Erfahrung in diesem Bereich wie Du. Die reden einfach nur zu viel, wenn es am Wochenende draußen regnet. Um abschätzen zu können, wie lange die Entwicklungszeit betragen würde, müßte man richtige Experten fragen, die sich mit sowas auskennen. Wahrscheinlich sind drei Dinge von belang:


    1.) Wie aufwendig soll die Hardware sein?
    Ein kleines System könnte, wie bereits erwähnt, zusammengebaut sein aus
    a) FPGA, b) Shield mit 512kb Speicher und Anschlüssen für VGA, PS/2, SD-Karte und anderes. Der FPGA übernimmt dabei die Rolle der CPU und der Videoausgabe sowie ein paar anderer Dinge.
    Sowas können Leute mit Eletronikkenntnissen hinkriegen (ich nicht). Auf Basis eines solchen Systems kann man dann anfangen, erste Systemroutinen und weitere Bibliotheken zu entwickeln, z. B. um überhaupt auf SD-Karten zugreifen zu können. Oder Grafikroutinen. Oder einen Monitor und Assembler... Irgendwo muß man halt anfangen. Möchte man einen Videocontroller mit allerlei grafischen Fähigkeiten (viele Sprites usw.), ist der Aufwand gleich zu Beginn viel größer. Dann braucht man einen entsprechend großen FPGA, d. h. man müßte schauen, ob man ein fertiges Board findet mit ausreichend Speicher darauf und den gewünschten Anschlüssen. (Ist aber etwas teurer.) Hier würde sich z. B. der MiSTer als Grundlage anbieten. Damit kann man dann sofort loslegen und die CPU etc darauf programmieren. Meiner Erfahrung nach sollte man aber besser erst einmal klein anfangen und sich die Grundlagen aneignen. Das geht mit einem überschaubaren System besser. So oder so ist es letztendlich eine Frage von Zeit und Willen. Wie lange dauert es, bis man das FPGA so programmiert hat, daß man ein einigermaßen funktionierendes System vor sich hat? Hängt wohl von der Freizeit ab. Vielleicht ein halbes Jahr.


    2.) Wie aufwendig soll die Software sein?
    Je höher die Ansprüche an die Software, umso länger dauert es, bis was sichtbar wird. Beschränkt man das System auf das Notwendigste und sorgt erst einmal dafür, daß dies funktioniert, hat man zumindest eine solide Ausgangsbasis, die man später sukzessive erweitern kann. Betrachtet man die Geschichte der Homecomputer, sieht man ja, daß die alle klein angefangen haben. Der AppleII bootete ganz am Anfang nicht ins Basic, sondern direkt in den Monitor, um damit Programme austesten zu können. Sowas würde ich als ersten Schritt ebenfalls vorschlagen, also: simpler Monitor zum Anzeigen der Speicherinhalte. Das ist relativ leicht geschrieben, und ein (einfacher) Assembler auf dem PC für die Programmentwicklung stellt auch kein Problem dar.
    Das erste Ziel ist es, ein Gefühl zu kriegen für den Rechner. Dazu schreibt man ein paar kleine Testprogramme. Einfach um zu schauen, was wie darauf geht. Dazu braucht man keine opulente Grafik. Textmodus oder simple Bitmap reichen aus. (Wie gesagt, alle anderen Feature können später immer noch kommen.) Mit der Zeit hat man dann eine kleine Bibliothek angelegt, die man als Grundsystem von SD-Karte booten kann. Die Bibliotheken kann man dann ausbauen, während man ein paar größere Programme schreibt.
    Im Grunde genommen ist dieser Prozeß der Bibliothekenentwicklung unendlich lang, weil nie zuende. Irgendwo wird es immer was geben, was man verbessern oder anders machen kann. Daher sollten sich alle Programme darauf einrichten, statisch gelinkt zu werden, weil damit zu rechnen ist, daß das System sich ändern wird. In der Regel stellt dies für Spiele jedoch kein Problem dar, da diese ohnehin kaum auf "ROM"-Routinen zugreifen. Da reicht es aus, wenn man ähnlich dem BIOS von CP/M ein paar IO-Basisroutinen zur Verfügung stellt (z. B. Tastatur lesen).
    Eigentlich ist gerade das Spannendste an der Entwicklung eines Rechners der Wachstumsprozeß der Software um das System herum, so wie man es früher beim AppleII oder C64 gesehen hat. Zu Beginn schreibt man einfache Spielchen, aber mit der Zeit wird es in alle Richtungen immer besser, und man fängt an, die Kiste auszureizen. Was hier jedoch oft verlangt wird, ist ein Sprung über die ersten Anfänge hinweg: Fertig entwickelte Software wie Sprite-/Grafikeditor usw. Bis sowas vorhanden ist, kann es natürlich lange dauern. Es braucht ja jemanden, der diese Programme schreibt. Damit aber ein Programmierer sich hinsetzt und in seiner Freizeit solche Programme entwickelt, müssen zwei Dinge gegeben sein:
    a) Es muß ein realer Bedarf bestehen.
    b) Die Entwicklung von Tools muß so leicht und schnell wie möglich sein. App-Programmierung kann ganz schön langweilig sein. Und auch in 68000-Assembler (oder vergleichbares) macht es nicht unbedingt Spaß. Daher die Idee einer brauchbaren Hochsprache.


    3.) Wie aufwendig soll die Hochsprache sein?
    Unter Aufwand verstehe ich hier die Qualität der Übersetzung und die Ausführungsgeschwindigkeit. Einen nichtoptimierenden Compiler zu schreiben, ist jetzt nicht so schwer. Dann ist allerdings die Ausführungsgeschwindigkeit nicht so gut, und der Code ist länger. Zumindest übergangsweise könnte man auch einen bestehenden Compiler nehmen, der nach Bytecode kompiliert, der dann auf der Zielmaschine interpretiert wird. Ist langsam, aber funktioniert. Man muß halt bereit sein, Abstriche zu machen in den Wünschen und Anforderungen.
    Wie auch bei der Software gilt, daß man mit der Hochsprache schon anfangen kann, während die Hardware sich noch in der Entwicklung befindet, z. B. indem man einen Emulator verwendet.


    Und was heißt das jetzt...?
    Im Grunde genommen muß jeder für sich selber entscheiden, ab wann er ein System für so akeptabel hält, daß er es benutzen möchte, sei es zur Eigenentwicklung oder zur Anwendung (Spiele). Es wurde schon von vielen Seiten der äußerst sinnvolle Vorschlag gemacht, einen Emulator für den PC zu schreiben. Da hat man zwei Möglichkeiten:
    1.) Man verwendet einen bereits bestehenden und paßt ihn an, so wie es Profis wie alx machen.
    2.) Man schreibt sich selber einen simplen Emulator ohne jeglichen Komfort, aber er läuft halt irgendwie.
    Dafür braucht man vielleicht einen Monat.


    Mit anderen Worten: Die Antwort auf Deine Frage "wie lange würdest du die Entwicklungszeit schätzen" könnte man beantworten mit "solange es braucht, einen Emulator zu schreiben". Wir könnten also jetzt sagen: Okay, einigen wir uns auf ein/zwei einfache Systeme (einmal 8 Bit für echtes 8 Bit-Feeling, einmal 32 Bit für Warmduscher), schreiben einen Emulator dafür und können dann in einem Monat loslegen. Die Hardware folgt dann etwas langsamer nach, und dann schaut man, welche Ergänzungen möglich sind.


    Es ist eine Frage von Zeit und Wollen, und auch mit wie wenig man sich zumindest zu Beginn zufriedenstellen läßt. Erwartet man gleich zu Anfang das perfekte System mit allen möglichen Tools, kann man halt lange warten.


    Nebenbei: Der Prozessor, den alx vorgeschlagen hat, schreit förmlich danach, mit kompilierten Programme einer Hochsprache gefüttert zu werden. Man sollte einen wichtigen Aspekt bei Hochsprachen nicht unterschätzen: Egal, wie oft sich der Unterbau, d. h. die ISA des Prozessors noch ändert, wird das in einer Hochsprache geschriebene Programm neu kompiliert weiterhin laufen. Denn auch damit sollte man rechnen: Am Anfang ist noch vieles im Fluß. Das sieht man ja auch an der Diskussion hier im Forum.

  • Ich werfe mal einfach mal ein paar Gedanken in den Raum... evtl. kann damit ja jemand was damit anfangen.


    Ich hab mit BASIC 2.0 angefangen. Auf Papier. D.h. bevor ich meinen C64 bekommen hab, hatte ich damals erste Programme mit Bleistift auf Karo-Papier geschrieben. Das war so Ende der 80er... Heute würde ich, wenn ich die Zeit hätte, mich am "BASIC 10-Liner Contest" versuchen. Also BASIC hat schon so seinen Reiz. Und auch Zeilenorientiert ist nicht ganz falsch.


    Zu 99% arbeite ich aber mit einer IDE. Das ist eine grafische Oberfläche am C64 (GEOS), ein Texteditor (GeoWrite) und ein Compiler/Assembler (MegaAss). Was dabei rauskommt sind keine Demos oder Spiele...


    Also IDE finde ich nicht falsch... BASIC aber auch nicht, und zeilenorientiert schon gar nicht. Ist halt etwas mehr Retro. Ich hab noch immer eigene BASIC-Tools mit denen ich die CMD-RAMlink in 0-komme-nix automatisiert vorkonfigurieren kann. Code von vor über 20 Jahren...


    Gibt es denn keinen Weg die Software von der Hardware zu trennen? In der Art von "Cores" die man laden kann? Core #0 = Default = Basic, Core #1 = Python o.ä. ? Per F-Taste oder Sys/Poke/GO-IDE dann wechseln?

  • Gibt es denn keinen Weg die Software von der Hardware zu trennen? In der Art von "Cores" die man laden kann? Core #0 = Default = Basic, Core #1 = Python o.ä. ? Per F-Taste oder Sys/Poke/GO-IDE dann wechseln?

    Doch, genau das soll möglich sein: Die Software ist von der Hardware getrennt. Da es kein fest eingebautes ROM gibt, sondern das Basissystem von SD-Karte gebootet wird, kann man sich jede Sprache auf die Karte packen, die man möchte. Das schließt zeilenorientiertes Basic natürlich mit ein. Es ist jedem völlig unbenommen, ein solches Basic zu entwickeln und/oder anzuwenden. Man muß sich nur im Klaren darüber sein, daß der Abstand zwischen Programmen in Basic und denen in anderen Sprachen in puncto Leistungsfähigkeit sehr groß sein wird.

  • Doch, genau das soll möglich sein: Die Software ist von der Hardware getrennt.

    Dann frage ich mich warum man sich hier seit geraumer Zeit im Kreise dreht...
    Warum versucht man nicht eine Hardware zu definieren die leistungsfähig genug ist. Der Rest (IDE) kommt dann später.


    Mir persönlich ist die Leistung unter BASIC sch.... egal. Ich kann mich noch an die Dateneingabe auf Bandlaufwerken erinnern... ich meine die alten großen runden. Ob da ein Programm etwas langsamer ist... Es gibt auch Programme die nicht CPU/Compiler-performant sind.


    Also braucht es erstmal ein System das BASIC kann... und mittels Befehl eine IDE laden kann. Wenn der Speicher groß genug ist sollte man doch sogar ein Programm compilieren und starten können...


    Unter GEOS128 hab ich gerade erst bemerkt das ich ein BASIC-Programm starten kann und wenn das Programm einen Soft-Reset ausführt lande ich wieder in der grafischen Oberfläche. Sofern das RAM der anderen Bank nicht beschädigt wurde.


    Warum also nicht ein System mit BASIC, IDE starten, "HELLO WORLD" programmieren, starten, nach Programm-Ende zurück in der IDE.

  • Doch, genau das soll möglich sein: Die Software ist von der Hardware getrennt. Da es kein fest eingebautes ROM gibt, sondern das Basissystem von SD-Karte gebootet wird, kann man sich jede Sprache auf die Karte packen, die man möchte. Das schließt zeilenorientiertes Basic natürlich mit ein. Es ist jedem völlig unbenommen, ein solches Basic zu entwickeln und/oder anzuwenden. Man muß sich nur im Klaren darüber sein, daß der Abstand zwischen Programmen in Basic und denen in anderen Sprachen in puncto Leistungsfähigkeit sehr groß sein wird.

    Wenn nur die Hardware fest ist und die Software beliebig austauschbar ist, dann ist der Rechner doch nicht groß anders als z.B. ein Raspi, auf den man auch installieren kann, was man will. Da fehlt meiner Ansicht nach die "gemeinsame Komponente", wenn quasi jeder sein "eigenes" System auf die SD-Karte installiert.


    Wenn sowas das Ziel sein soll, dann verstehe ich die Diskussion über DIE zu verwendende Programmiersprache sowieso nicht. Dann muss man dafür ja keinen gemeinsamen Konsens finden, wenn das "ROM" eh beliebig austauschbar sein soll. Nur wird dann in meinen Augen auch der Rechner irgend "beliebig".

  • Warum versucht man nicht eine Hardware zu definieren die leistungsfähig genug ist

    Genau das ist doch schon passiert, und zufälligerweise hatte ich gerade erst ein paar Zeilen höher solch eine Hardware erneut vorgeschlagen.

    Warum also nicht ein System mit BASIC, IDE starten, "HELLO WORLD" programmieren, starten, nach Programm-Ende zurück in der IDE.

    Weil solch ein System nicht vom Himmel fällt. Siehst Du hier jemanden, der vortritt und sagt: "Okay, Leute, ich schreib jetzt den Basic-Interpreter"? Ich sehe niemanden. Ergo: Wenn Du ein interpretiertes Basic mit IDE haben willst, mußt Du es DIr selber schreiben. Ganz einfach.

    Wenn nur die Hardware fest ist und die Software beliebig austauschbar ist, dann ist der Rechner doch nicht groß anders als z.B. ein Raspi
    [..]
    Wenn sowas das Ziel sein soll, dann verstehe ich die Diskussion über DIE zu verwendende Programmiersprache sowieso nicht. Dann muss man dafür ja keinen gemeinsamen Konsens finden, wenn das "ROM" eh beliebig austauschbar sein soll. Nur wird dann in meinen Augen auch der Rechner irgend "beliebig".

    Dann hätte ich mal eine Frage an Dich:
    Was schätzt Du, wie häufig Spiele auf dem C64, AppleII oder Amiga nach dem Booten auf das Rom zugreifen? Nimm mal "Dragon Wars". Wie oft benutzt das Spiel das C64-Rom? Oder nimm mal "Drol" auf dem AppleII oder "Bandits". Wie oft? Oder "Elite" auf dem Amiga. Oder "Paradroid90" oder "Carrier Command". Wie oft?


    Hier die Auflösung: Kein Mal. Deiner Definition nach müßten folglich all diese Rechner "beliebig" sein, weil die Software das Rom links liegen gelassen hat. Die "gemeinsame Komponente" war eben noch nie das ROM, sondern der Hardwareaufbau.

  • Wenn sowas das Ziel sein soll, dann verstehe ich die Diskussion über DIE zu verwendende Programmiersprache sowieso nicht. Dann muss man dafür ja keinen gemeinsamen Konsens finden, wenn das "ROM" eh beliebig austauschbar sein soll. Nur wird dann in meinen Augen auch der Rechner irgend "beliebig".

    Und da bin ich ganz bei Dir... Diskussion über die IDE... Eine Hardrware designen und dann ist die Herausforderung daraus das beste herauszuholen. Als man den C64 entwickelt hat war ja nicht im Traum daran zu denken was man damit heute machen kann... Aber man kann eben via SYS/Poke/GO Alternativen starten...


    Ein RasPi kann die Grundlage sein... wenn alle Anforderungen der IDE-Entwickler gegeben sind (Zugriff auf Datenleitungen, Genügend Speicher, Grafik-Schnittstellen usw...)


    Daher denke ich ist es der richtige Ansatz mal eine Hardware festzulegen und die IDE-Entwickler sagen ob das reichen könnte...

  • Weil solch ein System nicht vom Himmel fällt. Siehst Du hier jemanden, der vortritt und sagt: "Okay, Leute, ich schreib jetzt den Basic-Interpreter"? Ich sehe niemanden. Ergo: Wenn Du ein interpretiertes Basic mit IDE haben willst, mußt Du es DIr selber schreiben. Ganz einfach.

    Ist ja in Ordnung... Aber dann muss man halt mal sagen das die Hardrware da ist... wenn es keinen Entwickler für die IDE gibt... Pech... aber deshalb das ganze Projekt auszubremsen wenn es Entwickler für eine andere IDE gäbe?
    Also Hardware festlegen für die es mind. 1 Entwickler für eine IDE gibt, egal ob BASIC oder was auch immer. Anderes lässt sich immer entwickeln.

  • @darkvision
    Sorry, ich kann Dr nicht folgen. Hardware wurde definiert. Vorhin noch habe ich geschrieben, daß man einen Anfangsemulator dafür in einem Monat schreiben kann. Dabei verlangt ein Basic-Interpreter wie der vom C64/AppleII gar keine umfangreiche Hardware. Der ist von der Hardware ziemlich abstrahiert. Der braucht lediglich zwei Routinen für eine definierte Zeicheneingabe und -ausgabe. Mehr nicht. Und für die Entwicklung eines Interpreters braucht man nicht einmal reale Hardware, ja nicht mal einen Emulator. Es würde ja schon genügen, wenn man zuerst die Algorithmen dafür in einer Hochsprache wie C auf dem PC austestet.
    ABER:
    Es gibt keinen Entwickler. Punkt.


    Was mir leider immer wieder auffällt, ist, daß an der Bereitschaft zur Entwicklung von XYZ irgendwelche Bedingungen geknüpft werden: Zuerst muß die Hardware da sein. So und so. Und dann auch noch eine IDE. Und einen Editor will ich auch haben. Auch für Sprites und Graphik und Sound. Und wenn all diese Bedingungen erfüllt sind, dann erhebe ich mich vielleicht vom Sofa und mache was. Ich komme mir dabei vor wie Judith in "Das Leben des Brian", die zu der Möchte-Gern-Volksfront sagt: "Es ist ganz einfach: Alles, was ihr tun müßt, ist aufzustehen und durch diese Tür zu gehen.", und die Reaktion daraufhin besteht nur aus weiterem Palaver der Schreibtisch-Revolutionäre.


    Niemand bremst hier etwas aus (ich schon gar nicht), aber es ist nun einmal so, daß (bis auf wenige Ausnahmen) auch niemand bereit ist, irgendwas zu tun.


    Sorry, wenn es etwas harsch klingt. Ich denke, es ist besser, wenn ich mich aus der Diskussion hier ein wenig zurückziehe.

  • Daher denke ich ist es der richtige Ansatz mal eine Hardware festzulegen und die IDE-Entwickler sagen ob das reichen könnte...


    Das halte ich hingegen fuer den voellig falschen Ansatz. Einfach mal ne Hardware entwickeln und dann wird schon einer dafuer Software schreiben, diesen Gedanken finde ich sehr blauaeugig. Meiner Meinung nach muss der Rechner genau umgekehrt designt werden, naemlich von der Nutzbarkeit und der Nutzersicht her. Wenn da mal das Konzept klar ist, dann kann man sehen, welche Hardware-Anforderungen man dafuer benoetigt, um diese Vision in ein reales Produkt umzusetzen.


    Nur so als Denkansatz: Ich glaube z.B. nicht, dass bei der Entwicklung des iPhones als erstes festgelegt wurde, welche CPU und wie viel Speicher das Teil haben soll.

  • Nur so als Denkansatz: Ich glaube z.B. nicht, dass bei der Entwicklung des iPhones als erstes festgelegt wurde, welche CPU und wie viel Speicher das Teil haben soll.

    Für das iPhone ist das Wissen darum vermutlich in der Geheimhalterei in Cupertino versickert, für den Macintosh ist die Story allerdings überliefert: Ursprünglich sollte es nur ein 6809 mit 64KB RAM sein. IIRC wird in einer der anderen Stories auf der Seite auch vom Wachstum der System-ROMs berichtet.


    (und ursprünglich war es eine reines Crossdev-Zielsystem mit einem Pascal-Compiler auf der Apple Lisa...)

  • Dann hätte ich mal eine Frage an Dich:Was schätzt Du, wie häufig Spiele auf dem C64, AppleII oder Amiga nach dem Booten auf das Rom zugreifen? Nimm mal "Dragon Wars". Wie oft benutzt das Spiel das C64-Rom? Oder nimm mal "Drol" auf dem AppleII oder "Bandits". Wie oft? Oder "Elite" auf dem Amiga. Oder "Paradroid90" oder "Carrier Command". Wie oft?


    Hier die Auflösung: Kein Mal. Deiner Definition nach müßten folglich all diese Rechner "beliebig" sein, weil die Software das Rom links liegen gelassen hat. Die "gemeinsame Komponente" war eben noch nie das ROM, sondern der Hardwareaufbau.

    Wenn man eine Spielkonsole entwickeln will, wo es um rein passives Spielen geht, dann ist das ROM in der Tat eher unwichtig bis egal.


    So wie ich es bisher verstanden habe, geht es hier darum, dass man auf dem Rechner selbst entwickeln will. Und dafür wird "mühsam" diskutiert, ob man nicht gleich eine neue Programmiersprache entwickeln will.


    Diese Diskussion halte ich für völlig überflüssig, wenn eh nicht geplant ist, ein "festes" ROM mit dieser Sprache beim Rechner zu haben, sondern "nur" die Hardware zur Verfügung stellt und das ROM beliebig austauschbar sein soll. Dann kann ich z.B. als Hardwarebasis auch ein MIST oder MISTer nehmen und den Rechner darauf als Core entwickeln. Dann brauche ich genau NULL neue Hardware. Den Rechner kann man super als Core "basteln".


    Wenn ich an einen "Wunsch"-Retrorechner denke, dann ist das ein Gerät aus "einem Guss", also Hard- und Software als Einheit. So wie eben bei den meisten 8-Bitter. Einschalten und in BASIC losprogarmmieren.


    Wenn andere andere Wünsche haben, ist das ja auch ok. Hier im Thread werden halt die Wünsche mehrerer gesammelt.

  • Das Problem ist halt, viele wollen unbedingt BASIC und 8Bit Beschränkung, aber gleichzeitig soll man mit diesem BASIC auch Spiele programmieren können, die über ein Textadventure oder eine Wirtschaftssimulation hinaus gehen. Beides geht aber nicht.

    Alles, was zum Zeitpunkt unserer Geburt bereits vorhanden war, wird als Bestandteil der natürlichen Ordnung empfunden.
    Alles, was in der Zeit zwischen dem 15. und 35. Lebensjahr erfunden wurde, ist aufregend, revolutionär und fördert vielleicht sogar die eigene Karriere.
    Alles, was nach unserem 35. Geburtstag erfunden wurde, verstößt gegen die natürliche Ordnung der Welt und wird abgelehnt.
    - Douglas Admas -

  • Das Problem ist halt, viele wollen unbedingt BASIC und 8Bit Beschränkung, aber gleichzeitig soll man mit diesem BASIC auch Spiele programmieren können, die über ein Textadventure oder eine Wirtschaftssimulation hinaus gehen. Beides geht aber nicht.

    Das habe ich auch schon geschrieben, dass das wohl unvereinbare Wünsche sind.


    Das einzige was vielleicht klappen könnte, wäre ein guter BASIC-Compiler. Nur wird man dafür wohl wieder eine IDE am PC benötigen, wenn man beim reinen 8bit-Rechner bleiben will.


    Ich persönlich habe überhaupt kein Problem damit, die Entwicklung von größeren Projekten am PC zu machen. Das ist einfach um Dimensionen bequemer als am Rechner selbst. Das kriegt man nicht mal annähernd bequem am Rechner selbst hin, egal wie viel Gehirnschmalz man da noch reinsteckt.


    Für mich steht 8bit für einfachere Sachen mit Basic AM Rechner und größere Projekte dann am PC für den Rechner. Und da muss auch niemand jetzt "krampfhaft" versuchen das zu ändern. Das bedeutet eben "8 bit" für mich.


    Es sind hier wohl einfach mindestens zwei verschiedene Meinungsströmungen, die keinen gemeinsamen Nenner finden werden. Muss ja auch nicht.

  • @Snoopy es geht doch aber auch darum, dass dieser "neue 8-Bit-Rechner" auch irgendwie eine Daseinsberechtigung benoetigt. Wenn man jetzt einfach so einen neuen 8-Bit-Rechner rausbringt, was genau ist denn dann der Grund fuer die Entwickler, etwas dafuer zu entwickeln? Viele werden dann vielleicht sagen, "dann nehme ich doch lieber einen vorhandenen Rechner, den bereits zig Leute besitzen". Wenn man schon einen Fantasie-Rechner designt, dann muss der doch auch irgendwas koennen, was andere nicht koennen. Und der Punkt "direkt drauf entwickeln" waere da halt schon sehr reizvoll. Ansonsten wuesste ich jetzt halt keinen Grund, warum man sich den holen sollte. Anderer Projekte wie z.B. MEGA65 und Spectrum NEXT hingegen haben halt den Pluspunkt, dass sie eine vorhandene Rechner-Linie fortfuehren oder einen nie erschienenen Rechner zum Leben erwecken. Aber ein kompletter Fantasie-Rechner hat doch erstmal das Problem, dass er irgendjemanden davon ueberzeugen muss, dass er sich den holen soll, sei es als Entwickler oder Nutzer. Also was waere dann Dein Vorschlag, was dieser Rechner koennen soll, um ihn attraktiv zu machen?