Hello, Guest the thread was called101k times and contains 1748 replays

last post from Hoogo at the

Neuer Retro-Computer im 8-Bit Style

  • Der unique selling point für einen neuen Retro-artigen Lern- und Spielcomputer wäre für mich:
    "Du kannst mit dem Teil einfache 2D Retro-Spiele recht einfach selbst coden."
    "Wir nehmen Dich bei der Hand und geben dir genau das eine Toolset, womit das hier gemacht werden kann."
    "Wir verstecken keine Komplexität, sondern erklären schrittweise die ganze Kiste von oben bis unten".
    "Wenn Du die Kiste irgendwann super beherrschst, kann Du vielleicht so coole Sachen damit machen, wie wir es nicht erwartet hatten."
    Alles ist offen und nachvollziebar: Tools, Sprache, OS/ROM, Systemarchitektur, Prozessor, Grafik- und Soundchip

    Danke fuer die Zusammenfassung dessen, um was fuer einen Rechner es hier im Thread aktuell geht :thumbup:

    Also für mich liest sich das wie eine Beschereibung des C64. (-;

    Foristen gibt, die sich unter einem modernen Retrorechner immer noch gerne ein 8 Bit-System vorstellen wie den Mega65 in der Erwartung, daß so ein Rechner dann so leicht bedienbar sei wie der C64. Das ist nach allem, was ich bisher sehen konnte, allerdings weder beim Mega65 noch beim C256 Foenix noch beim Commander X16 der Fall.

    Ich bin ja von der C64-Fraktion, aber die Bedienung sollte doch auf den neuen Rechnern schon leichter sein? Modernerer Editor, bequemere Sprache?


    ZeHas Pseudocode inspirierte mich, mal zu sehen, wie sich auf dem C64 die Bequemlichkeit beim Programmieren steigern lässt, also habe ich mir das auch mal vorgenommen und in C64-BASIC umgesetzt, mit dem Ziel, dabei den neuen Befehlen nahe zu kommen.


    Dazu habe ich zu Beginn des Programms einige intuitiv benannte "Konstanten" definiert, dazu eine Byte-Tabelle und Arrays zur Sprite-Positionierung und -Datenzuordnung.


    Die "Befehle", um aus numerischen Daten oder einer String-Matrix Sprites zu erzeugen, sind nun Unterprogramm-Aufrufe, nachdem Sprite-Nummer, -Position und Formdefinition im Hauptprogramm angegeben wurden.


    Das eine Unterprogramm erzeugt aus den numerischen Daten 8x8-Sprites (der restliche Sprite-Datenbereich wird mit Nullen aufgefüllt), das andere erzeugt aus einer String-Matrix ein vollständiges Sprite. Das Programm ist also quasi auch ein spartanischer Sprite-Editor.


    Für gesetzte Bildpunkte bot sich dabei das PETSCII-Zeichen "ausgefülllter Kreis" an, damit ist die Form schon im Code recht gut erkennbar (es lässt sich aber auch jedes andere Zeichen verwenden, alles außer einem Punkt gilt als gesetzt):


    shot3.jpg


    Screenshot während des Programmablaufs, bevor Sprite 1 diagonal über den Bildschirm fliegt:


    shot1.jpg


    Ich hatte gehofft, ZeHas 8x8-Daten ergeben was Schönes, aber war wohl aus dem Zufallsgenerator. (-; Wobei Sprite 1 (links, rot) mit etwas Fantasie kniend einen Bogen spannt. (-:


    Fazit: Ist das Gerüst (Definitionen am Anfang und Unterprogramme) mal gebastelt, ist die Sprite-Handhabung recht ähnlich einfach wie mit den ausgedachten Befehlen im Pseudocode. Freilich ist dann da der Gerüst-Ballast, und das Einlesen der String-Matrix ist BASIC-typisch gemächlich (ginge vielleicht etwas schneller, bin nicht so der Code-Optimierer). Vielleicht krame ich mal einen Compiler raus.


    Der Code (umgewandelt mit PETCAT):


    PRG-Datei:

    sprite-demo.prg

  • sparhawk; Vielen Dank für die ausführliche Erklärung. Habe es jetzt einigermaßen verstanden. Hoffe ich. ^^

    Ich habe gestern noch bemerkt dass sich da ein Fehler eingeschlichen hatte, weil ich das falsch verstanden hatte. Ist aber nur ein kleines Detail, das jetz tnicht wesentlich was ändert. Die Register auf $ff01-$ff04 sind Register die die Auswahl aktivieren, soweit korrekt. $ff00 ist aber ein Schreib-/Leseregister. Man kann da also das Register $D500 verändern wenn man es beschreibt (um z.B. neue Konfigurationen zu ermöglichen). Wenn man in $ff01-$ff04 schreibt, dann wird der vorbelegte Wert in $d500 kopiert und aktiviert. Also ist eigentlich nur $d500 das "echte" Register mit dem auch eine Konfiguration aktiviert wird. Das hatte ich gestern bemerkt als im ROM Listing nochmal was nachgesehen hatte. :D

    Wie gesagt ist für die grundsätzliche Beschreibung nicht ganz so wichtig und wollte es nur der Vollständigkeit halber erwähnen falls du das ausprobieren willst. Jedenfalls kann ich dir "128 Intern" empfehlen von Data Becker, da ist das recht gut beschrieben und gibts auch als PDF zum Download.

    Also wenn du einen FPGA entwickelst und dir Gedanken machst wie man Banking implementieren könnte, dann wäre das sicher eine recht gute Methode.

  • wenn ich mir die drei Listings so ansehe dann fällt mir als unkwalifiziertem Laien auf das die ersten beiden Beispiele kürzer sind und das ich da mehr verstehen kann. Oder besser eine kleine Ahnung habe, was da gemeint ist.


    Selbst wenn ich die REM Zeilen aussen vor lasse, die ja nur für die Dokumentation sind soweit ich weiß, ist basic deutlich mehr zu tippen

  • Dafür ist das kein Pseudocode, sondern läuft. Auf einem Rechner, der existiert. (-;


    Wäre natürlich auch kürzer gegangen, ohne das "Gerüst", aber dann ohne die bequemere Sprite-Handhabung im Hauptprogramm. In dem kurzen Demo hat das "Gerüst" einen großen Anteil, in einem größeren Programm würde sich das relativieren.


    Und auf einem neuen Rechner mit umfänglicherem BASIC mit mehr Befehlen, auch für Sprites, wäre es wahrscheinlich kürzer und intuitiver als mit einer Pascal-artigen Sprache.

  • Also vielen Dank schonmal fuer die Umsetzung, natuerlich sieht man daran nun, welche Einschraenkungen das BASIC V2 hat. Auf einem C128 oder C16/C116/Plus4 wuerde das bestimmt schon wieder ganz anders aussehen, da es hier ja bereits entsprechende Befehle gibt.


    Grundsaetzlich hat der C64 aber auch das Problem, dass das Programm sehr langsam ist. Ein Spiel wie Pacman oder so koennte man damit nicht vernuenftig hinbekommen, und genau sowas waere in meinen Augen das Ziel - dass man einfache, Arcade-maessige Spiele mit wenig Code hinbekommen kann, die dann auch in einer Geschwindigkeit ablaufen, die man von den Originalen gewohnt ist. Das geht auf dem C64 mit reinem BASIC definitiv nicht.

  • Ich habe das Gefühl, dass sich hier teils unveränderliche Fronten auftun und alle in unterschiedliche Richtungen argumentieren und arbeiten. Die allerwenigsten (zumindest lauten) sind davon überzeugt, dass ein Retro-Computer, wie ich ihn mir z.B. vorstelle, sinnvoll, machbar oder erfolgreich sein könnte. Und ich habe zu viele andere, weitaus erquicklichere C64-Real-Projekte am Laufen, sodass mir die Zeit auch etwas zu schade ist, immer wieder gegen Mauern anzulaufen, Ideen zu vereinen, irgendwas zum drölfzigsten Mal zu erläutern, zu moderieren usw. Mir ist etwas die Lust vergangen, an diesem Gedankenspiel (zumindest momentan) weiter teilzunehmen. Jeder macht sein eigenes Ding, jeder läuft allein in seine eigene Richtung, niemand hat wirklich Interesse, ZUSAMMEN etwas zu machen oder Kompromisse einzugehen, Konsens ist nicht gefragt. Ich finde das zwar sehr schade – aber vielleicht kommen die anderen Beteiligten ja zu einem tollen Gesamtergebnis (und sei es auch nur theoretischer Natur, mehr kann man in so einem Thread ohnehin nicht verlangen) und dann freue ich mich mit.


    Wie gesagt, momentan bin ich hier erstmal raus und konzentriere mich auf "angenehmere" Projekte. Aber ich lese natürlich gerne mit und freue mich, wenn sich etwas (konstruktives) tut. Also weiterhin viel Spaß.

  • Naja meiner Meinung nach waere laengst die Zeit reif gewesen, das "konkrete Gedankenspiel" in einen neuen Thread abzukapseln, weil es hier im Thread keinen Konsens gibt und sich noch zu viele "sowas braucht man doch gar nicht"-Stimmen hier tummeln. Aber davon abgesehen glaube ich eh, dass die meisten, die sich einen eigenen "Traum-Retro-Rechner" designen wuerden, dies gerne "fuer sich" machen wuerden, weil sie dann alles genau so machen koennen, wie sie wollen. Ich hatte solch ein Projekt ja auch mal angefangen, hab aber auch ganz alleine recht schnell die Lust daran verloren - das kann auch passieren ;)

  • Was mir gerade noch einfaellt: Ich finde z.B. beeindruckend, was auf dem Atari XL mit Turbo Basic so moeglich ist:



    Das ist ein Spiel in 10 Zeilen. Klar, sowas gibts auf dem C64 auch. Aber immer nur mit PETSCII-Grafik. Das hier sieht aus wie ein richtiges Spiel, weil es umdefinierte Zeichen hat. Sowas finde ich z.B. auch essentiell wichtig, dass man sehr schnell und einfach eigene Grafiken fuer seine Programme machen kann. Sowas hat mir auf dem C64 als Kind immer gefehlt.



    EDIT: Korrektur, das ist kein Turbo Basic sondern "Fast Basic"

  • sowas waere in meinen Augen das Ziel - dass man einfache, Arcade-maessige Spiele mit wenig Code hinbekommen kann, die dann auch in einer Geschwindigkeit ablaufen, die man von den Originalen gewohnt ist. Das geht auf dem C64 mit reinem BASIC definitiv nicht.

    In interpretiertem BASIC - es wird aber gern vergessen, dass es auch Compiler gibt. Der nach Testergebnissen mit Abstand beste, BASIC BOSS, kam recht spät auf den Markt (1988, als der Zenit des C64 schon überschritten war), deshalb kennen den womöglich viele gar nicht.


    Ich komme die nächste Zeit wohl nicht dazu, aber ich will den selbst mal testen. Ich habe hier auch noch ein Autorennschleichspiel aus den 80ern in BASIC, das damit hoffentlich spielbar wird. (-:


    Es muss ja aber auch nicht immer schnelle Action sein. Ein entschleunigtes und entschleunigendes, fantasievolles Adventure o. ä. ohne Geballer ist auch mal schön.

  • Ja, dass man Adventures mit BASIC programmieren kann, duerfte jedem hier bekannt sein :)

    Tatsaechlich habe ich als Kind hauptsaechlich Adventures programmiert, da ich nichts anderes so richtig hinbekam. Aber aus der Not 'ne Tugend mache und sagen "es muss ja nicht immer Geballer sein!" ist ein wenig am Ziel vorbei. Hier gehts um die Idee eines NEUEN Retro-Rechners, auf dem man solche Dinge machen kann, und keiner wuerde Dir darauf verbieten, ein Adventure zu schreiben - aber es ist halt auch schoen, wenn andere Dinge auch gehen.


    Dass man auf dem C64 auch was programmieren kann und dass es dafuer auch Compiler gibt und alles, das ist halt nicht das Thema des Threads...

  • Grundsaetzlich hat der C64 aber auch das Problem, dass das Programm sehr langsam ist.

    Das Einlesen und Umwandeln der String-Sprite-Daten, aber sowas wäre einmal am am Anfang. Der Flug über den Bildschirm ist doch recht flott.


    Also bei einem statischen Hintergrund geht es eigentlich, wenn auch mit Joystick-Abfrage usw. wohl keine Hektik aufkommt. (-; Im Autoschleichen aus meiner Jugend lief die Strecke mit Zufalls-Biegungen und -Hindernissen am Bildschirm ab und dazu bewegten sich die Sprites, das war dann ein Gezuckel.

  • Der Flug über den Bildschirm ist doch recht flott.

    Der Flug ja, aber mehr als das passiert ja nicht.


    Ich habe mal versucht, sowas aehnliches mit 3 oder 4 Sprites zu programmieren. Das war schon ein "Schneckenrennen". Wenn da jetzt noch Spiellogik dazu kaeme, dann gute Nacht. Also das "flotte" BASIC-Spiel fuer den C64 will ich erst noch sehen, bisher sah ich da nix was auch nur annaehernd einem simplen Arcade-Spiel nahekommt.

  • Hast Du auch mal Compiler getestet (wenn ja, auch BASIC BOSS)?

    Haben wir den einen freien oder zumindest Freeware? Ich hab noch kein offizielles Statement vom BASIC-BOSS Autor gesehen das er das als Freeware raus gibt, demnach könnte er immer noch Leute verklagen wenn diese seinen Compiler nutzen wenn sie keine Lizenz besitzen, in dem Fall die Originaldiskette mit Buch.

  • Ich mag Tastaturcomputer.

    Foenix hat Zuwachs. Nicht billig.

    A2560K-040V

    Wow. Ich glaube ich setze hierfür wohl lieber weiter auf dem Commander X16 vom David Murray. o.O

  • Hast Du auch mal Compiler getestet (wenn ja, auch BASIC BOSS)?

    Nein, bisher nicht. Waere sicherlich mal interessant, aber von solch einem "Retro-Computer" wuerde ich mir gerade erhoffen, dass man sowas NICHT braucht oder es zumindest so im System verankert ist, dass das von allein geschieht. Das tolle am BASIC V2 ist ja, dass es im Rechner eingebaut und sofort verfuegbar ist. Wenn da jedesmal zusaetzliche Schritte notwendig sind, egal ob Compiler oder BASIC-Erweiterung, dann ist das irgendwie hinderlich fuer das gewuenschte "Erlebnis".

  • Nein, bisher nicht. Waere sicherlich mal interessant, aber von solch einem "Retro-Computer" wuerde ich mir gerade erhoffen, dass man sowas NICHT braucht oder es zumindest so im System verankert ist, dass das von allein geschieht.

    Schon den hier gesehen? https://geoffg.net/maximite.html
    Hat sogar einer Gauntlet für nachgeschrieben. In BASIC. Sprich die MCU macht BASIC und Video und Soundausgabe in Software schnell genug das man interpretierte Arcadespiele schreiben kann.