Hello, Guest the thread was viewed20k times and contains 147 replies

last post from JeeK at the

Der perfekte Heimcomputer - oder: Welcher Heimcomputer hat das sauberste Hardwarearchitektur-Design

    Die Modularität des Archimedes fand ich auch klasse. Seinen kleinen Bruder hatte ich leider nicht kennengelernt.


    Aber ein starres System hat auch einen Vorteil: Jede Software dafür läuft direkt auf jedem Exemplar und fordert nicht erst diese und jene Erweiterung.

    Es gibt auch für den C64 eine Speichererweiterung und ein Beschleunigungsmodul, und wie oft wurde das von einem Spiel verlangt? Fast alle Spiel wurden so entwickelt, dass sie direkt auf einem C64 aus dem Laden laufen, damit jeder es nutzen kann und nicht nur die, die über Erweiterung X verfügen. Und dann stellt sich irgendwann die Frage nach dem Sinn dieser Erweiterungen.

    Quote from atomcode

    Die Modularität des Archimedes fand ich auch klasse. Seinen kleinen Bruder hatte ich leider nicht kennengelernt.


    Aber ein starres System hat auch einen Vorteil: Jede Software dafür läuft direkt auf jedem Exemplar und fordert nicht erst diese und jene Erweiterung.

    Es gibt auch für den C64 eine Speichererweiterung und ein Beschleunigungsmodul, und wie oft wurde das von einem Spiel verlangt? Fast alle Spiel wurden so entwickelt, dass sie direkt auf einem C64 aus dem Laden laufen, damit jeder es nutzen kann und nicht nur die, die über Erweiterung X verfügen. Und dann stellt sich irgendwann die Frage nach dem Sinn dieser Erweiterungen.

    Und genau da hat die PC-Welt viel 'gelernt'.

    Grafik wurde gepuscht, Sound wurde gepuscht, und CPU-Power (erst MHz, danach 32 - 64 Bit & zZ Kerne, Kerne, Kerne).

    Heute wirst du gezwungen neue PC's zu kaufen, wenn du einigermaßen 'aktuell' sein willst.

    Quote from Freddy

    Und genau da hat die PC-Welt viel 'gelernt'.

    Grafik wurde gepuscht, Sound wurde gepuscht, und CPU-Power (erst MHz, danach 32 - 64 Bit & zZ Kerne, Kerne, Kerne).

    Heute wirst du gezwungen neue PC's zu kaufen, wenn du einigermaßen 'aktuell' sein willst.

    Naja das wuerde ich so auch nicht unbeding unterschreiben. In den 90ern ging die Entwicklung rasant, aber selbst da konnte man 4-5 Jahre lang den gleichen PC verwenden, wenn man nicht immer 100% die neuesten Spiele zocken will. Und heute arbeite ich mit einem Rechner von 2013 (den ich aber dieses Jahr ersetzen werde), und davor 2009, 2005, 2000, also auch grob alle 4-5 Jahre. Wenn nun aber einer 1982 einen C64 gekauft hat, dann hat er vielleicht 1987 auch schon mit dem Amiga geliebaeugelt. Und der war ja im Vergleich zum C64 auch ein riesen Sprung. Ob Du heute einen PC von 2012 nutzt oder von jetzt, macht (bis auf Spiele) oftmals keinen vergleichbar grossen Unterschied. Und wenns wirklich um Spiele geht, dann reicht manchmal auch einfach nur das Austauschen der Grafikkarte oder mehr RAM, und nicht gleich ein komplett neuer Rechner. Also so dramatisch sehe ich das alles nicht.

    Quote from Freddy

    Heute wirst du gezwungen neue PC's zu kaufen, wenn du einigermaßen 'aktuell' sein willst.

    äh...Nein. Das ist der SciFi Glaube der Retro-Fundies aus den 90ern und early 2000er, als damalsTM tatsächlich die PCs in der Gameindustrie noch den Takt angaben.

    Heute wird eher parallel mit gleicher Engine für Konsolen und PCs, Tablets etc. entwickelt. Das sind die Voraussetzungen ganz anders.

    Wie ZeHa schon schrieb ein 2-5 oder mehr Jahre alter (aber vernünftig aufgebauter) PC kann durchaus für Vieles noch verwendet werden, auch für Games. Hier ein 2011 Developer Notebook und ein GamerPC aus 2015. Alles funzt wie ich es will.

    Also nicht die 300.- Büchse von Aldi & co.

    Das habe ich alles aus dem, zumindest beim BBC-Micro recht umfangreichen, Handbuch. Daß es für Programierer Sinnvoll ist, nehme ich an. Auf jeden Fall erleichtern sie dem Anwender den Umgang.

    Z.B. die Sache mit den ROM-Bänken. (Der BBC-Master wurde ja schon ab Werk mit ein paar Programmen im "Sideways-ROM" ausgeliefert.)

    Wenn ich in einen Computer beliebig viele ROMs einstecken und wahlweise aktivieren kann, ist es für mich schon ein Unterschied, ob die Entwickler die Fähigkeit hinzugestoppelt haben und ich muß Wert X mit Wert y addieren und in Speicherstelle Z poken oder ob die Entwickler sich ein paar Gedanken gemacht haben wie:

    "So, es können ja mehr ROM-Bänke eingebaut werden, als Das Betriebssystem verwalten kann. Das muß ja irgendwie bedient werden. Dann geben wir dem Betriebssystem mal ein Unterprogramm mit und nennen es "Mount". Die ROM-Bänke bekommen vom Nutzer Namen mit aufgebrannt. Z.B. "Terminal". Darin können sich beliebige Dateien befinden, auch die Programmdatei "Term". Dann wird die ROM-Bank mit "*mount terminal" aktiviert. Programm aufrufen? Moment, das geht doch. Programme werden per Namen aufgerufen. Dann machen wir das doch so, wenn der Nutzer "term" eingibt sucht das Betriebssystem erst die eigenen Befehle durch, Findet er da nichts, werden ROM- und RAM-Bänke durchsucht und wird er auch da nicht fündig, geht es auf einem angeschlossen und angemeldeten Laufwerk weiter. Ja, das funktioniert."


    Letztere Überlegungen machen das Ganze runder, finde ich. Übrigens, speziell diese Funktion ist doch eher für den Anwender interessant, nicht für den Programmierer.

    Auch daß Betriebssystemfunktionien direkt aus dem Basic aufgerufen werden, ist eher was für den Anwender. Mit *Mount werden Laufwerke und ROMs aktiviert, mit *Unmount wieder deaktiviert, *Configure werden die Systemeinstellungen, wie Uhr, Bildschirmmodus beim Start, Diskettensystem u.s.w. festgelegt. *configure tube wechselt zum Zweitprozessor (wie man von dort zurück kommt hängt davon ab, was da läuft). Das sind eher Befehle für den Nutzer.

    Der Wahlweise Wechsel zwischen den Prozessoren. Das ist wirklich etwas nur für Programmierer. Aber es ist möglich. Ergebnisse könnten über das "Sideways-RAM" ausgetauscht werden, aber ich bin halt kein Programmierer.


    Ich mag den C64 sehr, weil es der erste Computer war, den ich erlebt habe und er mich seit meiner Kindheit (ich war damals 7) begleitet hat. Aber ein "rundes" System war er nie. Auch als Anwender hatte ich immer das Gefühl, daß sich alles nicht wirklich zu einem Ganzen fügt. Beim BBC-Master schon. Seit ich ihn habe fasziniert er mich. Nicht weil er soundso viele oder besondere Fähigkeiten hat. Sondern, weil er sich mir als Anwender als ein Ganzes zeigt. Es fügt sich alles scheinbar natlos zusammen.


    Hast Du die hier gefunden?

    https://en.wikipedia.org/wiki/BBC_Micro

    https://en.wikipedia.org/wiki/BBC_Master

    Habe gerade die Handbücher überflogen. Die Kommandos heisen anders (da warf ich was durcheinander) aber die Funktionen sind, wenn auch leicht anders, vorhanden und es können 16 ROM-Bänke mit je 16 KB eingesetzt und beliebig deaktiviert werden.

    Ansonsten stimmt das oben gesagte.

    Quote from BIF

    2. Hardware-Architektur:
    a) BASIC+KERNAL zusammenlegen und den I/O Bereich ans Speichende legen.
    Dann hätte man Grafiken(10kB) problemlos in einem Zug in den oberen 16kB Bereich laden können.

    Problem: Die Vektoren sind in der letzten Page. Da hätte man dann Reset-Vektor und ev. andere aus dem ROM an diese Stelle einblenden müssen. Eine Konstruktion, die die Entwickler wohl unter Zeitdruck vermieden haben. Dass man mit Bankswitching auch fast die gesamten 64 K hätte nutzen können, liegt ja nur am BASIC, das BASIC 3.5 der 264er-Linie zeigt es ja. Nur, das ist ein massive Änderung am BASIC-Interpreter, die weit mehr Aufwand ist, als den VC20 als Prototyp zu nehmen und einige Speicherstellen anzupassen ... aber dabei ist jedenfalls egal, wo I/O- und ROM-Bereiche liegen.


    Quote from BIF

    4. Ein paar zusätzliche Maschinensprachebefehle hätten dem C64 eine höhere Geschwindigkeit geben können.
    z.B. TXS, TYS,TSX,TSY

    Ja, das ist ja unrealistische Träumerei. Als könnte man einer CPU so aus der Laune heraus mal den einen oder anderen Befehl "dazutun" ... Die Beispiele sind gerade die so selten benötigten Befehle, die hätten tatsächlich nichts gebracht.

    Nett wären die Verbesserungen von 65C02 gewesen. Aber auch da, den BASIC-Interpreter dahingehend zu optimieren, damit die CPU auch ausgenutzt wird ... das schreibt man nicht an einem Nachmittag um. ;)


    Quote from BIF

    4. Auch das Basic hätte natürlich noch verbessert werden können.
    Den Fehlermeldungsbereich hätte man ganz weglassen können.
    und statt dessen die BASIC-BEFEHLE für Fehlermeldungen verwenden können: PRINT-ERROR, LET-ERROR, usw
    Bei vielen BASIC-Befehlen hätte man die Leistungfähigkeit natürlich auch noch stark verbessern können.

    Ist eigentlich 5.

    Den Fehlermeldungsbereich weglassen? Was soll das sein. Primitiver geht es ja kaum. Alles andere wäre ja mit mehr implementierungsaufwand verbunden.

    Andere MS-BASICs haben statt lesbare Fehlermeldungen 2-Buchstabenkürzel. Ist das gemeint? Z.B. beim Dragon oder CoCo. Obwohl die Dank 6809-CPU weit kompakter codieren können, hat man dort zugunsten der Funktionalität auf ausschweifende Fehlertexte verzichtet. Für einen Anfänger sicherlich auch nicht lustig (aber die langen Fehlermeldungen sind ja auch nicht immer auf den ersten Blick verständlich ;) ).