Neuer Retro-Computer im 8-Bit Style

Es gibt 1.853 Antworten in diesem Thema, welches 267.598 mal aufgerufen wurde. Der letzte Beitrag (12. April 2024 um 17:24) ist von Retrofan.

  • Gegen CBM BASIC V2 lässt sich das eine oder andere sagen (wenn auch m. E. weniger, als gemeinhin unreflektiert nachgeplappert wird), aber dass es nicht geradezu dazu zwingen würde, viel über das konkrete System sowie allgemeine Computergrundlagen zu lernen, sicher nicht.

  • Gegen CBM BASIC V2 lässt sich das eine oder andere sagen (wenn auch m. E. weniger, als gemeinhin unreflektiert nachgeplappert wird)

    Willst du die Zeilennummern beibehalten?

    Warum nicht? DAS ist doch Retro :wink:

  • Gegen CBM BASIC V2 lässt sich das eine oder andere sagen (wenn auch m. E. weniger, als gemeinhin unreflektiert nachgeplappert wird)

    Willst du die Zeilennummern beibehalten?

    Wenn meine Nebensätze diskutiert werden und ich mich darauf einlasse, führt das zu vielgeliketen Off-Topic-Ermahnungen, Abspaltungen, Löschungen, Thread-Schleißungen und womöglich irgendwann noch schlimmeren Erschütterungen des Raum-Zeit-Kontinuums. (Ich weiß Vorteile von Zeilennummern, bin aber im Saldo bei neuen Sprachen gegen obligatorische Zeilennummern und hoffe, das hält das Raum-Zeit-Kontinuum an dieser Stelle noch aus; es wird sich zeigen, ob Klammern in der Lage sind, das Raum-Zeit-Kontinuum zu stabilisieren.)

  • Wieso nehmen eigentlich alle Lua? Ich finde die Sprache eher speziell und viel zu abstrahierend, als dass man damit wirklich was über einen Rechner lernt

    Wichtig finde ich, DASS es weit verbreitet ist:

    Wikipedia: "In video game development, Lua is widely used as a scripting language by programmers, mainly due to its perceived easiness to embed, fast execution, and short learning curve. Notable games which use Lua include Roblox, Garry's Mod, World of Warcraft, Payday 2, Phantasy Star Online 2, Dota 2, Crysis, and many others. Some games that do not natively support Lua programming or scripting, have this functionality added by mods, such as ComputerCraft does for Minecraft. In addition, Lua is also used in non-video game software, such as Adobe Lightroom, Moho, iClone, Aerospike and certain system software in FreeBSD and NetBSD, and is used as a template scripting language on MediaWiki using the Scribunto extension.

    In 2003, a poll conducted by GameDev.net showed Lua was the most popular scripting language for game programming. On 12 January 2012, Lua was announced as a winner of the Front Line Award 2011 from the magazine Game Developer in the category Programming Tools."

    Was hier gar nicht erwähnt wurde: Alle Games in Pico-8 (und fast alle in Tic-80) sind in Lua programmiert – und das sind tausende. Es scheint also zu funktionieren.

    Ich finde wichtig, dass Lua einfach zu erlernen ist – und im Gegensatz zu BASIC V2 ist es keine Sackgasse. Wer mit Lua lernt, (Retro-) Spiele zu programmieren, kann die Erkenntnisse durchaus aktuell weiterverwenden. Und dann soll die Programmiersprache hier ja flankiert werden von einer IDE, die für die Entwicklung von Games optimiert ist (ähnlich Pico-8). Die Kombination macht es meiner Meinung nach.

    Wer etwas über Rechner lernen will, soll sich meinetwegen einen nackten Raspi kaufen und damit herumspielen oder einen 8-Bit-Computer selbst zusammenlöten – dafür ist dieses Projekt weniger gedacht.

    Bitte melde dich an, um diesen Link zu sehen. | Meine Lieblings-Themen im Forum64:

    Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen.

  • im Gegensatz zu BASIC V2 ist es keine Sackgasse. Wer mit Lua lernt, (Retro-) Spiele zu programmieren, kann die Erkenntnisse durchaus aktuell weiterverwenden.

    So lange der C64 in klassischer Form und in neuen Inkarnationen und Variationen lebt, und das wird er sicher länger als wir, ist ein anderenorts eingesetztes BASIC V2 ebenfalls keine Sackgasse, denn es lässt sich ja am C64, C128, Commander 16, Mega 65 usw. weiterverwenden. Es gibt ja schon so Projekte mit BASIC V2 als Skriptsprache. Lua ist schon ok, ist natürlich auch aktuell weiter verbreitet; könnte sich im Vergleich zu BASIC V2 allerdings als kurzlebiger erweisen.

  • ist ein anderenorts eingesetztes BASIC V2 ebenfalls keine Sackgasse

    Wer mit Basic V2 programmieren will, kann sich den Commmander X16 zulegen. Die hier diskutierte Idee ist in Abgrenzung dazu entstanden.

  • Wieso nehmen eigentlich alle Lua? Ich finde die Sprache eher speziell und viel zu abstrahierend, als dass man damit wirklich was über einen Rechner lernt

    In 2003, a poll conducted by GameDev.net showed Lua was the most popular scripting language for game programming. On 12 January 2012, Lua was announced as a winner of the Front Line Award 2011 from the magazine Game Developer in the category Programming Tools."

    Diese Aussagen sind schon wieder sehr retro - wir haben schon 2024. Da ist sind irgendwelche Internet-Umfragen von 2003 und auch 2012 schon als historisch einzuordnen.

    Meines Wissens nach, nutzen aktuelle, große Game-Engines so ziemlich alles an Scripting, aber selten und erst recht nicht exklusiv Lua.

    Unreal Engine 4/5: C++, Blueprint

    Unity: C#

    Godot: GDscript, C#,...

    Lua wird noch in Lumberyard/Open 3D Engine (neben Python) genutzt, aber dessen Entwicklung unter Amazon war ja sehr träge und scheint auch unter Apache eher mau...

    Natürlich leben all die alten und kleineren Game Engines in irgendwelchen Nischen weiter, evtl. mit viel Lua Code. Man kann jedoch auch heute noch mit COBOL oder FORTRAN sein Brot verdienen...

    Aber als Sprache mit viel Zukunft würde ich Lua nicht sehen. Beim Scripting hat sich Python (und nun MicroPython) viel weiter durchgesetzt. Im Web natürlich Javascript und dessen Ver(schlimm)besserungen aller Art...

  • denn es lässt sich ja am C64, C128, Commander 16, Mega 65 usw. weiterverwenden.

    Das sind aber alles Vintage/Retro-Plattformen, zudem alle mit Commodore-Bezug. Lua ist im Gegensatz zu CBM-Basic nicht proprietär, sondern multi-plattform und open source. Man kann sie (später) auch für aktuelle Games, wie Roblox, nutzen und man kann aktuelle Lua-Games auf Smartphones und Konsolen zocken – ganz ohne Emulator dazwischen. Es gibt moderne IDEs und Frameworks, die Lua verwenden, wie z.B. Bitte melde dich an, um diesen Link zu sehen., Bitte melde dich an, um diesen Link zu sehen., Bitte melde dich an, um diesen Link zu sehen., Bitte melde dich an, um diesen Link zu sehen., Bitte melde dich an, um diesen Link zu sehen. usw. Ein Retro-Computer, der also als "native/eingebaute" Sprache Lua statt Basic mitbringt, ist mE eine bessere Vorbereitung, wenn man sich in dieser Richtung weiterentwickeln will.

    Und programmier' mal solche Games in Basic V2: Bitte melde dich an, um diesen Link zu sehen.

    Wer also in die (Spiele-) Programmierung ganz allgemein einsteigen will, ist heutzutage mit Lua sicherlich besser bedient als mit Basic V2. Schon alleine wegen des moderneren Kozepts, selbst wenn es am Ende nicht Lua sein sollte, mit dem man weiter arbeitet.

    Und es kommt noch etwas entscheidendes hinzu: Die oben von dir erwähnten Computer gibt es schon – es herrscht hier also kein Mangel, keine Marktlücke. Wer in Basic V2 programmieren will, kann sich einfach den Commander X16 zulegen, fertig. (Ich glaube aber, dass das eine Sackgasse ist. Letztlich wird man mit CBM-Basic scheitern, wenn man "vernünftige" Games entwickeln will – die meistens Coder werden sich irgendwann genötigt sehen, von Basic auf Assembler umzusteigen und nochmal von vorne anzufangen.)

    Bitte melde dich an, um diesen Link zu sehen. | Meine Lieblings-Themen im Forum64:

    Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen.

  • Aber als Sprache mit viel Zukunft würde ich Lua nicht sehen. Beim Scripting hat sich Python (und nun MicroPython) viel weiter durchgesetzt.

    Mit Lua arbeiten immer noch viele Engines, wenn auch vor allem im 2D/Pixel-Bereich. Für mich ist es am Entscheidendsten, dass die virtuelle Konsole Pico-8, das Schwesterprojekt Voxatron, der gemeinsame Nachfolger Picotron und auch TIC-80 damit arbeiten. Aus 2 Gründen: Erstens würde ich mir bei (gedachter) Realisierung unseres Projektes erhoffen, einige der vielen Entwickler auf unsere Plattform holen zu können (neue Herausforderung durch andere Specs, ähnliche IDE/Sprache, echte Hardware) und zweitens können wir bei Verwendung von Lua ganz einfach alles auf auf dem open source Projekt TIC-80 (in Kombination mit Linux und einer Embedded-Computer-Hardware) basieren lassen.

    Ich will auch gar nicht mit Zähnen und Klauen Lua verteidigen. Wenn es für den Zweck (Retro-Spiele-Entwicklung) eine bessere und schneller zu erlernende Sprache gibt und man die mit geringem Aufwand mit der TIC-80 IDE verheiraten kann, soll es mir recht sein. Denn die IDE (inkl. der Anbindung an die Sprache) ist das, was mich am Meisten an Pico und Tic begeistert. Die Kombination, wie man z.B. ein "Sprite" erzeugt und dieses mittels der Sprache ansteuern kann – das ist als Gesamt-Konzept einfach genial.

    Einfache Dinge, die auf dem C64 (oder auch Mega65) Tage dauern würden, erledigt man mit dem PICO-8 in wenigen Stunden – und kann sich dann mehr um das Spielprinzip oder die Gestaltung kümmern. Weniger Technik, mehr Spiel.

    Wenn ich mir die bisher erschienenen Spiele und aktuelle Projekte angucke, dann sieht es bei z.B. PyGame eher mau aus, während es tausende von Lua Games alleine für Pico-8 gibt. Und rund 1000 auch schon für TIC-80, WIP-Projekte nicht mitgezählt.

    Und zuletzt wurde ja gar nicht Python als Alternative zu Lua angepriesen, sondern CBM-Basic (V2) – so kam die neuerliche Diskussion um die Sprache ja erst auf. Welche aktuellen Engines arbeiten denn damit, welche nativen Android/iOS-Games wurden mit CBM-Basic entwickelt? Wie sind da die Zukunftsaussichten?

    Bitte melde dich an, um diesen Link zu sehen. | Meine Lieblings-Themen im Forum64:

    Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen.

  • Unity: C#

    Unity hat ja auch alternativ JavaScript angeboten. Aber hat sich irgendwie nicht durchgesetzt.

    Ich hatte ja mal hier auch vorgeschlagen, verschiedene Syntaxe anzubieten, um den unterschiedlichen Geschmäckern gerecht zu werden. Mit Basic-, C- oder Pascal-Flavour sozusagen. Die IDE wandelt dann transparent hin und her.

  • Ich hatte ja mal hier auch vorgeschlagen, verschiedene Syntaxe anzubieten, um den unterschiedlichen Geschmäckern gerecht zu werden. Mit Basic-, C- oder Pascal-Flavour sozusagen. Die IDE wandelt dann transparent hin und her.

    Das hat die TIC-80 IDE ja auch schon gemacht. Letztlich wurde dann aber fast nur Lua verwendet. Wenn man Spaß daran hat, kann man es hier genau so machen: Wir bieten einfach unterschiedliche Sprachen an und dann wird eben wieder Lua verwendet. ;)

    Der Vorteil nur einer Sprache ist es, dass sich wirklich alle User untereinander (und auch Code) austauschen können. Außerdem hat man eine weitere Anfangs-Verwirrungs-Möglichkeit ausgeschlossen. Das wird oft unterschätzt – aber mE ist z.B. genau die große Auswahl an Distros DAS Problem bei der Verbreitung von Linux. Ich habe schon mehrfach darüber nachgedacht, auch mal etwas länger Linux auszuprobieren aber da die Empfehlungen immer andere sind (und ich keine Zeit für Fehlgriffe zu verschenken habe), habe ich wiederholt die Lust und Motivation verloren.

    Ziel soll hier ja sein, dass man einen Homecomputer kauft, ihn anschließt, einschaltet und ins Prompt bootet. Wenn dann erst wieder gefragt wird, welche Programmiersprache es denn (fürs erste) sein soll, hat man nur eine zusätzliche Hürde aufgebaut.

    Edit: Aber sieh meine Ansicht nicht als Bremsklotz an. Wenn DU das umsetzten willst und zur Bedingung machst, dass DU da 6 Geschmacksrichtungen einbauen darfst – dann nur zu. Wenn das die Voraussetzung für DEINE Realisierung ist und DU da deine Erfüllung siehst, lass dich bitte nicht ausbremsen. Wer's macht, hat recht. Meine Intention ist alleine, wie weit man die Sache runterstrippen kann, um mit möglichst wenig Aufwand möglichst doch noch ein "rundes" Ergebnis bekommen zu können.

    Bitte melde dich an, um diesen Link zu sehen. | Meine Lieblings-Themen im Forum64:

    Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen.

  • Aber als Sprache mit viel Zukunft würde ich Lua nicht sehen. Beim Scripting hat sich Python (und nun MicroPython) viel weiter durchgesetzt.

    [...]

    Wenn ich mir die bisher erschienenen Spiele und aktuelle Projekte angucke, dann sieht es bei z.B. PyGame eher mau aus, während es tausende von Lua Games alleine für Pico-8 gibt. Und rund 1000 auch schon für TIC-80, WIP-Projekte nicht mitgezählt.

    PyGame kann man ja auch gar nicht mit Pico-8 oder TIC-80 und anderen Fantasy-Consolen vergleichen. Das ist einfach ein Wrapper von Python auf SDL. Einfach nur ein Weg, um mit purem Python irgendwie Grafik anzuzeigen, Sound abzuspielen und Eingaben wie Tastatur und Gamecontroller abzufragen. Das wollen ja selbst Hardcore-Linux Anhänger alles mit der Text-Console machen :wink:

    PyGame ist keine Game Engine und erst recht nicht eine Fantasy-Konsole mit Tools.

    Es ist für reines Python einfach, was DirectX/SDL für C/C++ ist: ein Weg zur Ein-/Ausgabe ohne GUI-Ballast.

    Aber es gibt natürlich auch Dinge ähnlich zu Pico-8 mit Python, z.B. Bitte melde dich an, um diesen Link zu sehen..

    Doch der "Community/Platform" Aspekt von Pico-8 ist da auch noch sehr schwach. Das ist erstmal nur eine Retro-Fantasy Engine mit Tools in Python.

    Aber es gibt natürlich dann auch wieder Versuche, das mehr als Online-Platform zu nutzen:

    Bitte melde dich an, um diesen Link zu sehen.

    Bitte melde dich an, um diesen Link zu sehen.

    Aber mir fehlt bei all diesen Fantasy-Dingern einfach der Unterbau, bzw. der Hardware-Aspekt eines Systems. Klar kann man das dann auf jedem PC nutzen und auf

    irgendein ARM-SbC tun. Z.B. Raspis ab dem Raspi Zero; und evtl. auch bare-metal ohne Linux dazwischen.

    Im Gegensatz zu den 8- und 16-Bit Homecomputern wird da aber immer eine "Barriere" sein, weil man eben nicht im Speicher rumpoken kann, und im Zweifelsfall nicht per Maschinencode ganz nah an CPU und I/O-HW kommt.

    Man wird in seiner Lua/Python-Interpreter-Kiste gefangen sein und akzeptieren, dass alle Performance alleine dadurch kommt, eine mehr oder minder effiziente Skriptsprache auf einer irre schnellen CPU und GPU läuft.

    Selbst ein Raspi Zero hat doch Specs, mit denen er zu klassischen Homecomputer-Zeiten jeder High-End-Workstation überlegen gewesen wäre.

    Und das ist halt imho ein riesen Pluspunkt von neuer Retro-Hardware wie X16 und Mega65 oder SpectrumNext: auch wenn die HW modernere Komponenten nutzt, ist sie immer noch deutlich näher an den Möglichkeiten der Homecomputer-Zeit. OK, man hat mit FPGAs halt Leistung, die in den frühen 90er wohl teurere 32Bit CPUs und ausgefeiltere ASICs für Grafik benötigt hätten, aber noch nix, was technisch Lichtjahre weiter ist.

  • Ja, bei vielen Spiele-Entwicklern ist Lua bereits wieder kein Thema mehr... Man stösst zu schnell an Performance Grenzen, die man nicht mehr wegoptimieren kann. Interpretierter byte code ist eben nicht native, vorallem heutzutage wo von vielen Spielen erwartet wird das sie jenseits von 60 fps haben sollen.

    Da wird dann eher mit graphishen node-basierten Skriptingsystemen gearbeitet und der Code dann daraus generiert und kompiliert.

  • Aber mir fehlt bei all diesen Fantasy-Dingern einfach der Unterbau, bzw. der Hardware-Aspekt eines Systems. Klar kann man das dann auf jedem PC nutzen und auf

    irgendein ARM-SbC tun. Z.B. Raspis ab dem Raspi Zero; und evtl. auch bare-metal ohne Linux dazwischen.

    Naja es hält Dich ja niemand davon ab, die Plattform auf die üblichen Microcontroller zu portieren und dort spezielle PEEK/POKE-Befehle einzubauen, die eben auf die typischen Peripherals zugreifen. Aber mal ehrlich, wer auf modernen Plattformen sowas macht, schreibt dann sowieso C (oder Rust).

    OK, man hat mit FPGAs halt Leistung, die in den frühen 90er wohl teurere 32Bit CPUs und ausgefeiltere ASICs für Grafik benötigt hätten, aber noch nix, was technisch Lichtjahre weiter ist.

    Das ist eine Fehleinschätzung. Die in diesen Projekten benutzten FPGAs sind völlig übermotorisiert. Z.B. wird schon nur im FPGASID ein FPGA benutzt, der damit beworben wird, auch gut für DDR3/1GHz-Interfacing geeignet zu sein, und auf den man mit "Fingerschippsen" einen Mikroprozessor-Core draufbekommt, auf dem man ein ganz normales Linux inkl. Zugriff auf ein paar hundert MB RAM laufenlassen kann. Edit: Im Mega65 wird ein Artix 7 100T verwendet. Bitte melde dich an, um diesen Link zu sehen. dazu. Hört sich "6.6Gb/s transceivers enabling 211Gb/s peak bandwidth" oder der Hinweis auf die gute Eignung für Militär/Crypto oder überhaupt schon der 28nm-Prozess auch nur entfernt nach 90ern an? Für mich nicht. Da wurde einfach nur ein möglichst fetter FPGA verbaut, damit man damit (als Entwickler) eine schöne Spielwiese hat. Macht auch völlig Sinn! Aber hat so gar nichts mit "schmale Ressourcen" zu tun.

    Und um bei Deiner Kritik zu bleiben, wenn man auf dem Mega65 tatsächlich Zugriff auf die Hardware hätte, könnte man seinen FPGA natürlich auch von C64-Seite aus rekonfigurieren.

    Interpretierter byte code ist eben nicht native

    Ach wenigstens luajit ist schon echt schnell. Selbst JavaScript/V8 ist in den typischen Benchmarks "nur" rund doppelt so schnell, und dagegen kommt kaum eine andere Sprache/Umgebung an.

    Nur interpretiertes Lua ist natürlich geschwindigkeitsmäßig nicht so der Knaller.

    Was mir bei Lua nicht gefällt, ist, dass es mit "Retro" so gar nichts zu tun hat. Der zentrale Datentyp von Lua ist eine Hashmap. Da braucht man doch wirklich eigentlich nichts mehr weiter zu sagen. Aber bequem und schnell ist es freilich.

    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.

    2 Mal editiert, zuletzt von 1570 (26. März 2024 um 16:22)

  • Aber mir fehlt bei all diesen Fantasy-Dingern einfach der Unterbau, bzw. der Hardware-Aspekt eines Systems. Klar kann man das dann auf jedem PC nutzen und auf

    irgendein ARM-SbC tun. Z.B. Raspis ab dem Raspi Zero; und evtl. auch bare-metal ohne Linux dazwischen.

    Naja es hält Dich ja niemand davon ab, die Plattform auf die üblichen Microcontroller zu portieren und dort spezielle PEEK/POKE-Befehle einzubauen, die eben auf die typischen Peripherals zugreifen.

    PICO-8/TIC-80 sind dann aber wieder zu fett, um auf Microcontrollern zu laufen. Man braucht dafür einen recht potenten Unterbau, wie eben ein Raspi

    OK, man hat mit FPGAs halt Leistung, die in den frühen 90er wohl teurere 32Bit CPUs und ausgefeiltere ASICs für Grafik benötigt hätten, aber noch nix, was technisch Lichtjahre weiter ist.

    Das ist eine Fehleinschätzung. Die in diesen Projekten benutzten FPGAs sind völlig übermotorisiert. Z.B. wird schon nur im FPGASID ein FPGA benutzt, der damit beworben wird, auch gut für DDR3/1GHz-Interfacing geeignet zu sein, und auf den man mit "Fingerschippsen" einen Mikroprozessor-Core draufbekommt, auf dem man ein ganz normales Linux inkl. Zugriff auf ein paar hundert MB RAM laufenlassen kann. Edit: Im Mega65 wird ein Artix 7 100T verwendet.

    Man muss ja nicht teure Overkill-FPGAs wie bei MEGA65 oder Mister verwenden, wenn man nur ein System haben will, dass etwas besser ist als ein typischer 80er 8-Bit Homecomputer.

    Da geht es ein paar Nummern kleiner und billiger. In Kombi mit klassischer CPU usw. ist der FPGA dann einfach der realistische ASIC-Ersatz. Selbst wenn der deutlich mehr könnte, als das für was er dann eingesetzt wird, kann man ihn erstmal als unveränderliche Blackbox betrachten.

    Ein solches System sollte auch auf keinen Fall dazu gedacht sein, es per FPGA zu einer Universal-Platform zu machen. Dafür gibt es ja schon MiST, SiDi, Mister, AnalogPocket u.v.m.

    Und wenn man mit CPLDs auskommt, ist das in diesem Aspekt evtl. sogar besser; siehe z.B. Bitte melde dich an, um diesen Link zu sehen..

    Leider ist der mit seinen 2 CPUs dann aber HW-technisch schon wieder totaler Overkill, und hat aber mit der gebotenen Grafik nicht so das Spiele-Potential.

    Von Olimex gibt es zwar Bitte melde dich an, um diesen Link zu sehen., die sind aber entsprechend teuer.

    Meine Kids sind momentan bei so einer Roboterbastel-Gruppe und da wird Raspi Pico genutzt (mit MicroPython). Da gibt es ja von Olimex auch ein lustiges Produkt mit 65C02 als CPU und RP2040 für "den Rest".

    Der Bitte melde dich an, um diesen Link zu sehen. ist dann mit 30€ schon deutlich bezahlbarer (30€) und hat HDMI/DVI out. Wenn ich es richtig verstehe ist da momental Apple II und Oric-Emulation das Ziel, aber die HW sollte auch eigenständige "Fantasy-Homecomputer" erlauben.

    Aber wenn einem einer der ARM-M0+ Kerne auf dem RP2040 als CPU auch genehm ist (der andere geht sicher für I/O wie Grafik drauf), dann tut es evtl. schon so ein 12€ Board von Waveshare:

    Bitte melde dich an, um diesen Link zu sehen.

  • Aber mir fehlt bei all diesen Fantasy-Dingern einfach der Unterbau, bzw. der Hardware-Aspekt eines Systems.

    Im Gegensatz zu den 8- und 16-Bit Homecomputern wird da aber immer eine "Barriere" sein, weil man eben nicht im Speicher rumpoken kann, und im Zweifelsfall nicht per Maschinencode ganz nah an CPU und I/O-HW kommt.

    Die Frage ist halt, wer das will. Beim C64 MUSS man herumpoken, um auch nur die Hintergrundfarbe zu setzen. Um ein Sprite auf den Bildschirm zu bekommen und zu bewegen, erst recht. Wer das toll findet, für den gibt es mannigfaltige Lösungen. Wir hatten den X16 und Mega65 ja hier schon sehr oft erwähnt. Und wer noch näher an der Hardware dran sein will, der bastelt sich halt einen Rechner auf Basis eines Z80 oder 68000 zusammen – dafür gibt es Anleitungen. Das gibt es ja alles schon. Für Fans solcher Lösungen ist also gesorgt – um die müssen wir uns nicht mehr kümmern. Warum immer nur in die selbe Kerbe schlagen statt sich eine Lösung zu überlegen, die es noch NICHT gibt?

    Selbst ein Raspi Zero hat doch Specs, mit denen er zu klassischen Homecomputer-Zeiten jeder High-End-Workstation überlegen gewesen wäre.

    Ja, um zum einen eine performante Basis für die IDE zu haben und zum anderen einen Ausgleich, um die Performance-Verluste durch die Script-Sprache aufzufangen. Im Gegensatz zu den Fantasy-Konsolen ist es hier nur so, dass die Hardware mitgeliefert und fest definiert wäre. Entwickler müssen also mit den Hardware-Beschränkungen umgehen und können nicht einfach die Specs anheben.

    Und das ist halt imho ein riesen Pluspunkt von neuer Retro-Hardware wie X16 und Mega65 oder SpectrumNext: auch wenn die HW modernere Komponenten nutzt, ist sie immer noch deutlich näher an den Möglichkeiten der Homecomputer-Zeit.

    Mag sein. Aber wie schon gesagt: Gibt es schon – und es macht keinen Sinn, da noch eine weitere Kiste dazuzustellen, die ein ähnliches Konzept verfolgt. Ein weiteres Projekt macht nur Sinn, wenn es andere Wünsche erfüllt bzw. die vorhandenen besser erfüllen kann. Und ich bin fest der Überzeugung, dass das Projekt, wie es jetzt definiert ist, dazu in der Lage wäre.

    Der Community-Effekt gerade beim PICO ist "huge". Nur fehlt mir da die Hardware zum Auspacken und Anfassen. Genau da sehe ich eine große Lücke im Angebot, von der ich glaube, dass sich da einige drauf stürzen würden. Mengenmäßig sehe ich das in einem Bereich, der weit über sowas wie Mega65, Foenix oder Spectrum Next hinausgeht. Einfach, weil man damit nicht nur 60-jährige ansprechen würde, die unbedingt in Speicherzellen poken und sich nochmal jung fühlen wollen.

    Bitte melde dich an, um diesen Link zu sehen. | Meine Lieblings-Themen im Forum64:

    Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen.

  • Aber wenn einem einer der ARM-M0+ Kerne auf dem RP2040 als CPU auch genehm ist (der andere geht sicher für I/O wie Grafik drauf), dann tut es evtl. schon so ein 12€ Board von Waveshare:

    eckstein-shop.de/WaveShare-RP2040-PiZero-Development-Board

    Haha ja. Auf keinen Fall bastele ich an sowas mit C64-Bezug: Bitte melde dich an, um diesen Link zu sehen.

    12€ ist dann schon fast etwas viel, eigentlich braucht man nur den/die RP2040 plus HDMI-Buchse.

    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.