Hallo Besucher, der Thread wurde 180k mal aufgerufen und enthält 1853 Antworten

letzter Beitrag von Retrofan am

Neuer Retro-Computer im 8-Bit Style

    Zitat von Snoopy

    Die sind nämlich naturbedingt [...] weniger komfortabel in der Benutzung als aktuelle Rechner.

    Nein, sind sie nicht. Es ist doch gerade der Wunsch vieler, wieder diese "Einfachheit" zu spüren. Einschalten und sofort ein paar Basic-Zeilen eingeben dürfen und auch sofort ein Ergebnis sehen. Das geht mit heutigen Computern nicht – da drängt sich einem keine Programmiersprache auf. Das Problem bei den originalen alten Rechnern ist halt, dass sie die Erwartungen, die sie beim Einschalten erwecken, oft nicht erfüllen können. Der Editor ist dann doch nicht so komfortabel, wie er sein könnte, Grafik- und Sound-Befehle sucht man zumindest beim C64 vergebens – und recht früh wird es kompliziert, wenn man entweder einfängt, zu "poken" oder doch gleich auf Assembler umsteigen muss. Genau dieses Manko würde ich bei einem Retro-Rechner gerne beseitigen.


    Genau die Zielgruppe, die du für ungeeignet hälst, würde ich gerne ansprechen wollen – weil sie sicherlich hundertmal größer ist als die der "Profi"-Coder, die eine PC-IDE mit Cross-Compiler im Anschlag haben.

    Zitat von Snoopy

    Wer davon enttäuscht ist und keinen Spaß hat, der ist schlichtweg die falsche Zielgruppe für einen 8bit-Rechner. Die sind nämlich naturbedingt langsam und weniger komfortabel in der Benutzung als aktuelle Rechner.

    Mich erstaunt es immer wieder daß die Leute ein Gogomobil fahren wollen daß sich wie ein Porsche Cayenne fährt...
    :whistling:

    Zitat von Freddy

    Mich erstaunt es immer wieder daß die Leute ein Gogomobil fahren wollen daß sich wie ein Porsche Cayenne fährt... :whistling:

    Es gibt ja auch den neuen Fiat 500, den New Beetle... es gibt also auch Leute, die den altmodischen Style auf moderner Basis haben moechten ;)

    Zitat von Retrofan

    Es ist doch gerade der Wunsch vieler, wieder diese "Einfachheit" zu spüren. Einschalten und sofort ein paar Basic-Zeilen eingeben dürfen und auch sofort ein Ergebnis sehen. Das geht mit heutigen Computern nicht –

    Ja, entweder startet man dann Python per Doppelklick oder packt das in den Autostart und schon kann man viel einfacher als mit jedem Basic Spiele programmieren. Aber du hast recht, das muss man einmal installieren. Tuts gibt es allerdings für PyGame und Co wie Sand am Meer. Unterm Strich finde ich das viel einfacher als damals mit dem C64 was zu machen.


    Sachen wie Grafik- Und Soundprogrammierung und Spieleentwicklungs-Kenntnisse, also die ganzen Algorithmen und Datenstrukturen die es dazu gibt, nimmt dir keine IDE und keine Programmiersprache wirklich ab. Der Löwenanteil ist nicht die Programmiersprache zu lernen, das ist nur das Werkzeug.


    Spieleentwicklung auf einem Retrorechner ist um einiges schwerer zu lernen als am PC, da nutzt es auch nix wenn das Basic ohne Doppelklick gleich da ist.

    Ich weiss gar nicht warum da jetzt so viel "Nit-picking" betrieben wird. Der Sinn hinter der Idee muesste doch sowas von klar sein. Dass da jetzt jedes Argument hin- und hergewogen werden muss verstehe ich wirklich nicht. Klar kann ich auf einem modernen PC Python starten und damit Spiele entwickeln, aber wenn das fuer alle ausreichend waere, dann wuerde eine solche Idee doch gar nicht erst auf den Tisch kommen. Wenn ich auf dem PC mit Python etwas programmiere, muss ich mir trotzdem Gedanken machen, welche Aufloesung, welche Plattform (ja, da muss man teilweise Anpassungen vornehmen), man muss verschiedene Eingabegeraete unterstuetzen, man stoesst auf eine moegliche Vielzahl an Inkompatibilitaeten und Sonderfaelle usw usw usw...


    Was mit "Einfach" gemeint ist ist doch eben das, dass man den "8-Bit-Computer" einschaltet und genau fuer diese Specs programmieren kann. Es wurde zigmal PICO-8 erwaehnt, weil das aktuell eins der besten Vorbilder dafuer sein duerfte, dass eine genau spezifizierte Plattform mit super-elegant eingebetteten Entwicklungs-Tools eben doch eine gewisse Beliebtheit finden kann, auch wenn es sich hierbei nur um Software handelt. Die Grund-Idee, von der wir hier doch sprechen, ist doch eine Art "PICO-8 mit hoeheren Specs und in Hardware". Ist das so schwer zu verstehen, was fuer einen Reiz ein solcher Rechner haette, WENN er denn verfuegbar waere?

    Zitat von ZeHa

    Was mit "Einfach" gemeint ist ist doch eben das, dass man den "8-Bit-Computer" einschaltet und genau fuer diese Specs programmieren kann. Es wurde zigmal PICO-8 erwaehnt, weil das aktuell eins der besten Vorbilder dafuer sein duerfte, dass eine genau spezifizierte Plattform mit super-elegant eingebetteten Entwicklungs-Tools eben doch eine gewisse Beliebtheit finden kann, auch wenn es sich hierbei nur um Software handelt. Die Grund-Idee, von der wir hier doch sprechen, ist doch eine Art "PICO-8 mit hoeheren Specs und in Hardware". Ist das so schwer zu verstehen, was fuer einen Reiz ein solcher Rechner haette, WENN er denn verfuegbar waere?

    Das sehe ich ganz genauso!

    Zitat von ZeHa

    Die Grund-Idee, von der wir hier doch sprechen, ist doch eine Art "PICO-8 mit hoeheren Specs und in Hardware". Ist das so schwer zu verstehen, was fuer einen Reiz ein solcher Rechner haette, WENN er denn verfuegbar waere?

    Der Pico-8 oder auch der TIC-80 sind sehr interessant. Mit letzteren beschäftige ich mich auch hin und wieder.


    Allerdings haben diese "Software-Rechner" die aktuelle PC- bzw. Tablet-Power unter ihrer Haube. So eine Entwicklungsumgebung ist mit einem 8bit-Rechner schlicht nicht möglich. Und wer sich einen 8bit-Rechner hinstellt, der erwartet das auch nicht. Ganz im Gegenteil, dem sind die technisch bedingten Einschränkungen - auch beim Entwickeln - vollkommen bewusst und auch gewollt.


    Wer einen Pico-8 in Hardware will, der darf sich das gerne wünschen. Nur ist das dann mehr oder weniger ein aktueller PC, der bei Grafik und Sound entsprechend seinem Vorbild beschnitten ist.


    Mit "8bit" (siehe Threadtitel) hat das allerdings nichts zu tun. Darum geht es hier bei den Kommentaren.

    Was ich so bisserl vermisse ist ein anderer Aspekt eines solchen Projekts: man lernt bei basteln ganz doll viel! Deshalb kann ich nur jedem von raten, sich z.B. mal ein FPGA Board zu besorgen und mal mit dem Basteln zu beginnen. Sogar wenn kein tolles Endergebnis dabei rauskommt, könnt ihr von einem solchen Projekt enorm profitieren. Und das sag ich jetzt aus eigener Erfahrung!

    Zitat von alx

    Es ist so weit, dass man was sehen kann: das erste Programm entpackt ein Bild und zeigt es an

    Super! :thumbup: Weiter so! :dafuer:


    Wenn Du erlaubst, hätte ich noch ein paar Fragen:
    1.) Bei Ansicht der Befehle kommt es mir so vor, als wären diese recht breit (oftmals 4 Zeichen pro Befehl). Gäbe es die Möglichkeit, die Befehle im Sinne einer besseren Lesbarkeit ein wenig zu kürzen oder orientierst Du Dich an einer realen Vorlage und möchtest nach Möglichkeit Befehle in der Schreibweise übernehmen? Ansonsten wäre z. B. bei einer Anweisung wie "LDAI #$30" das "I" eigentlich redundant, sofern es "Immediate" bedeuten soll, was schon durch das "#" zum Ausdruck gebracht wird, und bei den Branch-Befehlen ließe sich analog zum 6502 oder 68000 das "R" einsparen, also "BNE" anstelle von "BRNE".
    2.) Wie gestaltest Du das Taktverhalten und damit die Ausführungsgeschwindigkeit Deines Prozessors? Folgst Du dem Beispiel des 6502, der (grob gesagt) für einen Speicherzugriff einen Takt (aufgeteilt auf zwei Phi-States) benötigt oder verfolgst Du ein komplizierteres Verhalten wie beispielsweise beim Z80, der die Maschinenzyklen in weitere T-States unterschiedlicher Anzahl unterteilt?
    3.) Für wie effizient hinsichtlich Ausführungsgeschwindigkeit und Codedichte würdest Du im Vergleich zum 6502 Dein Design einschätzen?
    4.) Möchtest Du langfristig gesehen über die CPU hinaus auch eine Systemumgebung (Video, Sound etc) als eigene Umwelt für Deine CPU definieren?

    Zitat von sparhawk

    Dieser Thread ha ja eine ganz schöne Wendung genommen. Von "NEUER (Wunsch)Rechner im Retrosytle der kein weiterer C64 Clon sein sollte" zu "muss aber auf jeden Fall C64 kompatibel sein".

    Das kann ich so nicht erkennen. Wie man sieht, arbeitet alx erfolgreich an einem eigenem 8 Bit-Prozessor-Design. Markaine hat eine ausführliche Liste mit Anforderungen an einen 32 Bit-Rechner zusammengestellt, und auch der Typ, der den Vorschlag mit dem c64x2 gemacht hat, hat an anderer Stelle ein einfaches 32 Bit-System beschrieben. Bislang wurden somit schon einige interessante Systeme genannt. Meiner Ansicht nach dient dieser Thread doch erst einmal dazu, verschiedene Vorstellungen zu sammeln und abzuklopfen auf Vor- und Nachteile, sowie sich darüber klarzuwerden, was man von einem System eigentlich will.


    Bezüglich Programmierung auf dem Gerät hätte ich z. B. noch einen Punkt, der mir noch nicht so klar ist:
    Wie soll die Programmiersprache aussehen, in der man auf dem Gerät programmiert? Zwar wurde schnell Basic genannt, aber wir wissen ja, daß es von Basic einen großen Haufen Dialekte gibt, die nicht kompatibel zueinander sind. Desweiteren wurde eine Sprache wie ACTION erwähnt, die sich von ihrer Struktur her ein wenig von Basic unterscheidet, z. B. dadurch, daß Variablen deklariert werden müssen. Daher meine Frage an diejenigen, die auch gerne auf dem Rechner selbst programmieren möchten: Wie darf die Sprache aussehen, damit sie noch akzeptiert wird?
    Als Beispiel: In Microsoft-Basic gibt es die FOR-Schleife mit dem fürchterlichen NEXT, welches eine abschließende Kompilierung unmöglich macht. Wäre es daher zwecks besserer Kompilierung vielleicht möglich, eine Sprache zu definieren, in der Schleifen z. B. so aussehen:

    Wäre das noch annehmbar, oder würden da schon einige sagen: Nee, das ist mir nicht mehr Basic genug?

    Zitat von M. J.

    1.) Bei Ansicht der Befehle kommt es mir so vor, als wären diese recht breit (oftmals 4 Zeichen pro Befehl). Gäbe es die Möglichkeit, die Befehle im Sinne einer besseren Lesbarkeit ein wenig zu kürzen oder orientierst Du Dich an einer realen Vorlage und möchtest nach Möglichkeit Befehle in der Schreibweise übernehmen? Ansonsten wäre z. B. bei einer Anweisung wie "LDAI #$30" das "I" eigentlich redundant, sofern es "Immediate" bedeuten soll, was schon durch das "#" zum Ausdruck gebracht wird, und bei den Branch-Befehlen ließe sich analog zum 6502 oder 68000 das "R" einsparen, also "BNE" anstelle von "BRNE".

    Das mit dem # ist ein versehen, das sollte nicht angezeigt werden (und eigentlich sollte auch alles als 0x und nicht $ da sein, aber ich hatte aus bequemlichkeit das erstmal einfach übernommen). Ich habe im allgemeinen nicht vor das zu kürzen, aber ob du das R aus allen branches rauswirfst oder nicht soll mir egal sein. Andererseits sollte der Name das kleinste Problem sein. (Die Befehle und Namen sind an 6809 und 8-bit-AVR angelehnt, von denen ich viel übernommen habe.)


    Zitat von M. J.

    2.) Wie gestaltest Du das Taktverhalten und damit die Ausführungsgeschwindigkeit Deines Prozessors? Folgst Du dem Beispiel des 6502, der (grob gesagt) für einen Speicherzugriff einen Takt (aufgeteilt auf zwei Phi-States) benötigt oder verfolgst Du ein komplizierteres Verhalten wie beispielsweise beim Z80, der die Maschinenzyklen in weitere T-States unterschiedlicher Anzahl unterteilt?

    Das Ziel ist es dass ein Takt pro gelesenem/geschriebenen Byte benötigt wird, und nicht mehr. (also "sta x,20" braucht 3 takte; 1. opcode, 2. offset, 3. speichern) (Aber wie genau das passieren kann/muss weiss ich nicht, ich hab' das nur dem VICE beigebracht.)


    Zitat von M. J.

    3.) Für wie effizient hinsichtlich Ausführungsgeschwindigkeit und Codedichte würdest Du im Vergleich zum 6502 Dein Design einschätzen?

    Durch den meistens kürzeren code und die schnellere Ausführung sollte er ca. doppelt so schnell sein.


    Zitat von M. J.

    4.) Möchtest Du langfristig gesehen über die CPU hinaus auch eine Systemumgebung (Video, Sound etc) als eigene Umwelt für Deine CPU definieren?

    Bevor ich die Idee der CPU hatte wollte ich mal den VIC erweitern (so dass man z.B. ein farbenreicheres charset direkt in den VIC lädt; bis auf das "reinladen" und aktivieren wäre der Code identisch und das selbe Spiel kann mit und ohne erweiterten vic laufen, nur halt auf dem einen schöner), was ich geschafft habe ist eine rudimentäre GPU, die aus großen Fonts/Screens ein Multicolor-Bitmap berechnet und diese dem VIC "unterschiebt". (Technisch: ist ein Modul, der VIC muss auf Multicolor-Bitmap gestellt werden, immer wenn der VIC Screen oder Bitmap lädt wird der C64-Bus auf inaktiv geschaltet und das Modul legt die Daten direkt auf den Bus. Hatte das in einer einfachen version auf echter Hardware am laufen. Ist auch in irgendeinem Thread hier erwähnt.) Aber nein, ich habe zumindest z.Z. nicht vor eigene Hardware zu Bauen/Definieren.

    Zitat von daybyter

    Was ich so bisserl vermisse ist ein anderer Aspekt eines solchen Projekts: man lernt bei basteln ganz doll viel! Deshalb kann ich nur jedem von raten, sich z.B. mal ein FPGA Board zu besorgen und mal mit dem Basteln zu beginnen. Sogar wenn kein tolles Endergebnis dabei rauskommt, könnt ihr von einem solchen Projekt enorm profitieren. Und das sag ich jetzt aus eigener Erfahrung!

    Das ist wiederum ein ganz anderes Hobby.
    Nicht jeder will ein FPGA-Programmierer werden.


    Und ich denke auch daß FPGA zwar ein gangbarer Weg ist, aber nicht 'DER' Weg ist, weil so ein FPGA halt viel zu ungenau ist.


    Ein 6502 (oder Z80 oder 65816) ist genau definiert.
    Gleiches gilt z.B. für den Y 9938 Grafikchip wie auch für StereoSID und oder OPL oder für AY-3-8910 soundchips.



    Der 'Reiz' eines Retro-8-Bit-Maschine ist es doch mit den eingeschränkten Resourcen klar zu kommen.

    Zitat von M. J.


    Bezüglich Programmierung auf dem Gerät hätte ich z. B. noch einen Punkt, der mir noch nicht so klar ist:
    Wie soll die Programmiersprache aussehen, in der man auf dem Gerät programmiert? Zwar wurde schnell Basic genannt, aber wir wissen ja, daß es von Basic einen großen Haufen Dialekte gibt, die nicht kompatibel zueinander sind. Desweiteren wurde eine Sprache wie ACTION erwähnt, die sich von ihrer Struktur her ein wenig von Basic unterscheidet, z. B. dadurch, daß Variablen deklariert werden müssen. Daher meine Frage an diejenigen, die auch gerne auf dem Rechner selbst programmieren möchten: Wie darf die Sprache aussehen, damit sie noch akzeptiert wird?
    Als Beispiel: In Microsoft-Basic gibt es die FOR-Schleife mit dem fürchterlichen NEXT, welches eine abschließende Kompilierung unmöglich macht. Wäre es daher zwecks besserer Kompilierung vielleicht möglich, eine Sprache zu definieren, in der Schleifen z. B. so aussehen:

    Wäre das noch annehmbar, oder würden da schon einige sagen: Nee, das ist mir nicht mehr Basic genug?

    Also, ich denke (im Geiste von 8-Bit-Retro) sollte die ROM-Sprache schon BASIC sein. So in etwa in dem Umfang wie das 3.5er von CBM.
    Kann auch wie Locomotive BASIC sein, oder Omicron- oder GFA-BASIC. Aber BASIC sollte es schon sein, weil BEGINNERS All Purpose Symbolic Instruction Code.


    Runnaways (aka Fortgeschrittene) werden dann eh zu Pascal oder cc65 usw. migrieren.


    Und natürlich: ein Monitor sollte im ROM auch vorhanden sein.

    Zitat von Freddy

    Runnaways (aka Fortgeschrittene) werden dann eh zu Pascal oder cc65 usw. migrieren.

    Pascal? :gruebel
    Ist ja fast so schlimm wie Python. :D

    Kann man eigentlich nicht einen BASIC Interpreter direkt in FPGA gießen um z.B. das Grundsystem nicht zu schnell machen zu müssen, aber auf der anderen Seite es zu erlauben in Basic kleinere Spiele programmieren zu können? Praktisch würde das BASIC dann bestimmte Funktionen direkt ausführen können, also z.b einen Speicherbreich kopieren, Linie ziehen etc. während man per Assembler dann den Weg über die emulierte CPU gehen müsste. Gut wer will dann noch in ASM programmieren? Ist nur so eine Idee. Ich weiß gar nicht ob ich jetzt hier totalen Schwachsinn erdenke^^


    Der Knackpunkt ist ja hier wirklich der Wunsch unter BASIC was performantes produzieren zu können, wozu das Hauptsystem sehr schnell sein muss, was dann wieder dem Retrogedanken mit beschränkten Ressourcen widerspricht.


    Selbst ein Amiga war ja für Basic zu langsam, also um damit einfache Jump&Run Spiele zu programmieren.

    Zitat von Snoopy

    Der Pico-8 oder auch der TIC-80 sind sehr interessant. [...] Allerdings haben diese "Software-Rechner" die aktuelle PC- bzw. Tablet-Power unter ihrer Haube. So eine Entwicklungsumgebung ist mit einem 8bit-Rechner schlicht nicht möglich.

    Der Pico-8 lief auch auf dem (Pocket-) CHIP-Computer, der nicht "die aktuelle PC-Power unter der Haube" hatte. Aber davon ab:


    Da niemand plant, das Pico-8 Konzept 1:1 auf schwache Hardware zu portieren (vom interpretierten Lua z.B. haben wir von Anfang an Abstand genommen), würde es mich interessieren, was denn deiner Meinung nach genau von der IDE nicht auf deutlich schwächerer Hardware (sagen wir mal: 8 MHz, 32 Bit) laufen würde. (denn einen C64 will hier ja auch niemand nachbauen)


    Zitat von M. J.

    Wäre das noch annehmbar, oder würden da schon einige sagen: Nee, das ist mir nicht mehr Basic genug?

    Meinst du den Basic- oder Pascal-Stil? Der Pascal-Stil wäre halt Pascal und nicht mehr Basic. Mit dem Basic-Stil könnte ich gut leben.


    (Wobei "ich" hier meint, als virtueller "Anbieter". In meinem Job z.B. mache ich ja alles für den Kunden und nicht für mich. Wenn ich also hier schreibe, dass "ich" dieses und jenes präferiere, dann heißt das, dass ich der Ansicht bin, dass dieses oder jenes von potentiellen Kunden eines solchen Geräts präferiert würde. Ich würde so einen Retro-Rechner ja nicht in erster Linie für mich haben wollen (ich persönlich habe genügend Rechner herumstehen), sondern für die Allgemeinheit.)

    Zitat von Snoopy

    Der Pico-8 oder auch der TIC-80 sind sehr interessant. Mit letzteren beschäftige ich mich auch hin und wieder.
    Allerdings haben diese "Software-Rechner" die aktuelle PC- bzw. Tablet-Power unter ihrer Haube. So eine Entwicklungsumgebung ist mit einem 8bit-Rechner schlicht nicht möglich. Und wer sich einen 8bit-Rechner hinstellt, der erwartet das auch nicht. Ganz im Gegenteil, dem sind die technisch bedingten Einschränkungen - auch beim Entwickeln - vollkommen bewusst und auch gewollt.


    Wer einen Pico-8 in Hardware will, der darf sich das gerne wünschen. Nur ist das dann mehr oder weniger ein aktueller PC, der bei Grafik und Sound entsprechend seinem Vorbild beschnitten ist.


    Mit "8bit" (siehe Threadtitel) hat das allerdings nichts zu tun. Darum geht es hier bei den Kommentaren.

    Natuerlich waere so eine Entwicklungsumgebung auch auf einem 8bit-Rechner moeglich! Das einzige, was schwierig waere, waere der Compiler, da die Programme bei PICO-8 ja sofort laufen, bei einem schmalbruestigen System muesste man aber eine gewisse Kompilier-Zeit in Kauf nehmen. Aber ein Code-Editor, ein Sprite-Editor, ein Map-Editor, ein Sound-Editor und ein Musik-Editor in der Art von PICO-8 wuerde ja sogar auf dem C64 laufen. Klar braeuchte man genuegend Speicher, aber einige Tendenzen hier im Thread gehen ja durchaus ueber die 64K-Grenze hinaus.


    Und zum Thema "mit 8bit (siehe Threadtitel) hat das nichts zu tun" - wir haben hier doch mehrere "Stroemungen". Die Variante, auf die sich Retrofan bezog, war grob gesagt die "PICO-8-maessige Entwicklung auf einem Hardware-Rechner"-Fraktion. Also ging es hier sehr wohl um solch eine Idee, und darauf bezog ich mich auch in meinem Kommentar. Es ging nicht um den Hardcore-8-Bit-alles-exakt-wie-frueher-Rechner (der mit Sicherheit von einer anderen Fraktion favorisiert wird).

    Zitat von ZeHa

    Es ging nicht um den Hardcore-8-Bit-alles-exakt-wie-frueher-Rechner

    Dazu möchte ich noch etwas ergänzen. Selbst wenn man einen Retro-Rechner plant, der nicht genau so wäre, wie ein echter alter Rechner (was ja komplett unsinnig wäre), sondern einen, den es nicht gegeben hat – mit z.B. Fähigkeiten, die zwischen den 8-Bittern (C64) und den 16-Bittern (Amiga/ST) liegen, heißt das noch lange nicht, dass genau diese Specs irgendwen hinterm Ofen wegholen, um damit zu spielen oder darauf/dafür zu coden. Der Rechner wäre ja nicht "besser", sondern nur irgendwie "dazwischen", also mit anderer Abmischung von Specs (plus teils für damals unrealistisch hohe Grafik-Möglichkeiten). So ist es beim C256 Foenix, beim Mega65 und auch beim 8-Bit-Guy-Rechner.


    Bei einem guten Retro-Rechner, der nicht Me-too sein will, sondern gute alte Konzepte mit Neuem anreichert, um etwas wirklich "neues Altes" zu schaffen, braucht man vielleicht noch einen zusätzlichen "Kick", den die Geräte aus den 80ern nicht hatten. Wenn man nur eine mutmaßliche, technische Lücke zwischen zwei Rechner-Generationen "schließen" will, dann ist so ein C-Irgendwas vielleicht eine Antwort – nur warum soll das heutzutage jemand besser finden als die Geräte, die es schon gibt? Nur weil es neu ist oder "weil man es kann"?


    Ich denke, die (noch) einfachere Zugänglichkeit und Programmierbarkeit (durch Anfänger) könnte der Schlüssel sein – Die Zugabe aus der Neuzeit, die die "alte Technik" noch besser macht. Wenn dann jemand die Wahl hat, auf dem C64 (abseits von Assembler) zu coden (was anfangs sehr leicht geht aber aufgrund der technischen Beschränkungen relativ schnell frustriert), auf dem Amiga (was – ohne Basic-Prompt – vom Zugang nicht mehr so leicht geht, dafür aber schon deutlich weiter führt, dann aber auch schnell komplex wird (Bitplanes, Shapes, Co-Prozessoren, Amiga-OS ...)) oder aber einen Gefühlt-dazwischen-Rechner (was Grafik und Sound angeht), der aber besonders easy zu programmieren ist (was die Hemmschwelle herabsetzen könnte), dann nimmt er ja vielleicht den Retro-Rechner statt der echt-alten Kisten.


    Es gibt noch einen zweiten Grund für die gewünschte leicht zugängliche On-Machine-Programmierung durch Coder-Laien/Anfänger. Es ist nicht sehr wahrscheinlich, dass es für eine der kommenden Retro-Rechner ein großes Angebot an "kommerzieller" Software geben wird – dafür sind die zu erwartenden Stückzahlen (außer vielleicht beim 8-Bit-Guy-Rechner) zu klein. Es wird dafür wahrscheinlich kein "Sam's Journey 2" o.ä. geben. D.H. die Casual-Coder sind vielleicht die einzige Hoffnung, überhaupt ein paar erträglich brauchbare Games (abseits von 2 oder 3 Leuchtturm-Projekten) für diese Plattformen zu bekommen. Deswegen würde ich diese Zielgruppe gerne besonders gut unterstützen.