Hallo Besucher, der Thread wurde 243k mal aufgerufen und enthält 1853 Antworten

letzter Beitrag von Retrofan am

Neuer Retro-Computer im 8-Bit Style

    Ja, du hast damit keine Probleme, die hätte ich auch nicht. Aber anderen scheint das wichtig zu sein. Warum ein BASIC Compiler nicht funktioniert hatte M.J. erklärt, dewegen ja der Schwenk hin zu einer anderen Programmiersprache, aber von BASIC wollen die Leute nicht weg, weil sie denken dass dies wirklich eine Beginner Sprache wäre, weil das damals so verkauft wurde. Die Katze beißt sich hier ständig in den Schwanz.


    Man müsste sich mal entscheiden:


    - 8Bit Retro(FPGA) mit Pascal ähnlicher Sprache oder viel Power(RaspPi) und dann aber in BASIC auch Spiele programmieren können?


    Auflösung und Farben, da ist man sich ja recht schnell einig geworden hier.


    Sound muss man dann schauen, auf dem RaspPi kann ein Software Synthesizer das wuppen, in FPGA, da gibt es sicher ein SID oder ähnliches schon als Core.

    Zitat von darkvision

    Ich hab mit BASIC 2.0 angefangen. Auf Papier. [...] Also BASIC hat schon so seinen Reiz. Und auch Zeilenorientiert ist nicht ganz falsch.


    Zu 99% arbeite ich aber mit einer IDE. Das ist eine grafische Oberfläche am C64 (GEOS), ein Texteditor (GeoWrite) und ein Compiler/Assembler (MegaAss).

    Ein wenig masochistisch veranlagt? :sm::bgdev

    Zitat von ckoe

    Das Problem ist halt, viele wollen unbedingt BASIC und 8Bit Beschränkung, aber gleichzeitig soll man mit diesem BASIC auch Spiele programmieren können, die über ein Textadventure oder eine Wirtschaftssimulation hinaus gehen. Beides geht aber nicht.

    Ich habe nochmal über "Basic" nachgedacht. Mir ist die Sprache ja ohnehin nicht so wichtig – ich befürchte(te) halt nur ein Akzeptanz-Problem beim Fehlen von Basic. Aber vielleicht ist die Lösung wirklich ein guter Name für die neue Sprache und eine Erklärung, warum sie so viel besser wäre als Basic. Ich meine, an Lua (dem Namen, wie dem Konzept) hängt sich ja auch niemand auf – der Pico-8 hat eine recht große Hobby-Entwickler-Gemeinde gefunden, ganz ohne Basic.


    Wenn man halt sagen könnte: 'Hier ist der neue Retro-Computer, "8-Bit"-Grafik und -Sound, 16-Bit-Power und mit neuer "eingebauter", komfortabler Programmiersprache/IDE, die für Action-Games, wie auch für Anwendungs-Apps, optimiert ist. So schnell, dass man lange ohne Assembler auskommt und trotzdem leistungsfähige Programme und Spiele entwickeln kann.' – Ich denke, damit könnte man evtl. punkten, auch ohne Basic.

    Zitat von Retrofan

    Wenn man halt sagen könnte: 'Hier ist der neue Retro-Computer, "8-Bit"-Grafik und -Sound, 16-Bit-Power und mit neuer "eingebauter", komfortabler Programmiersprache/IDE, die für Action-Games, wie auch für Anwendungs-Apps, optimiert ist. So schnell, dass man lange ohne Assembler auskommt und trotzdem leistungsfähige Programme und Spiele entwickeln kann.' – Ich denke, damit könnte man evtl. punkten, auch ohne Basic.

    FACK¹



    :Peace


    ¹) Fully acknowledged

    Zitat von ckoe

    Warum ein BASIC Compiler nicht funktioniert hatte M.J. erklärt, ...

    Habe ich gelesen. Jeder darf hier seine Meinung äußern, dafür ist dieser Thread ja da.


    Es gibt für den C64 einige gut funktionierende BASIC-Compiler. Und auch für andere 8bit-Rechner.


    Ich persönlich sehe jedenfalls keinen Grund, der für einen zukünftigen 8bit-Rechner einen BASIC-Compiler prinzipiell unmöglich machen würde.

    Ah ok, wusste nicht dass es 8Bit Basic Compiler gibt, die müssen sich ja dann vom Commodore Basic unterscheiden, da gab es ja so Sachen wie NEXT die erst zur Laufzeit klar definiert sind und sich daher nicht compilieren lassen. Vielleicht ist ja das ja dann ein NEXT + Bezeichner, keine Ahnung, bin da nicht in der Materie drin.

    Zitat von ckoe

    da gab es ja so Sachen wie NEXT die erst zur Laufzeit klar definiert sind und sich daher nicht compilieren lassen.

    Ist das eines dieser "Es geht in diesen bestimmten Sonderfällen nicht, also bauen wir lieber gar keine Lösung als eine, die mit den viel häufigeren harmlosen Fällen umgehen kann"-Argumente?

    Zitat von ogd

    Wie weiter oben schon gefragt (Neuer Retro-Computer im 8-Bit Style): Was gibt so an Action-Spielen, wo ein C 64-Basiccompiler zum Einsatz kam?

    Das kann ich aus dem Stegreif nicht faktenbasiert beantworten, aber mein "Erfahrungserinnerungsgefühl" würde hier irgendwo zwischen "sehr wenige bis keine" antworten.


    Für sehr gute Actionspiele auf einem 8bit-Rechner braucht es fast "zwingend" Assembler. Auch deswegen ist der Wunsch, mit einer Hochsprache (sei es nun Basic, Pascal, whatever ...) auf einem 8bit-Rechner auch nur halbwegs "zeigbare" Actionspiele zu programmieren, ein eher unrealistischer Gedanke.


    Entweder man macht den 8-bitter "so flott", dass vom 8bit-Feeling her nichts mehr übrig ist oder man entwickelt die Actionspiele auch weiterhin in Assembler.


    Und für kleinere bis mittelgroße Projekte, bei denen Geschwindigkeit nicht der Hauptpunkt ist, für die reicht ein eingebautes BASIC und kompliertes BASIC allemal.


    Hier ist zum Beispiel ein BASIC-Compiler für den C64 beschrieben: (Link zum C64-Wiki-Eintrag)

    Zitat von Unseen

    Ist das eines dieser "Es geht in diesen bestimmten Sonderfällen nicht, also bauen wir lieber gar keine Lösung als eine, die mit den viel häufigeren harmlosen Fällen umgehen kann"-Argumente?

    Das kann ich dir leider gar nicht beantwortet. Ich bezog mich nur auf die Erklärungen von M.J. zu diesem Thema.


    Zitat von M. J.

    Commodore-Basic ist mit normalen Bordmitteln nicht vollständig kompilierbar.


    Möchte man ein Actionspiel in einer Hochsprache programmieren, setzt dies bei einem 8-Bit-Rechner (aber auch einem 32 Bitter) voraus, daß die Programmiersprache kompilierbar ist. Ist sie dies nicht (wie beim Commodore-Basic egal in welcher Version), verhält sich das so wie bei einem Wanderer, der eine längere Wanderung machen möchte (egal über welche Distanz) und sich vor Beginn ins Knie schießt. Die einzige Möglichkeit, mit Commodore-Basic ein Actionspiel zu schreiben, besteht somit darin, die CPU-Leistung irrsinnig hochzuschrauben. Das hat jedoch (nach meinem Geschmack) mit Retro und 8 Bit-Stil nicht mehr viel zu tun.
    Den Grund, warum das Kompilieren nicht möglich ist, habe ich an anderer Stelle schon genannt. Die Kurzform: Die NEXT-Anweisung und dazugehörig die RETURN-Anweisung verhalten sich wie selbstmodifzierender Code und sind zur Compilezeit nicht eindeutig definiert. Eine Übersetzung ist ohne komplizierte Ablaufverfolgung/Codeduplikation... nicht machbar.


    Aus dem Grunde hatte ich diejenigen, die gerne auf dem Rechner selbst programmieren möchten, gefragt, ob es unbedingt Basic sein muß oder auch eine andere kompilierbare Sprache sein könnte, die sich nicht nur vom NEXT verabschiedet, sondern auch Datentypen wie INTEGER, CHAR, BOOLEAN beinhaltet sowie Strings fester Länge, um eine aufwendige Garbage Collection zu vermeiden.

    Zitat von ZeHa

    @Snoopy es geht doch aber auch darum, dass dieser "neue 8-Bit-Rechner" auch irgendwie eine Daseinsberechtigung benoetigt. Wenn man jetzt einfach so einen neuen 8-Bit-Rechner rausbringt, was genau ist denn dann der Grund fuer die Entwickler, etwas dafuer zu entwickeln? Viele werden dann vielleicht sagen, "dann nehme ich doch lieber einen vorhandenen Rechner, den bereits zig Leute besitzen". Wenn man schon einen Fantasie-Rechner designt, dann muss der doch auch irgendwas koennen, was andere nicht koennen. Und der Punkt "direkt drauf entwickeln" waere da halt schon sehr reizvoll. Ansonsten wuesste ich jetzt halt keinen Grund, warum man sich den holen sollte. Anderer Projekte wie z.B. MEGA65 und Spectrum NEXT hingegen haben halt den Pluspunkt, dass sie eine vorhandene Rechner-Linie fortfuehren oder einen nie erschienenen Rechner zum Leben erwecken. Aber ein kompletter Fantasie-Rechner hat doch erstmal das Problem, dass er irgendjemanden davon ueberzeugen muss, dass er sich den holen soll, sei es als Entwickler oder Nutzer. Also was waere dann Dein Vorschlag, was dieser Rechner koennen soll, um ihn attraktiv zu machen?

    Es gibt schon noch technische "Finessen", die mit 8bit möglich, aber damals nicht umgesetzt worden sind.


    Was mir persönlich sehr als Hardwaremerkmal gefallen würde, wäre zum Beispiel ein 8-bit Rechner, in dem zwei 8bit-CPUs eingebaut sind (wie z.B. beim Sharp MZ 3500 zwei Z80). Beide CPU sollten entweder komplett oder nur einen Bereich auf einen gemeinsamen Speicher zugreifen können, ansonsten unabhängig voneinander arbeiten. Das könnte ich mir mit einem angepassten Basic für "Parallelrechner" zum Beispiel sehr interessant vorstellen. Das gab es im Homecomputermarkt so nicht, wäre aber technisch nicht unmöglich. Und es wäre ein Merkmal, das zumindest mich zum Kauf reizen würde, weil es ein ganz neue 8bit-Erfahrung wäre.

    Zitat von ZeHa

    Wie wuerdest Du das 8-bit-Feeling denn definieren?

    Schwer zu beschreiben. Es hängt für mich schon auch mit der Geschwindigkeit zusammen. Man muss sich quasi anstrengen, um das letzte Quentchen Geschwindigkeit noch rauszuholen, damit es "flott genug" ist.


    Ein Rechner, der so schnell ist, dass er problemlos gefüllte 3D-Grafikwelten flüssig auf den Bildschirm zeichnen kann, wäre z.B. für mich kein 8bit-Feeling mehr.


    Zusammengefasst kann es schon ein bisschen(!) flotter sein, aber insgesamt schon "wie früher". Schwer in Worte zu fassen ...

    Für mich würde würde eine Grafikauflösung 320x200 und 32Farben und eine Soundengine mit 4-6 Stimmen per Grundwellenformen schon das Retrofeeling ausmachen. Allerdings dann nur 2D Games und mit Joystick/Pad gespielt. Ob das alles dann im Browser oder auf extra Hardware am Fernseher läuft ist mir persönlich egal. Am besten es läuft überall zu wie bei diesem Pico8.


    Assembler ist ja eine Sache die ich nur aus masochistischer Herausforderung jetzt wieder angehe. Freiwillig will man so was heute nicht mehr haben, dazu bin ich von aktuellen Sprachen + IDE viel zu sehr verwöhnt. Aktuelle PCs machen die Softwareentwicklung soooo viel einfacher als es damals der Fall war. Damals war wirklich alles ein Krampf von der Entwicklerseite her.

    Zitat von Korodny

    Allerdings habe ich keine Erfahrung mit separatem Video-RAM, abgesehen von etwas VDC-Gehacke.


    Wie muss ich mir so etwas vorstellen? Wird da alles, was der Videochip irgendwann anzeigen soll, Byte für Byte ins VRAM geschrieben?

    Hi, bin spät dran mit Erklären, und wurde sicher schon behandelt, aber du siehst das ganz richtig. Der Vergleich mit dem VDC passt auch ganz gut. Alles, was der darstellen muss, muss erstmal durch den Videochip in das VRAM gepumpt werden. Dazu kommt, dass der V9958 nicht der Allerschnellste ist. Nach jedem VRAM-Zugriff muss man quasi 8µs warten, bis der Chip wieder bereit ist, neue Daten entgegen zu nehmen. Zum Glück unterstützt der 9958 bis zu 192k DRAM, das bei uns auch komplett ausgebaut ist, so kann man schonmal viel Zeugs im Vorfeld auf die "richtige" Seite des Datenbus schaffen.

    Zitat von Snoopy

    Was mir persönlich sehr als Hardwaremerkmal gefallen würde, wäre zum Beispiel ein 8-bit Rechner, in dem zwei 8bit-CPUs eingebaut sind ..., weil es ein ganz neue 8bit-Erfahrung wäre.


    Mit 8-Bit assoziiert man doch eher einfache Zugänglichkeit und keine kompliziertere Programmierung.


    Zitat von ArnoldLayne

    Dazu kommt, dass der V9958 nicht der Allerschnellste ist.


    Was hat denn für euch den Ausschlag für den V9958 gegeben?

    Als Kind hat mich das mit dem PEEK und POKE verrückt gemacht. Ja, ich wußte echt nicht, wo Platz "außerhalb BASIC" zu finden ist, den man benutzen konnte, also das Schreiben von Bytes und danach das Lesen von Bytes da möglich ist. Und ich dachte immer, die PEEKs und POKEs würden ewig dauern, weil für 1k in Basic schon echt viel Zeit vergang.


    Heute bin ich schlau. Nicht nur PEEK und POKE ist langsam, sondern jeder Befehl, den der C64er kann. Also relativ.

    Zitat von Snoopy

    Was mir persönlich sehr als Hardwaremerkmal gefallen würde, wäre zum Beispiel ein 8-bit Rechner, in dem zwei 8bit-CPUs eingebaut sind (...) Das gab es im Homecomputermarkt so nicht, wäre aber technisch nicht unmöglich.

    C64 mit Final Chesscard oder CP/M-Modul, Apple II mit diversen Erweiterungskarten von Z80 über 68000 bis Transputer, SuperPET mit 6809-Karte, irgendeine andere obskure CBM-Kiste mit noch obskurerer 8088-Karte, Epson PX-8 mit getrennter CPU für die Display-Ansteuerung (und eigenem Z80 in der anflanschbaren RAM-Disk), DEC Rainbow, ...