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

    Nö, weil jeder Computer kann ein Hallo ausgeben. Wenn man sich einen Computer überlegt, dann sollte der schon etwas mehr können als das, und deshalb wird hier ja auch drüber diskutiert.

    Jein. Aber Du sprichst das Problem ja irgendwie an. Ihr überlegt einen Computer. Das können vermutlich viele. Aber einen Computer zu bauen, der mehr kann, wird schon schwieriger. Das wird eine gewisse Lernkurve geben. Und je höher ihr die Latte legt, desto schwieriger wird es doch für euch?

    Zitat von M. J.

    Wäre die Frage, wer hier "wir" ist.

    Einer oder mehrere von "uns", wer auch immer. Ich hätte auch "man" sagen können. Wie gesagt, ohne Anbindung an moderne Geräte, und sei es, über ein (getrenntes aber internes) "Modern"-Subsystem am Retro-Board, kann ich mir persönlich das Ganze nicht vorstellen. VGA-Aus- und PS/2-Eingabe ist mir dann doch zu vintage für ein aktuelles Retro-System, dass letztlich auch Neulinge ansprechen soll.


    Zitat von M. J.

    Den AtariST kenne ich nicht gut genug, aber beim Amiga hat der Blitter nicht gerade Wunder gewirkt.

    Ich nehme an, dass der Blitter für das Scrolling ein wichtiger Faktor war. Zumindest hatte der ST ohne Blitter damit seine liebe Not (und er wurde dann ja auch beim Mega-ST und STE eingebaut), während der Amiga ohne Probleme gescrollt hat. Gerade die typischen Horizontal-Shooter oder Jump&Runs mit horizontalem Scrolling gab es auf dem ST extrem wenig.


    Giana Sisters hatte auf dem ST noch nicht einmal Scrolling eingebaut:


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


    Das will man echt nicht haben, oder? (Ich weiß, dass es auch Gegenbeispiele gibt, es bleibt aber Fakt, dass Scrolling auf dem Blitter-losen ST eine Herausforderung war und deshalb nur selten vorkam.)


    Zitat von M. J.

    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.

    Für Standbilder kann man das auch ohne Emu, einfach in Photoshop. Habe ich auch schon öfters gemacht. Weiter unten ein Beispiel.


    Zitat von M. J.

    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?

    Ein "Rahmen" sieht aber eindeutig besser aus, wenn er das ganze Bild (möglichst gleichmäßig und so wenig wie möglich) umgibt und nicht nur schwarze Balken links und rechts vom eigentlichen Bild anzeigt. Das ist halt der Effekt, den man kennt, wenn man alte Serien auf HD-Screens guckt. Da fehlt halt was, es wirkt wie eine Notlösung, um Altes auf Neuem darstellen zu können. Aber unser Retro-Computer ist ja nicht wirklich alt, sondern retro.


    Auf einem Flatscreen wirkt aber jeglicher Rahmen irgendwie deplatziert und wie eine Verschwendung von Fläche.


    Zitat von Unseen

    Na ja, wenn VGA geht, geht auch DVI/HDMI mit externem Encoderchip.

    Ich hatte M. J. ja auch schon intern vorgeschlagen, man könne doch das FPGA-Retro-Board um ein "Modern-Daughter-Board" ergänzen, das den Vintage-Output für die heutige Welt umsetzt. Man könnte also so einen "Adapter" auch mit ins Gehäuse setzen, besser wäre allerdings wahrscheinlich ein richtiger Upscaler, der dann auch gleich virtuelle Scanlines und andere Pixel-Aufhübschungen hinzufügen kann (wenn gewünscht). Es gibt z.B. auch aktive USB-Eingabe-auf-PS/2-Buchse-Adapter für rund 10€ Endverbraucher-Preis. Intern und in Massen dürfte das recht günstig zu bekommen sein.


    Zitat von LastLemming

    Bei 768 x 216 hat man aber keinen ganzzahligen Teiler mehr oder ? 1920 / 768 = 2,5

    Dann wäre ja ein Pixel 3 und der nächste 2 Bildschirm-Pixel breit. usw. usf.

    Die beiden für Spiele (und damit für mich wichtigen) Auflösungen haben auf beiden Achsen einen ganzzahligen Teiler zu Full-HD: 5. Und für die höchste Auflösung würde man natürlich nicht jeden 2. Pixel schmaler als den vorherigen darstellen, sondern der Scaler würde alle Pixel gleichmäßig hochskalieren, wodurch eine kleine regelmäßige Unschärfe entsteht, die ich aber als nicht störend empfinde. Hier ein Ergebnis, hochskaliert auf Full-HD mit maximaler Schärfe (also ohne zusätzlichen Blur – wie ihn z.B. VICE bei CRT-Simulation anwendet). Vertikal ist das der glatte Teiler 5 (daher hundertprozentig scharf), horizontal bekommt das Bild eine Unschärfe, die wahrscheinlich die wenigsten auch nur merken würden, da regelmäßig und jeweils nur eine Pixelspalte breit. Selbst das 50%-Schachbrett-Raster in den Augen des Tigers stört das kaum. Und Typo sieht 1A aus – wichtig für Editoren.


    Screenshot768x216>1920x1080.png (bitte in Full-HD-Originalgröße außerhalb des Browsers angucken)


    Aber bei weiteren Experimenten bin ich auch zu einer Lösung gekommen, wie man mit der Basis-Auflösung 320 x 200 evtl. auch zu einer fast flächendeckenden Flatscreen-Abdeckung (ohne Unschärfen) käme. man müsste dann allerdings sogar in der mittleren Auflösung auf quadratische Pixel verzichten. Wenn man das als Pixelkünstler weiß, kann man es ja schon bei der Erstellung der Grafik kompensieren, wie man es ja auch beim C64 tut. Die niedrigste Auflösung hätte dann aber mehr als doppelt breite Pixel (in der Darstellung – rechnerisch natürlich nicht). Insgesamt nicht ganz so elegant aber M. J. könnte es sogar auf seinen VGA-Bildschirmen darstellen (allerdings dann halt quasi verzerrt).


    Wenn man also 320 x 200 Pixel auf Full-HD aufbläst, dann sollte man das evtl. nicht, wegen 16:10 vs. 16:9, mit schwarzen Rändern links und rechts tun (und die Pixel quadratisch lassen – also 1620 x 1080 mit je 150 Pixeln Rand links und rechts), sondern das Bild verzerren, und zwar auf 1920 (320 x 6 oder 640 x 3) in der Breite und 1000 (200 x 5) in der Höhe (also das, was eine Röhre beim C64 auch tut, nur in der anderen Richtung). Dann hätte man je 40 Pixel oben und unten "Letterbox", wie man es von Kino-Filmen im TV kennt. Und das könnte man sogar komplett eliminieren, wenn man vertikal auf 216 statt 200 Pixel gehen würde – das brächte uns auch 2 weitere Zeilen im Editor. Und 216 Pixel vertikal liegen ja auch noch locker in einem Bereich, den VGA darstellen könnte.


    Ich wäre auch versöhnlich mit nur 1620 x 1080 Pixeln auf einem Full-HD-TV – aber das sieht schon sehr danach aus, als hätte man überhaupt nicht an heute übliche Ausgabe-Geräte gedacht und seinen 90er-Jahre "Retro-Stiefel" einfach durchgezogen.


    ----


    Wie gesagt, wenn es keine (schon von Anfang an mit einbezogene) Option für den Anschluss des Retro-Computers an "moderne" Sicht- und Eingabe-Geräte geben sollte, dann fände ich das Ganze nicht sehr spannend – weil die von mir (und anderen) gewünschten ONU-Fähigkeiten des Geräts nicht mehr gegeben wären. Dann wäre ich nur noch Beobachter der ganzen Sache, weil es in eine Richtung liefe, die aus meiner Sicht eine Sackgasse wäre.


    Klar, jeder Retro-Computer mag besser sein als gar kein Retro-Computer – aber gerade, weil ich die Konzepte des Commander X16 und auch Mega65 an einigen wichtigen Stellen für suboptimal halte, hatte ich den Thread ja überhaupt erst gestartet. Kompromisse sind wichtig und nötig – aber ich sehe z.Z. quasi alle mein Felle wegschwimmen und nichts von der ursprünglichen Idee scheint übrig zu bleiben – so macht das natürlich auch keinen Spaß mehr.


    Das soll euch aber nicht ausbremsen – wenn die Mehrheit den Anschluss des Retro-Computers an moderne Geräte für verzichtbar oder nebensächlich hält, dann ist das eben so.

    Hier gibt es nen Thread in dem wir Ideen von vorhandenen Heimcomputern sammeln koennten um mal zu sehen wie der "perfekte" Heimcomputer aufgebaut werden muesste


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

    Ihr dürft nicht vergessen, dass so ein System immer ein Kompromiss ist. Auch bei der Entwicklung der 8 Bit Systeme in den 80ern wurde vieles nicht so gemacht, wie es die Entwickler gerne gehabt hätten, weil man die Kosten im Auge behalten musste.


    In dieses Problem lauft ihr auch gerade. Ja, man kann heute vieles machen, aber dann müsst ihr halt bereit sein, wesentlich mehr Geld in die Hand zu nehmen, was die Anzahl der Mitentwickler reduzieren wird.


    Ulkigerweise ist ja ein guter Teil der Software damals nur in dieser Form entstanden, weil man Hardware Beschränkungen umgehen wollte.

    Zitat von M. J.

    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."

    Würdest du dann auch soweit gehen und zum Beispiel keine grösseren Playfields anbieten, aus den dann ein ausgewählterAusschnitt angezeigt wird, vieleicht sogar ohne Feinscrolling? Wie rudimänter wäre dann die Soundsystem, etwa nur ein einfacher 8-/16-Bit-DAC-Port ohne DMA?

    Zitat von M. J.

    Da hat er wohl recht.

    Stimmt, insofern, als erst einmal die grundsätzliche Funktionsweise etabliert sein will. Wobei ich mir meine Reaktion nicht verkneifen konnte, die war einfach zu naheliegend :food , sollte aber keine Stellungnahme sein. Die Frage ist auch, wie das gemeint ist. Geht es um die Fähigkeit, Zeichen auf den Bildschirm auszugeben, oder eher um ein OS, das genau das tut?

    Zitat von M. J.
    Zitat von DivZero

    Beim ST weiß ich es jetzt gar nicht, ob der auch diesen Bitplane Mist hatte.

    Ja, wenn auch anders angeordnet. Beim Amiga lagen die Bitplanes bei einer 320x200x16-Grafik je nach Mod-Einstellung entweder 8000 oder 40 Bytes auseinander. Um einen einzelnen Punkt zu setzen, war das recht aufwendig. Bei einer horizontalen Linie hingegen (sprich: Polygon) fiel dies weniger ins Gewicht, da sich dadurch die Anzahl der Bytes, die man insgesamt setzen mußte, nicht viel änderte.

    Beim AtariST waren die Planes direkt nacheinander angeordnet in der Form 16 Bits 1. Plane, 16 Bits 2. Plane, 16 Bits, 3. Plane, 16 Bits 4. Plane. Auch hier mußte man für einen einzelnen Punkt viermal schreiben. Da die Planes aber direkt aufeinanderfolgten, konnte man anstelle der Adressierungsart "offset(Ax)" = Basisregister + Offset auch die etwas schnellere Adressierung "(Ax)+" = indirekt mit Postinkrement verwenden.

    Um Programme zu beschleunigen, hat man keine Routine geschrieben für alle Farben, sondern jede Farbe bekam ihre eigene Routine:

    Psst! Die "ORs" in der Amiga-Version sehen merkwürdig aus.

    Zitat von daybyter

    Ulkigerweise ist ja ein guter Teil der Software damals nur in dieser Form entstanden, weil man Hardware Beschränkungen umgehen wollte.

    Deshalb sind wir hier ja z.B. bei überraschend niedrigen Grafik-Fähigkeiten, die unterhalb eines Amiga/ST liegen, eher so auf dem Niveau von CPC und Atari 8-Bit – aber doch anders. Wir hoffen, dass dadurch die Kreativität der DevUser angeregt wird, mit den geringen Möglichkeiten geschickt umzugehen und interessante Ergebnisse zu produzieren.

    Zitat von Retrofan

    Wir hoffen, dass dadurch die Kreativität der DevUser angeregt wird, mit den geringen Möglichkeiten geschickt umzugehen und interessante Ergebnisse zu produzieren.

    Ich denke ich weiß, wie du es meinst.


    Anzumerken wäre hierzu, dass es für einen Entwickler "gefühlsmäßig" einen Unterschied machen könnte, ob er mit Limitierungen umgehen muss, weil diese zur damaligen Zeit eine Notwendigkeit (zeitlich, finanzielle oder technische Gründe) waren oder ob diese Limitierungen heutzutage "rein willkürlich" konstruiert sind.

    Das kann tatsaechlich einen Unterschied machen, somit sollten diese Design-Entscheidungen trotzdem irgendwie technisch nachvollziehbar sein. Beispielsweise 2 Pixel nebeneinander gleiche Farbe = ist nachvollziehbar weil das Sprite / die Chars gleich viel Speicher verbrauchen und an gleicher Stelle abgelegt werden koennen.

    Zitat von ZeHa

    Das kann tatsaechlich einen Unterschied machen, somit sollten diese Design-Entscheidungen trotzdem irgendwie technisch nachvollziehbar sein.

    Das sehe ich auch so. Jede technische Einschränkung sollte für Dritte "nachvollziehbar" sein. So dass man die gut akzeptiert und man einen Anreiz hat, damit umzugehen.

    Zitat von Retrofan

    Wenn man also 320 x 200 Pixel auf Full-HD aufbläst, dann sollte man das evtl. nicht, wegen 16:10 vs. 16:9, mit schwarzen Rändern links und rechts tun (und die Pixel quadratisch lassen – also 1620 x 1080 mit je 150 Pixeln Rand links und rechts), sondern das Bild verzerren, und zwar auf 1920 (320 x 6 oder 640 x 3) in der Breite und 1000 (200 x 5) in der Höhe (also das, was eine Röhre beim C64 auch tut, nur in der anderen Richtung). Dann hätte man je 40 Pixel oben und unten "Letterbox", wie man es von Kino-Filmen im TV kennt. Und das könnte man sogar komplett eliminieren, wenn man vertikal auf 216 statt 200 Pixel gehen würde – das brächte uns auch 2 weitere Zeilen im Editor. Und 216 Pixel vertikal liegen ja auch noch locker in einem Bereich, den VGA darstellen könnte.

    Ich habe mal Beispiele generiert:


    Hier kann man 160 x 200 px (kantenscharf) hochskaliert auf 1920 x 1000 px plus 80 px schwarzen Letterbox-Rand sehen:

    Jump&Run-HD.png Edge-Grinder-HD.png


    Und hier sind 640 x 216 px absolut kantenscharf hochskaliert auf 1920 x 1080 px:

    Workbench640x216>1920x1080.png


    Wenn niemand Argumente gegen 216 Pixel vertikal (bei 640/320/160 Pixel horizontal) anbringen kann, dann wäre das z.Z. mein Auflösungs-Favorit. Vertikal gab es auch früher schon diverse Unterschiede: 192, 200, 224, 240, 256 Pixel oder sogar frei definiert (wie beim Atari VCS) – alles schon da gewesen.

    Zitat von Snoopy

    Jede technische Einschränkung sollte für Dritte "nachvollziehbar" sein.

    Das ist ja das, was wir hier versuchen. Deshalb z.B. die Farbtiefen-Verdoppelung bei horizontaler Auflösungs-Halbierung. Das ist eine Limitierung, die jeder von den alten Maschinen kennt, weil dadurch der Speicherbedarf identisch bleibt.

    Das ist jetzt halt ohne Rand. Viele alte Heimcomputer haben ja einen Rand, den kann man auch beruecksichtigen, der Vorteil ist dass selbst aktuelle TVs oft einen Overscan-Bereich haben (es gibt aber bei vielen einen Game-Mode, oder PC-Mode, der dies abschaltet).


    Wenn man dann z.B. eine Aufloesung wie 320x200 MIT RAND auf 1920x1080 hochskalieren moechte, kann man sie daher mal 5 nehmen, dann bekommt man 1600x1000, d.h. oben und unten ist noch ein Rand von jeweils 40 Pixel und links und rechts ein Rand von jeweils 160 Pixel.

    Zitat von M. J.
    Zitat von LastLemming

    Wie schauts mit dem Löschen des Buffers aus ? Wenn man eh eine Liste hat, müssten nur die einzelnen Pixel gelöscht werden nicht der ganze Screen.

    Mag sein, aber auch hier gibt es den Punkt, an dem es aufwendiger wird, einzelne Pixel zu löschen (deren Koordinaten aus der Liste geholt werden müssen, die wiederum auch gelöscht werden soll) als rabiat den Hintergrund zu löschen. Die Frage ist nur, wann dieser Punkt erreicht ist. Darüber läßt sich an dieser Stelle nur spekulieren, weil schlecht abzuschätzen ist, wie aufwendig genau das Listenverfahren in der Praxis ist.

    Da es keine Hardware gibt, die auf die von Dir genannte Weise arbeitet, bleibt nur eine Möglichkeit: Emulator schreiben und austesten. Womit wir dann wieder beim Thema wären. Oder so wie es Daybyter formuliert

    Naja im Prinzip gibt es das als Hardware. Im HAM Modus nimmt man als Halte-Farbe "Grün-Komponente = 0" und die normalen 16 Farben zum Malen. Es fehlt dann halt der Grünanteil im Bild. Leider gehen die zwei zusätzlichen Planes Zeit bei der CPU klauen, das müsste man bei einem Vergleich entsprechend berücksichtigen.


    Bevor jetzt aber der Teil kommt wo ich 4 populäre Vektorgrafik-Spiele mit einer alternativen Render-Engine realisieren soll hake ich diesen Bereich erstmal ab und schau nochmal in meiner Argumente-Kiste ganz unten nach.


    Hey! Mit dem Modus lassen sich voll einfach Copper-Bars realiseren. Man muss nur die ersten Pixel der einzelnen Zeilen ändern. Cool oder ?


    Mehr is leider nich drin.

    Zitat von ZeHa

    Das ist jetzt halt ohne Rand.

    Das finde ich persönlich bei einem Flat-TV irgendwie logischer und ästhetischer. Die heutige Bildschirm-Hardware versucht möglichst randlos zu sein – dann sollte man da meines Erachtens keinen schwarzen Trauerrand um die Grafik legen. Bei Röhren macht der Rand ja auch dahingehend Sinn, dass man nichts im Overscan-Bereich darstellt, was dann hinter dem Plastikbezel des Monitors verschwindet.


    Aber diese Sachen sollte man halt zeitnah klären, weswegen ich darauf immer wieder hinweise – weil das letztlich auch Auswirkungen haben kann auf die Grafik-Erzeugung (Format etc.). Und was das wiederum für einen Rattenschwanz nach sich ziehen kann, hat M. J. ja eindrücklich erklärt. Nachdem ich mir hier die Finger "wundgeschrieben" habe, kommt der erste darauf, dass ich für alle Berechnungen randlose Darstellung voraussetze. ;)


    Was bei einem Rand zudem problematisch ist, ist der wahrscheinliche Wunsch vieler Programmierer, ihn doch wieder "verschwinden" zu lassen, in dem man dort Sprites, Rasterbars o.ä. darstellt. Das ist aber bisher nicht vorgesehen (auch weil der Rand nach aktuellem Stand vom Modern-I/O-Daughterboard generiert würde, nicht vom Retro-System-FPGA selbst.)

    Ich hoffe nicht, dass solche Bildschirmausgabe bei dem neuen Retrocomputer raus kommen wird. Die wirklich kantenscharfen Pixel sehen fürchterlich aus. Für eine Debugmodus sind solche scharfen Kanten aber sehr gut brauchbar.


    Hier sollen DivUser angesprochen werden? Was ist das? Sind das Leute die schon programmieren können oder die, die es noch vor haben? Mich als Entwickler juckt ein neuer Retrocomputer wenig bis überhaupt nicht, komme ja kaum dazu mich mit dem C64 richtig zu beschäftigen und dann interessieren mich auch noch andere wirkliche Retrosystem aus meiner Jugend. Was mich hier als Entwickler interessieren würde, wäre wirklich die Entwicklung des System und nicht dann mit dem System an sich was zu machen, außer für Tests.

    Naja ein Rand ist aber retro und muss auch nicht schwarz sein, sondern kann auch farbig sein ;)

    Und wie gesagt, moderne Glotzen haben oft auch einen Overscan, der ist zwar nicht so breit aber er ist oft da. Zumindest bei Film- und Fernseh-Material...


    Ich kann aber auch die Sichtweise verstehen, dass man heute ohne Rand auskommen moechte.