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

    Ich gebe Dir an sich recht, muss aber auch sagen dass ich gerade GOTO für einen der am einfachsten zu verstehenden Befehle halte. Gerade als Anfänger im Kindesalter war mir sofort die Logik hinter diesem Befehl klar.


    Es ist allerdings richtig, dass dieser Befehl in den meisten "richtigen" Programmiersprachen nicht vorkommt (zumindest in der Praxis), und das ist auch gut so. Trotzdem kann man nicht leugnen, dass dieser Befehl so ziemlich die simpelste und am leichtesten zu verstehende Abbildung einer Verzweigung darstellt und alles andere schon schwieriger zu verstehen sein kann.


    Ein wahres Dilemma :D

    Zitat von M. J.

    Die normale VGA-Auflösung ...

    ... ist eigentlich seit Jahren tot. Retro ist eine schöne Sache aber es geht dabei darum, heute etwas (mit (nachgebildetem) Altem) zu machen, eine Brücke zu schlagen zwischen alt und neu. Wenn wir also den Bildschirm nicht mitliefern, sollten wir uns daran orientieren, was bei den Usern (auch noch in 10 Jahren) vorhanden ist. Und wenn ich mich hier so umschaue, dann sehe ich (abgesehen von alten Röhren) nur noch 16:9-Screens – vor allem im Wohnzimmer. Und das wird sich ja nicht "bessern" – 4:3 und ähnliches wird (außerhalb von Tablets) aussterben. Warum sollte man also immer schwarze Balken links und rechts darstellen und Fläche verschenken? Außerdem fände ich persönlich es reizvoll, zwar Retro-zu-pixeln – aber in einem anderen Seiten-Verhältnis, als gewohnt.


    Zitat von M. J.

    Alle anderen Auflösungen sind technisch schwieriger zu meistern.

    Solange es nicht unmöglich ist, bin ich guter Dinge. Die Sache ist die, dass man die Hardware später nur an ONUs verkaufen kann, wenn sie diese auch an ihren Fernseher anschließen können. Und der hat üblicherweise keinen VGA-Anschluss. Daher muss alles, was aus einem Retro-FPGA-Board herauskommt (wenn es nicht schon HDMI ist, wie beim Ultimate 64) ohnehin durch einen "Booster" gejagt werden, um kompatibel zur heutigen Welt zu werden. Das ist kein "Kann", das ist ein "Muss".

    Wie sieht es eigentlich mit der Bildwiederholfrequenz aus, 50 oder 60Hz?

    Zitat von ZeHa

    Trotzdem kann man nicht leugnen, dass dieser Befehl so ziemlich die simpelste und am leichtesten zu verstehende Abbildung einer Verzweigung darstellt und alles andere schon schwieriger zu verstehen sein kann.


    Ein wahres Dilemma

    Da hat du sehr wohl recht:thumbsup:

    Zitat von Retrofan

    Reine Bitmap, kein Charmode.

    Frisst dann die Emulation eines Tile-basierten Grafiksystems in Spielen nicht wieder reichlich CPU-Zeit? Fast alle für 2D designten Spielekonsolen (inklusive Saturn und Handhelds) haben Tile-basierte Grafik verwendet und Bitmap höchstens als optionalen, selten verwendeten Zusatzmodus.

    Zitat von Unseen

    Bitmap höchstens als optionalen, selten verwendeten Zusatzmodus.

    Mir persönlich ist es egal, ob man mit Chars/Tiles arbeitet oder mit einer großen Bitmap. Das ist ein Vorschlag von M. J., den ich einfach übernommen habe, da er meinte, dass seine 8-MHz-32-Bit-CPU das locker handlen könne, auch was Scrolling, Shapes etc. angeht. Und es ist natürlich die simpelste (und damit am Besten verständliche) Art, Grafik im RAM zu repräsentieren. Die meisten 16/32-Bit-Computer der 80er-Jahre arbeiten so, von daher fand ich das überzeugend.

    Zitat von M. J.
    Zitat von RKSoft

    für mich sehr wichtig, einfach zu bedienende Sprites

    Wäre für Dich anstelle von Sprites auch die Verwendung von Shapes denkbar? Auf größeren Rechnern (ab Amiga/AtariST usw.) geht man so vor, daß man zwei Bitmaps definiert. Die erste Bitmap guckt sich der Benutzer an. Auf der anderen Bitmap wird die Grafik neu gezeichnet. Dabei malt man zuerst den Hintergrund neu und löscht dadurch gleichzeitig alle Figuren. Dann kopiert man die Shapes in die Bitmap. Ist man fertig, werden die beiden Bitmaps vertauscht. Der Benutzer sieht nun die (fertige) zweite Bitmap, und das Programm malt auf der ersten. Sprites sind bei dieser Methode nicht notwendig, und Shapes sind sogar viel flexibler. Sprites haben leider den Nachteil, daß sie a) in der Größe und b) in der Anzahl irgendwie beschränkt sind. Beim C64 z. B. kann man nur maximal 8 Sprites pro Zeile darstellen, was z. B. bei horizontalen Schüssen viel zu wenig ist. Vertikal kann man zwar mehr Sprites anzeigen lassen, doch gibt es da den Aufwand eines Sprite-Multiplexers. Mit Shapes gibt es all diese Probleme und Einschränkungen nicht.

    Blitz Basic gab es doch ursprünglich auf dem Amiga. Ich arbeite, wenn ich Zeit haben, neben DIV auch in Blitz Basic für Windows. Blitz Max z.B. hat so einiges, was man als Programmierer sich wünschen kann. Es arbeitet mit Bitmaps, allerdings hab ich mir für meine Spiele ein Spritesystem selber erstellt mit Befehlen wie SetSprite(nr, x, y) usw. Sogar eine Scrollingengine hab ich mir damit selber erstellt und so z.B. Plattformer (Mario Klon z.B.) geschrieben.

    Zitat von DivZero

    Tut mir leid wenn ich immer wieder auf BASIC rum hacke, aber diese Sprache ist fürchterlich und untauglich um das Programmieren zu lernen.

    Ich gebe dir völlig recht, was die SW-Entwicklung angeht, da ist GOTO sowieso ein Verbrechen. Aber ich sehe trotzdem, dass es für Anfänger leichter zu verstehen ist. Wenn man alle Schleifen und konditionalen Statements erst einmal auf der Basis begreift, ist es für Anfänger leichter, auf die umzusteigen, als umgekehrt. Anders gesagt: Basic ist für mich ein bisschen wie Assembler, nur nicht so konsequent.

    Zitat von Retrofan

    ... ist eigentlich seit Jahren tot. Retro ist eine schöne Sache aber es geht dabei darum, heute etwas (mit (nachgebildetem) Altem) zu machen, eine Brücke zu schlagen zwischen alt und neu. Wenn wir also den Bildschirm nicht mitliefern, sollten wir uns daran orientieren, was bei den Usern (auch noch in 10 Jahren) vorhanden ist.

    Volle Zustimmung. Ich sehe auch, dass man sich das Leben leicht machen und mit dem arbeiten sollte, was man in jedem Elektronik-Store problemlos kaufen kann.

    Zitat von Retrofan

    Die meisten 16/32-Bit-Computer der 80er-Jahre arbeiten so,

    Ja, ist die Frage was man will. 8Bit mit wenig MHz Programming ist eher die Arbeit mit Zeichensätzen, da für Bitmap zu langsam. 16/32 Bit mit 8MHz kann dann mit Bitmap was anfangen, aber ohne Blitter nur rudimentär(siehe ersten ST ohne Blitter). Also alles eine Frage der Geschwindigkeit. Wenn man schnell genug ist, kommen dann auch schon wieder Doom artige Spiele in Frage, will man das?

    Zitat von Retrofan

    Solange es nicht unmöglich ist, bin ich guter Dinge.

    Zum jetzigen Zeitpunkt ist es für mich unmöglich, höhere Auflösungen zu erzielen als 640 Pixel horizontal. Höhere Auflösungen verlangen, daß die Pixel schneller übertragen werden, und brauchen dadurch einen schnelleren Takt. Nun hängen aber an diesem Takt nicht nur der Videocontroller, sondern auch die SRam-Anbindung, die Audioausgabe und natürlich der Prozessor. Mein jetziges Design ist darauf ausgelegt, mit 50 Mhz als Basistakt zu laufen, was für eine X-Auflösung von 640 passend ist. Jedes weitere FPGA-Modul neben dem Videocontroller teilt zwar diesen Takt für sich auf (z. B. würde eine SID-Implementierung den Basistakt duch 50 teilen, um auf 1 Mhz zu kommen), aber die Kommunikation zwischen den einzelnen Modulen basiert auf besagten 50 Mhz. Dies bedeutet z. B., daß Videocontroller und Prozessor im Basistakt von 50 Mhz auf den SRam-Controller zugreifen, der bei dieser Geschwindigkeit mit dem externen SRam stabil kommuniziert. Würde man diesen Basistakt erhöhen, müßte man gleichzeitig alle Module so anpassen, daß sie ebenfalls mit dem höheren Takt klarkommen. Das ist sehr schwierig und in meinem Fall eben unmöglich, weil die CPU bereits am Limit liegt.

    Theoretisch könnte man die Videoausgabe vom Basistakt abkoppeln und über einen eigenen Takt laufen lassen, doch solch getrennte Zeitzonen im FPGA sind eine häufige Quelle für Fehler, da sich dann die Kommunikation über die Zeitzonen hinweg schwierig gestaltet. (Jeder Wert muß zuerst gelatcht werden, bevor man ihn in der anderen Zone weiterverwenden kann). So muß man z. B. beim Videocontroller die Buszugriffe weiter mit 25 Mhz durchführen (im Wechsel mit der CPU). Da aber die Videouhr intern schneller tickt, kommt eventuell die Speicheranbindung nicht hinterher, und man muß die Datenwörter im Voraus lesen und cachen. Noch schwieriger wird es bei einer Kommunikation über ein Blockram (= Videoram). Der Videocontroller greift für seine Ausgabe auf ein Blockram zu, welches z. B. die Farbpalette als auch die Displaylist beinhaltet. Der Prozessor jedoch liest und schreibt ebenfalls in dieses Blockram. Nun verfügt mein FPGA zwar über ein Dual-Port-Blockram (CPU und Videocontroller können gleichzeitig darauf zugreifen) und über Dual-Clock-Ram (Ein- und Ausgänge können verschieden getaktet sein), aber nicht über ein Dual-Port-Dual-Clock-Blockram. Folglich müßten z. B. alle Prozessorzugriffe wieder irgendwie abgepuffert werden. Das jedoch verträgt sich schwer mit dem allgemeinen Bussystem, welches davon ausgeht, daß das zu lesende Datenwort im Folgetakt vorliegt oder zumindest das Signal bekommt, ob der Zugriff möglich ist.

    Also: Takterhöhung geht zum jetzigen Zeitpunkt nicht. Da spielen SRam und CPU nicht mit. Und verschiedene Zeitzonen sind gefährlich für die Stabilität des Systems, fehleranfällig und aufwendig umzusetzen. Nichts für Anfänger wie mich.

    Zitat von Retrofan

    Warum sollte man also immer schwarze Balken links und rechts darstellen und Fläche verschenken?

    Wenn die Anzahl der Zeilen auf 180 reduziert wird, wäre dies eher eine Verschwendung von Fläche.:(

    Zitat von Unseen

    Frisst dann die Emulation eines Tile-basierten Grafiksystems in Spielen nicht wieder reichlich CPU-Zeit? Fast alle für 2D designten Spielekonsolen (inklusive Saturn und Handhelds) haben Tile-basierte Grafik verwendet und Bitmap höchstens als optionalen, selten verwendeten Zusatzmodus.

    Natürlich frißt sie CPU-Zeit. Dafür ist die CPU halt schneller als ein 1 Mhz-6502. Es soll ja auch ein Retrorechner sein und eben keine Spielkonsole mit spezialisierter Hardware für einen bestimmten Typus von Spiel. Daher greife ich in dieser Hinsicht gerne auf das Motto der Archimedes-Entwickler zurück, das sinngemäß lautet: "Alles, was in Software erledigt werden kann, macht die Software, und die Hardware ist so einfach wie möglich zu halten."

    Wenn es das Ziel sein soll, daß ein bestimmtes System gleichzeitig umgesetzt werden kann als FPGA oder Emulator auf einem Pi, Tablet, Smartphone oder PC, sollte man die Hardwaredefinition auch so einfach wie möglich belassen. Jedes Spezialfeature frißt nämlich andersherum LEs auf dem FPGA und jede Menge Power auf dem Hostsystem des Emulators.

    Prinzipiell finde ich es auch reizvoller, dem Programmierer ein weißes Blatt (eine leere Bitmap) zu übergeben mit dem Hinweis: Du kannst damit machen, was Du willst, als ihn von vornherein in eine bestimmte Richtung zu schubsen. Tile-Spiele gab es auch auf dem AppleII (z. B. "Lode Runner", "Ultima" oder "Mr. Robot"). Daneben erschienen aber ebenso Spiele wie "Conan", "The Bard's Tale" oder "The Goonies", die eben nicht auf Kacheln basieren und daher anders aussehen und funktionieren. Meine Befürchtung ist, daß bei einer Hardwarevorgabe mit Sprites und Kacheln sich Programmierer nur auf diese Features stürzen, dafür ein/zwei Programme schreiben und nicht mehr, weil sich die Fantasie darin erschöpft hat. So war ich z. B. erstaunt, als ich ein Video ansah von "Metal Dust", welches bekanntlich auf der SCPU läuft. Ich hätte erwartet, írgendwie ein Spiel zu finden, das die hohe Geschwindigkeit kreativ einsetzt und anders ist als herkömmliche Spiele auf dem C64, wurde in dieser Hinsicht aber enttäuscht. Noch ein horizontal Zeichensatz scrollender Shooter. Ja, das Spiel ist gut programmiert, hat ein paar digitale Töne und einen Haufen bunter Sprites, aber was wirklich Neues konnte ich darin nicht erkennen.

    Zitat von RKSoft

    Es arbeitet mit Bitmaps, allerdings hab ich mir für meine Spiele ein Spritesystem selber erstellt

    Ich nehme an, die "Sprites" beruhen im Grunde genommen auf Shapes, oder? Dann wirst Du entweder die Methode verwendet haben wie beschrieben oder Du hast jeweils den Bildschirmhintergrund unter dem Sprite in einem Puffer gerettet und beim Löschen der Figur daraus restauriert. Welchen Weg auch immer Du verwendet hast, führt es ja am Ende dazu, daß ein Sprite auf einem Shape basiert. Wenn Du also so gut mit BlitzBasic und dem Bitmap-Prinzip klar gekommen bist, dürfte es Dir und vielleicht auch anderen kein Problem bereiten, auf gleiche Weise auf einem Retrorechner zu arbeiten. Ich würde sogar sagen, Du wärest damit ein idealer Programmierer für ein erstes Demospiel. ;)

    Zitat von Snear

    die CPU ist eine 100% kompatible 6510, besitzt 64KB internen Speicher und schreibt nur noch Werte "nach draußen", die für VIC, CIA und SID notwendig sind

    Da der VIC auf die gesamten 64 kb zugreifen kann, gibt es beim C64 solch einen internen Speicher nicht. Machbar wäre wohl, den Speicher zu verdoppeln, also quasi einen schnellen Speicher für die CPU und einen langsamen Speicher für den VIC. Schreibt die CPU in ihren Speicher, wird der Wert nachfolgend in den Speicher für den VIC übertragen. Alle Lesezugriffe auf den CPU-Speicher laufen dagegen viel schneller ab, so daß es nur noch bei einem raschen Schreiben mehrerer Werte nacheinander gelegentlich ein wenig hakt. Dann kann man noch den CPU-Speicher ausbauen auf mehr als 64 kb, sei es durch Banking oder einen anderen Prozessor wie den 65816. Auf dieses erweiterte Ram kann dann der Prozessor auch schreibend schnell zugreifen, weil es nicht mehr in das VIC-Ram kopiert werden muß. Und dann ... hat man sowas wie die SCPU. ^^

    Zitat von Snear

    Wo genau ist das Problem die als Registerstack zu verwenden?

    Der "Registerbus" ist eine Verbindung im Inneren des Prozessors, die die Register (z. B. A, X, Y oder S) mit anderen Modulen des Prozessors (wie z. B. die ALU) verbindet. Das gleiche Prinzip des Datenbus bei einem Speicher existiert also auch im Prozessor selbst, nur daß es hier um den Transport der Registerwerte im Prozessor geht. Ohne einen allgemeinen Registerbus müßte man für jedes Register eine eigene Verbindungsleitung ziehen z. B. zur ALU, was die Komplexität drastisch erhöht.

    Ein interner Speicher in einem Prozessor funktioniert auch nicht viel anders als ein normaler Ram-Speicher. Es gibt einen Adreßbus, auf dem bestimmt wird, von welcher Stelle gelesen bzw. in welche hineingeschrieben werden soll, und es gibt einen Eingang für die zu schreibenden Werte und einen Ausgang für die zu lesenden Werte. In jedem Fall kann aber zunächst nur jeweils ein Wert gelesen oder geschrieben werden. Nun gibt es auch besonderes Ram, welches über zwei Ein-/Ausgänge verfügt: Dual-Port-Ram. Damit könnte man tatsächlich zwei Register gleichzeitig schreiben. Vielleicht gibt es auch ein Tertial(?)-Port-Ram, jedoch habe ich so eins noch nicht gesehen. (Bin aber alles andere als ein Experte.) Solch ein Tertial-Ram hätte 3 Eingänge und 3 Ausgänge und damit schon mindestens 3 Bussysteme (sofern man auf einem Bus Lesen und Schreiben gleichzeitig erlaubt, sonst wären es 6). Solch ein Design ist recht aufwendig.

    Eine Lösung für das Problem wäre, anstelle von 3 Bussen zu je 8 Bit und einem Ram mit 3 Ein-/Ausgängen nur einen Bus mit 24 Bit und ein Ram mit einem Ein-/Ausgang zu nehmen. Der interne Stapelzeiger wird dann nicht um 3 erhöht, sondern um 1, weil ein Speicherwort nun nicht mehr 8, sondern 24 Bit breit ist. Das kann man machen, doch schränkt man damit diesen Stapelspeicher ein auf die Verwendung als Speicher für 24 Bit-Werte. Die Frage wäre, ob das lohnt, denn der Befehl PUSH_AXY bzw. PULL_AXY ist eher selten im Programmcode anzutreffen, so daß auch dieser zusätzliche Aufwand (24 Bit-Bus mit Ram) sich kaum lohnen wird.

    Zitat von M. J.

    Wenn die Anzahl der Zeilen auf 180 reduziert wird, wäre dies eher eine Verschwendung von Fläche.

    Jein. Die Fläche wäre ja immer die des TV-Screens und je näher das Seitenverhältnis dem entspräche, desto weniger schwarze Balken (tote Fläche) sind vorhanden. Das Bild wäre ja immer hochskaliert. Aber ich bin ohnehin nicht sehr für die 180er-Auflösung, sondern eher für


    a) 384 x 216 @ 4 (und daraus ergebend: 192 x 216 @ 16 und 768 x 216 @ 2). Die Auflösungen ergeben sich aus der Full-HD-Auflösung von 1920 x 1080 Pixeln (HD/5 beim mittleren Modus).


    Zitat von M. J.

    Zum jetzigen Zeitpunkt ist es für mich unmöglich, höhere Auflösungen zu erzielen als 640 Pixel horizontal.

    Tja, das lässt mich an dem Konzept jetzt doch etwas zweifeln. Wenn wir keine vernünftige Ausgabe auf heutige TVs hinbekommen (also das Seitenverhältnis einhalten, Scaler und HDMI/DVI-Port sind eh Grundvoraussetzung), dann wäre die Hardware für mich persönlich wahrscheinlich "gestorben". Ich glaube nicht, dass sich mehr als eine Handvoll Leute finden werden, die auf dem Sperrmüll nach gammeligen VGA-Bildschirmen suchen (und sich die auch noch irgendwo zusätzlich hinstellen), um da eine nagelneue Retro-Konsole anzuschließen. :(


    Für Spiele könnte man allerdings auf die hohe Auflösung (768x216) verzichten – die bräuchte man ohnehin nur für den Code-Editor (und vielleicht noch andere Anwendungen). Man könnte also auf 640x216 gehen und den Scaler das Bild in die Breite zerren lassen. Im Text/Code-Editor wäre es am unwichtigsten, wenn die Darstellung verzerrt ist. Die anderen Auflösungen (384 x 216 @ 4 und 192 x 216 @ 16) könnten bestehen bleiben. Das wäre für mich ein erträglicher Kompromiss.

    Zitat von ZeHa

    Dazu gab es hier sogar mal einen Thread :)


    Das Wort "Retro"

    Jeder hat eine andere Vorstellung von "retro" und meine scheint nicht so ganz nah dem zu sein, was andere darunter verstehen. Vielleicht liegt es daran, dass ich vom C16 relativ schnell auf einen XT mit 4,7Mhz gewechselt bin und diese Kiste für mich heute auch "retro" ist. "Retro" heißt nicht immer gut. Es gibt Dinge, die waren sehr positiv und es gibt Dinge, die meiner Meinung nach eher negativ waren.


    Positiv:

    1. Langlebige und reparable Hardware. Am besten Teile verwenden, die es heute noch neu zu kaufen gibt und deren Verfügbarkeit auf lange Sicht garantiert ist. Oder eben solche Teile, die so oft produziert worden sind, so dass man sie problemlos nachkaufen kann. Ein Computer, an dem ich nicht mehr mit dem Lötkolben rumbasteln kann, ist für mich nicht "retro".


    2. Zero Lag. Ich glaube da Bedarf keiner weiteren Erklärung.


    3. Kurzes Booten.


    4. Erweiterbarkeit innen und einfache Schnittstellen nach außen. USB hat eher nichts an einem Retro-Computer verloren. HDMI sehe ich schon kritisch und sollte, wenn er dabei ist, nicht der einzige Video-Anschluss sein.


    Negativ:

    1. BASIC beim Einschalten. Ich fand das irgendwie schon immer ulkig. Wie oft bitte nutzt man den BASIC-Interpreter? Bei MS-DOS wird das gestartet, was man häufigsten braucht: eine Shell, mit der man problemlos Datei-Operationen durchführen kann und Programme bequem starten kann. Ich habe früher viel und gern in BASIC programmiert. Das C16-Basic, GW-BASIC und später Quickbasic. Ich wäre bei MS-DOS nicht auf die Idee gekommen GW-BASIC am Ende der autoexec.bat zu starten. Ich kenne einige, die sowas wie den Norton Commander automatisch gestartet haben, aber einen BASIC-Interpreter? Niemals.


    2. Eine eingebaute Tastatur ist vielleicht für viele "retro", aber ich finde sie störend. Die Tastatur am C64 ist ein Graus und die am Amiga auch nicht sonderlich gut. Es ist schon nett, sich seine Tastatur selbst aussuchen zu können.


    3. 3,5" Disketten. Die Dinger sind das unzuverlässigste Speichermedium, was es jemals gab und ich habe sie schon vor 20 Jahren aus meinem Haus verbannt. Ich will so ein Ding nie, nie wieder anfassen müssen. :)


    Was Sound und Video betrifft, bin ich ziemlich tolerant. Am Ende wird der benutzt, der sich am besten für die Anwendung oder das Spiel eignet. Beim C64 gibt's ja auch Spiele, die den Character-Mode und solche, die den Bitmap-Modus verwenden. Ein MS-DOS-PC konnte auch lange hohe Auflösungen darstellen. 800x600 in 16 Farben waren selbst mit 256K-Grafikkarten möglich. Genutzt hat es kein Spiel, weil es zu langsam war. Es muss irgendwo ein vernünftiges Verhältnis zwischen Taktzyklen und Pixelzahl da sein. HD-Auflösung wäre für den C64 ziemlich sinnlos, weil man von Frame zu Frame ja quasi nichts ändern kann. Bei Audio ist für mich der SID genauso retro wie der Adlib-Sound. Auch hier bin ich absolut leidenschaftslos, wobei der SID natürlich besser klingt. :)


    Von den derzeitigen bzw. kommenden Retro-Computern gefällt mir der Commander X16 am besten. Er behält alles bei, was positiv war und hält nicht an allem fest, was negativ war. Für welchen Soundchip man sich da letztlich entscheidet, ist gar nicht so wichtig. Ich kann nicht einschätzen, ob ein neuer Retro-Computer wie der Phoenix C256, der MEGA65 oder der Commander X16 irgendwann "kult" wird, aber wenn es tatsächlich einer schafft, wird es der X16 sein. Da bin ich mir ziemlich sicher. So ein Projekt zu überbieten, dürfte schwierig werden, insbesondere bei so unterschiedlichen Vorstellungen. Das ist völlig normal - wäre ja auch traurig, wenn hier alle einer Meinung wären. :) Aber so ein "neuer Retro-Computer im 8-Bit-Style" wird nur dann entstehen, wenn einer einfach loslegt und andere mitziehen. So war es ja auch beim C256 oder X16. Bis dahin bleibt es eine muntere und unterhaltsame Diskussion.

    Zitat von Snear

    Von den derzeitigen bzw. kommenden Retro-Computern gefällt mir der Commander X16 am besten.

    Ich finde den auch OK aber mich stören dann doch zu viele (von mir hier teils schon aufgezählte) Dinge, um ihn mir zu kaufen. So ein Gerät muss mich richtig "kicken", sonst kann ich auch bei meinen "Altgeräten" bleiben.


    Zitat von Snear

    Bis dahin bleibt es eine muntere und unterhaltsame Diskussion.

    Mit dem geringen Anspruch ist der Thread ja auch gestartet worden – und wenn es dabei bleibt, haben wir nichts verloren und alle etwas dazugelernt.


    Und wenn sich jemand findet, der etwas von den Ideen umsetzen will (egal ob in Hard- oder Software), wäre das quasi ein Bonus, über den sich viele freuen würden. Ich würde mich natürlich bei einer zustande kommenden Realisierung im Rahmen meiner Möglichkeiten und Kenntnisse einbringen, wenn gewünscht, aber federführend sollte das jemand machen, der sich mehr mit der nötigen Hard- und Software auskennt.

    Zitat von DivZero

    16/32 Bit mit 8MHz kann dann mit Bitmap was anfangen, aber ohne Blitter nur rudimentär(siehe ersten ST ohne Blitter)

    Hmm... Den AtariST kenne ich nicht gut genug, aber beim Amiga hat der Blitter nicht gerade Wunder gewirkt. Ich hatte an anderer Stelle schon darauf hingewiesen, daß von den mir bekannten 3d-Spielen nur "F18 Interceptor" und "Interphase" den Blitter zum Füllen von Flächen einsetzen. "Carrier Command" und verwandte Spiele der gleichen Engine benutzen den Blitter zum Malen von LInien, horizontalen Flächenlinien und Rechtecken. DIe wirklich schnellen 3d-Spiele wie "No Second Prize" oder "Virus" verwenden den Prozessor nur zum Löschen des Hintergrunds und stützen sich ansonsten auf den Prozessor. Nachteil des Blitters: Auch das Setzen der Blitterregister kostet viel Zeit. Nach dem Start des Blitters stiehlt dieser dann auch noch der CPU Taktzyklen, so daß das parallel zum Blitter laufende Programm ausgebremst wird. Da ein Blitter über einen DMA-Kanal zum Speicher verfügen muß, der wiederum mit dem Videocontroller kollidiert, würde ich solch eine Hardware aus dem Design lieber heraushalten. Ich finde eher, daß Spiele wie "No Second Prize" oder "Zeewolf" gezeigt haben, daß man auch ohne Zusatzhardware viel aus einer Kiste herausholen kann.

    Zitat von DivZero

    Ich habe gespannt deine super professionelle Argumentation gegen die Takterhöhung gelesen und dann kommt dieser Spruch

    Bin halt Realist.

    Zitat von Retrofan

    Wenn wir keine vernünftige Ausgabe auf heutige TVs hinbekommen

    Wäre die Frage, wer hier "wir" ist. Ich bin ja nur ein Entwickler, der zuhause vor sich hinbastelt mit den Möglichkeiten, die sich ihm anbieten. Das heißt, daß mein FPGA kein HDMI erzeugen kann, weil er dafür zu langsam ist. Außerdem habe ich nur zwei alte VGA-Bildschirme herumstehen. (Neue Bildschirme kaufe ich nicht mehr, da ich nur noch mit einem Laptop arbeite.) Da wäre in meinem Fall also schon mal die Hardware überhaupt nicht gegeben, und solange ich mit dem FPGA auskommen kann, werde ich den auch weiter verwenden. Wenn irgendwann einmal der Punkt gekommen ist, an dem ich den ausgereizt habe, kann ich über einen Wechsel nachdenken, aber das dauert sicherlich noch eine Weile.

    Das Alles schließt aber nicht aus, daß jemand anders, der mehr Ahnung hat als ich und über entsprechende Hardwaremöglichkeiten verfügt, sich hinsetzt und auf seinem FPGA mit HDMI-Ausgang das System implementiert mit Direktanbindung an einen 16:9-Bildschirm. Mittels Emulator wäre es auch sofort möglich, z. B. beim Pi. Anstelle also jetzt an dieser Stelle eine bestimmte Auflösung als absolut verbindlich vorzugeben, sollte man erst einmal einen Emulator schreiben und gucken, ob das Ergebnis dem entspricht, was man sich vorgestellt hat.

    Zwei Punkte gebe ich allerdings zu bedenken:

    1.) Damals[tm] war ein Rahmen um das Anzeigebild völlig normal. Rechner wie der AppleII hatten dabei nicht einmal die Möglichkeit, die Rahmenfarbe zu bestimmen. Warum sollte das also heute bei einem Retrorechner ein Problem sein?

    2.) Auflösungen sollten wenn möglich horizontal ein Vielfaches von 16 oder besser 32 aufweisen. Bei einer monochromen Auflösung bedeutet ein Bit entweder Pixel an oder aus. Bei einem 16 Bit-Datenbus (, den man bei einem 32 Bit-System voraussetzen kann), ergeben sich daraus 16 Pixel pro Speicherzugriff, und bei einem schnelleren 32 Bit-Datenbus können schon 32 Pixel auf einen Schlag geladen werden. (Solch einen Sprung von 16 auf 32 Bit gab es z. B. vom Amiga500 auf den Amiga1200.) Das bedeutet konkret, daß eine Auflösung von 180, 360 oder 720 Pixeln damit schon mal rausfallen würde.

    Zitat von M. J.

    Das heißt, daß mein FPGA kein HDMI erzeugen kann, weil er dafür zu langsam ist.

    Na ja, wenn VGA geht, geht auch DVI/HDMI mit externem Encoderchip. Nur wenn man direkt DVI-artige TMDS-Signale im FPGA erzeugen will muss der irgendwie die Daten mit zehnfachem Pixeltakt rauspusten, entweder per dediziertem Transceiverblock oder mittels entsprechend hoch getaktetem Shiftregister.

    HDMI geht, wenn Du die Daten parallel in ein schnelles Schieberegister schickst, wo sie halt seriell wieder rausgeschoben werden. Solche Boards machen das z.B.


    https://www.ebay.com/itm/HDMI-…le-Connector/253556239737


    Problem ist, dass Du auf dem FPGA genug Pins brauchst, um das Board zu bedienen (das mini-dev Board hat insgesamt nur 89 Pins, wird also nicht reichen).


    Ich hab gesucht, und das billigste Board mit integriertem HDMI, das ich gefunden hab, war dieses:


    https://shop.trenz-electronic.…x-Zynq-7010-MYS-7Z010-C-S


    (siehe diese Liste: https://joelw.id.au/FPGA/CheapFPGADevelopmentBoards )


    Knapp 106,- , hat dann aber halt u.a. einen 667 MHz Arm, 1 GB Ram, Gigabyte Ethernet usw an Board.


    Nicht schlecht, aber als wir damals die FPGA Bastelei angefangen haben, war halt u.a. die Idee, dass man einen möglichst niedrigschwelligen Einstieg anbieten sollte. 100,- geben viele Leute nicht mal nur so zum Spass aus. Zumindest ich nicht, wenn ich keinen Plan hab, ob ich das gekaufte Produkt auch wirklich oft verwenden werde.


    Maik hat mal einen Konverter VGA => HDMI empfohlen, der gerade mal knapp 10,- kostet:


    https://www.ebay.de/itm/VGA-au…rter-Adapter/312515673750


    Aber: wenn man das Projekt so im Geiste von Grant Searle's Multicomp Projekt machen würde, also unterschiedliche Module bastelt, dann würde ja auch nix dagegen sprechen, dass es eine VGA Ausgabe _und_ eine HDMI Ausgabe gibt. Muss halt jeder entscheiden, ob ihm der native HDMI Ausgang 100,- wert ist... :geld: