Hello, Guest the thread was called53k times and contains 1467 replays

last post from Unseen at the

Neuer Retro-Computer im 8-Bit Style

  • Freddy Das ist halt deine Ansicht zum Thema (und sie sei dir gegönnt), ich habe meine eigene. Ich konnte die von mir gewünschten Specs dank des Threads optimieren und konkretisieren. Mehr hatte ich mir ja ursprünglich auch gar nicht erhofft. Falls sich irgendwer durch den Thread "aufgerufen" fühlt, etwas davon praktisch umzusetzen (zumindest in Teilen) – umso besser. Vieles wird einem ja auch erst richtig klar, wenn man vor den technischen Problemen konkret steht.


    Auch das Verhältniss 4:3 ist 'mehr' Retro als 16:9.

    Natürlich. Das weiß jeder. Es ging aber nie darum, alte Rechner wieder auferstehen zu lassen – sondern einige (nicht alle) Kern-Ideen der klassischen Systeme in die heutige Welt zu transportieren. Und in der heutigen Welt stehen nun mal andere Fernseher bei den Leuten zuhause. Aber das ist nur EIN Grund, warum ich für die "Wide"-Darstellung plädiere – ein weiterer ist: Die anderen Retro-Systeme nutzen eher klassische Seitenverhältnisse – warum nicht eine Alternative bieten, die es anders macht? Ein dritter Grund ist, dass ich es aus Sicht der Grafik-Leute spannend finde, wie man mit dem neuen Seitenverhältnis (aber "alter" Pixel-Menge) als Herausforderung umgeht. Wenn ich einfach nur "alt" will, dann nehme ich einfach einen alten Rechner.

  • "8bit Style" heißt halt für einige hier (und speziell auch für mich) nicht notwendigerweise "mit 8bit CPU" - das sagt ja nun auch nicht viel. Es gibt moderne 8bit-RISC-CPUs und antiken Kram wie den 6510. Und man kann prinzipiell auch mit einer 8bit-ALU einen 32bit-Adreßraum benutzen - das ist nur unhandlich. Gerade ein großer Adreßraum ist halt einfache ein Offenbarung gegenüber Page-Gefrickel und wenn man schon einen 32bit-Adreßraum hat, ist eine 32bit ALU einfach ein logischer Schritt. Zumal eine 8bit ALU und selbst eine 16bit ALU halt doch mit großen Einschränkungen bei ganz normalen Berechnungen verbunden sind.


    Wie schon früher dargelegt, bedeutet für mich "8bit Style" im wesentlichen, das das eine relativ kompakte Kiste ist, die keine komplexe und modulare Hardware (interne Steckkarten wie im PC) enthält, die nur wenige Sekunden zum Booten braucht und mit der man danach sofort was machen kann. Außerdem sollte die Gesamtkomplexität so gering sein, daß man noch das ganze System verstehen und ohne riesige Libraries durch direkte Registerzugriffe usw. auf alle Hardwarekomponenten zugreifen kann.

    Oder um es mal anders auszudrücken: wenn der C64 mit 20MHz 32bit-CPU, 1MB RAM, 256 Farben bei 320x200 und 32 HW-Sprites rausgekommen wäre, hätte es dann unsere Begeisterung gemildert? Meine jedenfalls sicher nicht. Viele Spiele hätten einfach viel besser ausgesehen. Und hätte der C64 gleich einen ordentlichen Texteditor mit 80 Zeichen pro Zeile gehabt, wäre ich sicher auch nicht traurig gewesen.


    Wie gesagt: gewisse Beschränkungen sind nötig, um die Gesamtkomplexität für den Programmierer möglichst klein zu halten und um die Kosten gering zu halten. Beschränkungen, die die Komplexität für den Programmierer erhöhen, sind aber aus meiner Sicht weitestgehend sinnfrei. Und über Beschränkung als künstlerisches Mittel kann man trefflich streiten, aber IMHO schwingt da auch etwas nostalgische Schönfärberei mit: viele Spiele sehen auf dem C64 ziemlich übel aus und es gibt nur relativ wenige, die entweder mit großen technischem Aufwand einige Beschränkungen ausgehebelt haben oder halt speziell um die Beschränkungen herum entwickelt wurden. Bei statischen Bitmaps kann man da besser tricksen, aber wegen der extremen Einschränkungen wurde dieser Modus ja kaum für Spiele benutzt.

  • Mal ein Vorschlag zur Güte:

    man braucht ja so oder so eine Art "Graphics-Memory" Controller, der regelt, wer auf den Framebuffer wann zugreift (es sei denn man hat echtes dual-ported VRAM, was ich mal als unrealistisch abtue).

    Also hängt das entsprechende RAM ja nicht direkt am CPU-Bus und dieser Controller könnte der CPU ein Layout vorgaukeln, dass es einfacher macht, auf Pixel zuzugreifen.


    Konkret könnte man die Pixel byte-adressierbar machen, auch wenn es nur 4 Bit Werte sind. Wenn man dann noch Zeilenbreite 256 wählt (muss ja nicht komplett sichtbar sein, kann ein Teil unsichtbar für

    Bildaufbau vor dem Reinscrollen), dann ist es recht trivial von X,Y Coordinaten auf die Speicheradresse eines Pixels zu kommen.


    Man verschwendet natürlich etwas Bandbreite (es sei denn der Grafikcontroller wäre schlau genug für linear progressive Zugriffe der CPU zu puffern), aber ich denke es würde dadurch viel weniger Bitgefriemel geben, wenn man alle Grafikoperationen (als Bibliothek) in 68000er Assembler schreibt.

  • "8bit Style" heißt halt für einige hier (und speziell auch für mich) nicht notwendigerweise "mit 8bit CPU" - das sagt ja nun auch nicht viel. Es gibt moderne 8bit-RISC-CPUs und antiken Kram wie den 6510. Und man kann prinzipiell auch mit einer 8bit-ALU einen 32bit-Adreßraum benutzen - das ist nur unhandlich. Gerade ein großer Adreßraum ist halt einfache ein Offenbarung gegenüber Page-Gefrickel und wenn man schon einen 32bit-Adreßraum hat, ist eine 32bit ALU einfach ein logischer Schritt. Zumal eine 8bit ALU und selbst eine 16bit ALU halt doch mit großen Einschränkungen bei ganz normalen Berechnungen verbunden sind.


    Wie schon früher dargelegt, bedeutet für mich "8bit Style" im wesentlichen, das das eine relativ kompakte Kiste ist, ...

    wenn der C64 mit 20MHz 32bit-CPU, 1MB RAM, 256 Farben bei 320x200 und 32 HW-Sprites rausgekommen wäre, hätte es dann unsere Begeisterung gemildert?

    Den Punkt finde ich sehr zutreffend.

    Zum Programmieren lernen ist ein 80er Jahre 8-Bit Rechner wirklich sehr schlecht geeignet. Es gibt viel zu viel zu lernen, bis man mal zum Punkt kommt(Speichermanagement, Bit Gefrickel bis mal ein Sprite da ist wo er hin soll usw.)

    Eine schlanke Lib wie die SDL, meinetwegen noch schlanker, ist dagegen weit besser geeignet. Einfach nur eine Set und Get Pixel Funktion/Maus/Tastaturabfrage,/Soundausgabe in C oder Python oder was auch immer, macht es den Programmierer viel leichter sich wirklich auf die Entwicklung des Spiels zu konzentrieren und keinen, heute unnötigen, Quatsch zu lernen.

    Das kann man heute alles einfach haben und auch heute braucht ein OS nur wenige Sekunden bis es einsatzbereit ist, aber hier solle es unbedingt ein autarkes Gerät sein. (Verstehe den Sinn dahinter nicht, da es fürs Programmieren lernen völlig egal ob autark, im Browser oder Emu oder sonst was, aber die Diskussion müssen wir hier nicht führen.)

    Wenn es also simple sein soll dann eben keine 8 Bit CPU im alten Style und keine Hardwareregister mit bit 9 irgendwo anders oder solche Spezialfälle die einem wirklich den Spaß an der Sache rauben.

    ASM ist sone Sache, will man das wirklich? Ich meine früher musste man wenn man eine bestimmte Performance erreichen wollte. Aber wer einmal eine Hochsprache genossen hat, der will doch nicht freiwillig zu ASM zurück, es sei denn als Herausforderung, so wie ich das mache. Das ist wie Feuer machen mit dem Feuerstein, jedes mal wenn man sich einen Kaffee kochen möchte. Kann man machen, aber in der Regel nimmt man doch lieber die Kaffeemaschine.


    Für mich ist 8-Bit Coding auf dem C64 immer eine Reise in die Kompliziertheit der 80er, um die einfachsten Sachen umzusetzen muss man unglaublich viel machen.

    Heute sind die Computer viel komplexer und nicht zu verstehen von einer einzelnen Person, dafür um Längen einfacher zu bedienen und zu programmieren.


    Hat alles seine Vor- und Nachteile, nicht alles war früher besser. Darum finde ich diesen 8Bit Style Begriff hier auch viel besser als wirklich den 8-Bit Kram von früher zu kopieren und alles so kompliziert zu machen wie auf einem C64.

  • Von 8-Bit CPU haben wir uns ja längst verabschiedet. Und der Einsteiger soll auch (erstmal) nicht Assembler programmieren müssen. Es geht eher darum, ob man Grafik mit viel Special-HW (Sprites, Blitter, "GPU") macht, oder die CPU schnell genug ist, dass es brauchbare Grafik-Primitive in Software gibt. Wenn man aber nicht wieder eine super-duper high-end GHz CPU einbaut, müssen diese halt schon etwas low-level optimiert werden. Ein 7-25 MHz 68000 ist nunmal auch nicht so schnell, dass man alle Grafik Operationen pixelweise in interpretiertem Lua macht.


    Und was Assembler vs. Hochsprache angeht: ich persönlich würde 68K Assembler manchen modernen Hochsprachen vorziehen. Es ist sofort klar ,was ein Instruktion tut und zur Not steppt man durch, um den Ablauf zu verstehen.

    Bei "modern C++" mit genügend Boost, STL, Inlines, Templates und Lambdas kommt man auch mit dem Debugger single-step oft nicht mehr weiter. Zumindest der von VS gibt da irgendwann auch auf mit source-level Debugging.

  • Verstehe was du meinst, ich mache meine Software 3D Rendering Sachen gerade in purem C mit SDL und finde das super, hier und da ist es etwas kniffelig, aber nix was man nicht lösen kann. Für Kundensachen kommt sowas natürlich nicht in Frage da sind dann C# und Co weit besser geeignet, aber ich mag den portablen Assembler C, nah genug dran und doch CPU unabhängig und nur ganz wenige Grundlagen die man für die Sprache braucht.


    Aber das ist ja das schöne heute, wie leben in einem Programmiererparadies. Jede Grundlage nur einen Klick entfernt und man kann sich die Sprache aussuchen, die am besten zu einem passt. Was wäre ich froh wenn ich damals solche Möglichkeiten gehabt hätte.

  • Mit geht es darum, daß man auch in Assembler programmieren kann, aber nicht muß. Deshalb würde ich auch auf jeden Fall eine (Soft-)CPU mit verfügbarem C-Compiler auswählen.

    Und für mich ist es halt auch nur ein echter Heimcomputer, wenn man direkt in Register und den Grafikspeicher reinschreiben kann - möglichst per CPU oder DMA.

    Daß man das auch per Lib machen kann, ist ein anderes Thema. Aber wenn es nur über eine Library praktikabel ist, dann ist es für mich kein Heimcomputer mehr.


    Bin übrigens persönlich kein 100%iger Freund des 68000ers (mehr). Ich halte alleine schon "Big Endian" für einen Irrweg, der einem in der Praxis nur Ärger macht (Pointer auf Byte statt Word braucht andere Adresse usw.).

    Ich finde den Befehlssatz von (little endian) 32bit RISC-Prozessoren wie Cortex M3 und Renesas RH850 ganz sympathisch, aber die sind natürlich geschützt (Lizenzen usw.). Aus solchen Erwägungen fände ich einen 32bit-Risc-V-Softcore wie NEORV32 interessant. Wobei im Risc-V-Standard schrulligerweise noch praktisch keine erweiterten Befehle zur Bitmanipulation (count leading zeroes usw.) existieren bzw. festgezurrt sind. Aber ich gehe davon aus, daß die "Bitmanip Extension" auch in NEORV32nachgerüstet wird, sobald sie offiziell ist.

    Zur Not ginge auch sowas wie Amber (Arm v2a wie im Archimedes) wobei der Adreßraum wohl nur 26bit hat und der Befehlssatz wohl auch recht eingeschränkt ist.

  • Deshalb würde ich auch auf jeden Fall eine (Soft-)CPU mit verfügbarem C-Compiler auswählen.

    ZPU - dann wird freiwillig in einer Hochsprache statt in Assembler programmiert ;)