Warum nicht 320x200?
Vielleicht u.a., weil es das schon (sehr oft) gibt?
Runde Räder gibt's auch schon oft. Trotzdem kommt keiner auf die Idee, plötzlich eckige zu bauen, nur um mal was anders zu machen.
Hallo Besucher, der Thread wurde 8,7k mal aufgerufen und enthält 167 Antworten
letzter Beitrag von Retrofan am
Konzept eines Retro/Home-Computers (als Software auf Raspi)
- Retrofan
- Erledigt
-
-
Naja Hardware, auf der das Lua des PICO-8 läuft, gibt es wie Sand am Meer.
Das ist dann aber kein "PICO-8 als FPGA-Core bauen", sondern irgendeine Hardware, auf der die Pico-8-Software läuft. Das ist nicht das, was ursprünglich gesagt wurde.
Ähdoch? Klar gibt es auch haufenweise fertige VHDL-CPUs, auf denen Lua irgendwie zum Laufen zu bekommen ist. Ist aber die Frage, wieso man das machen will. FPGAs sind ja eigentlich nur im Zusammenspiel mit externer echter Retro-Hardware sinnvoll (Steckmodule etc.). Aber wenn's die nicht gibt, braucht man eigentlich auch keinen FPGA, außer man will die Fingerübung halt unbedingt machen.
-
Ich wuerde eher in Richtung 256x192 gehen
Da sind wir ja recht nah beieinander. Ich favorisieren ja 240 x 216 (weil das Teiler der FullHD-Auflösung sind und gleichzeitig durch 8 geteilt werden können) – auf 16:9 skaliert. Die Pixel wären also, ähnlich wie beim C64 in Multicolor, nicht quadratisch. Und für den Editor würde ich ein Mehrfaches dieser Auflösung wählen, z.B. 480 x 216, damit der Text besser lesbar wird als beim Pico/Tic.
Der TIC-80 verwendet übrigens 240 x 136. Horizontal würde das also schon passen. Das ist aber auch schon nicht wenig, wenn man sich die Games so ansieht. Der Unterschied zum PICO ist echt spürbar.
-
Ähdoch?
Ähnein? Du kannst keine reine Software in VHDL bauen. Zeig mir doch bitte die Schaltkreise, aus denen z.B. Photoshop besteht. Klar, du kannst eine Hardware nachbilden, AUF der Photoshop läuft. Das ist aber nicht das, was gesagt wurde. Ist hier aber ohnehin spitzfindig und bringt uns nicht weiter. Niemand kann oder will den Pico in VHDL bauen. FPGA-Cores sind hier nicht das Thema – hier geht es um ein Software-Projekt auf einem Raspi o.ä.
-
Retrofan PICO-8-Programme werden in Lua geschrieben, also braucht man nur irgendeine Hardware, auf der ein Lua-Interpreter laufen kann, also kann man sich irgendwas entsprechendes nehmen, und wie geschrieben wird es da schon diverses VHDL mit CPUs, auf denen man irgendwie einen Lua-Interpreter zum Laufen bekommt, geben. Muss man halt noch eine PICO-8-kompatible Runtime/Library bauen. Ist aber natürlich alles recht sinnbefreit.
FPGA-Cores sind hier nicht das Thema
Öh, dann muss ich #164 falsch verstanden haben, dort hast Du genau das aufgebracht...?
-
Runde Räder gibt's auch schon oft.
Blahblah. Die Sache ist die: jeder Retro-Rechner konkurriert mit den alten. Wer unbedingt Grafiken in 320 x 200 Pixeln bauen will, kann das seit über 35 Jahren tun: Einfach Amiga oder Atari ST nehmen und los geht's. Wo soll da der USP eines neuen Systems sein? Und dieser Thread ist u.a. aus der Idee entstanden, dass die Amiga-Auflösung (den Pixlern) zu hoch ist (Erklärungen sind mannigfaltig vorhanden). Deshalb ja sowas wie Pico oder TIC-80.
Die genaue Auflösung wissen wir noch nicht – aber wir sind sicher, dass sie UNTER 320 x 200 liegen soll.
-
hier geht es um ein Software-Projekt auf einem Raspi o.ä.
Das existiert doch schon in Form vom Pico-8 oder vom entsprechenden OpenSource TIC-80. Das auf dem Raspberry (Pi 400) installiert und fertig ist der "beschränkte" Rechner mit Tastatur und HDMI-Ausgang. Komplett mit fertigem Entwicklungssystem auf dem Fantasy-Rechner.
Ich wüsste wirklich nicht, was den Zeitaufwand rechtfertigen würde, hier das Rad quasi nochmal zu erfinden.
-
Ist aber natürlich alles recht sinnbefreit.
OK, das nehme ich.
Dann sind wir mit dem Thema hoffentlich durch, oder? -
Ich wüsste wirklich nicht, was den Zeitaufwand rechtfertigen würde, hier das Rad quasi nochmal zu erfinden.
Naja, EIN Produkt ist das noch nicht. Und zudem habe ich ja beschrieben, was alles noch an Software/Funktionen fehlt. Und ich will sicherlich keinen Pi 400, der aussieht, wie eine Tastatur. Und vielleicht ist der Pi 400 auch schon zu schnell – das müsste man mal testen. Und die Grafik-Specs vom Pico oder Tic gefallen mir auch nicht unbedingt. Es gäbe also eine ganze Menge, was noch zu tun wäre, um daraus eine runde Sache zu machen.
Hier wurde ja u.a. beschrieben, wie man den TIC-80 bare metal (also ohne Linux) auf dem Raspi zum laufen bekommt. Da stellt sich z.B. auch die Frage, ob das der richtige Weg ist. Man soll ja nach dem Einschalten des Computers direkt in die TIC-Console booten. Das wäre bare metal sicherlich einfach und schnell. Aber dafür müsste man sich dann u.a. wieder selbst um Bluetooth usw. kümmern. Das wäre wahrscheinlich auch eine Menge Arbeit, die einem sonst Linux abnehmen könnte. Bliebe man bei Linux als Host, müsste man darüber nachdenken, wie man das so eindampft, dass man die Extra-Schicht quasi nicht bemerkt.
Aber es könnte halt eine Basis sein, die ersten 50%. Das ist besser, als wenn man bei Null anfängt, wie es bei den anderen hier genannten Projekten der Fall war.
-
Ich sehe das ganze hier auch noch nicht als konkreten Versuch, etwas zu bauen. Ich sehe das eher als generelle Diskussion ueber die Sache selbst. Was waere sinnvoll, was nicht, was wuerde jemanden interessieren, was nicht. Ich finde sowas interessant und auch durch den MEGA65 und die zugehoerigen Diskussionen sind mir da auch neue Erkenntnisse gekommen. Fuer mich muss dieser Thread hier aber nicht am Ende in einem Produkt muenden. Das Ergebnis kann auch sein, dass letztendlich ueberhaupt kein Konsens gefunden werden kann. Auch das waere fuer mich ein valides Ergebnis. Und koennte sogar noch zum Weiterdenken anregen.
-
... um daraus eine runde Sache zu machen.
Der Pico-8 ist hier die "rundeste Sache", die ich mir in diesem Bereich vorstellen kann. Eine größere Nutzerbasis wird schwerlich auf einem anderen, wie auch immer, gelagerten "ähnlichen" Rechner zu bekommen sein.
Das Wichtigste ist hier sowieso die Entwicklungssoftware, die sofort und von Anfang an mitgeliefert werden müsste. "Limitierte" Rechner gibt es ja mehr als genug, sogar echte: Zum Beispiel den VC20. Und wem das noch zu bunt und hochauflösend sein sollte, der greift zum ZX81.
Die Hardware ist hier nicht das Problem.Die Entwicklungssoftware, die den Durchschnittsnutzer direkt in die Hand nimmt und ihm die einfache Möglichkeit bietet, seine Idee umzusetzen, die ist das A und O. Und die ist auf dem Pico-8 wirklich gut gelöst worden.
-
Fuer mich muss dieser Thread hier aber nicht am Ende in einem Produkt muenden.
Für mich auch nicht. Aber das fertige Produkt, also die virtuelle Konsole, IDE, Programmiersprache, Multimedia-Specs, Host-System, Host-Hardware, Gehäuse-Varianten, Internet-Funktionen, Controller-Anbindung, Schnittstellen, Vertrieb, Verpackung usw. gehört für mich alles zu dem Gedanken-Experiment. Ich würde mir gerne das Gesamt-Paket vorstellen können, so wie es unter dem Weihnachstsbaum liegen könnte – nicht "lade doch Tic-80 herunter und installiere das auf einem Raspi aus deiner Schublade".
Und wenn dann am Ende irgendwer sagt – OK ich mache daraus einen Kickstarter – dann ist das toll – aber der Spaß ist vorher, der Weg ist das Ziel.
-
Der Pico-8 ist hier die "rundeste Sache", die ich mir in diesem Bereich vorstellen kann.
Natürlich. Deswegen ist er eine große Inspirationsquelle. Aber er ist halt erstmal nur Software ohne jegliche Beschränkung der Performance. Und er ist vom Output nicht auf 16:9 ausgelegt. Und aus irgendeinem Grund gibt es sehr wenige Multi-Player-Games – fehlt es da an Unterstützung mehrerer oder überhaupt Controller? Und wir können den PICO ohnehin für nichts eigenes nehmen, weil er proprietär und kostenpflichtig ist. Von daher ist der PICO-8 eine tolle Inspirations-Basis – kann uns aber als Produkt nicht weiterhelfen. Daher ja der Schwenk hin zum TIC-80. Der hat vielleicht zu viele Programmiersprachen-Optionen (die man wohl ausdünnen sollte), eine hässlichere Farbpalette und vielleicht auch noch nicht die perfekten Specs – aber wir könnten ihn als Basis verwenden.
-
Jetzt was ganz anderes (als kleines Zwischenspiel): Das Gehäuse. Eigentlich wollen wir ja alle einen Tastatur-Computer, so wie den C64 oder Specci oder Apple IIc. Ein eigenes Layout oder womöglich eigene Keycaps wollen wir sicherlich aus Kostengründen vermeiden, oder? Ein eigenes Gehäuse wäre aber schon cool. Die alte Tastaturgehäuse-Bauform will man zwar aus nostalgischen Gründen haben – aber sie ist nicht unbedingt immer praktisch. Im Wohn- oder Kinderzimmer müsste man ein langes Display- und Stromkabel durchs Zimmer legen, wenn man z.B. am Couchtisch oder auf dem Sofa/Bett coden oder zocken will. Am Schreibtisch wäre das hingegen egal, da steht der Bildschirm in der Nähe. Im Wohnzimmer würde ich es bevorzugen, wenn die Computer-Einheit (heutzutage ein kleines Kästchen) beim TV und in der Nähe einer Stromquelle aufgestellt werden könnte und das Keyboard per Funk kommuniziert. Kein Kabelsalat, keine Stolpergefahr, alles hübsch aufgeräumt. Allerdings meist optisch langweilig gelöst.
Aber was wäre, wenn man beides haben könnte?! Die Enterprise unter den Home-Computern, die abtrennbare Untertassensektion!
Ich stelle mir ein Gehäuse vor, das Keyboard und Zentraleinheit enthält – aber auseinandergenommen werden kann. Problem (kreativ) gelöst. So hätten wir beides – einen coolen Tastatur-Computer mit eigenständiger Optik UND eine kabellose Aufteilung von Zentraleinheit und Keyboard, wenn man es wünscht.Die Elemente könnte ich übereinander oder hintereinander (oder von beidem etwas) positionieren, da habe ich schon ein paar Entwürfe auf dem Zettel.
-
jeder Retro-Rechner konkurriert mit den alten. Wer unbedingt Grafiken in 320 x 200 Pixeln bauen will, kann das seit über 35 Jahren tun: Einfach Amiga oder Atari ST nehmen und los geht's. Wo soll da der USP eines neuen Systems sein?
Bei den alten Rechnern hat jeder seine eigene, sehr spezielle Hardware, mit Dingen wie Hardware-Sprites, "Copper", "Blitter", "Display Lists" und Interrupt-Handling durch sehr spezielle Custom-Chips, die es seit den 80ern nicht mehr gibt und die in darauf zugeschnittenem Assembler programmiert werden müssen, und dazu gibt's noch Speichermangel, den man heute nicht mehr haben müßte. Das ist heute viel zu anstrengend, damit kommt man nicht so schnell so weit, wie man mit einer modernen Sprache kommen könnte.
Stimmt schon, mein Ziel ist es, in einer modernen Sprache wie z.B. Python, 2D-Spiele in der Assembler-Qualität von damals zu schreiben. Und es soll möglichst auch so aussehen wie damals.
Mit Pygame kann ich das im Prinzip schon machen. Nur ist das aus irgendeinem Grund nicht verbreitet, und Leute scheuen sich davor, den Python-Interpreter und die nötigen Module zu installieren. Also ist es bisher nur eine Einzelgeschichte, es sind bisher nur kleine Experimente, die man sich hier mal angucken kann.
Aber ein Stand-Alone-Rechner, der direkt in Python bootet (so wie früher in BASIC) und dann noch mächtige Bibliotheken für die Ansteuerung von Grafik und Sound in einer Retro-Auflösung mitbringt, so daß sich schließlich auch (so wie früher) eine eigene Community entwickelt (ein Rechner etwa vom Format und Preis wie der "Pi 400"), das wäre schon ein Traum, deshalb hatte ich hier mitdiskutiert.
-
next_i https://micropython.org/ plus https://github.com/kitao/pyxel ? (wobei ich nicht weiß, ob man Pyxel unter MicroPython zum Laufen bekommt, kann doch aber nicht so schwer sein(TM) )
-
Aber ein Stand-Alone-Rechner, der direkt in Python bootet (so wie früher in BASIC) und dann noch mächtige Bibliotheken für die Ansteuerung von Grafik und Sound in einer Retro-Auflösung mitbringt, so daß sich schließlich auch (so wie früher) eine eigene Community entwickelt, das wäre schon ein Traum, deshalb hatte ich hier mitdiskutiert.
Ich kann das schlecht abschätzen aber ZeHa meinte etwas weiter oben, dass er den PICO-Lua-Dialekt gegenüber PyGame bevorzugen würde. Ich persönlich mag den Lua-Code sehr gerne, ich finde ihn gut lesbar. Mit Python kenne ich mich gar nicht aus.
Bei den alten Rechnern hat jeder seine eigene, sehr spezielle Hardware, mit Dingen wie Hardware-Sprites, "Copper", "Blitter", "Display Lists" und Interrupt-Handling durch sehr spezielle Custom-Chips, die es seit den 80ern nicht mehr gibt und die in darauf zugeschnittenem Assembler programmiert werden müssen. Das ist heute viel zu anstrengend, damit kommt man nicht so schnell so weit, wie man mit einer modernen Sprache kommen könnte.
Die Hardware-Specs der frühen Home-Computer haben automatisch einen gewissen eigenständigen Look erzeugt, den man bei 320 x 200 Pixeln in 256 Farben nicht mehr hat. Da sieht alles alles gleich aus, egal welche Hardware und welches OS darunter ist. Deshalb versuchen wir hier, auch einen besonderen Look zu schaffen – nur entsteht der halt nicht aus Hardware-Beschränkungen, sondern ist vollkommen frei "erfunden", so wie ihn sich ein paar Pixler wünschen. Er soll aber dazu führen, das die Spiele eigenständig wirken, nicht so, wie auf anderen Plattformen.
Und was wir nicht gebrauchen können, sind Einschränkungen, die die Erstellung nur erschweren – weil man einen Sprite-Multiplexer coden muss oder wissen muss, wo die Sprites im Speicher liegen und so Sachen, die früher natürlich auf einen zukamen. Es gibt "ausreichend" bewegliche Objekte und wo die liegen, ist eigentlich egal (Hauptsache, nicht als Data-Zeilen im Code). Die "Sprites" bekommen Namen und werden so angesprochen und Töne spielt man mit einem virtuellen Keyboard ein. Dafür soll es ja die PICO-ähnliche IDE geben.
Also eigentlich, was du haben willst: Das Coden/Erstellen möglichst angenehm machen, sodass es vielleicht sogar Spaß macht. Auf das Projekt konzentrieren können und sich nicht mit Nickeligkeiten einer Speicherverwaltung herumschlagen. Eine moderne Sprache, kein Assembler.
Im Prinzip ist hier zwischen dir und Zeha eigentlich nur die Frage: Welche Sprache?
-
Die Elemente könnte ich übereinander oder hintereinander (oder von beidem etwas) positionieren, da habe ich schon ein paar Entwürfe auf dem Zettel.
über die Grafik wurde ja schon hinreichend gesprochen, finde ich auch sinnig. Was m.E. etwas zu kurz kommt ist der Sound. Ich hätte gerne einen Yamaha YMF825 mit an Board, den man zusätzlich zu den SOC PCM Sounds mit einmischen können sollte. Als weiteren Vorschlag, ich würde es klasse finden, wenn statt eines Nummernblocks sechs bis acht Music-Touchpads verbaut würden. Dies würde der Erstellung von Beats/Tunes auf dem System m.M.n. entgegen kommen. Vielleicht noch vier bis acht Rotary-Encoder mit dazu, dann hätte man so ein minimales Eingabegerät ohne MIDI implementieren bzw. anbieten zu müssen, und könnte damit auch (angehende) Musiker begeistern (Mehrwert).
Ich wäre auch für den Verbau eines 8-10 Zoll FullHD IPS Displays, statt nur HDMI. Tastatur & Maus könnten für mich auch kabelgebunden sein, ich habe noch nie vom Sofa aus programmiert, für die Spiele-Controller sieht das natürlich anders aus, obgleich ich es toll fände, wenn Sega-Megadrive-6Btn Controller eingeplant würden und dann auch gerne mit Kabel und mit den original Buchsen 4Stk. Bei der angestrebten Auflösung sollte das noch alles gut seh/spielbar sein, auch aus einiger Entfernung.
my 2ct.
-
Verbau eines 8-10 Zoll FullHD IPS Displays,
Dann hätten wir fast ein Notebook (bis auf den Akku). Wäre jetzt nicht so mein Favorit, zumal das den Preis in die Höhe treiben würde.
Was m.E. etwas zu kurz kommt ist der Sound.
Das liegt natürlich daran, dass hier noch kein Sound-Profi mitgemischt hat. Ich freue mich da über jeden Vorschlag – solange er unser Multimedia-Prinzip "weniger ist mehr" einhält. Ein Orchester-Sound würde zu der angepeilten Minimal-Grafik nicht gut passen. Einen speziellen Chip kann es bei unserem Prinzip nicht geben (es gibt ja auch keine CPU) – man könnte höchstens sagen, dass er wie dieser oder jene Chip klingen soll (da müsste man evtl. mit Samples arbeiten) und die Eigenschaften z.B. bzgl. der Stimmen-Anzahl übernehmen soll.
Als weiteren Vorschlag, ich würde es klasse finden, wenn statt eines Nummernblocks sechs bis acht Music-Touchpads verbaut würden. Dies würde der Erstellung von Beats/Tunes auf dem System m.M.n. entgegen kommen. Vielleicht noch vier bis acht Rotary-Encoder mit dazu, dann hätte man so ein minimales Eingabegerät ohne MIDI implementieren bzw. anbieten zu müssen, und könnte damit auch (angehende) Musiker begeistern (Mehrwert).
An einen Nummernblock hätte ich ohnehin nicht gedacht. Ich gehe eher von einer Art kompaktem Notebook-Keyboard aus – das gäbe mir am ehesten ein Homecomputer-Feeling und nimmt möglichst wenig Platz vom Tisch weg. Was du da so alles ins Keyboard integrieren würdest, fände ich zu speziell. Damit müssten ja alle leben, ob Musiker (eher die Minderheit) oder nicht. Ich würde sowas einfach extern anbinden, z.B. per USB.
-
Ich würde sowas einfach extern anbinden, z.B. per USB.
Noch ein Gedanke dazu. Das wäre wahrscheinlich preislich realistisch nicht umsetzbar aber ansonsten cool: Ich habe die Haupteinheit ja jetzt ohnehin modular angedacht – wie wäre es, wenn man das auf Keyboard-Ebene weiterspinnen würde. Man stelle sich vor, rechts am kompakten Keyboard wäre eine Schnittstelle für Erweiterungen. Wer möchte, könnte sich da einen Nummernblock reinklinken, andere nehmen vielleicht lieber ein Touchpad (statt Maus) und ein Musiker halt Musik-Controller. Ein Plugin-Keyboard – hat auch nicht jeder (und ist ohne Erweiterungen schön kompakt).
