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

last post from Unseen at the

Neuer Retro-Computer im 8-Bit Style

  • Ja, es sind heterogene Systeme. Das macht die Entwicklung umständlicher, weil man überlegen muss, welche Ausführungseinheit für was verwendet werden soll. Und wie die kommunizieren. Und dann verwendet man auch unterschiedliche Hochsprachen, Compiler und Tools.


    Ich schlage mich tagtäglich beruflich damit herum, dass CPUs und GPUs doch im Detail nicht das selbe tun, selbst wenn man fast den gleichen C++ Code füttert. Unterschiedliche Toolchains und Profiler/Debugger machen es noch hakeliger.


    Daher ist der Ansatz: eine Verarbeitungseinheit ist schnell und flexibel genug für alles (auch Grafik und Sound) doch für Anfänger sehr hilfreich.

    Da wären wir dann beim TED der 264er Serie ;-)

    Display + Sound + Refresh + Tastatureingaben + + +

    :-D

  • Daher ist der Ansatz: eine Verarbeitungseinheit ist schnell und flexibel genug für alles (auch Grafik und Sound) doch für Anfänger sehr hilfreich.

    Das auf jeden Fall, das nimmt die Komplexität. Ich z.B. arbeite mich gerade in die 3D Programmierung ein und setze jeden Pixel selbst und schreibe jede Berechnung selbst um das alles vollständig zu verstehen. Mir ist klar, dass es mit OpenGL etc. viel performanter ginge, aber es ist eine Baustelle mehr und damit eine Fehlerquelle mehr. Also bleibe ich bei nacktem C plus SDL und der Rest ist reine Software.

    OpenGL ist ja fast auch schon wieder "retro" ;-)

    Man lernt halt auch mehr, wenn man nicht eine Blackbox nutzt. Ob jetzt Hardware oder Software (Lib).


    Aber was ist für Anfänger besser geeignet? Die wollen halt vielleicht lieber erstmal ein Sprite definieren und bewegen können, ohne zu verstehen, wie es geht.

    Wenn es eine Software-Lösung ist (basierend auf schneller CPU) dann können sie sich den Code später ansehen und vielleicht eigenen schreiben.


    Bei einer open-source FPGA Retro-Maschine könnten sie natürlich den HDL Code der Sprite-Engine anschauen und modifizieren, aber das ist eine viel größere Baustelle.

  • Ja, schwer zu entscheiden. Ich fand das damals ultra kompliziert mit dem ganzen Setzen der VIC-II Register. Ich hätte es eher begriffen, wenn ich einfach einen Bitmapspeicher gehabt hätte in den ich was rein kopiere. Aber die Technik war früher halt kompliziert zu programmieren für die einfachsten Sachen musste man sich ziemlich verbiegen im Gegensatz zu heute. Heute wird es komplex wenn man an die Limits gehen muss. Ich habe mir mal aus Spaß ein Vulkan API Video angeschaut, mein lieber Scholli, war dann doch ein paar Hausnummer zu viel für mich.

  • Je mehr ich überlege, was mich an dem Thema reizt, so mehr ist es ein pädagogischer "top-down" Ansatz, der genau andersrum ist, wie der "NAND to Tetris" bottom-up Ansatz von "The Elements of Computing Systems".


    Mag sein, dass das Buch super für Studis ist, die genügend Motivation mitbringen. Aber mich hätte es als Einsteiger mit 12 völlig überfordert. Ich hätte gerne was, wo meine Kinder (11 und 9) bald kleine, eigene Spiele in einer vernünftigen Hochsprache schreiben können. Dann lernen was Assembler ist und was die CPU tut. Was ein minimales OS ist und was der Rest der Hardware tut. Und wie man das alles aus einfachen Logik-Funktionen herleiten kann.


    Eben erst Tetris (programmieren), dann Hardware-Komponenten, OS und Compiler verstehen und am Schluss alles bis auf NAND, false und Flipflop herunterbrechen.

  • Je mehr ich überlege, was mich an dem Thema reizt, so mehr ist es ein pädagogischer "top-down" Ansatz, der genau andersrum ist, wie der "NAND to Tetris" bottom-up Ansatz

    !!!!!!! :dafuer:


    Wenn man eine Thematik völlig durchdringen will/muss, dann ist der alte bottum-up Ansatz aus Schule/Studium sicherlich sinnvoll, aber es lernt sich unendlich viel besser, wenn man es selber will. Und erst wenn einen etwas begeistert, will man es (vielleicht) im Detail verstehen.


    So verstehe ich auch die Ursprungsidee von Retrofan: Erst mit einem schnell erfassbaren Komplettsystem zu Erfolgserlebnissen und Begeisterung führen und trotzdem "den Weg in die Tiefe" offen lassen.

  • Sorry, falls diese Frage schon erörtert wurde, aber meine Freizeit erlaubt mir aktuell nur ein grobes Überfliegen der sehr dynamischen und inzwischen auf mehrere Threads verteilten Diskussion.


    [Grafik][Beschleunigung][Anbindung][Speicherzugriff]

    Auch bei realen Retro-Computern gab es ja schon separate Chips zur Unterstützung der Grafik. Manche hingen mit der CPU am gleichen RAM, andere hatten eigenes Grafik-RAM und wurden von der CPU nur mit Grafikbefehlen gefüttert.


    Mir scheint ein separates Grafik-RAM sinnvoller, da die Speicherkosten heute viel geringer sind und eine größere Entlastung der CPU realisierbar wäre. Aber ich habe nie Arcade-Games programmiert, deshalb interessiert mich Eure Meinung dazu. Macht ein Direktzugriff der CPU auf das Grafik-RAM heute noch Sinn?

  • Ausserdem willst Du ja die CPU Leistung für Hochsprache statt Assembler nutzen. Und dann soll sie noch die ganze Grafik alleine stemmen?

    Wer da was zu stemmen hat, ist ja noch ungeklärt. Ich wollte darauf hinaus, dass (Hardware-) Sprites nicht die einzige Möglichkeit sind, ausreichende Gaming-Performance hinzubekommen. Beim Amiga werden die Hardware-Sprites oftmals gar nicht genutzt, weil sie zu unflexibel sind. Er hat halt andere Möglichkeiten, genügend bewegte Objekte auf den Bildschirm zu bekommen.


    Dann ist ein 8MHz 68000 aber schnell am Limit. Hat der Ur-ST ja gezeigt.

    Das ist richtig. Allerdings hatte der Atari keine Probleme bei der Anzahl beweglicher Objekte, sondern vor allem beim Scrolling. Da hätten ihm Hardware-Sprites auch nichts genützt. Auch beim Scrolling müsste man gucken, ob die CPU das alleine schaffen kann (und mit wieviel MHz) oder ob sie auch da Grafikchip-Beschleunigung benötigt.


    Was man beim ST im Vergleich zur hier angedachten Maschine aber auch bedenken muss – Seine Auflösung ist evtl. (ja nach Vorschlag) etwas höher (320 x 200 vs. 240 x 216, 64K statt 52K), weswegen mehr Speicher zu verschieben war.


    Wie es ohne Sprites ausgesehen hat, sieht man ja am Spectrum. Trotz 3,5 MHz Z80 war die Grafik ja um längen primitiver und ruckeliger.

    Das lag aber meines Erachtens weniger an der CPU-Power (wobei ja ein Z80 für den gleichen Job mehr MHz braucht als ein 6502 – habe ich mal gelesen), sondern vor allem an der eingeschränkten Farb-Darstellung. Wegen der 2-Farben-je-Char-Regel fiel besonders auf, dass es keine Sprites gab, die sich über diese Einschränkung hätten hinweg setzen können. Könnte man allerdings im Background, wie auch in den Sprites/Shapes alle 16 Farben darstellen – wer sollte dann erkennen, welche Technik (Sprites/Shapes) überhaupt zu Einsatz kommt?


    Daher ist der Ansatz: eine Verarbeitungseinheit ist schnell und flexibel genug für alles (auch Grafik und Sound) doch für Anfänger sehr hilfreich.

    Das denke ich auch. Aber wie schon alle sagten, hängt die Machbarkeit davon ab, ob die CPU das schafft. Und das bezieht sich halt nicht nur auf Sprites, sondern auch auf das Scrolling und auch auf Verfahren, ob und wie man Auflösungen mischen kann.


    ----


    Zu letzterem: Auf dem C64 gibt es dafür 2 Möglichkeiten: Zum einen kann man im Multicolor-Char-Mode einzelnen Zeichen in Hires darstellen, was für Schrift in MC-Games gerne verwendet wird. Zum anderen kann man per Raster-Interrupt den Screen vertikal aufteilen und dort verschiedene Auflösungen nutzen, was z.B. gerne in Grafik-Adventures Anwendung findet.


    Auch für sowas sollte man nach Lösungen gucken (und auch für Aufteilungen, was gescrollt wird und was stehen bleiben soll). Denkbar wäre vielleicht eine Lösung, die es erlauben würde (wie die alten HTLM-Frames in Netscape), meinetwegen bis zu 4 "Fenster/Frames" (horizontal oder vertikal) definieren zu können, für die man Auflösungs-Modus (Lores oder Hires) und Scrollverhalten einstellen könnte. Das würde bei Adventures und auch bei scrollenden Shootern auf sehr logische Weise helfen, Bereiche von einander zu trennen). Aber vielleicht ist das auch schon wieder zu "modern" gedacht.

  • Beim Amiga waren die Sprites aber nicht deswegen unwichtiger, weil die 7MHz 68000 CPU so schnell gewesen wäre, sondern weil der Blitter so schnell und flexibel war. Der Blitter hatte auf dem Chip-RAM Bus Priorität vor der CPU, weil Miner & Co davon ausgingen, dass der Blitter die Grafikaufgaben schneller erledigen kann, als die CPU.


    Man kann den Blitter als bit-orientierten Vektorprozessor auffassen, der drei zweidimensionale Eingabe-Vektoren auf 256 verschiedene Arten verknüpfen und in ein Ziel-Vektor schreiben kann.

    Desweiteren kann er noch Linien ziehen und Flächen füllen - bei Bedarf mit Pattern.


    Das ist nicht nur viel schneller als die CPU, weil diese die notwendige Bitverwurschtelung nicht sonderlich schnell kann, sondern auch weil eine einfache CPU ohne Instruktionscache bei der Abarbeitung der entsprechenden Schleifen recht viel Speicherbandbreite verschwendet, um immer wieder die gleichen Instruktionen zu holen.

    Der Blitter wird mit eine paar Bytes konfiguriert und rattert dann über tausende Verarbeitungselemente, ohne selbst weitere "Instruktionen" holen zu müssen.


    Wie nützliche das war, sieht man auch daran, dass Paul Lassa aus dem C65 Team unbedingt auch einen Blitter einbauen wollte und dies hinter dem Rücken des Managements auch tat und dass auch Atari ab Mega ST oder STe einen Blitter in die STs einbaute.


    Eine konventionelle CPU muss schon einiges an Wumms mitbringen, um Ähnliches zu leisten. Nicht nur einen Barrelshifter wie beim 68020, sondern auch einen I-Cache, der das "Von-Neumann-Bottleneck" zumindest bei kleinen Schleifen abmildern kann.


    Und Scrolling will man auf jeden Fall in Hardware. Den ganzen Screen per CPU zu lesen und neu zu schreiben ist eine gigantische Verschwendung von CPU-Instruktionen und Speicherbandbreite.

    Erst recht, wenn man noch pro Pixel irgendwelche Bit-Shiftereien braucht.


    BTW: der original 1984 Mac hatte ja nur 512 x 342 SW Bitmap Grafik (ca 21 KB), und obwohl "QuickDraw" in hochoptimiertem 68000 Assembler geschrieben war, fühlte es sich nicht so "quick" an. An Farbgrafik hat sich Apple dann erst 1987 beim Macintosh II mit 14 MHz 68020 getraut. Und für wirklich schnelle Farbgrafik hat man eine "8.24 CG" Karte mit 30 MHz AMD 29000 RISC Prozessor nur für ColorQuickDraw-Beschleunigung verkauft.

    Das war kurze Zeit lang der schnellste kommerziel verfügbare RISC Prozessor. Apple Werbeaussage " The Macintosh Display Card 8•24 GC contains an Am29000 RISC-based microprocessor that runs a version of QuickDraw™

    that has been optimized for a coprocessing environment. The Am29000 and the Macintosh CPU work together to accelerate the QuickDraw environment, increasing the Macintosh drawing speed 5 to 30 times depending on the
    application."


    Das war natürlich einem Amiga-Blitter haushoch überlegene Profi-Technik, die Ende 1989/90 aber auch ein vielfaches eines Amigas gekostet hat. Müsste jetzt alte MacWelts durchsuchen, aber ich habe im Kopf, dass die so ab 5000 DM verkauft wurde. Hab noch zwei im Keller (vom E-Schrott).

  • Beim Amiga waren die Sprites aber nicht deswegen unwichtiger, weil die 7MHz 68000 CPU so schnell gewesen wäre, sondern weil der Blitter so schnell und flexibel war.

    Ich sprach ja nur davon, dass wir erst einmal klären sollten, ob wir "echte" Sprites benötigen oder ob es nicht auch andere Möglichkeiten gäbe. Der Blitter wäre z.B. so eine Möglichkeit.


    dass auch Atari ab Mega ST oder STe einen Blitter in die STs einbaute.

    Nicht "ab", sondern genau für diese Geräte. Die Nachfolger hatten schon keinen Blitter mehr, weil die CPU das schneller konnte.


    Und Scrolling will man auf jeden Fall in Hardware.

    Braucht man spezielle Hardware, wenn man einen größeren Speicherbereich als Map definieren kann und einfach den Anfang des Bildschirm-Speichers versetzt?


    Und für wirklich schnelle Farbgrafik hat man eine "8.24 CG" Karte mit 30 MHz AMD 29000 RISC Prozessor nur für ColorQuickDraw-Beschleunigung verkauft.

    Das war kurze Zeit lang der schnellste kommerziel verfügbare RISC Prozessor.

    Ich glaube, die suche ich noch für meine Macintosh-II-Reihe. (ich bin mir aber nicht ganz sicher und muss erstmal meine Nubus-Karten ein wenig katalogisieren.)

  • Ich sprach ja nur davon, dass wir erst einmal klären sollten, ob wir "echte" Sprites benötigen oder ob es nicht auch andere Möglichkeiten gäbe. Der Blitter wäre z.B. so eine Möglichkeit.

    ...

    Braucht man spezielle Hardware, wenn man einen größeren Speicherbereich als Map definieren kann und einfach den Anfang des Bildschirm-Speichers versetzt?

    Hatte ja vor ein paar Beiträgen eine andere Möglichkeit vorgestellt, wie man ohne echte Sprites mit einer Art HW-Multiplexer zu einem ähnlichen Ergebnis kommen kann. Aber anscheinend war das zu länglich als daß es jemand gelesen hätte.

    Und ja, natürlich ist ein Scrolling über die Definition der Startadresse ein HW-Feature. Kein komplexes HW-Feature, aber wenn das jede Architektur automatisch könne, müßte man ja nicht darüber reden.

  • Aber anscheinend war das zu länglich als daß es jemand gelesen hätte.

    Ich hatte es gelesen. Nur ist das für mich eine spezielle Sprite-Hardware, auch wenn sie anders/flexibler arbeitet als C64/Amiga-Sprites. Was ist der Vorteil gegenüber z.B. den Amiga-Coprozessoren?


    Und ja, natürlich ist ein Scrolling über die Definition der Startadresse ein HW-Feature.

    Ja klar, ein Feature ist das sicherlich – aber halt nicht unbedingt ein ganzer spezieller Chip (wie der Blitter) dafür nötig. Es müssen halt keine Speicherbereiche verschoben werden, wenn einfach nur das Sicht-Fenster verschoben wird. Das macht natürlich vor allem Sinn, wenn man genügend zusammenhängenden Speicher zur Verfügung hat.

  • Hatte ja vor ein paar Beiträgen eine andere Möglichkeit vorgestellt, wie man ohne echte Sprites mit einer Art HW-Multiplexer zu einem ähnlichen Ergebnis kommen kann. Aber anscheinend war das zu länglich als daß es jemand gelesen hätte.

    Gelesen hatte ich es, aber ich dachte mir, dass ein "Das braucht aber auf den ersten Blick ziemlich viel Speicherbandbreite und häufige Umschaltung zwischen Lesen und Schreiben" hier zu destruktiv ankommen würde.

  • Ich hatte es gelesen. Nur ist das für mich eine spezielle Sprite-Hardware, auch wenn sie anders/flexibler arbeitet als C64/Amiga-Sprites. Was ist der Vorteil gegenüber z.B. den Amiga-Coprozessoren?

    Na ja, der Blitter ist erstmal was völlig anderes. Aus meiner Sicht war er hauptsächlich notwendig wegen des Blitplane-Gefrickels beim Amiga, um überhaupt einigermaßen flott grafische Objekte in den Bildspeicher zu kopieren bzw. zu maskieren usw. Aber Bitplanes wollen wir ja eh nicht haben, in einen byteweise aufgebauten Bildschirmspeicher kann man einfach per CPU oder DMA reinschreiben. Und genau da setzt mein Vorschlag halt an: um bewegliche Objekte mit möglichst wenig Hardwareaufwand und möglichst wenig CPU-Intervention auf den Bildschirm zu bringen, wird ein einfacher DMA-Transfer etwas aufgebohrt, um (palettenbasierte) Transparenz, Clipping und Löschen (nur) der dynamischen Objekte zu beschleunigen.

    Mal abgesehen davon, daß die CPU nicht in feste Register, sondern in Transferdeskriptoren schreibt, würde sich das Anfühlen wie (fast) beliebig viele HW-Sprites beliebiger Größe und trotzdem müßte man nicht unendlich viel Hardware dafür spendieren.

    Wenn man schon unbedingt Spezialhardware spendiere wollte, fände ich sowas wie das Runterskalieren der Grafikdaten beim Reinkopieren (angelehnt an die Skalierung beim NeoGeo) spannender als einen Blitter.

  • Gelesen hatte ich es, aber ich dachte mir, dass ein "Das braucht aber auf den ersten Blick ziemlich viel Speicherbandbreite und häufige Umschaltung zwischen Lesen und Schreiben" hier zu destruktiv ankommen würde.

    Klar, einen Tod muß man sterben. Das die Speicherzugriffe die CPU ausbremsen könnten und letztendlich auch die Anzahl und Größe der darstellbaren Objekte limitieren würden, hatte ich ja erwähnt. Nur reden wir ja hier nicht von zig Megabytes pro Frame angesichts der niedrigen Auflösung. Und vermutlich könnte man die beiden Bildschirmspeicher komplette im Blockram ablegen und Grafik-DMA-Zugriffe priorisieren usw.

    Und das Thema "Unschaltung zwischen Lesen und Schreiben" kann man sicherlich bereist mit einfachen Puffern deutlich abfedern.

  • Aus meiner Sicht war er hauptsächlich notwendig wegen des Blitplane-Gefrickels beim Amiga

    Anscheinend "brauchte" auch der Atari ST (ohne Bitplane-Gefrickel) einen Blitter – sonst hätte man ihn ja nicht beim STE eingebaut.


    würde sich das Anfühlen wie (fast) beliebig viele HW-Sprites beliebiger Größe und trotzdem müßte man nicht unendlich viel Hardware dafür spendieren.

    Ich war nie ein Freund von starker Sprite-Hardware (für unseren Retro-Rechner), weil ich die Befürchtung hege, dass damit Grafik-Beschränkungen (die wir absichtlich einführen) ausgehebelt werden könnten. Wenn wir z.B. einen Lores-Mode mit doppelt breiten Pixeln haben und die Sprites diese Auflösung nicht übernehmen müssten oder trotzdem pixelweise positioniert werden können (beides beim C64 machbar), dann könnte man durch Überlagerung die Auflösung erhöhen – wenn genügend Sprites verfügbar sind. Das wäre ein Fall, denn ich ungerne sehen würde – weil man sich dann jegliche Einschränkungen gleich sparen könnte.


    Deshalb favorisiere ich Lösungen, die nicht die Bitmap-Einstellungen umgehen können (also Lores-Background mit Hires-Sprites mischen), sondern einfach mit diesen Möglichkeiten auskommen müssen. Das wäre bei Shapes ja der Fall, weil da nichts überlagert, sondern gleich reingerechnet wird.

  • Ich weiß zu wenig über den Atari um sagen zu können, wozu er der Blitter genau gebraucht hat. Aber zunächst mal ist der Blitter ja auch nichts anderes als ein spezialisierter DMA. Er kopiert Bitmuster von A nach B, hat aber halt noch die Möglichkeit, dabei ein zusätzliches Bitmuster reinzurechnen. Das kann man zum Maskieren von Grafikobjekten benutzen oder halt für anderen Schnickschnack. Der Atari hatte wohl irgendwelches "Halftone-RAM", das mit dem Blitter genutzt werden konnte. Oder so.

    So oder so ist ein Blitter architekturell (!) jetzt auch nichts völlig anderes als mein spezialisierter DMA. Also Bandbreite sparen wird man damit zum Beispiel auch nicht.


    Und wenn man wirklich nur einen Bildschirmspeicher hat (was ja durchaus ein diskutabler Ansatz ist und wie erwähnt auch mein erster Vorschlag hier im Thread war), dann hat es sich halt mit Hardware-Scrolling. Bzw. man müßte beim Bewegen von Objekten nicht nur die Pixel an der alten Position mit dem Transparenzindex überschreiben wie in meinem Vorschlag, sondern die Pixel der Hintergrundbitmap restaurieren. Und das gleiche natürlich per se auch bei jedem Hintergrundscrolling oder Tile- bzw. Zeichensatzanimationen - was bei einer unabhängigen Bildschirmebene halt nicht nötig wäre.


    Auch wenn man meinen Grafik-DMA-Vorschlag ablehnt: ein unabhängiger Bildschirmspeicher für bewegte oder (bezüglich des Scrolling) statische Objekte wäre an sich schon eine riesige Erleichterung, weil man sich dann nämlich nicht mehr um das Restaurieren des Hintergrundes kümmern muß, wenn man Objekte verschiebt. Das ganze restliche Konzept sollte nur zeigen, wie man mit dieser Grundidee einen DMA-Zugriff aufbohren könnte, um sowas ähnliches wie HW-Sprites zu bekommen.

  • Eine Laien-Frage dazu: Ein Sprite ist ein beweglicher winziger "Bildschirm", der über einen anderen gelegt wird, und dabei bitweise verschoben werden kann. Ein so beschriebener Layer ist ein riesiges (bildschirmgroßes) Sprite, das man in vielen Fällen nicht bewegen kann. Warum nicht die Konzepte verheiraten und grundsätzlich in verschiedenen Größen Bildschirmbereiche definieren, die man übereinander legen und bitweise positionieren kann?

  • Wir verwenden nen TFP410 von TI. Geht dann auf ne DVI Buchse. HDCP & CEC geht damit aber glaub ich nicht. Wäre aber wohl auch nicht notwendig.

  • Sowas gibt es soweit ich weiss beim Gameboy, dort gibt es sog. "Windows", die man uebereinander schieben kann, vor allem um z.B. ein Pausen- oder "Kontext"-Menue reinzuschieben oder die Punkteanzeige darzustellen. Ist an sich keine schlechte Idee sowas zu haben, vielleicht sogar nicht ausschliesslich fuer Spiele sondern auch fuer alle moeglichen anderen Anwendungen. Aber ob das ein sinnvoller Ersatz fuer Sprites waere? Keine Ahnung, muesste man sich Gedanken machen...