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

last post from Hoogo at the

Neuer Retro-Computer im 8-Bit Style

  • ZeHa Der Titel heisst Retro-Computer im 8-Bit Style.

    Von Lern- bzw. Schulcomputer steht da nix.

    Und was die Programmiersprache angeht: nicht jeder der einen Computer kauft will programmieren lernen.

    Klar, 'ne kleinigkeit mal ausprobieren. Paar Töne, oder ein Bildchen will schon jeder mal machen.

    Aber wenn es 'ernstere' Musikstücke bzw. ernstere Bilder/Zeichnungen werden sollte, dann holt man sich dazu ein passendes Programm.

    Keiner schreibt seine Briefe in BASIC/Python/<andere Sprache>, sondern mit eine Textverarbeitung.

    Das BASIC wirklich nicht das non-plus-ultra ist, ist bekannt, aber fürs schnelle ausprobieren allemal gut genug.

    Wer wirklich Programmieren will steigt eh schnell auf andere Sprache. Sei es Pascal/Modula2/Forth/C und/oder Assembler.

  • Mal ganz ehrlich, wäre ein C65 School Edition 1989/90 gekommen, gegen was wäre der angetreten:

    • Atari 1040 ST(E)
    • Acorn Archimedes 3010/3020
    • Schneider Euro PC (II)
    • C= PC 10-III
    • Macintosh LC

    Ich lass den Amiga mal weg, wäre als Schulrechner eher schwierig zu vermarkten. Bin auch unsicher wegen der Preise, aber C65 haben wir ja auch keine genaue Preisvorstellung.

    Was hätte wohl eure Schule gekauft, und was hättet ihr da gerne für den ITG/Informatik Unterricht gehabt?

    Also meine Präferenz wäre sicher kein C65 Light gewesen.

  • Freddy Okay, dann ignorieren wir einfach mal die letzten 80 Seiten Diskussion :)

    DER MEGA65 IST DOCH EIN NEUER RETRO-COMPUTER! Fall geschlossen! Thread dicht machen! Und ueberhaupt gibts ja auch den C128 und den C64!

  • Mal ganz ehrlich, wäre ein C65 School Edition 1989/90 gekommen, gegen was wäre der angetreten:

    • Atari 1040 ST(E)
    • Acorn Archimedes 3010/3020
    • Schneider Euro PC (II)
    • C= PC 10-III
    • Macintosh LC

    Ich lass den Amiga mal weg, wäre als Schulrechner eher schwierig zu vermarkten. Bin auch unsicher wegen der Preise, aber C65 haben wir ja auch keine genaue Preisvorstellung.

    Was hätte wohl eure Schule gekauft, und was hättet ihr da gerne für den ITG/Informatik Unterricht gehabt?

    Also meine Präferenz wäre sicher kein C65 Light gewesen.

    Auszug aus 'Preliminary Manual' zum C65:

    1.1. System Concept


    The C65 microcomputer is a low-cost, versatile, competitive product

    designed for the international home computer and game market.


    Der C65 war NIEMALS als Lern- bzw. Schoolcomputer gedacht.

    Ziel Anwender war schon immer der Heimanwender und Spieler.

    Nicht mehr und nicht weniger.

  • Freddy Okay, dann ignorieren wir einfach mal die letzten 80 Seiten Diskussion :)

    DER MEGA65 IST DOCH EIN NEUER RETRO-COMPUTER! Fall geschlossen! Thread dicht machen! Und ueberhaupt gibts ja auch den C128 und den C64!

    Ich sehe schon einen Sinn in der Diskussion hier.

    Moderne PCs sind einfach zu komplex.

    Ein Homecomputer braucht diese Komplexität gar nicht.

    Und leider müssen wir auch feststellen daß der Markt schon reichlich gesättigt ist.


    Vielleicht entsteht hier ja sowas wie ein Computer der leicht verständlich ist, leicht zu handhaben und sehr kostengünstig ist.

    Ich denke da z.B. an dem Versuch mit dem 1 Laptop per Child, der nur 100,-$ kosten soll.

    Haben die auch nit geschafft.

  • Naja deshalb haben sich hier im Thread ja mehrere Ansaetze herauskristallisiert, wie ein neuer Retro-Computer sein koennte und welchen Zweck er erfuellen koennte. Der Ansatz, den Retrofan am besten findet (und er ist der Ersteller des Threads), ist, einen modernen Retro-Computer zu designen, der den Leuten beim Einstieg ins Coden helfen soll. Und deshalb geht es jetzt hier hauptsaechlich darum. Andere Ansaetze wurden in andere Threads ausgelagert. Jetzt zu sagen, hier gehts nicht um einen Lern-Rechner, und nicht jeder der einen Computer kauft will coden lernen, ist daher ziemlich verkehrt.

  • Einstieg ins Coden ist aber quasi die Primärfunktion vom Raspberry Pi.

    Vielleicht die angedachte Primaerfunktion, aber mit Sicherheit nicht die de-facto-Primaerfunktion.


    Genauso wie der C64 ja primaer fuer Hausaufgaben und so gedacht war ;)

  • - Der deutlichste Unterschied zu Basic dürfte sein, daß alle Bezeichner inklusive Variablen vor ihrer Verwendung deklariert werden müssen. Das sieht umständlich aus, hat aber fünf Vorteile:

    Die Vorteile sehe ich – allerdings ist es für Anfänger quälend und für Ex-Basic-Nutzer ungewohnt. Könnte der Editor nicht so einen kleinen Helfer-Dämon haben, der bei vergessenen Deklarationen den Nutzer darauf hinweist und auch gleich hinzufügt (der Typ ist ja oft erratbar, bei For-Schleifen z.B. meistens integer)? Wenn man es richtig macht, sieht man das Helferlein nie und wenn man es falsch macht, wird es einem korrekt beigebracht und auch gleich korrigiert.


    - Ein weiterer Unterschied zu Basic ist die Verwendung von ';' anstelle von ':' zur Trennung von mehreren Befehlen. Bei Basic müssen alle Befehle zwingend in einer Zeile abgeschlossen sein, bei Pascal und dessen Derivate nicht.

    Semikolons: Ich verstehe nicht ganz, warum manche Befehle ein Semikolon bekommen und manche nicht. Manche ENDs haben eins, manche nicht. Da waere ich auf jeden Fall fuer Konsistenz, und ich persoenlich halte das Semikolon fuer ueberfluessig.

    Ich finde Semikolons auch eher nervig (werden gerne vergessen und man sucht sich dann einen Wolf und wenn man stattdessen einen Doppelpunkt eingegeben hat, findet das Auge den Fehler auch nur mit Mühe) und finde z.B. Lua-Code, bei dem ein Return ein Befehlstrenner ist, viel übersichtlicher und weniger Fehlerträchtig. Ich finde, das Semikolon sollte man von Pascal nicht übernehmen. Es macht den Code auch einfach "hässlich". ;)


    Was die Definition von Grafikdaten auf diesem Wege anbelangt, so habe ich auch meine Zweifel, ob es wirklich sinnvoll ist. Zum einen verbrauchen die Strings sehr viel Platz im Speicher (nämlich doppelt so viel als hätte man einen 16 Farbmodus). Außerdem entsteht die Frage, wie man die verschiedenen Farben kennzeichnen soll.

    Ich bin nach wie vor der Meinung, Grafik- und Sounddefinitionen haben im Code nichts verloren. Dafür haben wir die entsprechenden Editoren. Deren Inhalt wird beim Speichern an die Datei angehängt (vielleicht sogar ab bestimmten Größen gepackt) und fertig.


    COLOR: Beim Befehl COLOR soll es sich um die Textfarbe handeln. Auf dem CPC heisst das z.B. INK. In CSS heisst es ebenfalls "color" und nicht z.B. "text-color", waehrend die Hintergrundfarbe "background-color" heisst.

    Wo du gerade von Text sprichst: In CSS definiert man ja Schrift-Stile noch etwas umfangreicher, kann z.B. einen Schatten definieren und welcher Font und welche Auszeichnung (bold, kursiv ..) und welche Ausrichtung verwendet werden soll. Vielleicht macht man es hier ganz ähnlich und definiert Styles (bzw. Formatvorlagen), die man dann bei der Darstellung nutzen kann.


    Mein 'ideal' Homecomputer wäre ein 128er mit StereoSID (ist ja nachrüstbar), SD2IEC als 'Massenspeicher', ein 17xx, eine 1351, vielleicht noch eine WiC64 (brandneu & ideal).

    Dann solltest du doch zufrieden sein – das gibt es alles schon. Ich frage mich immer wieder, was Leute, die für sich den perfekten Homecomputer gefunden haben, in diesen Thread treibt (wo Leute diskutieren, die sich einen noch tolleren vorstellen können).


    Der Titel heisst Retro-Computer im 8-Bit Style.

    Von Lern- bzw. Schulcomputer steht da nix.

    Und was die Programmiersprache angeht: nicht jeder der einen Computer kauft will programmieren lernen.

    Tut mir leid, dass du erst jetzt aus dem Koma aufgewacht bist. Der Thread hat sich entwickelt – sorry, dass wir nicht auf dich gewartet haben. ;)


    Irgendwann mittendrin haben wir neben Wünschen auch versucht zu definieren, was denn eine Marktlücke für einen weiteren Retro-Homecomputer sein könnte. Ich hatte gemutmaßt, dass alle Retro-Computer der 2020er Jahre ein gemeinsames Problem haben werden: zu wenig native Spiele (im Vergleich zu damals™ oder zu Spielkonsolen). Und ich bin der Meinung (andere teilen die sogar), dass das CBM-Basic (egal ob nun Version 2 oder 12) einen potentiellen Programmierer von Videospielen (die über Kartenspiele und Zahlenraten hinaus gehen) sehr schnell vor hohe Hürden stellt, die letztendlich bedeuten, nochmal mit Assembler neu anfangen zu müssen.


    Aus diesen beiden Axiomen haben wir dann eine denkbare Lösung geformt: Ein neuer/weiterer Retro-Homecomputer sollte/könnte sich auf das Erstellen von Spielen konzentrieren. Wenn viele der Kunden anfangen würden, (wenn auch anfangs einfache) Games zu entwickeln, dann hätte dieser Rechner nicht das potentielle Problem der anderen, wo vielleicht auf 20 Käufer ein Assembler-Coder kommt (oder noch viel weniger) und man mit Basic nicht wirklich "gute" (Artion-)Spiele entwickeln kann (ich meine damit sowas wie Pac-Man, Zelda oder Xevious). Das wäre also ein Weg aus der "Software-Krise".


    Aber wenn der Rechner zum leichten Erlernen einer (modernen) Programmiersprache taugen würde, deren Ergebnisse zudem Spaß machen würden – dann könnte man ihn auch als Lern-Computer einsetzen. Das ist aber mitnichten der einzige Anwendungsfall – aber ein zusätzlicher.


    Das BASIC wirklich nicht das non-plus-ultra ist, ist bekannt, aber fürs schnelle ausprobieren allemal gut genug.

    Wer wirklich Programmieren will steigt eh schnell auf andere Sprache.

    Aber genau diesen doppelten Einstieg wollen wir den Usern ersparen. Das hier zuletzt besprochene Rechnerkonzept lässt den Kunden nicht so schnell hängen, sondern soll es ermöglichen, viel länger ohne Frust von dem einmal erlernten partizipieren zu können.


    Und was den Mega65 angeht: Der Thread lag ja eine ganze Zeit lang brach und erst der Einwurf von vor ein paar Tagen, der M65 wäre doch genau das, was sich alle hier wünschen würden, hat ihn wieder aus der Versenkung geholt. Denn der Mega65 erfüllt kaum welche der hier geäußerten Wünsche – nicht mal die nach einem günstigen Preis von 100 bis 200 Euro. Und damit auch dem Wunsch nach einer hohen Verbreitung. Das Basic ist zwar gegenüber dem C64 besser geworden (und der Takt um das absurde 40-fache gesteigert) – ich sehe aber nicht, dass das die damaligen™ Grenzen bzgl. Basic-Spiele-Entwicklung wirklich aufhebt.

  • Aber dieser Thread heißt nun einmal "Neuer Retro-Computer im 8-Bit Style." Persönlich halte ich auch einen 16 Bit-Prozessor für eine Untergrenze.

    Wie gesagt, ich bin schon lange davon ausgegangen, dass eine 8-Bit-CPU nicht ausreichen wird. Aber 8 Bit war für den Prozessor auch gar nicht "gesetzt" – es ging von Anfang an um den 8-Bit-STYLE, also um die Wirkung, die Multimedia-Fähigkeiten.

  • Mal ehrlich, keiner wird seinem Filius, seiner Filia einen 800€ Mega65 kaufen, damit die vielleicht mit BASIC 10 in die Programmierung einsteigen.

    Da ist in der Tat ein Raspi 400 der sinnvollere Einstieg. Im Kit ist ja auch ein gedrucktes Buch dabei mit AFAIR einem Scratch 3 und einem Python/PyGameZero Kurs.

    Klar kann man damit locker die Grundlagen der Programmierung und den Umgang mit Linux lernen.


    Vielleicht unterschätze ich die Wissbegier der heutigen Kids, aber ich glaube nicht, dass die da in Massen jetzt Spiele für den Raspi 4/400 coden und dabei auch noch tiefer in OS und Hardware reinschauen.

    Also so tief, dass man wirklich ein Gefühl dafür bekommt, wie die Kiste wirklich tickt.


    Warum:

    • gegen eine moderne Konsole/PC ist der Pi sehr schwache HW (für Spiele)
    • die Kinder sind komplexen 3D Bombast mit vielen Jahren und Millionen Entwicklungsaufwand gewohnt
    • alle Tools sind extrem high-level und weit weg von der HW
    • die HW ist vom OS verrammelt
    • das OS ist super komplex, weil 30-50 Jahre Unix/Posix/Linux/X11 Ballast und portabel zu Unmengen an Zeug
    • die HW ist nicht offen, aktuelle Pi4 VC6 Treiber werden z.B. mit NDA Doku entwickelt, die man von Broadcom erbetteln muss
    • ARMv7/ARMv8 ISA haben auch viel Ballast und Speck, echte "Reduced Instruction Set Architecture" ist das seit Jahrzehnten nicht mehr
    • es gibt unmengen Sprachen, IDEs, Frameworks - womit soll man weitermachen, wenn Python nicht mehr reicht

    Der unique selling point für einen neuen Retro-artigen Lern- und Spielcomputer wäre für mich:

    1. "Du kannst mit dem Teil einfache 2D Retro-Spiele recht einfach selbst coden."
    2. "Wir nehmen Dich bei der Hand und geben dir genau das eine Toolset, womit das hier gemacht werden kann."
    3. "Wir verstecken keine Komplexität, sondern erklären schrittweise die ganze Kiste von oben bis unten".
    4. "Wenn Du die Kiste irgendwann super beherrschst, kann Du vielleicht so coole Sachen damit machen, wie wir es nicht erwartet hatten."
    5. Alles ist offen und nachvollziebar: Tools, Sprache, OS/ROM, Systemarchitektur, Prozessor, Grafik- und Soundchip

    Die Kinder sollen doch heute schlucken, dass die Digital-Toys eigentlich nicht mehr ihnen gehören, sondern Apple, Nintendo, Google, MS damit treiben, was sie wollen und dass Offenheit und Programmierbarkeit absichtlich immer weiter verhindert werden. Die Industrie will abhängige, unmündige Enduser, die alles fressen, alles abbonieren und am Ende noch dafür blechen, dass sie bevormundet, ausspioniert und gegängelt werden.

    Und dafür bekommen sie noch nicht mal halbwegs sichere Geräte und Systeme, sondern ein Haufen chronisch unsicherer Bloatware.

  • Aus diesen beiden Axiomen haben wir dann eine denkbare Lösung geformt: Ein neuer/weiterer Retro-Homecomputer sollte/könnte sich auf das Erstellen von Spielen konzentrieren. Wenn viele der Kunden anfangen würden, (wenn auch anfangs einfache) Games zu entwickeln, dann hätte dieser Rechner nicht das potentielle Problem der anderen, wo vielleicht auf 20 Käufer ein Assembler-Coder kommt (oder noch viel weniger) und man mit Basic nicht wirklich "gute" (Artion-)Spiele entwickeln kann (ich meine damit sowas wie Pac-Man, Zelda oder Xevious). Das wäre also ein Weg aus der "Software-Krise".

    Ich möchte das nochmal ein wenig auswalzen:


    Das wäre auch die Lösung gegen das Henne/Ei-Problem, mit dem sich jede neue Plattform herumschlagen muss: Zu wenig Software = zu wenige Kunden UND zu wenige Kunden = zu wenig Software. DENN die Käufer dieses Rechners hätte keine großen Erwartungen an vorgefertigter Software (= Spiele-Katalog) – sie wollen ja programmieren. Und indem sie programmieren, entsteht Software für die Plattform. Und wenn erst diese Hürde genommen wurde, steigen evtl. auch diejenigen ein, die doch gerne fertige Games zocken wollen – und mit denen (bzw. den steigenden User-Zahlen) kommen dann auch professionelle Entwickler, die mit Cross-Assemblern auf PCs FÜR die Plattform entwickeln.


    Aber selbst, wenn das nicht passiert – so hat die erste Welle der Entwickler-Nutzer ja genau das, was sie haben wollte: Einen Rechner, mit dem man sehr einfach hübsche Spiele entwickeln kann. Ob sie nun Pioniere sind für eine weitere Welle von reinen Konsumenten/Gamern, muss sie ja nicht interessieren.

  • Der unique selling point für einen neuen Retro-artigen Lern- und Spielcomputer wäre für mich:
    "Du kannst mit dem Teil einfache 2D Retro-Spiele recht einfach selbst coden."
    "Wir nehmen Dich bei der Hand und geben dir genau das eine Toolset, womit das hier gemacht werden kann."
    "Wir verstecken keine Komplexität, sondern erklären schrittweise die ganze Kiste von oben bis unten".
    "Wenn Du die Kiste irgendwann super beherrschst, kann Du vielleicht so coole Sachen damit machen, wie wir es nicht erwartet hatten."
    Alles ist offen und nachvollziebar: Tools, Sprache, OS/ROM, Systemarchitektur, Prozessor, Grafik- und Soundchip

    Danke fuer die Zusammenfassung dessen, um was fuer einen Rechner es hier im Thread aktuell geht :thumbup:

  • sparhawk; Vielen Dank für die ausführliche Erklärung. Habe es jetzt einigermaßen verstanden. Hoffe ich. ^^


    Die Vorteile sehe ich – allerdings ist es für Anfänger quälend und für Ex-Basic-Nutzer ungewohnt. Könnte der Editor nicht so einen kleinen Helfer-Dämon haben, der bei vergessenen Deklarationen den Nutzer darauf hinweist und auch gleich hinzufügt (der Typ ist ja oft erratbar, bei For-Schleifen z.B. meistens integer)? Wenn man es richtig macht, sieht man das Helferlein nie und wenn man es falsch macht, wird es einem korrekt beigebracht und auch gleich korrigiert.

    Daß es für Ex-Basic-Nutzer ungewohnt ist, mag ja sein. Das wäre bei C oder Python oder Lua oder... aber auch so. Daß es für Anfänger quälend ist, wage ich hingegen sehr zu bezweifeln. Wir haben damals[tm] an unserer Schule als erste Sprache Pascal gelernt, und ich habe keinen gesehen, der dies nicht als einleuchtend und leicht zu handhaben empfand. Von Quälerei keine Spur.

    Soweit ich es beobachten konnte, trifft das Nichtdeklarieren von Variablen in Basic nur bei sehr kleinen Programmen zu. Bei allen größeren finde ich zu Beginn des Programms eine Nennung der Variablen in Form einer Zuweisung wie "i=0", damit diese Variable später vom Interpreter schnell gefunden werden kann. Außerdem müssen Arrays mit mehr als 10 Elementen mittels DIM erzeugt werden, was in der Regel ebenso am Anfang geschieht. Pseudokonstanten wie die VICII-Adresse werden ebenfalls gerne ganz am Anfang des Programms definiert. Anders gesagt: Wer wirklich schon längere Programme in Basic geschrieben hat, ist mit dem Konzept der Vorabnennung durchaus vertraut.

    Was den Editor anbelangt, darf jeder sich gerne einen Editor wie von Dir beschrieben anfertigen.

    Ich finde Semikolons auch eher nervig (werden gerne vergessen und man sucht sich dann einen Wolf und wenn man stattdessen einen Doppelpunkt eingegeben hat, findet das Auge den Fehler auch nur mit Mühe)

    Ein Semikolon in Pascal/Oberon wird nicht häufiger vergessen als ein Semikolon in C/Java... oder ein Doppelpunkt in Basic. Und man sucht sich auch keinen Wolf, weil der Compiler sagt, an welcher Stelle er es vermißt.

    Lua-Code, bei dem ein Return ein Befehlstrenner ist, viel übersichtlicher und weniger Fehlerträchtig

    Daß jedes Statement sich nur über eine Zeile erstrecken darf, ist eine unnötige Einschränkung bei der optischen Gestaltung des Programms. In der Praxis kommt es häufig vor, daß umfangreiche Ausdrücke (= Berechnungen) oder Funktionsaufrufe mit vielen Parametern sich über mehrere Zeilen erstrecken. Und auch wenn mein persönlicher Stil so aussieht, daß ich jedem Statement eine eigene Zeile zuweise, gibt es immer Situationen, in denen dies unpassend ist und anders gehandhabt werden muß.

    Ich dachte, darüber wären wir schon hinaus. Dein (besser-als-68000er-) "Fantasie"-Prozessor war doch, glaube ich, sogar ein 32 Bit-Prozessor.

    Wie gesagt, ich bin schon lange davon ausgegangen, dass eine 8-Bit-CPU nicht ausreichen wird. Aber 8 Bit war für den Prozessor auch gar nicht "gesetzt" – es ging von Anfang an um den 8-Bit-STYLE, also um die Wirkung, die Multimedia-Fähigkeiten.

    Ja, klar bin ich persönlich längst von dem Gedanken an einen 8 Bit-Computer weg. Aber Du siehst ja, daß es genügend Foristen gibt, die sich unter einem modernen Retrorechner immer noch gerne ein 8 Bit-System vorstellen wie den Mega65 in der Erwartung, daß so ein Rechner dann so leicht bedienbar sei wie der C64. Das ist nach allem, was ich bisher sehen konnte, allerdings weder beim Mega65 noch beim C256 Foenix noch beim Commander X16 der Fall.

    Das wäre auch die Lösung gegen das Henne/Ei-Problem

    Sehe ich auch so. Nutzer schreiben Programme für andere Nutzer. In der Anfangszeit von VC20 und C64 konnte man das noch so beobachten. Da wurden kleine Spiele in Basic geschrieben und herumgereicht (oder sogar verkauft!). Als dann die Assemblerspiele immer besser wurden, sahen Basicprogramme dagegen zu mickrig aus, und leider waren sie auch zu langsam für Actionspiele.

    An der Stelle sei der Hinweis gestattet auf das ApplePascal, das wir an der Schule benutzten. Da unsere Programme in einen P-Code übersetzt wurden, waren sie erheblich schneller als das interpretierte Basic. Außerdem bot das Pascal mächtige Grafikbefehle an, so daß wir in der Lage waren, kleine Spiele in Pascal zu schreiben, die schon besser aussahen als die von Basic. Natürlich war der Abstand zu den Assemblerspielen immer noch recht groß, aber nicht mehr so sehr, daß der Eindruck entstand, das eigene Werk sei im Vergleich dazu totaler Mist. Im Gegensatz zu den vielen hier im Forum, die mit Commodore Basic angefangen haben, habe ich daher schon früh die Erfahrung gemacht, daß man mit einer Hochsprache leicht eigene Spiele schreiben kann. Und genau dieses Gefühl sollte meiner Meinung nach ein moderner Retrorechner von heute ebenfalls vermitteln.