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

letzter Beitrag von Retrofan am

Neuer Retro-Computer im 8-Bit Style

    Zitat von ogd

    Ok, aber wie sähe dann ein (unkompliziertes) Basic aus, dass zwei CPUs bedienen kann?

    Ich denke da an einen Rechner, der zwei gleiche und auch gleichwertige 8bit-CPUs (z.B. zwei Z80) hat, die auch gleichwertig auf einen gemeinsamen Speicherbereich zugreifen und schreiben können, ebenso gleichwertig mit Sound, Grafik, Speichermedium und Eingaben umgehen können.


    Ich hatte im Studium mal das Vergnügen an einer solchen Simulation zu arbeiten. War ganz interessant, weil es die Art des Programmierens doch sehr ändert und erweitert.


    Im Prinzip kann man sich das wie zwei getrennte Rechner vorstellen, jede CPU lädt ihr "eigenes" Basic-Programm. Zusammenarbeiten und sich "absprechen" könnten sich die CPUs jeweils z.B. über sog. Semaphore. Wichtig wären da z.B. neben der Absprache beim Speicher usw. auch Möglichkeiten für einen synchronen Start/Stop der CPUs.


    So wäre zum Beispiel denkbar, dass eine CPU sich hauptsächlich um den Sound kümmert und die andere um die Grafik. Für jede CPU schreibt man ein BASIC-Programm und lädt diese vor Programmstart in die jeweilige CPU.


    Im Studium hatten wir z.B. als Spiel eine Art "Pong" entwickelt, links ein Schläger und rechts einer. Und jede Seite wurde von jeweils einer CPU gesteuert. Da haben beide CPUs gegeneinander gespielt und auf jeder lief quasi das gleiche Programm. Die Schwiergkeiten dabei beim Entwickeln und dann das Erleben, wie es klappt, war schon interessant und eine neue Erfahrung für mich damals.


    Klar wäre sowas nicht jedermanns Sache und manche fänden das auch langweilig. Ist ja auch ok, das ist schon ein sehr spezieller "Wunsch". Für mich wäre das halt ein Beispiel, wie man was "Frisches" im 8bit-Bereich entwicklen könnte, was es so als "ein Rechner" mit zwei gleichwertigen(!) CPUs noch nicht gab (von eventuellen speziellen Erweiterungskarten vielleicht mal abgesehen).

    Ihr habt da mal dolle Ideen...ich weiss nicht...


    Im Moment seh ich ja unsere Probleme, überhaupt nur 1 CPU mit Daten zu versorgen, während der Grafikcontroller permanent Daten zieht, um ein buntes Bild zu schmeissen. Vielleicht wäre so ein Mehr-CPU Rechner leichter zu implementieren, wenn man nur eine serielle Schnittstelle dran baut und ein Terminal dran hängt...aber gibt es wieder Geschrei, dass ihr ja dolle Spiele schreiben wollt, und so..

    Zitat von Snoopy

    Ich hatte im Studium mal das Vergnügen an einer solchen Simulation zu arbeiten. ... Im Prinzip kann man sich das wie zwei getrennte Rechner vorstellen, jede CPU lädt ihr "eigenes" Basic-Programm. ... Im Studium hatten wir z.B. als Spiel eine Art "Pong" entwickelt, links ein Schläger und rechts einer. Und jede Seite wurde von jeweils einer CPU gesteuert.


    Und ihr habt das auch in Basic umgesetzt?

    Zitat von Snoopy

    Ich denke da an einen Rechner, der zwei gleiche und auch gleichwertige 8bit-CPUs (z.B. zwei Z80) hat, die auch gleichwertig auf einen gemeinsamen Speicherbereich zugreifen und schreiben können, ebenso gleichwertig mit Sound, Grafik, Speichermedium und Eingaben umgehen können.

    Ach so, du willst SMP. Sag das doch...


    Zitat

    Für mich wäre das halt ein Beispiel, wie man was "Frisches" im 8bit-Bereich entwicklen könnte, was es so als "ein Rechner" mit zwei gleichwertigen(!) CPUs noch nicht gab (von eventuellen speziellen Erweiterungskarten vielleicht mal abgesehen).

    Spontan fallen mir da als Beispiele die Commodore IEEE-Laufwerke und einige Wersi-Synthies mit zwei 680x-CPUs ein. Ob irgendwer wahnsinnig genug war das in einem Computer (statt "nur" dessen Peripherie) so umzusetzen weiss ich nicht, aber wundern würde ich mich nicht wenn jemand ein Beispiel ausgraben kann.

    Zitat von ogd

    Was hat denn für euch den Ausschlag für den V9958 gegeben?

    Wir wollten einen Chip verbauen, der halbwegs gängig ist, und den es noch (zumindest als New Old Stock) zu kaufen gibt, man ihn also nicht aus einem funktionierenden Rechner rausreißen muss. So wirklich viele Optionen gibts da anscheinend nicht. Daher haben wir mit dem TMS9929 angefangen. Irgendwann wollten wir dann höher hinaus, und haben mit dem V9958 dann den Nachfolger des Nachfolgers des TMS9929 genommen.

    Zitat von Snoopy

    Ich denke da an einen Rechner, der zwei gleiche und auch gleichwertige 8bit-CPUs (z.B. zwei Z80) hat, die auch gleichwertig auf einen gemeinsamen Speicherbereich zugreifen und schreiben können, ebenso gleichwertig mit Sound, Grafik, Speichermedium und Eingaben umgehen können.

    Arcade Maschinen hatten häufig ähnliche Setupos um die Limitierung der langsamen Hardware zu umgehen. Wäre also durchaus auch noch Retro. :)

    Zitat von Snoopy

    Ich denke da an einen Rechner, der zwei gleiche und auch gleichwertige 8bit-CPUs (z.B. zwei Z80) hat, die auch gleichwertig auf einen gemeinsamen Speicherbereich zugreifen. [...] Klar wäre sowas nicht jedermanns Sache und manche fänden das auch langweilig. Ist ja auch ok, das ist schon ein sehr spezieller "Wunsch".

    Ich finde das eine witzige Idee. Allerdings, wie du schon sagst, etwas speziell. Und damit wahrscheinlich zu speziell für ein Umsetzung in dem hier angestrebten Projekt. Bei aller freier Suche nach Möglichkeiten ist es doch ein Ziel, dass der ausgedachte Rechner massentauglich sein sollte – also letztendlich kein Bastelprojekt für Einzelne.


    Überzeugen könntest du mich nur, wenn du mir erklärst, welche Software auf so einem Rechner entstehen könnte, die nicht auf einem Single-CPU-Rechner möglich wäre. Ich habe ja nun, wie die meisten hier, den Sprung von einer CPU (einem Core) auf 2, 4, 8, 16 usw. mitgemacht und ich sehe zwar die Performance-Steigerung – aber einen qualitativen Sprung bei der Software habe ich da nicht wirklich bemerkt. Sind die Games beim Wechsel von Single-Core auf Dual-Core wirklich besser geworden? Oder standen die Entwickler nur vor der Herausforderung, mit viel Aufwand ihre monolithischen Programme in Threads aufzusplitten, die dann parallel abgearbeitet werden können? Wäre den Spiele-Codern ein doppelt so schnell getakteter Core nicht viel lieber gewesen als 2 langsame? Alleine von der Komplexität her? Also ich betrachte das ganze vom Ergebnis her und da sehe ich bei 2 CPUs einfach keine Vorteile.


    Zitat von ArnoldLayne

    Wir wollten einen Chip verbauen, der halbwegs gängig ist, und den es noch (zumindest als New Old Stock) zu kaufen gibt, man ihn also nicht aus einem funktionierenden Rechner rausreißen muss. So wirklich viele Optionen gibts da anscheinend nicht.

    Da die meisten hier angedachten Umsetzungen von Emulation oder FPGA ausgehen, haben wir dieses Problem glücklicherweise nicht. Wir können im Endeffekt jeden Grafikchip haben, den man (also die, die Ahnung davon haben) sich vorstellen kann. Mein Favorit ist nach wie vor der vom M. J. beschriebene VIC IIx2, der die Fähigkeit des VIC II moderat anhebt (horizontale Auflösungs-Verdoppelung). Ich habe da ja noch eine überarbeitete Palette beigesteuert, die die Möglichkeiten des VICs nochmals etwas verbessert.


    Was ich da als Vorteil ansehe, ist, dass viele Pixel-Grafiker ihre Erfahrungen vom C64 (größte Vintage-Plattform) übertragen könnten aber trotzdem auch etwas Neues vorfinden (doppelte Auflösung und veränderte Palette). Diese typischen Malerei-artigen Pixeleien mit den weichen Übergängen sind auf CPC, Specci und Co. (die nicht weniger Farben haben) nicht wirklich umsetzbar – auf dem VIC IIx2 aber schon. Und das ganz ohne Farbpaletten-Overkill mit 64, 256 oder tausenden von Farben.


    Zwei Dinge würden mir auf dem Chip aber noch fehlen. Zum einen so eine einfache (und CPU-freundliche) Möglichkeit, wie auf dem Atari, den sichtbaren Bildschirm-Bereich auf einer größeren Map zu verschieben – und zum zweiten, zusätzlich zur bekannten VIC II Sprite-"Engine" noch eine "Bullet"-Engine für meinetwegen 8 einfarbige Char-große "Missiles" zu bekommen, damit man Schüsse nicht immer mit Chars (im Char-Raster) simulieren muss, wenn die Sprites nicht reichen. Je nach CPU-Leistung könnten allerdings beide Wünsche wahrscheinlich auch vom Prozessor erfüllt werden.

    Zitat von Retrofan

    Da die meisten hier angedachten Umsetzungen von Emulation oder FPGA ausgehen, haben wir dieses Problem glücklicherweise nicht.

    Schon klar. Die Idee beim Steckschwein war ursprünglich, einen 8bit-Computer zu bauen, den es früher hätte geben können, damit waren FPGAs quasi raus. Allerdings hatten wir in den letzten Jahren genug feature bzw. scope creep, dass wir FPGAs oder auch CPLDs gegenüber inzwischen aufgeschlossener sind, und da wird auch noch was kommen. Wobei ich da erstmal an glue logic und MMU denke und weniger an Videochip.

    Der thread ist inzwischen zu lang um zu checken dass das nicht schon mal eingebracht wurde, also ignoriert mich, wenn ich was doppelt auffuehre, aber kennt Ihr diesen Vortrag?


    [Externes Medium: https://www.youtube.com/watch?v=CDPeeURxy78]


    Kurz gefasst geht es darum, wie man ein professionelleres Speichermanagement an eine 6502 anbinden kann, und mit ganz wenig zusaetzlicher Hardware weitaus groessere Speicherbereiche als nur 64kb ansprechen kann, mit konkreten Vorschlaegen. Damit waeren auch sowas aehnliches wie virtuelle Maschinen moeglich. z.B. eine, die die Entwicklungsumgebung laufen laesst, und eine, auf der assemblierter/kompilierter Code dann ausgefuehrt werden koennte. Die Maschine in den ersten 64k als Hypervisor fuer die anderen. Ich denke mit sowas sollte man doch alle gluecklich machen koennen. Wahrscheinlich sollte man damit auch per Erweiterung eine C64-kompatible Umgebung anbinden koennen.


    Was haltet Ihr davon?


    Gibt es nicht sogar noch immer neue 6502? Sind die nicht auch inzwischen schneller taktbar als auf dem C64?

    Zitat von ogd

    Und ihr habt das auch in Basic umgesetzt?

    Das war von der Uni eine extra für diese Simulationsumgebung geschriebe Sprache, die mich allerdings ziemlich an BASIC erinnert hat. Das waren eine Handvoll Befehle, die die Simulation interpretiert hat. Wenn ich mich richtig erinnere, war sogar Schritt für Schritt-Ausführung beider CPUs möglich mit Darstellung des jeweils aktuellen Status. War schon ein interessantes Teil. Ich wüsste zumindest nicht, was gegen ein entsprechendes BASIC sprechen würde. Wir reden hier ja auch weiterhin von kleineren Programmen mit "Test-Demo-Charakter".

    Zitat von Retrofan

    Überzeugen könntest du mich nur, wenn du mir erklärst, welche Software auf so einem Rechner entstehen könnte, die nicht auf einem Single-CPU-Rechner möglich wäre.

    Theoretisch könntest du bei einem z.B. fiktiven "Doppel-C64" zwei Programme gleichzeitig auf dem Rechner laufen lassen. Du tippst zum Beispiel in der Textverarbeitungen deinen Text und auf der anderen CPU wird dein Apfelmännchen berechnet. Und zwar während du die Textverabeitung benutzt ohne dass die Berechnung nenneswert ausgebremst wird.


    Von dieser Gleichzeitigkeit zweier Programme könnten auch Spiele profitieren, aber das ist schon ein Mehraufwand für Programmierer.


    Wie gesagt, dass ist schon ein sehr spezieller Wunsch, wo eindeutig die Technik bzw. die neuen Aspekte der Programmierung überwiegen. Insofern gehe ich auch nicht davon aus, dass dieser Wunsch mehr als einen Freund davon finden wird. "Überzeugen" probiere ich erst gar nicht. :)

    Zitat von Snoopy

    Insofern gehe ich auch nicht davon aus, dass dieser Wunsch mehr als einen Freund davon finden wird. "Überzeugen" probiere ich erst gar nicht.

    OK, dann speichere ich das mal als "netten Nebenstrang" im Gedächtnis ab und konzentriere mich wieder auf den Hauptstrang der Diskussion. :)

    Zitat von Retrofan

    Zwei Dinge würden mir auf dem Chip aber noch fehlen. ... und zum zweiten, zusätzlich zur bekannten VIC II Sprite-"Engine" noch eine "Bullet"-Engine für meinetwegen 8 einfarbige Char-große "Missiles" zu bekommen, damit man Schüsse nicht immer mit Chars (im Char-Raster) simulieren muss, wenn die Sprites nicht reichen.


    Ich bin eher kein Freund von solchen "Spezialfällen", weil dadurch die Programmierung oft komplizierter wird..Auch deshalb hatte ich ja weiter oben (Neuer Retro-Computer im 8-Bit Style) schon vorgeschlagen, lieber die X- und Y-Dimensionen der Sprites flexibeler zu gestalten, indem man z.B. 8x8-Pixel-Sprites zu grösseren gruppieren kann.

    Zitat von ogd

    Ich bin eher kein Freund von solchen "Spezialfällen"

    Wie gesagt, evtl. sind sie gar nicht nötig, weil eine schnellere CPU den Job erledigen kann. Aber falls nicht, habe ich einfach mal eine Alternativ-Idee in den Raum geworfen. Bei der Betrachtung des VIC II Chips dachte ich mir: Würde man wirklich die Sprites, die ohnehin schon 2/3 der Die-Fläche einnehmen, nochmals erweitern? Der Chip-Flächenverbrauch dieser kleinen Bild-Objekte war ja schon damals irgendwie verrückt – das hat sich auch kein anderer Hersteller getraut. Selbst im Amiga gab es weiterhin nur 8 Hardware-Sprites. Deshalb dachte ich daran, dass man damals vielleicht einfach eine schwächere Zusatz-Engine (halt 8 kleine, monochrome Missiles) (in Anlehnung an die Atari-Missiles) den mächtigen Sprites hinzugesellt hätte.


    Dazu kommt, dass ich vermeiden möchte, dass findige Grafiker/Coder sehr leicht die gewollten Auflösungs- und Farbbeschränkungen aushebeln, indem sie alles vollflächig mit Overlay-Sprites vollkleistern können. Von daher bin ich lieber vorsichtig, was die Leistungsfähigkeit der Sprites angeht.

    Na ja, wer die Sprites für softwaremäßige Spezifikationserweiterung nutzt, hat aber keine Sprites mehr zum Bewegen. Und wenn man es so macht, wie bei den C64-Lemmings, finde ich es nur fair. Ein paar Sprites mehr, und man hätte die ganze Breite verwenden können. Anders als mit Sprites drüber/drunter wäre es gar nicht gegangen, solange man den Colorclash nicht abschafft. Das finde ich deswegen ohnehin viel wichtiger als viele Sprites. Zumindest sind 8 bewegliche Sprites auf dem gesamten Schirm nicht so sehr der Brüller. Warum bei bestimmten Anforderungen kein Multiplexing hilft, hatte ich weiter oben schon erklärt.


    Mal ehrlich, was möchte man wirklich?


    Man möchte als Entwickler darauf ein Spiel entwickeln. Je einfacher und effektiver, desto schneller, komplexer oder umfangreicher.


    Wir haben festgestellt, dass sich eine nicht zu große Punkt- und Farbauflösung positiv auf Entwicklungsgeschwindigkeit und System-Charakter auswirkt. Das gleiche gilt auch für den Sound. Die typische 8bit-Charakteristik entsteht mitunter durch den Mangel an Kanälen (steht sogar auf Wiki so beschrieben). In Zahlen (und nach m.M.): Maximalstens 6! Für Musik eigtl. nur 4, aber dadurch, dass man Sfx braucht, reduziert sich das oft von allein in einem Spiel. Natürlich kommen noch ein paar andere Dinge hinzu, die die Arbeit vereinfachen und 8bit-typisch machen, bspw. die vorgegebene Kachelung.


    Das ist alles ok und so gewünscht. ABER: Was ich nicht mehr bräuchte, sind zusätzliche Beschränkungen, die man dann wieder mühselig durch Tricks versucht, zu umgehen oder gar als Softwarelösung zu ersetzen, was sich gerade ein 8-Bitter nicht so sehr leisten kann. Damit hält man sich dann auf, ohne das eigentliche Spiel zu programmieren. Das hatte mich damals schon genervt. Zum Glück muss man beim C64 heute nicht mehr die ganzen Räder neu erfinden, aber es gibt noch genug Hürden, die einen immer wieder vom wesentlichen abhalten bzw. dabei aufhalten. Und genau dazu gehört das Problem mit den wenigen Sprites und der Bitmap-/Charmode-Spezifikation, die das alternative Shaping erschwert. Entweder mehr Sprites nebeneinander oder ausreichend Bitplanes würde ich wünschen. Und andererseits: Wenn man alle Farben direkt nebeneinander darstellen könnte, bräuchte man ja gar kein Overlay aus Sprites mehr, und dann dürften es auch mehr Sprites sein. :)


    Der Grund, dass ich weiter oben/vorne sagte, dass die Anzahl mal Breite der Sprites gleich der Bitmap-Breite sein sollte, hat wiederum nichts mit Software-Modi oder so zu tun, sondern allein damit, dass, wenn man schon Sprites multiplexen muss, diese auch aneinander vorbei wandern können sollten. Wie gesagt, bei einem 2-Player-Spiel, in dem das aufgrund der Strategie notwendig ist, kann man sich bei 8 Sprites also ganze 6 NPCs leisten, ohne von Items, Effekten oder Projektilen gesprochen zu haben. Etwas mehr dürfte es schon sein.

    Zitat von ogd

    Ich bin eher kein Freund von solchen "Spezialfällen", weil dadurch die Programmierung oft komplizierter wird..Auch deshalb hatte ich ja weiter oben (Neuer Retro-Computer im 8-Bit Style) schon vorgeschlagen, lieber die X- und Y-Dimensionen der Sprites flexibeler zu gestalten, indem man z.B. 8x8-Pixel-Sprites zu grösseren gruppieren kann.

    Wie wäre es mit etwas Inspiration vom Neo Geo: Sprites mit fester Breite von 8 Pixeln, aber beliebiger Höhe und dafür deutlich mehr davon pro Scanline.

    Für mich macht es auch einen Unterschied ob ich jetzt lernen will wie man auf dem C64 programmiert oder auf einem neuen 8-Bit Rechner. Sprite Multiplexer Farbeinschränkungen, irgendwelche überlagerten Speicherbereiche würde mich eher abschrecken was für den neuen 8-Bit Rechner zu machen.


    Die Limitation von Auflösung von 320x200 32 Farben, 4 Stimmen Audio(Synth und Samples) und 256kBytes Ram zum Beispiel würde mir als Beschränkung locker reichen. Die ganzen Krämpfe, die man auf dem C64 und dann noch in Assembler machen muss, ist nichts was Spaß macht. Da ist es eher ein: "Guckt mal ich habe was brauchbares auf so einem mies zu programmierenden System hinbekommen." oder "Schaut, ich habe mich durch all die Stolperfallen durchgeboxt, damit ich dann endlich mal mit dem Spieldesign anfangen konnte."


    Beim neuen 8-Bit System würde ich mich lieber auf die Spielprogrammierung konzentrieren, also auf die Stolperfallen, die man damals zwangsläufig hatte, weil es besser nicht ging.


    Heimcomputer waren damals vieles, aber einfach zu programmieren waren sie leider nicht. Viele viele Hürden musste man überspringen bis man mit der eigentlichen Arbeit anfangen konnte.


    Wenn man denn unbedingt in Assembler programmieren muss, was ich auch nur aus Nostalgie-Gründen mache, dann ist der CPU Typ wichtig. Dort ist es hundert mal angenehmer einen 68000er vor sich zu haben, als einen 6502, wo man wegen der wenigen Register für jede Kleinigkeit ein Fass aufmachen muss. Programmiere ich in C, ist mir die CPU komplett egal, da die Sprache ja als portabler Assembler genutzt wird. Jede Abstraktionsschicht ist ein Segen, je mehr man an die Hardware und die CPU muss, desto weniger Zeit hat man um sich um das eigentliche Spiel oder die Demo zu kümmern.


    Wie gesagt, beim C64 oder Amiga macht es Spaß zu versuchen durch die ganze Materie durch zusteigen um dann irgendwann mal mit der eigentlichen Arbeit(dem Spiele/Demo-entwickeln) anfangen zu können. Aber bei einem neuen System würde es mich Null reizen mich durch Limitationen durch zu kämpfen die nicht hätten sein müssen. Damals ging es leider nicht anders zu dem Preis.


    Für einen kompletten Programmieranfänger würde ich auch niemals einen C64 oder vergleichbares empfehlen, da ist so ein Pico8 wesentlich einfacher zu handhaben. Einen C64 oder Amiga zu programmieren ist hardcore.


    Was noch weniger Spaß macht ist auf dem System selbst zu entwickeln, jedenfalls geht es mir so. Ich bin da einfach zu PC verwöhnt, wo alles so viel einfacher von der Hand geht und man sich viel mehr auf die eigentliche Aufgabe konzentrieren kann.

    Gute Frage, für mich ist das Programmieren auf C64 und Amiga eher eine geistige Herausforderung zusammen mit dem Nostalgie-Gefühl. Da ist man schon stolz, wenn man so einigermaßen begreift was man für Klimmzüge machen muss um die einfachsten Sachen zu programmieren.

    Zitat von enthusi

    Wieso sollte man auf einem 'retro 8 bit Rechner' programmieren wollen wenn man Tricks und Hardwarebesonderheiten scheut?

    Diesem Problem muss sich jedes neu entwickelte "Retroprojekt" stellen. Das ist halt das prinzipielle Problem bei einem neuen 8bit-Projekt.


    Bei den Rechnern von damals sieht man die Limitierungen als eine Art Herausforderung und nimmt sie als Programmierer auch an, weil es "damals halt so war".


    Bei einem heute neu entwickelten 8bit-Rechner sind viele damalige Limitierungen im Grunde nicht mehr zwingend notwendig und erscheinen deshalb mehr oder weniger "willkürlich". Das macht ein "sich Hineinknien", um mit diesen Limitierungen umzugehen schwerer. Wenn man weiß, dass eine Limitierung "nicht sein müsste", dann tut man sich mit einer Akzeptanz einfach schwerer.