Hello, Guest the thread was viewed4.4k times and contains 167 replies

last post from Retrofan at the

Konzept eines Retro/Home-Computers (als Software auf Raspi)

    Quote from Retrofan

    Ich kann das schlecht abschätzen aber ZeHa meinte etwas weiter oben, dass er den PICO-Lua-Dialekt gegenüber PyGame bevorzugen würde.

    Hmmmmmmmmmm da bin ich mir nicht sicher ob ich das behauptet habe. Ich nutze beides ganz gerne, habe aber auch an beiden durchaus Kritik ;)

    Falls Du das im Video meintest - da habe ich evtl. gesagt, dass man bei PyGame mehr Code benoetigt. Das liegt aber nicht an der Sprache selbst, sondern eher daran, dass PICO-8 halt ein Gesamtsystem ist (ich will jetzt nicht "Engine" sagen, aber es ist irgendwas zwischen Engine und Framework - vor allem ist da vieles fest vorverdrahtet), waehrend PyGame "nur" eine Library ist.

    Quote from Retrofan
    Quote from SprintC128

    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.

    Das Ding kann auch OPL3 direkt abspeielen, das entspräche der Zeit von Monkey Island unter DOS ... Es gibt keine CPU, aber ein Gehäuse? Also wovon redest Du, ich dachte Du wolltest ein erweitertes TIC-80 auf einem SOC ablaufen lassen und dies dann in ein Gehäuse stecken, und wenn das so ist, dann hast Du ja eine CPU, und damit kann auch via SPI der Chip angesprochen werden. Man ersparrt sich dann die PCM Wrickelei, das spart Rechenleistung, und man erweitert die Musik-Editoren, um den Chip entsprechend zu programmieren, das geht via WebMIDI, kann also nicht Rocket-Science sein. Ich sehe nicht warum es nach ZX Spectrum klingen sollte.

    Mit den Eingabgeräten ist das natürlich so eine Sache, Du hast Recht USB steht zur Wahl, dann reden wir aber auch von Hosted Linux und nicht mehr von Bare Metal, das muss dann auch klar sein und Linux ist unter Musikern nicht wirklich häufig, das hat Gründe, auch technische. Wenn es für Dich egal ist, wie die Musik erstellt wird, ggf. als Import vom PC/MAC, dann gilt das gleiche natürlich auch für die Grafik und den Text. Dann würde ja so ein AndroidStick reichen, auf dem das läuft, wozu ein Gehäuse auf dem Tisch stehen haben?


    RPI400 soll es nicht sein, OK, finde ich auch shiet! Aber muss das Ding noch einen extra Monitor benötigen, der dann in 22"iger Pracht den ohnehin vollen Schreibtisch vollstopft? Du hast bei mir ein Bild von etwas Vertikalem erzeugt, dass zusammengesetzt wenig Platz einnimmt und dass, wenn Zeit da, schnell einsatzbereit ist, ohne dass ich Monitore umstöpseln, aufstellen oder sonst etwas muss. Ich finde die Switch da genial, für sowas kleines findet sich immer ein Plätzchen.


    und ja, warum sollten nicht auch mal Designer Drehreglern und Touchpads ausgesetzt sein, vielleicht bringt es ja den einen oder anderen zum Ausprobieren und spielen mit Sounds und Musik. Wäre ja nicht das Schlechteste. Und lecker an old-school FM Sounds rumbasteln, da finden sich sicher viele die da Bock drauf haben. über Kosten hatten wir uns ja noch nicht unterhalten, oder?

    Quote from Retrofan
    Quote from Retrofan

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

    Das hatte ich erst nach meinem Post gelesen:


    Die Idee finde ich gut, es sollte nur ein Bogen um USB gemacht werden, das bedeutet immer Linux und das zieht Latenzen nach sich, insbesondere auf "kleinen" SOCs. Deswegen wollte ich das auch direkt verbauen. Wenn dass z.B. via SPI oder Equi. nachträglich angesteckt werden können soll, dann kann ich auch damit leben.

    Quote from emulaThor

    Edit: Außerdem ist es mir etwas peinlich, dass ich durch die Auskopplung aus dem anderen Thread jetzt als Thread-Starter dastehe. ;(

    Dieser Thread ist 2020 ausgekoppelt worden und seitdem stehe ich als Threadersteller da. Ich habe diesen Thread nicht erstellt und ich glaube, ich habe auch das Threadthema nicht formuliert, obwohl es stimmt, dass die Diskussion eingegrenzt werden sollte auf Raspberry Pi, dafür wurde dieser Thread von Retrofan ausgekoppelt - das war seine Entscheidung.


    Nun geht es hier aber nicht um einen Raspberry Pi und ich habe auch das Interesse an dieser Diskussion verloren.


    Gleichzeitig bin ich nicht glücklich damit, dass ich diesen Thread, den ich selbst nicht erstellt habe, dauernd sehe und dazu eigentlich nichts zu sagen habe.


    Was kann man da tun?

    Wie sollte die Ausstattung hinsichtlich Musik(-wieder und -ein)gabe sein. Hättest Du da eine Idee?

    Quote from emulaThor

    Dieser Thread ist 2020 ausgekoppelt worden und seitdem stehe ich als Threadersteller da. Ich habe diesen Thread nicht erstellt

    Das ist ein Automatismus. Ich habe eine Anzahl von Postings aus einem alten Thread herausgelöst und der zeitlich älteste ist automatisch der erste im Thread und der wird von der Forums-Software als Thread-Starter benannt. Mir ist normalerweise vollkommen schnuppe, wer einen Thread "gestartet" hat – der hat weder besondere Rechte noch Pflichten. Aber wenn dein Herz so sehr daran hängt, dass du nicht mehr genannt wirst, mache ich mich im Ursprungs-Thread auf die Suche nach einem Posting von mir, das noch älter ist als deines und wenn das nicht vollkommen sinnentstellend ist, verschiebe ich den hierhin, damit ich dann als Thread-Ersteller benannt werde. Aber bitte gib mir Zeit und nagle mich nicht darauf fest. Ich finde das zwar unnötigen Aufwand aber was tut man nicht alles, um andere glücklich zu machen.


    Quote from emulaThor

    Nun geht es hier aber nicht um einen Raspberry Pi

    Doch, schon. Es geht darum, eine bestimmte Software auf einem PI zum Laufen zu bekommen – und zwar entweder bare metal oder mit (einem abgespeckten) Linux drunter.

    Quote from Retrofan
    Quote from Snoopy

    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.

    Es wurde ja im Thread schon mal erwähnt, aber evtl. wäre auch der OK64 was für deine Anforderungen: https://lemonspawn.com/ok64/

    6502-Prozessor mit 1 MHz, Sid Chip, Fantasie-Grafik.

    Die Auflösung und Farbtiefe entspricht nicht deinen Anforderungen, aber der Emulator ist als Open-Source verfügbar. Den Grafikteil an deine Anforderungen anzupassen sollte erheblich weniger Aufwand sein, als so was von Grund auf zu coden.

    Wollte nur mal zum Pico 8 (aus User/Gamer-Sichtweise) einwerfen: Ich bin oft auf der Seite und spiele online einfach mal drauf los, weil das meist Games ohne Lernkurve sind.


    Kein Installieren, kein Konfigurieren, keine 32 Tastatur-Belegeungen und Moves auswendig lernen müssen!


    Also genau das, was wir vor 40 Jahren an Arcade und deren ersten Umsetzungen auf dem 64er vorfanden.

    Mir ist wumpe, ob 320x200 oder 128x128 oder 1920x1080... auch wenn ich Pixel präferiere gehen auch genauso Klassiker in Neuauflage wie https://superhardboiled.itch.io/drone-raider

    pasted-from-clipboard.png


    Wie gesagt - mir egal auf welcher HW das (im Original) läuft - es muss PROBLEMLOS auf meinem PC laufen (in Emu oder native - I don't care ;) )

    Quote from ZeHa

    da bin ich mir nicht sicher ob ich das behauptet habe.

    Sorry, dann hatte ich mich da falsch erinnert. Ich wollte dir nichts in den Mund legen.


    Quote from SprintC128

    ich dachte Du wolltest ein erweitertes TIC-80 auf einem SOC ablaufen lassen und dies dann in ein Gehäuse stecken, und wenn das so ist, dann hast Du ja eine CPU

    Ach, du meinst die CPU des Raspis? Dem willst du einen echten Hardware-Soundchip zur Seite stellen? Wäre mir egal, wenns nicht zu viel kostet (also vielleicht 1/10 vom Raspi selbst). Ich bin davon ausgegangen, dass Grafik und Sound oberhalb der echten Hardware ablaufen, also in der TIC-ähnlichen Software definiert werden. Die Grafik-Specs würden wir ja auch nicht in der Raspi-GPU, sondern innerhalb der TIC-Software (also Ebenen höher) definieren.


    Quote from SprintC128

    Ich sehe nicht warum es nach ZX Spectrum klingen sollte.

    Nein, muss es nicht. Im Sinne der einfach zu benutzenden IDE soll es aber auch ungeübten möglich sein, ein paar nette Melodien oder Sound-Effekte zusammenzuklicken. Wenn ein Profi mehr herausholen kann, schön – aber die Zugänglichkeit für Sound-Laien muss, wie bei der Grafik, gewährleistet sein. Also nicht zu viel wollen – genau das haben wir hier bei der Grafik versucht – und genauso soll es beim Sound sein. Weniger ist mehr. Für mich wäre z.B. bei 4 Stimmen/Channels (Atari 8-Bit) Schluss – dann kann man ohne Tricks Musik und ein paar Geräusche gleichzeitig abspielen. Stereo wäre OK, weil die HDMI-Ausgabe und viele TVs das unterstützen. Das wäre ein subtiler Effekt, der sich nicht aufdrängen würde.


    Wenn der Sound trotzdem unique wäre, hätte ich aber überhaupt nichts dagegen.


    Quote from SprintC128

    Wenn es für Dich egal ist, wie die Musik erstellt wird

    Egal ist mir das nicht. Ich bin nur bisher davon ausgegangen, dass Sound am Amiga oder C64 oder Pico-8 mit Trackern auf dem Bildschirm gemacht wird. Mit Tastatur oder Maus. Dass man dafür auf einmal "sechs bis acht Music-Touchpads" und "vier bis acht Rotary-Encoder" auf der Tastatur benötigt, ist mir entgangen. Sowas würde ich nicht unbedingt in ein Standard-Keyboard integrieren wollen, wenn das kein ausgesprochener Musik-Computer sein soll. Aber als optionale Keyboard-Erweiterung wäre das natürlich OK. Aber bitte versteh', dass Sound zwar dabei sein soll aber die Erstellung nicht der primäre Zweck des Rechners wäre.

    Quote from Freudentaumel

    6502-Prozessor mit 1 MHz, Sid Chip, Fantasie-Grafik.

    Es sind ja nicht nur die harten Grafik-Specs, die dieses Konzept antreiben, sondern vor allem auch die leicht zu erlernende Interpreter-Sprache (bisher wurde Lua, wie beim Pico, favorisiert, Python wurde auch genannt) und die sehr zugängliche IDE. Beides sehe ich auf einem 1 MHz 8-Bitter nicht. Außerdem haben wir jetzt schon so viele Retro-Rechner im Markt, die sich auf Commodore Rechner beziehen, dass ich mir nicht unbedingt einen weiteren mit 6502 und SID wünschen würde. Mit der Lösung, gar keine CPU zu definieren und eher an der Oberfläche zu bleiben (wie halt TIC und PICO) bin ich eigentlich sehr zufrieden.

    Ich habe mir mehrfach Pico und Tic angesehen, werde damit aber einfach nicht warm,ir fehlt der Charme eines "echten" Geräts. So geht es mir bei jeglicher Emulation am PC, es kommt kein richtiges Gefühl auf. Meine Hoffnung lag auf dem Mega65, aber da ist mir der Preis zu hoch.


    Ein Pi in einem ansprechenden Gehäuse würde zumindest bei mir mehr zusagen als eine ordinäre PC Tastatur.


    Was die Fähigkeiten betrifft würde ich mir wünschen daß er dezent oberhalb des C64 liegt, aber noch weit vom Amiga entfernt. Und natürlich schönere Farben...


    Und jetzt schweige ich wieder und hoffe, das am Ende auch was herauskommt, was man irgendwann auch in Händen halten kann.

    Weil es hier zum Thema passt. Da bin ich gerade darüber gestolpert:


    OK64 : The OK 8-bit computer


    Edit: Okay, ich sehe gerade, dass ich paar Beiträge zu spät dran war. War keine Absicht! :D

    Quote from Retrofan
    Quote from Freudentaumel

    6502-Prozessor mit 1 MHz, Sid Chip, Fantasie-Grafik.

    Es sind ja nicht nur die harten Grafik-Specs, die dieses Konzept antreiben, sondern vor allem auch die leicht zu erlernende Interpreter-Sprache (bisher wurde Lua, wie beim Pico, favorisiert, Python wurde auch genannt) und die sehr zugängliche IDE. Beides sehe ich auf einem 1 MHz 8-Bitter nicht. Außerdem haben wir jetzt schon so viele Retro-Rechner im Markt, die sich auf Commodore Rechner beziehen, dass ich mir nicht unbedingt einen weiteren mit 6502 und SID wünschen würde. Mit der Lösung, gar keine CPU zu definieren und eher an der Oberfläche zu bleiben (wie halt TIC und PICO) bin ich eigentlich sehr zufrieden.

    OK, dann hatte ich deine Anforderungen missverstanden.

    Du hattest geschrieben, dass dich am PICO stört, dass es keine Beschränkung der Performance gibt. Das macht in meinen Augen nur Sinn, wenn man einen schwachbrüstigen Prozessor targeted/emuliert. Eine moderne Interpreter-Sprache irgendwie Performance-mäßig zu drosseln fände ich sehr künstlich.

    Für mich gibt es zwei Ansätze, die irgendwie beide sinnvoll sind:

    - Was einfaches für Einsteiger, wo der sinn ist, sofort loslegen zu können, und die Einschränkungen z.B. bei der Grafik auch dazu dienen, es einfach zu halten/zu machen. Die Performance zu begrenzen macht hier mMn keinen Sinn, warum sollte man dem Einsteiger diese Hürde in den Weg legen? Ich denke dieser Ansatz wird gut vom PICO abgedeckt.

    - Was irgendwie beschränktes, wo man auch an die "Hardware" denken muss, wie damals, um diese Denkweise kennenzulernen, was aber einfacher zu Programmieren ist als ein C64. Ich dachte, das wäre dein Ansatz. Der OK64 stellt ja auch eine IDE mit einer Pascal-ähnlichen Sprache zur Verfügung.

    Guckst Du ein paar posts weiter oben. :P

    Ich hab den Thread erst gerade mitbekommen.:whistling:

    Quote from Retrofan

    Die genaue Auflösung wissen wir noch nicht – aber wir sind sicher, dass sie UNTER 320 x 200 liegen soll.

    Generell bin ich bei Dir, dass man die Auflösung niedrig halten sollte.

    Soll das Gerät (auch mal) am Heim-TV angeschlossen werden? Dann wir das sehr klotzig.

    Beim C64 hatte man 13" Monitore, die Heim-TVs sind heute meist irgendwas zwischen 50" und 75".


    Beim C64 würde ich mir wünschen, dass man in Hires die 16 Farben ohne Restriktionen setzen kann. Sowas würde auch reichen.


    Wie wäre es mit?


    384x216 (=FullHD/5)

    Beiderseits auch teilbar durch 8: 48x27 Chars


    Quote from Retrofan

    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.

    "Anamorphe" Pixel erschweren das Pixeln imo wieder. PAR 1:1 wäre schon gut.

    Wäre das zuviel Content, der gefüllt werden muss?


    mfg Tobias

    Unkwalifiziert


    Ich hatte eine zeitlang PICO-8 auf einem Raspberry Pi laufen, und zwar mit einem Boot-Image aus dem Netz, welches direkt in PICO-8 hineinbootet. Damit war das ganze eine Art "PICO-8-Heimcomputer", den man ueber Composite sogar an einem Roehren-TV anschliessen konnte. War ziemlich cool. Wenn man das ganze in ein Tastaturgehaeuse bauen wuerde (gibt ja ein paar, oder man baut sich selbst was), dann waere das zumindest schonmal ein Schritt in diese Richtung.

    Ja, ich faende eine 1:1-Aufloesung ehrlich gesagt auch besser. Aber ich kann auch verstehen, dass Retrofan mal was anderes machen will :)


    Ich faende 384x216 an sich ok, nur wenn man es auf HD-Ready skaliert (1280x720), dann haette es einen minimalen Rand (1152x648). Andererseits sollte man sich eh darueber im Klaren sein, dass viele Fernseher auch heute noch einen sog. "Overscan"-Bereich haben (es sei denn, man schaltet in den "Game Mode" oder "PC Mode", falls der Fernseher so etwas hat). Daher waere es generell nicht unbedingt verkehrt, einen Rand zu haben. Ich fand den Rand beim C64 auch nie stoerend, so ein bisschen Farbe ums Bild hat ja doch auch was. Er braeuchte aber nicht unbedingt genauso breit sein.


    Selbst wenn man 320x200 in 384x216 einbettet und dann auf FullHD hochskaliert mit Rand, erhaelt man z.B. folgendes:


    pasted-from-clipboard.png


    Einen Rand in solchen Dimensionen faende ich jetzt halb so wild, vor allem wenn er farbig sein kann. Und er loest wie gesagt die Overscan-Probleme. Aber natuerlich ist das jetzt nur ein Beispiel, die konkrete Groesse und die konkreten Aufloesungen koennte man ja noch diskutieren.


    Den 240x216-Ansatz mit 8x6-Font und 8:5-Pixel-Aspect-Ratio kann ich vermutlich erst dann befuerworten, wenn ich dazu mal ein Mockup gesehen habe, wo jemand versucht, ein Beispiel-Spiel dafuer zu gestalten. Vielleicht etwas simples, grid-basiertes wie Bomberman, Sokoban oder so. Vielleicht koennte Retrofan da ja mal ein Beispiel-Mockup machen, wie ein Spiel in einem solchen Modus wirken koennte :)

    Quote from ZeHa

    HD-Ready skaliert (1280x720)

    Hatte ich nicht berücksichtigt.
    Sollte man das heute noch? Gefühlt hat doch jeder Wald-und-Wiesen Monitor schon lange Full-HD, egal, wie klein.:)


    Wer einen Retro-Rand möchte, kann das durch eine zu wählenden, ganzzahligen Skalierfaktor ja selbst bestimmen.
    Z.B. bei 384x216 statt Faktor 5 nur Faktor 4.