Hello, Guest the thread was called4.7k times and contains 86 replays

last post from BlondMammuth at the

Vision eines Home Computer der 20er-Jahre und darüber hinaus

    Die vielen Debatten zu verschiedenen Ansätzen, das Home Computer Feeling der 80er Jahre zu restaurieren, bringen viele interessante Ideen hervor, die oft in faszinierenden Software- und Hardware-Projekten münden. Die Nostalgie und Begeisterung hat viele Quellen. Sie ist sicher auch eine der Sinne - es ist ganz einfach ein taktiles und olfaktorisches, aber auch akustisches und visuelles Erlebnis, einen Home Computer auszupacken und loszulegen - aber auch eine des Abenteuers und der Entdeckung neuer Möglichkeiten. Man kann von Hardware schwärmen, von Software, von Kreativität, und vielem mehr. Das Wesentliche ist aber aus meiner Sicht in den 80er-Jahren gewesen, dass es etwas völlig Neues gewesen ist, und etwas, was man damals sofort unter Kontrolle haben hat können. Und doch sind es in erster Linie die Kindheits- und Jugend-Tage, die wir damit ein wenig zurückholen.


    Ich möchte eine weitere Vision bringen, die nach vielen Eindrücken bei mir langsam gewachsen ist. Sie soll einfach als weitere Möglichkeit gesehen werden, für alle, denen die Idee gefallen könnte.

    Das Erlebnis Home-Computer, denke ich, könnte man folgenden Generationen wieder vermitteln. So sehen die Eckpfeiler meiner Vision aus:

    • Das zentrale Element ist die Architektur. Die kann man emulieren, oder in Hardware gießen. Am besten beides.
    • Diese Architektur soll nach oben offen sein. Sie kann verschiedene frühe Prozessor-Typen emulieren (oder beinhalten, wenn man das will). Sie darf (muss nicht) heute eine Mehrkern-64bit-Architektur zur Verfügung stellen, und beliebig großen Hauptspeicher aufweisen. Sie soll skalierbar sein, und sie soll keinen weiteren technischen Entwicklungen im Weg stehen. Man soll in hundert Jahren, basierend auf der dann aktuellen Technologie, ebenso ein Modell davon sinnvoll nutzen können wie heute.
    • Ihr Sinn und Zweck ist lernen, experimentieren, erleben. Das System soll dem Benutzer auf einfache Weise völlig offen stehen und jederzeit totale Kontrolle ermöglichen.


    Die Architektur stelle ich mir ca. so vor

    • Sie soll ein "turnkey"-Modell sein, wie alle Homecomputer der ersten Generation. Man dreht es auf, und es meldet sich mit einer Einschaltmeldung und ist bereit.
    • Sie ermöglicht von Anfang an Multi-Processing, um verschiedenste Modelle darauf laufen zu lassen. Wenn antike Prozessor-Modelle zum Einsatz kommen, reicht für die ein Prozess.
    • Sie bietet virtuelle Displays, zwischen denen man leicht wechseln kann. Ein Haupt-Display ist immer zugreifbar, im reinen Text-Modus und mit dem Flair eines 8-Bitters.
    • Eine (vielleicht BASIC-artige) Kontrollsprache, mit der man das gesamte System jederzeit kontrollieren kann. Jedes User-Interface (z.B. GUIs) nutzt diese Sprache (bzw. dieselben System Calls).
    • Verschiedenste Interpreter, Compiler, etc., die beliebig auf den verfügbaren CPU-Typen aufsetzen. Standardmässig werden Programme samt Compile-Anweisungen geladen, übersetzt und gestartet (also ein Open Source Ansatz), natürlich kann man wahlweise auch vorcompilierte Programme laden. Wenn nicht anders angegeben, läuft jedes Programm mit seinem eigenen virtuellen Display. Darin können sie im Textmodus laufen, oder über eine GUI, oder sonstige Graphik.
    • Es gibt systemweit definierte Interfaces und Datenstrukturen (Typen), mittels denen Programme verschiedenster Art miteinander kommunizieren können (insbesondere z.B. Libs einer ganz anderen Bauart mitbenutzen).
    • Jedes Programm definiert (in welcher Sprache auch immer) namentlich systemweite Einsprungspunkte. Das kann für Applikationen ein einziger sein, für Libs entsprechend viele. Programme können andere Programme oder Libs anfordern.
    • Mit der Zeit sollten möglichst viele Treiber in Form solcher Libs für standardisierte reale Komponenten (z.B. Soundkarten, Graphikkarten, Netzwerkkarten, etc.) entstehen, die bei Bedarf nachgeladen und genutzt werden können.

    Vor allem aber sollte diese Architektur einfach sein und möglichst selten bis gar nicht geändert werden, damit Generationen daran ihren Spaß haben.

    Soweit ein erster Grundgedanke. Ich bin neugierig, was zurück kommt.

    Ich habe es mir 2-3x durchgelesen und bin nicht ganz sicher, ob ich verstehe, was Du meinst.


    Es klingt stellenweise nach einem Universellen Emulations-Computer, also so eine Art MIST, aber halt in einem Tastatur-Gehaeuse und ohne dass die Cores 100% getrennt sind, sondern dass es ein Grund-Betriebssystem gibt, von dem man aus z.B. ein Programm oder Spiel starten kann, und dieses sucht sich dann seine Chips/Architektur zurecht und bildet dann z.B. einen C64 nach um das C64-Spiel abzuspielen, und wenn man danach ein Spectrum-Spiel spielt, dann wird das System zum Spectrum usw...


    Auf der anderen Seite soll es aber ein lern- und experimentier-orientierter Computer sein. Da wuerde ich vermuten dass diese flexible Architektur mit vielen Grund-Chips die man waehlen kann schon wieder zu viel des guten ist, und die Awender es evtl. schwer haetten, sich zu fokussieren - oder sollen das eher so "Phantasie-Architekturen" sein, so wie bei "Pixel Vision 8", wo man sich quasi sein Zielsystem zusammenbauen kann indem man sagt, welche Aufloesung, welche Farblimitierungen usw man haben moechte?


    Unterm Strich glaube ich auch, dass heute einfach die Zeit zu "anders" ist, als dass man darin erfolgreich nochmal ein solches System plazieren koennte, weil es einfach zu viele Moeglichkeiten gibt, wie man das gestalten koennte und egal wie mans macht, es wird wieder dem ein oder anderen nicht gefallen. Vielleicht ist zurecht heute das Raspberry Pi noch am ehesten das Aequivalent zu den damaligen HomeComputern, zwar nicht vom Formfaktor her, aber mehr so vom "Spirit" her (ein Rechner zum Experimentieren und Lernen und tolle Sachen machen). Vielleicht moechtest Du es deshalb so flexibel halten, aber ich glaube dass das gleichzeitig auch wieder der Untergang des Projekts waere. Keine Ahnung.

    Quote from ZeHa

    Ich habe es mir 2-3x durchgelesen und bin nicht ganz sicher, ob ich verstehe, was Du meinst.

    Danke, das ist schon einmal sehr wertvolles Feedback. Ich habs sicher nicht optimal formuliert.

    Quote from ZeHa

    Es klingt stellenweise nach einem Universellen Emulations-Computer, also so eine Art MIST, aber halt in einem Tastatur-Gehaeuse und ohne dass die Cores 100% getrennt sind, sondern dass es ein Grund-Betriebssystem gibt, von dem man aus z.B. ein Programm oder Spiel starten kann, und dieses sucht sich dann seine Chips/Architektur zurecht und bildet dann z.B. einen C64 nach um das C64-Spiel abzuspielen, und wenn man danach ein Spectrum-Spiel spielt, dann wird das System zum Spectrum usw...

    Nein, das muss ich korrigieren. Es klingt streckenweise so. Ich bin davon ausgegangen, dass es sich um eine möglichst flexible Architektur handelt, wobei es einen "echten" Prozessor gibt (falls der emuliert wird, ist er natürlich auch nicht echt, aber auf dem soll das System laufen), und man die anderen dann emulieren kann, oder, wenn man will, tatsächlich dazu basteln (ein wenig wie der C128, mit einem zusätzlichen Z80A), wobei das aber alles optional sein soll. Das Basis-System sollte auf eine möglichst moderne HW zugeschnitten sein.

    Aber:Für den Fall, dass diese Architektur in "Ungnade" fällt, oder einfach nur den Bach der Geschichte runter geht, sollte man eine andere "echte" HW-Architektur wählen, die alte aber obligatorisch emulieren können, damit alles, was explizit dafür geschrieben worden ist, weiterhin laufen kann. Herbeiphantasiert: Heute schon kann man 6510 und Z80A etc. recht gut emulieren. In 30 Jahren wird man vielleicht die heutigen Prozessoren wunderbar in SW emulieren können. Wenn man (eine Möglichkeit) eine heutige CPU auswählt, kann man die irgendwann austauschen und nur mehr emulieren, bleibt damit aber auch auf Assembler-Ebene problemlos abwärts-kompatibel.

    Quote from ZeHa

    Auf der anderen Seite soll es aber ein lern- und experimentier-orientierter Computer sein. Da wuerde ich vermuten dass diese flexible Architektur mit vielen Grund-Chips die man waehlen kann schon wieder zu viel des guten ist, und die Awender es evtl. schwer haetten, sich zu fokussieren - oder sollen das eher so "Phantasie-Architekturen" sein, so wie bei "Pixel Vision 8", wo man sich quasi sein Zielsystem zusammenbauen kann indem man sagt, welche Aufloesung, welche Farblimitierungen usw man haben moechte?

    Ich würde für das Grundsystem eine bestimmte Architektur nehmen (und ich weiß nicht, welche. Das ist eine wichtige Überlegung), und ganz rudimentäre HW-Optionen voraussetzen. Von mir aus ein paar Graphikmodi, ein paar Sound-Möglichkeiten, die eh heute schon überall drin sind. Der Rest wäre dann Erweiterungssache (mit Treibern etc).

    Quote from ZeHa

    Unterm Strich glaube ich auch, dass heute einfach die Zeit zu "anders" ist, als dass man darin erfolgreich nochmal ein solches System plazieren koennte, weil es einfach zu viele Moeglichkeiten gibt, wie man das gestalten koennte und egal wie mans macht, es wird wieder dem ein oder anderen nicht gefallen. Vielleicht ist zurecht heute das Raspberry Pi noch am ehesten das Aequivalent zu den damaligen HomeComputern, zwar nicht vom Formfaktor her, aber mehr so vom "Spirit" her (ein Rechner zum Experimentieren und Lernen und tolle Sachen machen). Vielleicht moechtest Du es deshalb so flexibel halten, aber ich glaube dass das gleichzeitig auch wieder der Untergang des Projekts waere. Keine Ahnung.

    Der Pi ist schon ein recht gutes Beispiel, und er wäre vielleicht auch eine gute Basis für sowas, wenn man z.B. eine ARM-Architektur vorzieht. Oder auch, wenn man stattdessen eine virtuelle Maschine entwickelt, die dann überall laufen könnte, aber etwas langsamer wäre.

    Die Flexibilität habe ich nicht als Beliebigkeit gemeint, sondern schon als eindeutige Festlegung, die aber möglichst viele Optionen für Weiterentwicklungen bietet.

    Das ist das Problem der 8-bit-Generation. Die haben sich kaum weiter entwickeln können, weil das meiste an Software bis an die nackte HW heran gegangen ist und genau das und nichts anderes vorausgesetzt hat. Das sollte man von vorn herein vermeiden. Andererseits, wenn ich eine Maschine aufdrehe, und sofort mit einem freundlichen Prompt begrüßt werde, und loslegen kann - das gibts nicht mehr so oft.

    Ich frage mich oft: Wie klein könnte ein vernünftiges OS auf moderner HW werden? Ich denke, wenn meine System-Partitionen allesamt zweistellige Gigabytes brauchen, dann hats was. Das OS frisst mir dann schon so viel von der Leistung. Man stelle sich einen C64 mit 4 GHz und 8 GB RAM vor (und einem 32-64 bit Prozessor natürlich), aber mit dem bekannten Kernal und Basic, vielleicht etwas bequemer. Was hätte man damit alles gemacht? Hätte man den sofort mit einem riesigen OS zugekleistert, wie man das mit modernen Systemen tut? Oder hätten ein paar MB System auch gereicht? Das ist es, was mich fasziniert: Was kommt raus, wenn man ein überschaubar kleines OS mit vergleichsweise endloser, nach oben offener Leistungsfähigkeit paart?

    Das ist gewissermaßen das Gegenteil der Frage, ob man auf dem C64 ein modernes OS entwickeln kann.

    Hmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm...


    Ich sehe das halt so. Die Rechner damals waren so, weil nicht mehr ging. Vieles davon idealisieren wir heute, und einige Aspekte sind ja auch wirklich toll (z.B. das mit dem Sofort-Prompt). Heute geht viel mehr, und deshalb sind heutige Rechner eben anders. Oft wird geschumpfen dass die heutigen OSe viel zu viele Ressourcen brauchen, aber man muss ja auch bedenken, was die alles koennen und beinhalten (einen Haufen an Software und Treibern und Abstraction Layern usw.... und natuerlich Hintergrundbilder :D ). Der C64 und Konsorten wurden damals ja nicht so minimalistisch designt, weil sich das irgendwer ausgedacht hatte, sondern es entspricht halt alles den damaligen Gegebenheiten und Umstaenden.


    Damals war es auch generell spannend, ueberhaupt einen Rechner im Haus zu haben. Das war was neues. Und Computerspiele waren auch was neues. Und Programmieren auch. Heute gibt es Spiele in Massen und kostenlos, egal ob auf dem Handy, dem Tablet, im Fernseher, im Wecker, in der Mikrowelle (ok ich uebertreibe jetzt etwas), in der Smartwatch, und jeder der irgendwann das Programmieren beginnen moechte, ist bereits von Tag 0 an mit Technik aufgewachsen. Er wurde schon von den Eltern mit dem Handy fotografiert und gefilmt. Er wusste schon mit 2-3 Jahren, dass man Fotos mit dem Handy direkt an die Oma schicken kann und dass die sofort ihren Kommentar abgeben kann. Oder per Videochat mit einem reden kann, ueber ein Geraet das man in der Hand halten kann. Wenn derjenige nun im Alter von 10-15 Jahren dann mal programmieren lernen will, dann hat derjenige schon eine ganz andere Kindheit durchlebt als unsereiner, der in dem Alter ueberhaupt den Computer erst bekommen hat, und dessen Eltern keine Ahnung von dem Ding hatten.


    Diese aeusseren Umstaende gehoeren da halt alle auch dazu. Das "flexible System" das Du da beschreibst, IST eigentlich ein moderner Rechner mit einer Software-Umgebung a la PICO-8. Oder einem x-beliebigen Emulator. Klar koennte man sich da jetzt extra was ueberlegen, aber im Falle von PICO-8 ist das bereits geschehen. Da hat sich einer genau sowas ueberlegt und umgesetzt. Und das ist ein erfolgreiches kleines System, das aber doch wiederum nur in einer Nische Platz findet. Auch wenn heute einer ein Raspberry Pi kauft, um damit zu lernen (das war ja der eigentliche Sinn hinter dem Raspberry Pi - ein moderner Lern-Rechner zu sein, den sich jeder leisten kann), dann hat er bereits schon viele Vorerfahrungen mit zig anderen Geraeten und Systemen und hat eine voellig andere Herangehensweise und auch ganz andere Ideen, die er umsetzen will, als jemand der bis er 12 war nur Fussball im Garten gespielt hat und jetzt auf einmal einen Brotkasten zu Weihnachten bekommt.


    Ich glaube das wird alles viel zu selten durchdacht, wenn man drueber nachdenkt, einen "modernen 8-bit-Rechner" zu gestalten, der heute irgendwie etwas reissen soll. Ich schliesse es nicht aus, dass es nicht doch irgendwie machbar ist, aber ich glaube da muss man einen voellig anderen Ansatz finden, der PERFEKT in die heutige Zeit passt. Eigentlich darf das schon gar nicht mehr in irgendeiner Weise was mit "Retro" zu tun haben.


    Und noch was zum Prompt, der sofort da ist: Heute ist jedes Handy, jedes Tablet und auch die meisten Computer "sofort da", weil die dauerhaft an sind und man nur auf die Entsperr-Taste druecken muss. In den 90ern und 2000ern waren lange Boot-Zeiten bei PCs vielleicht noch etwas, was einen stoeren konnte im Vergleich zur guten alten Zeit, aber heute ist die Welt so anders, dass man eigentlich anerkennen muss, dass auch dieser Punkt heute wieder einer ganz anderen Situation unterlegen ist. (Und ja, ich weiss natuerlich dass es bei dem Prompt vor allem auch um die direkte Programmier-Moeglichkeit geht... aber ich wollte das als Beispiel nennen um zu zeigen, wie sehr wir inzwischen in einer anderen Welt leben - die nicht einfach nur "weiterentwickelt" ist, sondern eben wirklich ANDERS ist)

    Die Antwort klingt in meinen Ohren ziemlich plausibel. Sie bringt mich dann zur Frage, ob nicht alle diese Bemühungen hier auf diese Generation(en) beschränkt sind. Wird in 80 Jahren noch irgendwer sich die Mühe machen, 8-Bit-Rechner zu programmieren, zu restaurieren, zu konzipieren oder konstruieren?

    Das scheint mir die zentrale Frage zu sein. Wobei ich denke, dass es immer ein paar Enthusiasten nach dem Motto geben wird "verdammt, ich bin viel zu spät geboren, ich hätte die Zeit sooo gerne miterlebt". Vielleicht geht dann da doch noch was weiter. Aber wir, die wir mit der faszinierendsten Phase in den 70ern, 80ern, 90ern aufgewachsen sind, uns wirds nicht mehr geben.

    Wird die Faszination weiterleben? Und wenn ja, wie?

    Vielleicht (sehr wahrscheinlich sogar) hast du recht, dass es sinnlos ist, zu viel in die heutige Zeit mitnehmen zu wollen. Es gehört in die 80er (und umliegende Ortschaften), und was immer man für heute macht, wird wohl diesem Heute viel eher entsprechen müssen.

    Ich antworte am besten so: "Man wird doch wohl noch träumen dürfen?" Die Gefahr, dass ich das alles jetzt im Alleingang verwirklicht hätte, besteht ohnehin nicht. ;-)

    Quote from BlondMammuth

    Die Antwort klingt in meinen Ohren ziemlich plausibel. Sie bringt mich dann zur Frage, ob nicht alle diese Bemühungen hier auf diese Generation(en) beschränkt sind.

    Sind sie definitiv. Mit alter Technik von damals kann ich meine Kinder ab und zu mal begeistern. Aber nicht, weil sie so toll ist, sondern weil sie so alt ist. ^^

    Quote from BlondMammuth

    Vor allem aber sollte diese Architektur einfach sein

    Dies und

    Quote from BlondMammuth

    Diese Architektur soll nach oben offen sein. Sie kann verschiedene frühe Prozessor-Typen emulieren (oder beinhalten, wenn man das will). Sie darf (muss nicht) heute eine Mehrkern-64bit-Architektur zur Verfügung stellen, und beliebig großen Hauptspeicher aufweisen. Sie soll skalierbar sein, und sie soll keinen weiteren technischen Entwicklungen im Weg stehen. Man soll in hundert Jahren, basierend auf der dann aktuellen Technologie, ebenso ein Modell davon sinnvoll nutzen können wie heute.

    dies scheinen sich für mich zu widersprechen.


    Zunächst gibt es, sofern die Architektur nicht auf realer Hardware basiert, sondern auf Emulation, ein Problem mit der Geschwindigkeit. Zwar ließe sich mit einem PC auch ein komplexes System emulieren, doch wäre das emulierte System dann nicht mehr in der Lage, weitere ausgereifte Systeme exakt zu emulieren. Heute schon kann mein PC einen Amiga emulieren, dieser dann einen AppleII, und der wiederum eine 16-Bit-PCode-Maschine, aber dies funktioniert nur, weil die Komplexität des zu emulierenden Systems mit jeder Emulationsschicht drastisch abnimmt. Schon der AppleII wird dabei nur noch grob nachgebildet und kann in keinster Weise mit einer Emulation auf dem PC (wie z. B. AppleWin) mithalten. Bei schwierigeren Homecomputern wie dem C64 ist das noch deutlicher der Fall.

    Damit ist an sich die grundlegende Idee eines Basissystems, welches andere Prozessoren emuliert, zwar reizvoll, aber eher unrealistisch in der Umsetzung.

    Quote from BlondMammuth

    Hätte man den sofort mit einem riesigen OS zugekleistert, wie man das mit modernen Systemen tut? Oder hätten ein paar MB System auch gereicht?

    Schau Dir beispielsweise den Amiga an. Zunächst gab es 256 kb Rom, jedoch waren darin kein Basic-Interpreter oder ähnliches enthalten. Für die Workbench mußte sogar extra weiter von Diskette gebootet werden. Spätere Versionen des AmigaOS benötigten 512 kb Rom und wurden zusätzlich auf mehreren Disketten ausgeliefert, deren Inhalt man - falls vorhanden - auf einer Festplatte installieren konnte, weil der Benutzer sonst schnell zum Diskjockey wurde.

    Geh davon aus, daß, sobald eine 32-Bit-Architektur auftaucht, jemand versuchen wird, irgendein Linux (notfalls auch ohne MMU) darauf laufen zu lassen. Im Handumdrehen entsteht dadurch ein OS, welches von der Komplexität her sich an modernen Systeme orientiert, so daß die Unterschiede zunehmend verschwinden. Der Raspberry Pi ist so ein Fall. Gedacht war er als Lerncomputer, doch um ihn benutzen zu können, muß man zuerst das moderne Betriebssystem lernen geradeso wie beim PC. Wenn aber die Bedienung prinzipiell gleich ist und auch die gleichen Programmiersprachen erhältlich sind und das Ergebnis sich kaum vom PC unterscheidet... Wozu braucht man dann einen Pi? (Ja, man braucht ihn z. B. für Hardwarebasteleien, aber darum geht es hier nicht.)

    Das Feeling von damals[tm] war ja: Einschalten und loslegen. Aber darüber hinaus auch: Verstehen, was passiert. Wissen, wie der Prozessor funktioniert. Direkt auf die Hardware zugreifen ohne einen Haufen von Abstraktionslayern dazwischen. Heutige PCs mögen wieder schneller starten, so daß man nicht lange warten muß, bis die IDE bereit ist, aber wirklich verstehen, was da genau abläuft, dürfte kaum noch jemand.

    Wenn heute Jugendliche an der Schule "Programmieren" lernen ( z. B. Java über BlueJ), setzen sie nur noch 3d-Modelle aus vorgefertigten Einzelteilen (Kugeln, Klötzen etc) zusammen, geradeso wie Kinder im Kindergarten. Nach einem Schuljahr haben sie dann mal Begriffe gehört wie "Objekt" und "Methode" und "Konstruktor", aber keine Ahnung, was ein Zeiger ist oder ein Hauptprogramm oder ein Thread etc.

    Wenn es wirklich ein System zum Lernen und Experimentieren sein soll, dann bitte kein Mehrkernprozessor und Multiprocessing (Race condition!); es braucht m. M. n. auch keine 64-Bit-Architektur. sondern tatsächlich wäre sowas wie ein C64 ausreichend, vorausgesetzt, man verwendet entweder einen Crossassembler oder einen guten Crosscompiler und nicht Basic V2.0. Der Nachteil der alten Geräte ist nicht, daß sie schwer zu erlernen wären (sind sie nicht) oder das Erlernte unbrauchbar wäre (ist es nicht, denn es geht darum, Programmieren an sich zu lernen), sondern schlicht, daß die Grafik- und Soundmöglichkeiten in Zeiten von Handyspielen nur noch diejenigen interessieren, die auch tatsächlich motiviert sind, etwas zu lernen.

    Quote from BlondMammuth

    damit Generationen daran ihren Spaß haben.

    Das wage ich daher sehr zu bezweifeln. Die Ansprüche werden weiter wachsen (demnächst 3d-Brille oder Holodeck?), und da kein Programmieranfänger in der Lage sein wird, mit den Produkten auf dem Markt mitzuhalten, vielmehr der Abstand zwischen den Eigenkreationen und dem angebotenen Fremdmaterial immer größer wird, dürfte der Spaß der kommenden Generationen sich sehr in Grenzen halten.

    Quote from BlondMammuth

    Für den Fall, dass diese Architektur in "Ungnade" fällt, oder einfach nur den Bach der Geschichte runter geht, sollte man eine andere "echte" HW-Architektur wählen, die alte aber obligatorisch emulieren können, damit alles, was explizit dafür geschrieben worden ist, weiterhin laufen kann.

    Im Grunde genommen beschreibst Du damit den AppleMacintosh: Hat auf dem 68000 angefangen, dann kam der PowerPC, später der Intel und jetzt vielleicht der ARM. Möglich wäre sowas, sicherlich, aber es bedeutet auch, daß das neue System leistungsfähiger ist als das vorhergehende, und wo mehr Leistung ist, wird es Programme geben, die das Mehr an Leistung für sich verbrauchen mit aufwendigeren Bibliotheken usw.

    Quote from BlondMammuth

    Es gibt systemweit definierte Interfaces und Datenstrukturen (Typen), mittels denen Programme verschiedenster Art miteinander kommunizieren können (insbesondere z.B. Libs einer ganz anderen Bauart mitbenutzen).

    [..]

    Mit der Zeit sollten möglichst viele Treiber in Form solcher Libs für standardisierte reale Komponenten (z.B. Soundkarten, Graphikkarten, Netzwerkkarten, etc.) entstehen, die bei Bedarf nachgeladen und genutzt werden können.

    Irgendwie vermag ich den Unterschied zwischen dem neuen System und einem PC nicht zu erkennen. Beide bestehen aus einem Haufen Bibliotheken und Treibern, die von Dritten zur Verfügung gestellt werden und eine Schicht über Hardware und Co legen. Ich befürchte, wenn man über ein neues System nachdenkt, sollte man vielleicht besser von vornherein festlegen, wie das Programmieren auf dem System funktionieren soll: Bare metal oder über Layer. Persönlich stimme ich für bare metal, denn letzteres habe ich schon genug auf dem PC. Da fehlt mir einfach der Reiz.

    Quote from BlondMammuth

    Man stelle sich einen C64 mit 4 GHz und 8 GB RAM vor (und einem 32-64 bit Prozessor natürlich)

    Wo wäre das dann noch ein C64?

    Quote from BlondMammuth

    Wird die Faszination weiterleben? Und wenn ja, wie?

    Nein. Vielleicht gibt es in der Zukunft einen Museumstechniker, der in der Lage ist, alte Geräte fürs Museum zum Angucken aufzubereiten, aber die Faszination wird es nicht mehr geben. Versteht heute jemand den Inhalt von "Tommy" und weiß, was ein Flipper ist? Wieviele Leute sehnen sich zurück nach der "Jukebox" abgesehen von Peter Handke? "Zinnsoldaten" irgendjemand?

    Grundvoraussetzung für ein neues emuliertes System wäre auch wohl ein PC, doch in wievielen Haushalten wird in Zukunft überhaupt noch ein PC stehen? Wieviele Jugendliche können heutzutage noch einen PC bedienen oder in 10 Jahren? Stirbt der PC nicht auch schon aus und wird ersetzt durch das Smartphone? Es mag ja sein, daß Kinder und Jugendliche heute mit dem Smartphone aufwachsen und wissen, wie sie wischen müssen. Das heißt aber leider nicht, daß sie deswegen irgendwie Ahnung von Technik haben, geschweige denn von sowas wie "Programmieren". Von daher weiß ich auch nicht, an wen sich ein neues System richten soll. Programmiereinsteiger, die experimentieren wollen? Dafür gibt es den PC oder Pi. Bare Metal-Programmierer, die Spaß haben an direkter Auseinandersetzung mit der Hardware? Dafür ist es viel zu kompliziert.

    Quote from BlondMammuth

    und was immer man für heute macht, wird wohl diesem Heute viel eher entsprechen müssen.

    Was kaum möglich sein wird. Wie ZeHa schrieb:

    Quote from ZeHa

    [..] ich glaube da muss man einen voellig anderen Ansatz finden, der PERFEKT in die heutige Zeit passt. Eigentlich darf das schon gar nicht mehr in irgendeiner Weise was mit "Retro" zu tun haben.

    Diese Forderung läßt sich mit dem vorgeschlagenen System nur schwer vereinbaren. Dafür ist der Zugang bei modernen Geräten (Wischen, Sprache...) zu verschieden. Solche modernen Schnittstellen brauchen zudem enormen Rechenaufwand entweder auf dem Rechner selbst oder per Leitung zu einem Großrechner.


    Ich versuche mich mal an einem hinkenden Vergleich:

    Wenn man lernen möchte, was Musik ist, kann man

    a) ein Musikinstrument erlernen. Das ist die harte Tour, aber dabei kann man Musik wirklich durchdringen.

    b) Musik konsumieren. Mag Spaß machen, aber es ist unwahrscheinlich, daß das reine Hören von Musik vermitteln kann, aus was sich Musik zusammensetzt (Harmonie, Melodie, Polyphonie, Thema, Klangfarbe...)

    c) sich einen Beat an einem PC aus Bausteinen zusammenklicken, darüber rappen und allen erzählen, was für ein toller Kerl man ist, weil man einen eigenen Rapsong komponiert hat.

    Methode c) macht die Schule.

    Methode b) machen die Jugendlichen.

    Methode a) ist halt was für die wirklich Interessierten. Dabei ist es für den Anfang ziemlich egal, ob man eine Blockflöte nimmt, eine Gitarre, ein Klavier, Saxophon... Es muß gar nicht sofort ein Superkeyboard sein für mehrere tausend Euro mit 1001 Spezialeffekten und in bunt und in Farbe.

    Ja, 8 Bit sind genug. Okay, es dürfen auch ein wenig mehr sein. Also anstelle von Bontempi etwas von Yamaha. Oder so. Aber Musik muß man halt irgendwie spüren. Bare Metal. Und zuviel Brimborium lenkt davon nur ab.


    Lange Rede kurzer Sinn: Mir erscheint die Liste zu hochgegriffen und am Ziel vorbei. Daraus wird am Ende bestenfalls ein neuer PC, den keiner braucht. Aber das ist nur meine Meinung.

    Quote from M. J.

    dies scheinen sich für mich zu widersprechen.

    Tut es. War auch schlecht formuliert, und ich habs dann korrigiert.

    Quote from M. J.

    Schon der AppleII wird dabei nur noch grob nachgebildet und kann in keinster Weise mit einer Emulation auf dem PC (wie z. B. AppleWin) mithalten. Bei schwierigeren Homecomputern wie dem C64 ist das noch deutlicher der Fall.

    Er wird logisch korrekt abgebildet, aber das Zeitverhalten ist im Eimer. Das wäre aber zu beheben, wenn man von Anfang an Zeitverhalten über entsprechende Mechanismen regelt. Dann ist diese Architektur durchaus emulierbar ohne am Zeitverhalten zu kranken.

    update: Habe grade online gelernt, dass der Raspberry Pi keine Echtzeituhr hat (oder manche Modelle?). Ja, so relativiert sich mein Argumente recht schnell. :nene::roll2:

    Quote from M. J.

    Damit ist an sich die grundlegende Idee eines Basissystems, welches andere Prozessoren emuliert, zwar reizvoll, aber eher unrealistisch in der Umsetzung.

    Das ist wieder meiner fehlerhaften Formulierung geschuldet.

    Quote from M. J.

    Schau Dir beispielsweise den Amiga an. Z

    Gutes Beispiel. Beim Amiga gehört allerdings schon vieles zum OS, was ich gar nicht dazu zählen würde. Darum geht es mir ja gerade: Das Basis-System klein, und alles andere raus zu halten, es nämlich als ganz normale Software über definierte Schnittstellen zu akzeptieren.

    Quote from M. J.

    Geh davon aus, daß, sobald eine 32-Bit-Architektur auftaucht, jemand versuchen wird, irgendein Linux (notfalls auch ohne MMU) darauf laufen zu lassen. Im Handumdrehen entsteht dadurch ein OS, welches von der Komplexität her sich an modernen Systeme orientiert, so daß die Unterschiede zunehmend verschwinden.

    Wäre zu hoffen. Allerdings wird das eben niemals das Basis-System und den Zugang dazu zudecken können. Es kann seine eigenen Prozesse, seine eigenen Ressourcen in dem System haben, und somit wunderbar als Lernsystem dienen. Sogar, wenn man will, als Produktiv-System, wobei allerdings der Schutz nicht gegeben wäre, denn den sehe ich in dem Modell nicht vor. Das ist übrigens auch ein großer Unterschied zur derzeitigen Tendenz: Die Systeme werden immer weiter zugemauert, die User haben immer weniger Kontrolle drüber. Auch das wäre ein Motiv für so ein Konzept, diesen Trend total umzukehren. Ernsthafte Arbeiten kann man mit hinreichend geschützten Systemen durchführen. Das Ding wäre rekreativer Natur.

    Quote from M. J.

    Das Feeling von damals[tm] war ja: Einschalten und loslegen. Aber darüber hinaus auch: Verstehen, was passiert. Wissen, wie der Prozessor funktioniert. Direkt auf die Hardware zugreifen ohne einen Haufen von Abstraktionslayern dazwischen. Heutige PCs mögen wieder schneller starten, so daß man nicht lange warten muß, bis die IDE bereit ist, aber wirklich verstehen, was da genau abläuft, dürfte kaum noch jemand.

    Und das ist noch viel mehr eine Motivation für meine Idee. Gerade darum geht es mir ja, ein System von Anfang an so offen zu halten, dass man es eben doch verstehen kann, weil man von Anfang an viel tiefer drin sitzt.

    Quote from M. J.

    Nach einem Schuljahr haben sie dann mal Begriffe gehört wie "Objekt" und "Methode" und "Konstruktor", aber keine Ahnung, was ein Zeiger ist oder ein Hauptprogramm oder ein Thread etc.

    Als allgemeine Einführung mag das passen. Um wirklich das Handwerk und die Kunst zu erlernen, ist der Einstieg völlig daneben.

    Quote from M. J.

    Wenn es wirklich ein System zum Lernen und Experimentieren sein soll, dann bitte kein Mehrkernprozessor und Multiprocessing (Race condition!); es braucht m. M. n. auch keine 64-Bit-Architektur. sondern tatsächlich wäre sowas wie ein C64 ausreichend, vorausgesetzt, man verwendet entweder einen Crossassembler oder einen guten Crosscompiler und nicht Basic V2.0.

    Missverständnis: Es soll ein Multiprozessing-System sein, weil man damit viel leichter experimentieren kann. Irgendwas stürzt dir furchtbar ab. Du brauchst nicht ausschalten und ganz neu anfangen. Du kannst eventuell von "nebenan" debuggen. Mehrkernprozessoren? Weil das die sind, die man heute zu kaufen kriegt. Muss aber wirklich nicht sein, um was zu lernen. Warum mehr als ein C64? Weil das Ding ruhig sehr schnell sein darf, um Dinge zu ermöglichen, für die die alten Architekturen zu langsam gewesen sind. Action-Spiel in Basic programmieren? Warum nicht?

    Quote from M. J.

    Das wage ich daher sehr zu bezweifeln. Die Ansprüche werden weiter wachsen (demnächst 3d-Brille oder Holodeck?), und da kein Programmieranfänger in der Lage sein wird, mit den Produkten auf dem Markt mitzuhalten, vielmehr der Abstand zwischen den Eigenkreationen und dem angebotenen Fremdmaterial immer größer wird, dürfte der Spaß der kommenden Generationen sich sehr in Grenzen halten.

    Ich wage zu prognostizieren: Wenn man die nötigen Schnittstellen in Hi-Level-Sprache bereitstellt, geht auch das. Man braucht ja nicht extrabreite GPUs in Assembler ansteuern. Es reicht ja, wenn eine hinreichend leicht zu verstehende Graphik-Pipeline-Sprache vorhanden ist. Dann kann man damit genauso langsam zu lernen beginnen wie man es mit Basic-Programmen tut.

    Quote from M. J.

    Im Grunde genommen beschreibst Du damit den AppleMacintosh

    Im Grunde hat Apple das getan, was ich beschreibe, ja. ;-)

    Quote from M. J.

    Irgendwie vermag ich den Unterschied zwischen dem neuen System und einem PC nicht zu erkennen.

    Der Unterschied ist, dass du eine PC aufdrehst, und auf einem enormen OS-Berg mit vielen Schichten sitzt, und keine Ahnung mehr hast, was da wirklich passiert, aber so ein System aufdrehen würdest, und es relativ leicht durchschauen könntest (klare, einfache Schnittstellen vorausgesetzt, und die habe ich ja vorausgesetzt). Alles, was komplizierter wird, an SW, HW-Schittstellen, OS, etc., kann man dazu basteln. Man muss nicht. Es wird einem nicht aufgezwungen. Man kann das Ding wohl so konfigurieren, dass es am Anfang diese und jene Treiber lädt. Oder man kann seine Programme so konfigurieren, dass sie diese Treiber bei Bedarf nachladen. Man kann eine graphische Benutzeroberfläche laden. Vielleicht ein Holodeck-Interface. Aber man muss es nicht tun. Man kann mit dem Ding auf ganz primitiver Ebene arbeiten. Der Unterschied wäre der Ausgangspunkt.

    Quote from M. J.

    Grundvoraussetzung für ein neues emuliertes System wäre auch wohl ein PC, doch in wievielen Haushalten wird in Zukunft überhaupt noch ein PC stehen?

    Man könnte sowas genauso auf einem Smartphone laufen lassen, man könnte eigene HW dafür entwickeln, man könnte es auf einem Server in der Cloud laufen lassen .. das ist nebensächlich.

    Quote from M. J.

    Von daher weiß ich auch nicht, an wen sich ein neues System richten soll.

    An alle, denen sowas gefällt, und die daraus lernen und dazu beitragen möchten. Wieviele das dann wären, kann ich nicht sagen. Vielleicht hast du recht, und es wäre praktisch niemand. Weiß ich nicht.

    Quote from M. J.

    Programmiereinsteiger, die experimentieren wollen? Dafür gibt es den PC oder Pi. Bare Metal-Programmierer, die Spaß haben an direkter Auseinandersetzung mit der Hardware? Dafür ist es viel zu kompliziert.

    Was ist wofür zu kompliziert? Wäre es das? Wenn es ausdrücklich als Standard bloß ein ganz kleines OS enthält, mit den nötigsten Funktionen, im Sinne eines Homecomputers erster Generation?

    Quote from M. J.

    Diese Forderung läßt sich mit dem vorgeschlagenen System nur schwer vereinbaren.

    Ich habe ZeHa ihm damit eigentlich recht gegeben. Vermutlich wäre sowas gar nicht so begehrt, das wollte ich damit sagen.

    Quote from M. J.

    Aber das ist nur meine Meinung.

    Perfekt. Du hast mich so animiert, doch ein wenig weiter zu argumentieren, was ja Spaß macht. ;-)

    Ich sage es noch einmal: Ich vermute, dass ihr mit eurer Skepsis mit großer Wahrscheinlichkeit richtig liegt. Mir machts Spaß, die Sache abzuklopfen, auf die Gefahr hin, dass vielleicht doch was dran wäre. Je skeptischer die Argumente, desto mehr zwingt mich das, die Sache zu überdenken. Was besseres kann mir gar nicht passieren, als auf diese Weise dazuzulernen. :ilikeit::wilkommen::thanx:

    Quote from detlef
    Quote from BlondMammuth

    Die Antwort klingt in meinen Ohren ziemlich plausibel. Sie bringt mich dann zur Frage, ob nicht alle diese Bemühungen hier auf diese Generation(en) beschränkt sind.

    Sind sie definitiv. Mit alter Technik von damals kann ich meine Kinder ab und zu mal begeistern. Aber nicht, weil sie so toll ist, sondern weil sie so alt ist. ^^

    Vielleicht können deine Kinder irgendwann auch ihre Kinder dafür begeistern? Denn dann ist sie noch älter. :-)

    Quote from BlondMammuth

    Das wäre aber zu beheben, wenn man von Anfang an Zeitverhalten über entsprechende Mechanismen regelt. Dann ist diese Architektur durchaus emulierbar ohne am Zeitverhalten zu kranken.

    Tut mir leid, das habe ich leider nicht verstanden. ;( Könntest Du dafür bitte ein Beispiel geben?

    Quote from BlondMammuth

    Es soll ein Multiprozessing-System sein, weil man damit viel leichter experimentieren kann. Irgendwas stürzt dir furchtbar ab. Du brauchst nicht ausschalten und ganz neu anfangen. Du kannst eventuell von "nebenan" debuggen.

    Entwicklung läuft heutzutage auf dem PC, d. h. Texteditor und Compiler/Assembler befinden sich nicht auf der Zielmaschine. Von daher ist es völlig egal, wie oft die Kiste abschmiert. Natürlich könnte man, ausreichend Power vorausgesetzt, auch direkt auf der Zielmaschine programmieren, aaaaber... Wenn man ein System definiert, sollte man es tun ohne Software, denn darauf zu warten, bis $irgendwer mal einen Texteditor geschrieben haben wird für die Zielmaschine, der dann auch noch vergleichbar komfortabel ist wie der vom PC, heißt wahrscheinlich bis in alle Ewigkeit zu warten.

    Software, die es auf dem PC bereits ausreichend gibt, auf dem Zielsystem neu zu entwickeln, kann man machen, wenn das System an sich bereits fertig und vorhanden ist. Persönlich gehe ich jedoch davon aus, daß Programmierer sich lieber mit dem Schreiben von Spielen beschäftigen als mit Texteditoren etc, die sie ja schon auf dem PC haben.

    Zudem ist die Entwicklung auf dem PC mit Hilfe eines Emulators, der Programme beliebig unterbrechen und Speicherinhalte anzeigen kann, einfach unschlagbar. Von daher wäre ein Multiprozessing-System für mich keine Voraussetzung. Es würde viel mehr sowohl die Programmierung einer Emulation als auch eine Umsetzung in Hardware (FPGA) erschweren.

    Was nebenbei die Power anbelangt: Bei einer Emulation auf dem PC erreicht man je nach Komplexität des Zielsystems von der Leistung her ungefähr ein 32-Bitsystem mit ca. 30 Mhz (vgl. WinUAE mit 68020- oder 68030-Prozessor), sofern der PC nicht die ganze Zeit unter Vollast aufheulen soll. Da eine Emulation ein streng serieller Vorgang ist, nutzen einem hier leider mehr Kerne nicht. Auch bei einem (günstigen) FPGA kommt man eher an Taktgeschwindigkeiten von 12-25 Mhz heran. Man kann daher davon ausgehen, daß das Zielsystem wesentlich langsamer ist als ein PC und entsprechend jedes Programmiertool auch nur stark gebremst läuft. Hinzukommen dann noch kleinerer Speicher und ähnliches, so daß ich nicht davon ausgehen würde, daß jemand allein auf dem Zielsystem programmieren möchte.

    Quote from BlondMammuth

    Mehrkernprozessoren? Weil das die sind, die man heute zu kaufen kriegt.

    Da wäre dann wieder die Frage, auf welcher Prozessorbasis das System aufbauen soll. Ist es ein x86/x64? Den programmiere ich auch auf dem PC. Ist es ein ARM? Dafür hat man den Pi. Interessant wäre es für mich wohl nur dann, wenn es sich um einen neuen Prozessor handelt, den es in dieser Form noch nicht gab.


    Irgendwie widerspricht sich in meinen Augen dies

    Quote from BlondMammuth

    Gerade darum geht es mir ja, ein System von Anfang an so offen zu halten, dass man es eben doch verstehen kann, weil man von Anfang an viel tiefer drin sitzt.

    noch mit diesem

    Quote from BlondMammuth

    Das Basis-System klein, und alles andere raus zu halten, es nämlich als ganz normale Software über definierte Schnittstellen zu akzeptieren.

    Sobald man nämlich anfängt, Schnittstellen zu definieren, ist man als Entwickler in bezug auf Direktzugriff raus. Zwar denke/hoffe ich, daß ich verstanden habe, was Du meinst, aber in der Praxis sehe ich da Probleme. Das Ausbalancieren des Verhältnisses zwischen Direktzugriff und Schnittstelle/Abstraktionsschicht entspricht einer Gratwanderung, bei der man leicht auf die eine oder andere Seite abstürzen kann.


    Folgendes Beispiel:

    Das System stellt über IO-Adressen (memory-mapped IO) ankommende Tasten zur Verfügung. Wie der Tastendruck zustandekommt und an das Zielsystem weitergeleitet wird, ist Sache der Peripherie, nicht des Systems an sich. Das bedeutet z. B. daß eine USB-Tastatur angeschlossen werden kann, wenn in der externen Peripherie ein Mikrocontroller mit der USB-Tastatur kommuniziert und das nackte Ergebnis als definierten Code an das Zielsystem weiterreicht. Anders gesagt: Ein Programm auf der Zielmaschine kann nicht erkennen, ob die Taste von einer USB-Tastatur oder einer PS/2-Tastatur oder von sonstwoher kommt.

    Die Abstraktionsschicht findet in diesem Falle nicht in Software statt, sondern bereits auf Hardwareebene. Ein USB-Treiber (für die Tastatur) ist dadurch nicht Teil des Zielsystems oder des OS. Weder ein Treiber, noch sonst irgendeine Bibliothek muß geladen werden, um einen Tastendruck in Empfang zu nehmen. Vorteil: Solch eine Verlagerung der Schicht auf die Hardwareebene ist für viele erträglicher als das Einfügen eines Softwarelayers, da Hardware eher als gegeben angenommen wird.


    Schwieriger wird es bei Datenträgern, da diese sich nicht so leicht auf Hardwareebene umsetzen lassen, sei es aufgrund der Dateiverwaltung oder aufgrund der Hardware. Wie soll man damit umgehen? Soll im Zielsystem ein FAT32-Treiber vorhanden sein? Oder NTFS? Oder irgendwas Linuxiges? Wie wird die Hardware des Datenträgers angesprochen? Muß jetzt ein Treiber bestimmen, welcher Kopf, Track, Sektor benutzt werden soll?

    Prinzipiell gäbe es zwei Möglichkeiten:

    1.) Man macht es wie beim C64 und setzt auf "intelligente" Peripherie, d. h. es werden Kommandos an den Datenträger geschickt wie z. B. "Dateiladen" oder "Dateispeichern" zusammen mit den Daten. Was dann passiert mit welchem Dateisystem, ist allein Sache der Peripherie. Vorteil: Funktioniert wahrscheinlich mit vielen Datenträgern. Nachteil: Setzt für jedes Gerät einen eigenen Mikrocontroller voraus, der die Befehle umsetzen kann. Außerdem lassen sich so nur bestehende Dateisysteme verwenden, aber keine eigenen erzeugen. Das Experimentieren wird hier sehr stark eingeschränkt.

    2.) Man macht es wie beim AppleII mit ProDos: Der Datenträger wird in kleine Einheiten aufgeteilt (bei ProDos Häppchen von jeweils 512 Bytes), die man z. B. "Block" nennen kann. Ein Datenträger hat zunächst kein Dateisystem, sondern besteht nur aus einer Anzahl von Blöcken. Eine kleine Routine im Rom sorgt dafür, daß ein Block gelesen oder geschrieben werden kann. Außerdem enthält das Rom ein Miniprogramm, welches auf dem Datenträger nach einem Bootprogramm sucht, dieses lädt und startet. Der Abstraktionslevel bestände dann allein in der Schnittstelle zum Laden/Speichern eines Blocks. Ein Programm weiß damit nicht mehr, wie die Hardware an sich angesteuert wird, ist aber noch so lowlevel dabei, daß es z. B. ein eigenes Dateisystem auf dem Datenträger anlegen kann. Vorteil: Sehr flexibel. Ein Bootprogramm könnte z. B. einen Treiber für FAT32 laden, sofern der Datenträger ein FAT32-System enthält. Es könnte aber auch einfach nur ein Spiel laden, welches sich direkt in den Blöcken auf der Diskette befindet (so wie bei früheren Homecomputern üblich). Nachteil: Man braucht auf dem PC spezielle Tools, um Daten auszutauschen (z. B. wenn der Datenträger als Imagedatei vorliegt).

    Persönlich gefällt mir Methode 2) besser, weil sie dem entspricht, was ich damals[tm] am AppleII oder Amiga gemacht habe, aber es beißt sich wahrscheinlich mit dem Wunsch von Leuten, möglichst einfach auf den Datenträger zugreifen zu können.

    Quote from BlondMammuth

    Wenn es ausdrücklich als Standard bloß ein ganz kleines OS enthält, mit den nötigsten Funktionen, im Sinne eines Homecomputers erster Generation?

    Homecomputer erster Generation hatten gar kein OS.^^ Der Kernal des C64 ist genau nur das: ein Kerna(e)l. Auch der AppleII hatte nur einen Monitor, Basic und ein paar Ein-/Ausgaberoutinen im Rom. Das DOS mußte erst von Diskette nachgeladen werden. Welch Wunder, es reichte immerhin von $9600..$bfff und war damit schon ziemlich groß für ein Rom. Erst Homecomputer der zweiten Generation (Amiga, AtariST) hatten ein richtiges OS, aber damit fingen sie auch schon an, die Hardware vor dem Programmierer unter Schichten zu verbergen.

    Quote from BlondMammuth

    Der Unterschied ist, dass du eine PC aufdrehst, und auf einem enormen OS-Berg mit vielen Schichten sitzt, und keine Ahnung mehr hast, was da wirklich passiert, aber so ein System aufdrehen würdest, und es relativ leicht durchschauen könntest (klare, einfache Schnittstellen vorausgesetzt, und die habe ich ja vorausgesetzt). Alles, was komplizierter wird, an SW, HW-Schittstellen, OS, etc., kann man dazu basteln. Man muss nicht. Es wird einem nicht aufgezwungen. Man kann das Ding wohl so konfigurieren, dass es am Anfang diese und jene Treiber lädt. Oder man kann seine Programme so konfigurieren, dass sie diese Treiber bei Bedarf nachladen. Man kann eine graphische Benutzeroberfläche laden. Vielleicht ein Holodeck-Interface. Aber man muss es nicht tun. Man kann mit dem Ding auf ganz primitiver Ebene arbeiten. Der Unterschied wäre der Ausgangspunkt.

    Hmmm.... Ich versuche mal, das Ganze irgendwie so zusammenzustellen, daß daraus ein einigermaßen realistisches Bild wird. Wie wäre folgender Vorschlag:

    1.) 32 Bit-Prozessor mit leicht zu erlernenden Befehlen in der Geschwindigkeit schätzungsweise eines 68000. 16 Bit wären ebenso möglich, jedoch haben 32 Bit den Vorteil, daß man auf größeren Speicher direkt zugreifen kann.

    2.) 512 kb Ram. Klingt wenig im Vergleich zu heute, ist aber das, was damals[tm] der Amiga500 hatte. Ein Spiel, das diese 512 kb vollständig ausnützt, muß man erst einmal schreiben. Schließlich gibt es auch noch:

    3.) Datenträger mit bis zu 32 GB Speicher. Angesprochen wird er wie oben beschrieben blockweise. Beim Einschalten sucht eine Romroutine nach einem Bootprogramm und lädt es. Da das Nachladen heutzutage ungleich schneller ist als damals[tm], kann also ein Spiel viele Daten auf dem Datenträger auslagern und muß nicht alles auf einmal in den Speicher bringen. 512 kb sind wirklich Arbeitsspeicher.

    4.) Grafische Auflösung bis zu 320x200x16 oder 640x200x4. Zu wenig? Kommt darauf an. Je größer die Auflösung, je schwieriger auch dafür das Malen der Grafik. Wenn es ein Experimentierrechner sein soll, sollte man sich besser mit Superhardwaremöglichkeiten zurückhalten. Computer wie der C64 sind auch deswegen so beliebt, well sie keine übernatürlichen Fähigkeiten vom Durchschnittsprogrammierer verlangen. Schraubt man die Hardware zu hoch, setzt man quasi auch immer voraus, daß sie voll ausgenutzt wird, doch diesen Anspruch kann eine Einzelperson überhaupt nicht erfüllen. Zu gute Hardware verhindert ein Erfolgserlebnis, weil es immer heißen wird: Ja, ganz nett, könnte aber besser sein.

    Ach ja: Nur Bitmap, kein Zeichensatz.

    5.) Was für die Grafik gilt, gilt natürlich auch für den Sound. Ein einfacher mehrstimmiger Synthesizer wie beim C64 und Co. Mehr braucht es nicht.


    Wäre so ein System für Dich denkbar? Oder wäre es Dir nicht leistungsfähig genug? Wenn mehr Power, dann was und wofür genau?

    Quote from BlondMammuth
    Quote from detlef
    Quote from BlondMammuth

    Die Antwort klingt in meinen Ohren ziemlich plausibel. Sie bringt mich dann zur Frage, ob nicht alle diese Bemühungen hier auf diese Generation(en) beschränkt sind.

    Sind sie definitiv. Mit alter Technik von damals kann ich meine Kinder ab und zu mal begeistern. Aber nicht, weil sie so toll ist, sondern weil sie so alt ist. ^^

    Vielleicht können deine Kinder irgendwann auch ihre Kinder dafür begeistern? Denn dann ist sie noch älter. :-)

    Die werden dann wohl eher ihre Kinder von der Technik ihrer Jugend begeistern - Smartphones mit nur 2 GB Arbeitsspeicher. :D

    Quote from ZeHa

    Ich sehe das halt so. Die Rechner damals waren so, weil nicht mehr ging. Vieles davon idealisieren wir heute, und einige Aspekte sind ja auch wirklich toll (z.B. das mit dem Sofort-Prompt). Heute geht viel mehr, und deshalb sind heutige Rechner eben anders. Oft wird geschumpfen dass die heutigen OSe viel zu viele Ressourcen brauchen, aber man muss ja auch bedenken, was die alles koennen und beinhalten (einen Haufen an Software und Treibern und Abstraction Layern usw.... und natuerlich Hintergrundbilder :D ). Der C64 und Konsorten wurden damals ja nicht so minimalistisch designt, weil sich das irgendwer ausgedacht hatte, sondern es entspricht halt alles den damaligen Gegebenheiten und Umstaenden.

    Das ist sehr gut auf den Punkt gebracht. Ich bin froh keine Heimcomputer aus den 80er und 90er mehr nutzen zu müssen. Ich lebe computertechnisch in der Zukunft, die ich mir hätte besser nicht vorstellen können. Ich brauche mir keine Kommandobefehle mehr merken, habe keine große Limitierung der Auflösung, Farben, Soundmöglichkeiten und kann den Computer samt Bildschirm einfach mit auf die Couch nehmen und gemütlich vor mich hincomputern, oder Filme gucken, recherchieren, an was arbeiten, tolle 3D Sachen machen, oder sonst was alles. Und das mit einem Gerät was 500,-EUR kostet. Dafür hätte ich früher getötet.


    Die Beschäftigung mit der Technik von damals macht mir ja erst Spaß seit dem ich übers Internet so viele Infos darüber bekomme und vor allem muss ich zum Programmieren nicht den C64 selbst nutzen und mir irgendwelche Shortcuts merken und in jedem Programm ist dann Cut and Paste anders gelöst usw. ist doch schrecklich von der Bedienung her. War schon damals so, dass wenn man einen PC zum Entwickeln nutzen konnte für C64 oder Amiga so hat man das getan. Warum auch nicht? Man nimmt das System was einem die meiste Arbeit abnimmt. Ein Computer ist ein Werkzeug und da nutzt man das beste was man sich leisten kann.


    Um das Nostalgiegefühl zu bekomme tippt man natürlich auf Originalhardware rum und legt mal eine Floppy ein. Aber um Himmels Willen: Ich würde nie auf die Idee kommen auf einem Homecomputer surfen zu wollen oder darauf wirklich zu arbeiten. Es sei denn als Machbarkeitsstudie oder so was.


    Wer heute einen Computer haben will, der gleich in einer Programmiersprache bootet, der kann das per Autostart lösen, oder sich ein Linux booten auf einem RaspPi was gleich in eine Python Shell oder so hoch fährt. Das blöde an solchen Sachen ist, dass man dann wieder einen zweiten Computer braucht, um zu recherchieren warum mein Programm nicht läuft, wie die Libs funktionieren oder die Syntax ist usw. Also kann ich die Sache gleich auf dem Computer machen, der eh immer an ist.


    Warum also zwei Computer?


    Für mich macht ein echter Homecomputer nur Sinn um damit Sachen zu testen, die eventuell noch nicht 100% im Emulator laufen oder falls ich mal Hardware für den Computer basteln möchte, oder weil ich mal wieder ein Spiel von Kassette starten möchte. Aber das trifft alles nur auf die Heimcomputer zu, die ich aus meiner Jugend kenne.


    Die Beschäftigung mit Heimcomputer hat mir zudem gezeigt wie weit wir gekommen sind in Punkto: Softwareentwicklung, Programmiersprachen, Sound- und Grafikprogramme, Office, Vernetzung, Benutzerführung, Treiber, Speicher, CPUs, GPUs usw.


    Das ist wie wenn man merkt, dass das Zuhause doch ganz toll ist. Diese Erkenntnis kommt einen erst dann wenn man sein Zuhause verlassen hat. So ist das bei mir mit anderen Computer oder auch Betriebssystemen. Hinterher weiß man wieder das gewohnte zu schätzen.

    Quote from M. J.

    Tut mir leid, das habe ich leider nicht verstanden. ;( Könntest Du dafür bitte ein Beispiel geben?

    Ich habe damit eher gemeint, dass man bei modernerer HW das Zeitverhalten eher über Timer steuern wird, als sich auf die Geschwindigkeit der HW zu verlassen. Wenn man das tut, wird es sich im Grunde nie ändern. Einem Video, das ich mir anschaue, oder einer graphischen Animation, wird es heute völlig egal sein, wie schnell der Prozessor läuft, oder wie leistungsfähig die GPU ist. Das Ding wird immer mit derselben Geschwindigkeit ablaufen. Setzt man hinreichend moderne HW voraus, erhält man diesen Effekt, dass sich an gewolltem Zeitverhalten nichts mehr ändert. Bei den 8-Bittern war das defintiiv anders, drum ist es dort so wichtig, das Zeitverhalten exakt zu emulieren.

    Quote from M. J.

    Entwicklung läuft heutzutage auf dem PC, d. h. Texteditor und Compiler/Assembler befinden sich nicht auf der Zielmaschine.

    Ich habe das immer als eine Notlösung gesehen, weil die alten Maschinen das nicht konnten. Aber vielleicht irre ich mich da.

    Quote from M. J.

    aaaaber... Wenn man ein System definiert, sollte man es tun ohne Software, denn darauf zu warten, bis $irgendwer mal einen Texteditor geschrieben haben wird für die Zielmaschine, der dann auch noch vergleichbar komfortabel ist wie der vom PC, heißt wahrscheinlich bis in alle Ewigkeit zu warten.

    OK, die Regel habe ich nicht beachtet. ;-) Nein ernsthaft, ich habe das Wort "Architektur" durchaus im OS-Sinn auch gemeint. Die Abstraktionsschichten sollten schon definiert sein. Klein, simpel, aber doch vorhanden und vorausgesetzt.

    Quote from M. J.

    Entwicklung läuft heutzutage auf dem PC, d. h. Texteditor und Compiler/Assembler befinden sich nicht auf der Zielmaschine. Von daher ist es völlig egal, wie oft die Kiste abschmiert. Natürlich könnte man, ausreichend Power vorausgesetzt, auch direkt auf der Zielmaschine programmieren, aaaaber... Wenn man ein System definiert, sollte man es tun ohne Software, denn darauf zu warten, bis $irgendwer mal einen Texteditor geschrieben haben wird für die Zielmaschine, der dann auch noch vergleichbar komfortabel ist wie der vom PC, heißt wahrscheinlich bis in alle Ewigkeit zu warten.

    Guter Punkt, danke! Ja, natürlich müsste man einfache Editoren und Interpreter/Compiler voraussetzen. Bis zu einem gewissen grad ist es natürlich Bootstrapping. Meine Idee wäre eher, dass man zu dem Punkt kommt, ab dem man alles on board machen kann. Zugegeben aber - wie viel das sein muss, damit man cross development nicht mehr bevorzugt, das ist eine andere Frage.

    Quote from M. J.

    Zudem ist die Entwicklung auf dem PC mit Hilfe eines Emulators, der Programme beliebig unterbrechen und Speicherinhalte anzeigen kann, einfach unschlagbar. Von daher wäre ein Multiprozessing-System für mich keine Voraussetzung. Es würde viel mehr sowohl die Programmierung einer Emulation als auch eine Umsetzung in Hardware (FPGA) erschweren.

    Was nebenbei die Power anbelangt: Bei einer Emulation auf dem PC erreicht man je nach Komplexität des Zielsystems von der Leistung her ungefähr ein 32-Bitsystem mit ca. 30 Mhz (vgl. WinUAE mit 68020- oder 68030-Prozessor), sofern der PC nicht die ganze Zeit unter Vollast aufheulen soll. Da eine Emulation ein streng serieller Vorgang ist, nutzen einem hier leider mehr Kerne nicht. Auch bei einem (günstigen) FPGA kommt man eher an Taktgeschwindigkeiten von 12-25 Mhz heran. Man kann daher davon ausgehen, daß das Zielsystem wesentlich langsamer ist als ein PC und entsprechend jedes Programmiertool auch nur stark gebremst läuft. Hinzukommen dann noch kleinerer Speicher und ähnliches, so daß ich nicht davon ausgehen würde, daß jemand allein auf dem Zielsystem programmieren möchte.

    Multi-Processing würde ich auch nicht deshalb voraussetzen. Eher, weils interessant sein könnte, das zu haben, oder weil man dann CPUs nehmen kann, die man am Markt kriegt. Das von dir geschilderte Szenario ist faszinierend, aber es ist einfach ein anderes als das, was ich mir hier ausgedacht habe.

    Quote from M. J.

    Da wäre dann wieder die Frage, auf welcher Prozessorbasis das System aufbauen soll. Ist es ein x86/x64? Den programmiere ich auch auf dem PC. Ist es ein ARM? Dafür hat man den Pi. Interessant wäre es für mich wohl nur dann, wenn es sich um einen neuen Prozessor handelt, den es in dieser Form noch nicht gab.

    Ja, das ist dann schlicht und einfach ein Unterschied in der Interessenslage. Mich fasziniert die Frage viel mehr, wie man sowas von der SW-Architektur aufbauen könnte, existierende HW (CPU) vorausgesetzt. Ist einfach ein anderer Blickwinkel. Und es zeigt, dass es nicht den einen Blickwinkel auf das Thema Home Computer gibt. Es gibt so viele verschiedene: "es muss diese Hardware sein, was kann ich rausholen, damit es möglichst modern aussieht" und "es kann irgendeine Hardware sein, solange das Feeling ist wie damals" und "wie würde ich so ein System von Grund auf aufbauen" und sicher einiges mehr.

    Quote from M. J.

    Schwieriger wird es bei Datenträgern, da diese sich nicht so leicht auf Hardwareebene umsetzen lassen, sei es aufgrund der Dateiverwaltung oder aufgrund der Hardware.

    Stimmt. Grade an der Stelle bräuchte es bereits eine leistungsfähige Abstraktions-Schicht.

    Quote from M. J.

    Persönlich gefällt mir Methode 2) besser, weil sie dem entspricht, was ich damals[tm] am AppleII oder Amiga gemacht habe, aber es beißt sich wahrscheinlich mit dem Wunsch von Leuten, möglichst einfach auf den Datenträger zugreifen zu können.

    Ich würde sagen, man kann auch Methode 2) in eine Abstraktionsschicht einwickeln, und Methode 1) dann sichtbar drauf aufbauen.

    Quote from M. J.

    Homecomputer erster Generation hatten gar kein OS. ^^

    Oder sagen wir, man muss den Begriff ein wenig dehnen und quetschen, um das, was die Maschinen im Rom hatten, so zu bezeichnen. :LOL

    Quote from M. J.

    Zu gute Hardware verhindert ein Erfolgserlebnis, weil es immer heißen wird: Ja, ganz nett, könnte aber besser sein.

    Der Aspekt ist mir neu, gebe ich zu. Ich bin auch nicht sicher, ob es so ist. Eigentlich kann man aus jeder Hardware immer noch mehr rausholen, und insbesondere, wenn man ein Anfänger ist. Auf der anderen Seite bieten "modernere" Systeme meistens auch die Abstraktionsebenen, auf denen manches viel leichter wird, oder sollten es wenigstens. Ich kann auf einem PC Sachen recht schnell programmieren, für die ich auf dem C64 elendiglich lang brauchen würde. Z.B. Parser, Transformatoren. Die sind z.B. in Prolog extrem schnell zu implementieren, mit LEX/YACC dauerts länger, aber immer noch wesentlich schneller als auf dem C64 in Basic oder Assembler (wobei, nebenbei, sowohl Prolog als auch LEX und YACC schon auf PDP-11 gelaufen sind, was bedeuten würde, dass sie auch auf deinem Vorschlag wunderbar laufen könnten).

    Natürlich wärs das, und ich hab riesigen Respekt vor allen, die sowas zuwege bringen. Es wäre faszinierend und ein Riesen-Spaß.


    Es wäre aber das genau gegenteilige Konzept (und als solches hoffe, ich dass es erfolgreich wäre!), insofern:

    - ein kleines System, das die Leistung der Programmierer umso mehr unterstreicht, weil sie das letzte rausholen.

    - ein starkes System, das es einfach macht, mit geringem Aufwand recht gute Ergebnisse zu erzielen.


    Ich habe mir bloß gedacht: Diese zweite Idee fehlt noch in dem Konzert der Konzepte, (bzw. ist mir so noch nicht untergekommen), nämlich das 8-bit-Homecomputer-Feeling auf einer modernen CPU. Mal schauen, welches Echo sie bringt (das weiß ich inzwischen *g*). Ich spiele einfach nur gerne mit Gedanken. Wie schnell wären Basic-Programme auf einem Basic-Interpreter auf fast nackter, moderner Hardware? Das war so einer meiner Grundgedanken. "Supercomputer" im Einsatz um faule Programmierer doch noch mit passablen Ergebnissen zu belohnen. :wurm::xlol: Den Gedanken muss man nicht mögen. Ich verstehe glaub ich sogar alle, die ihn nicht mögen. :bmotz:ROTFL


    (Zum 32-Bitter: Wäre so ein Konzept nicht auch geeignet, um ab einem bestimmten Punkt on board drauf entwickeln zu können? Bei 512 KB RAM lässt sich schon einiges an Entwicklungs-Tools unterbringen, und der Speicher wäre ja erweiterbar auch noch.)

    Nochmal zum Thema "Lerncomputer", ich glaube halt auch dass die meisten, die heute was programmieren wollen, das auch fuer ein Geraet tun wollen, das sie bereits besitzen. Auch Kinder vermutlich. Das heisst, wer heute programmieren moechte, der moechte dass es auf dem Handy laeuft, oder dem Tablet, oder dem PC. Aber viele werden wahrscheinlich den Sinn darin nicht verstehen, warum sie einen Extra-Rechner kaufen sollten, auf dem sie dann etwas programmieren koennen, was dann aber auch wiederum NUR auf diesem Rechner laeuft. Das wirkt dann halt wirklich wie so ein "Lern-Ding" und sowas ist ja eh schon unattraktiv, man will ja eigentlich schon immer "was gescheites" ;)

    Diese Beobachtung kommt mir extrem bekannt vor. :D


    Das führt schon wieder direkt zur Frage, wozu die Beschäftigung mit den alten Kisten? Ich glaube: Weil sie da sind. Weil sie uns faszinieren. Weil sie es wert sind, als Monumente der Entwicklung ihrer Zeit. Oder noch direkter:

    Weils uns Spaß macht. :thumbsup:

    Quote from ZeHa

    Nochmal zum Thema "Lerncomputer", ich glaube halt auch dass die meisten, die heute was programmieren wollen, das auch fuer ein Geraet tun wollen, das sie bereits besitzen. Auch Kinder vermutlich. Das heisst, wer heute programmieren moechte, der moechte dass es auf dem Handy laeuft, oder dem Tablet, oder dem PC. Aber viele werden wahrscheinlich den Sinn darin nicht verstehen, warum sie einen Extra-Rechner kaufen sollten, auf dem sie dann etwas programmieren koennen, was dann aber auch wiederum NUR auf diesem Rechner laeuft. Das wirkt dann halt wirklich wie so ein "Lern-Ding" und sowas ist ja eh schon unattraktiv, man will ja eigentlich schon immer "was gescheites" ;)

    Das spricht wieder sehr für Emulationen, wenn man schon ein System neu designen will, oder? Ich bin ohnehin ein Fan der Virtualisierung. Ich hätte auch den Platz nicht, um auf alten physikalischen Geräten zu arbeiten.

    OK, aber spricht es überhaupt für die Entwicklung solcher Systeme, ob emuliert oder physikalisch? Gute Frage. Wenn man so anfängt, kann man es lassen. Man soll die Dinge tun, weil sie Spaß machen, das ist der Hauptzweck. Ob die nachfolgenden Generationen altmodische Systeme interessant finden werden oder nicht - wer kann das schon voraussagen?

    Quote from tilobyte

    Ich verstehe es leider nicht, was genau du im ersten Beitrag beschreibst und dir vorstellst. Was ist der Vorteil zu den vorhandenen Lösungen Emulator und FPGA?

    Es ist ein ganz anderes Konzept. Falls ich je den Eindruck erweckt habe, ich wollte irgendein existierendes Konzept kritisieren, tuts mir leid. Das war überhaupt nicht meine Absicht, im Gegenteil: Ich habe größten Respekt vor solchen Projekten. Es ist einfach eine andere Idee: Quasi eine 8-bit-like Umgebung auf moderner 64-bit Hardware quasi nach zu bilden, vom Look and Feel (aber nicht von der Hardware). Ich habe einiges an Ideen gesehen, wie man moderne OS-Konzepte (GUIs z.B.) auf dem C64 verwirklichen könnte. Ich habe das genaue Gegenteil vorgeschlagen: Wie wärs, eine Umgebung wie die damalige: Einschalten, Basic programmieren .. auf moderner Hardware zu verwirklichen, wobei man manche Vorteile der modernen HW auch nutzt?

    Wunderbar, so kompakt hab ich es noch nie formuliert. :ChPeace

    Quote from BlondMammuth
    Quote from tilobyte

    Ich verstehe es leider nicht, was genau du im ersten Beitrag beschreibst und dir vorstellst. Was ist der Vorteil zu den vorhandenen Lösungen Emulator und FPGA?

    Es ist ein ganz anderes Konzept. Falls ich je den Eindruck erweckt habe, ich wollte irgendein existierendes Konzept kritisieren, tuts mir leid. Das war überhaupt nicht meine Absicht, im Gegenteil: Ich habe größten Respekt vor solchen Projekten. Es ist einfach eine andere Idee: Quasi eine 8-bit-like Umgebung auf moderner 64-bit Hardware quasi nach zu bilden, vom Look and Feel (aber nicht von der Hardware). Ich habe einiges an Ideen gesehen, wie man moderne OS-Konzepte (GUIs z.B.) auf dem C64 verwirklichen könnte. Ich habe das genaue Gegenteil vorgeschlagen: Wie wärs, eine Umgebung wie die damalige: Einschalten, Basic programmieren .. auf moderner Hardware zu verwirklichen, wobei man manche Vorteile der modernen HW auch nutzt?

    Wunderbar, so kompakt hab ich es noch nie formuliert. :ChPeace

    Dann gebe ich Dir ebenso kompakt eine Antwort: Es gibt bereits PICO-8 (und sehr viele aehnliche Klone, wie PixelVision8, TIC-80, etc) ;)

    Quote from ZeHa
    Quote from BlondMammuth
    Quote from tilobyte

    Ich verstehe es leider nicht, was genau du im ersten Beitrag beschreibst und dir vorstellst. Was ist der Vorteil zu den vorhandenen Lösungen Emulator und FPGA?

    Es ist ein ganz anderes Konzept. Falls ich je den Eindruck erweckt habe, ich wollte irgendein existierendes Konzept kritisieren, tuts mir leid. Das war überhaupt nicht meine Absicht, im Gegenteil: Ich habe größten Respekt vor solchen Projekten. Es ist einfach eine andere Idee: Quasi eine 8-bit-like Umgebung auf moderner 64-bit Hardware quasi nach zu bilden, vom Look and Feel (aber nicht von der Hardware). Ich habe einiges an Ideen gesehen, wie man moderne OS-Konzepte (GUIs z.B.) auf dem C64 verwirklichen könnte. Ich habe das genaue Gegenteil vorgeschlagen: Wie wärs, eine Umgebung wie die damalige: Einschalten, Basic programmieren .. auf moderner Hardware zu verwirklichen, wobei man manche Vorteile der modernen HW auch nutzt?

    Wunderbar, so kompakt hab ich es noch nie formuliert. :ChPeace

    Dann gebe ich Dir ebenso kompakt eine Antwort: Es gibt bereits PICO-8 (und sehr viele aehnliche Klone, wie PixelVision8, TIC-80, etc) ;)

    Habe ich noch nicht gekannt. Vielen Dank für die Info, muss ich mir gleich genauer anschauen!

    Update: OK; angeschaut.


    "The Pico-8 (stylized as PICO-8) is a virtual machine and game engine created by Lexaloffle Games. It is designed to mimic a "fantasy video game console,"[1] by emulating the harsh hardware limitations of the video game consoles around the 1980s."


    Gut, genau die "harsh hardware limitations" wären gerade nicht Teil meiner Idee. Im Gegenteil, ich wollte ja die Power moderner Hardware genutzt sehen, nur halt im Stil der frühen Homecomputer (wie auch immer das dann aussieht, mehr als eine Idee isses noch nicht - und obs jemals mehr wird, ist seeehr fraglich :whistling:).