letzter Beitrag von ogd am
Neuer Retro-Computer im 8-Bit Style
- Retrofan
- Erledigt
-
-
Mal ganz ehrlich, wäre ein C65 School Edition 1989/90 gekommen, gegen was wäre der angetreten:
- Atari 1040 ST(E)
- Acorn Archimedes 3010/3020
- Schneider Euro PC (II)
- C= PC 10-III
- Macintosh LC
Ich lass den Amiga mal weg, wäre als Schulrechner eher schwierig zu vermarkten. Bin auch unsicher wegen der Preise, aber C65 haben wir ja auch keine genaue Preisvorstellung.
Was hätte wohl eure Schule gekauft, und was hättet ihr da gerne für den ITG/Informatik Unterricht gehabt?
Also meine Präferenz wäre sicher kein C65 Light gewesen.
Auszug aus 'Preliminary Manual' zum C65:
1.1. System Concept
The C65 microcomputer is a low-cost, versatile, competitive product
designed for the international home computer and game market.
Der C65 war NIEMALS als Lern- bzw. Schoolcomputer gedacht.
Ziel Anwender war schon immer der Heimanwender und Spieler.
Nicht mehr und nicht weniger.
-
...und wieso heisst der Classroom dann Classroom?
-
Ausserdem geht es hier nicht um den C65, sondern um den MEGA65, und der kommt im Jahr 2021 raus, und nicht im Jahr 1991. Das ist also so oder so eine ganz andere Situation.
-
Freddy Okay, dann ignorieren wir einfach mal die letzten 80 Seiten Diskussion
DER MEGA65 IST DOCH EIN NEUER RETRO-COMPUTER! Fall geschlossen! Thread dicht machen! Und ueberhaupt gibts ja auch den C128 und den C64!
Ich sehe schon einen Sinn in der Diskussion hier.
Moderne PCs sind einfach zu komplex.
Ein Homecomputer braucht diese Komplexität gar nicht.
Und leider müssen wir auch feststellen daß der Markt schon reichlich gesättigt ist.
Vielleicht entsteht hier ja sowas wie ein Computer der leicht verständlich ist, leicht zu handhaben und sehr kostengünstig ist.
Ich denke da z.B. an dem Versuch mit dem 1 Laptop per Child, der nur 100,-$ kosten soll.
Haben die auch nit geschafft.
-
Naja deshalb haben sich hier im Thread ja mehrere Ansaetze herauskristallisiert, wie ein neuer Retro-Computer sein koennte und welchen Zweck er erfuellen koennte. Der Ansatz, den Retrofan am besten findet (und er ist der Ersteller des Threads), ist, einen modernen Retro-Computer zu designen, der den Leuten beim Einstieg ins Coden helfen soll. Und deshalb geht es jetzt hier hauptsaechlich darum. Andere Ansaetze wurden in andere Threads ausgelagert. Jetzt zu sagen, hier gehts nicht um einen Lern-Rechner, und nicht jeder der einen Computer kauft will coden lernen, ist daher ziemlich verkehrt.
-
...und wieso heisst der Classroom dann Classroom?
"For the Classes, not the Masses."
-
Einstieg ins Coden ist aber quasi die Primärfunktion vom Raspberry Pi.
-
Einstieg ins Coden ist aber quasi die Primärfunktion vom Raspberry Pi.
Vielleicht die angedachte Primaerfunktion, aber mit Sicherheit nicht die de-facto-Primaerfunktion.
Genauso wie der C64 ja primaer fuer Hausaufgaben und so gedacht war
-
...und wieso heisst der Classroom dann Classroom?
"For the Classes, not the Masses."
lol
-
- Der deutlichste Unterschied zu Basic dürfte sein, daß alle Bezeichner inklusive Variablen vor ihrer Verwendung deklariert werden müssen. Das sieht umständlich aus, hat aber fünf Vorteile:
Die Vorteile sehe ich – allerdings ist es für Anfänger quälend und für Ex-Basic-Nutzer ungewohnt. Könnte der Editor nicht so einen kleinen Helfer-Dämon haben, der bei vergessenen Deklarationen den Nutzer darauf hinweist und auch gleich hinzufügt (der Typ ist ja oft erratbar, bei For-Schleifen z.B. meistens integer)? Wenn man es richtig macht, sieht man das Helferlein nie und wenn man es falsch macht, wird es einem korrekt beigebracht und auch gleich korrigiert.
- Ein weiterer Unterschied zu Basic ist die Verwendung von ';' anstelle von ':' zur Trennung von mehreren Befehlen. Bei Basic müssen alle Befehle zwingend in einer Zeile abgeschlossen sein, bei Pascal und dessen Derivate nicht.
Semikolons: Ich verstehe nicht ganz, warum manche Befehle ein Semikolon bekommen und manche nicht. Manche ENDs haben eins, manche nicht. Da waere ich auf jeden Fall fuer Konsistenz, und ich persoenlich halte das Semikolon fuer ueberfluessig.
Ich finde Semikolons auch eher nervig (werden gerne vergessen und man sucht sich dann einen Wolf und wenn man stattdessen einen Doppelpunkt eingegeben hat, findet das Auge den Fehler auch nur mit Mühe) und finde z.B. Lua-Code, bei dem ein Return ein Befehlstrenner ist, viel übersichtlicher und weniger Fehlerträchtig. Ich finde, das Semikolon sollte man von Pascal nicht übernehmen. Es macht den Code auch einfach "hässlich".
Was die Definition von Grafikdaten auf diesem Wege anbelangt, so habe ich auch meine Zweifel, ob es wirklich sinnvoll ist. Zum einen verbrauchen die Strings sehr viel Platz im Speicher (nämlich doppelt so viel als hätte man einen 16 Farbmodus). Außerdem entsteht die Frage, wie man die verschiedenen Farben kennzeichnen soll.
Ich bin nach wie vor der Meinung, Grafik- und Sounddefinitionen haben im Code nichts verloren. Dafür haben wir die entsprechenden Editoren. Deren Inhalt wird beim Speichern an die Datei angehängt (vielleicht sogar ab bestimmten Größen gepackt) und fertig.
COLOR: Beim Befehl COLOR soll es sich um die Textfarbe handeln. Auf dem CPC heisst das z.B. INK. In CSS heisst es ebenfalls "color" und nicht z.B. "text-color", waehrend die Hintergrundfarbe "background-color" heisst.
Wo du gerade von Text sprichst: In CSS definiert man ja Schrift-Stile noch etwas umfangreicher, kann z.B. einen Schatten definieren und welcher Font und welche Auszeichnung (bold, kursiv ..) und welche Ausrichtung verwendet werden soll. Vielleicht macht man es hier ganz ähnlich und definiert Styles (bzw. Formatvorlagen), die man dann bei der Darstellung nutzen kann.
Mein 'ideal' Homecomputer wäre ein 128er mit StereoSID (ist ja nachrüstbar), SD2IEC als 'Massenspeicher', ein 17xx, eine 1351, vielleicht noch eine WiC64 (brandneu & ideal).
Dann solltest du doch zufrieden sein – das gibt es alles schon. Ich frage mich immer wieder, was Leute, die für sich den perfekten Homecomputer gefunden haben, in diesen Thread treibt (wo Leute diskutieren, die sich einen noch tolleren vorstellen können).
Der Titel heisst Retro-Computer im 8-Bit Style.
Von Lern- bzw. Schulcomputer steht da nix.
Und was die Programmiersprache angeht: nicht jeder der einen Computer kauft will programmieren lernen.
Tut mir leid, dass du erst jetzt aus dem Koma aufgewacht bist. Der Thread hat sich entwickelt – sorry, dass wir nicht auf dich gewartet haben.
Irgendwann mittendrin haben wir neben Wünschen auch versucht zu definieren, was denn eine Marktlücke für einen weiteren Retro-Homecomputer sein könnte. Ich hatte gemutmaßt, dass alle Retro-Computer der 2020er Jahre ein gemeinsames Problem haben werden: zu wenig native Spiele (im Vergleich zu damals™ oder zu Spielkonsolen). Und ich bin der Meinung (andere teilen die sogar), dass das CBM-Basic (egal ob nun Version 2 oder 12) einen potentiellen Programmierer von Videospielen (die über Kartenspiele und Zahlenraten hinaus gehen) sehr schnell vor hohe Hürden stellt, die letztendlich bedeuten, nochmal mit Assembler neu anfangen zu müssen.
Aus diesen beiden Axiomen haben wir dann eine denkbare Lösung geformt: Ein neuer/weiterer Retro-Homecomputer sollte/könnte sich auf das Erstellen von Spielen konzentrieren. Wenn viele der Kunden anfangen würden, (wenn auch anfangs einfache) Games zu entwickeln, dann hätte dieser Rechner nicht das potentielle Problem der anderen, wo vielleicht auf 20 Käufer ein Assembler-Coder kommt (oder noch viel weniger) und man mit Basic nicht wirklich "gute" (Artion-)Spiele entwickeln kann (ich meine damit sowas wie Pac-Man, Zelda oder Xevious). Das wäre also ein Weg aus der "Software-Krise".
Aber wenn der Rechner zum leichten Erlernen einer (modernen) Programmiersprache taugen würde, deren Ergebnisse zudem Spaß machen würden – dann könnte man ihn auch als Lern-Computer einsetzen. Das ist aber mitnichten der einzige Anwendungsfall – aber ein zusätzlicher.
Das BASIC wirklich nicht das non-plus-ultra ist, ist bekannt, aber fürs schnelle ausprobieren allemal gut genug.
Wer wirklich Programmieren will steigt eh schnell auf andere Sprache.
Aber genau diesen doppelten Einstieg wollen wir den Usern ersparen. Das hier zuletzt besprochene Rechnerkonzept lässt den Kunden nicht so schnell hängen, sondern soll es ermöglichen, viel länger ohne Frust von dem einmal erlernten partizipieren zu können.
Und was den Mega65 angeht: Der Thread lag ja eine ganze Zeit lang brach und erst der Einwurf von vor ein paar Tagen, der M65 wäre doch genau das, was sich alle hier wünschen würden, hat ihn wieder aus der Versenkung geholt. Denn der Mega65 erfüllt kaum welche der hier geäußerten Wünsche – nicht mal die nach einem günstigen Preis von 100 bis 200 Euro. Und damit auch dem Wunsch nach einer hohen Verbreitung. Das Basic ist zwar gegenüber dem C64 besser geworden (und der Takt um das absurde 40-fache gesteigert) – ich sehe aber nicht, dass das die damaligen™ Grenzen bzgl. Basic-Spiele-Entwicklung wirklich aufhebt.
-
Aber dieser Thread heißt nun einmal "Neuer Retro-Computer im 8-Bit Style." Persönlich halte ich auch einen 16 Bit-Prozessor für eine Untergrenze.
Wie gesagt, ich bin schon lange davon ausgegangen, dass eine 8-Bit-CPU nicht ausreichen wird. Aber 8 Bit war für den Prozessor auch gar nicht "gesetzt" – es ging von Anfang an um den 8-Bit-STYLE, also um die Wirkung, die Multimedia-Fähigkeiten.
-
Mal ehrlich, keiner wird seinem Filius, seiner Filia einen 800€ Mega65 kaufen, damit die vielleicht mit BASIC 10 in die Programmierung einsteigen.
Da ist in der Tat ein Raspi 400 der sinnvollere Einstieg. Im Kit ist ja auch ein gedrucktes Buch dabei mit AFAIR einem Scratch 3 und einem Python/PyGameZero Kurs.
Klar kann man damit locker die Grundlagen der Programmierung und den Umgang mit Linux lernen.
Vielleicht unterschätze ich die Wissbegier der heutigen Kids, aber ich glaube nicht, dass die da in Massen jetzt Spiele für den Raspi 4/400 coden und dabei auch noch tiefer in OS und Hardware reinschauen.
Also so tief, dass man wirklich ein Gefühl dafür bekommt, wie die Kiste wirklich tickt.
Warum:
- gegen eine moderne Konsole/PC ist der Pi sehr schwache HW (für Spiele)
- die Kinder sind komplexen 3D Bombast mit vielen Jahren und Millionen Entwicklungsaufwand gewohnt
- alle Tools sind extrem high-level und weit weg von der HW
- die HW ist vom OS verrammelt
- das OS ist super komplex, weil 30-50 Jahre Unix/Posix/Linux/X11 Ballast und portabel zu Unmengen an Zeug
- die HW ist nicht offen, aktuelle Pi4 VC6 Treiber werden z.B. mit NDA Doku entwickelt, die man von Broadcom erbetteln muss
- ARMv7/ARMv8 ISA haben auch viel Ballast und Speck, echte "Reduced Instruction Set Architecture" ist das seit Jahrzehnten nicht mehr
- es gibt unmengen Sprachen, IDEs, Frameworks - womit soll man weitermachen, wenn Python nicht mehr reicht
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
Die Kinder sollen doch heute schlucken, dass die Digital-Toys eigentlich nicht mehr ihnen gehören, sondern Apple, Nintendo, Google, MS damit treiben, was sie wollen und dass Offenheit und Programmierbarkeit absichtlich immer weiter verhindert werden. Die Industrie will abhängige, unmündige Enduser, die alles fressen, alles abbonieren und am Ende noch dafür blechen, dass sie bevormundet, ausspioniert und gegängelt werden.
Und dafür bekommen sie noch nicht mal halbwegs sichere Geräte und Systeme, sondern ein Haufen chronisch unsicherer Bloatware.
-
Aus diesen beiden Axiomen haben wir dann eine denkbare Lösung geformt: Ein neuer/weiterer Retro-Homecomputer sollte/könnte sich auf das Erstellen von Spielen konzentrieren. Wenn viele der Kunden anfangen würden, (wenn auch anfangs einfache) Games zu entwickeln, dann hätte dieser Rechner nicht das potentielle Problem der anderen, wo vielleicht auf 20 Käufer ein Assembler-Coder kommt (oder noch viel weniger) und man mit Basic nicht wirklich "gute" (Artion-)Spiele entwickeln kann (ich meine damit sowas wie Pac-Man, Zelda oder Xevious). Das wäre also ein Weg aus der "Software-Krise".
Ich möchte das nochmal ein wenig auswalzen:
Das wäre auch die Lösung gegen das Henne/Ei-Problem, mit dem sich jede neue Plattform herumschlagen muss: Zu wenig Software = zu wenige Kunden UND zu wenige Kunden = zu wenig Software. DENN die Käufer dieses Rechners hätte keine großen Erwartungen an vorgefertigter Software (= Spiele-Katalog) – sie wollen ja programmieren. Und indem sie programmieren, entsteht Software für die Plattform. Und wenn erst diese Hürde genommen wurde, steigen evtl. auch diejenigen ein, die doch gerne fertige Games zocken wollen – und mit denen (bzw. den steigenden User-Zahlen) kommen dann auch professionelle Entwickler, die mit Cross-Assemblern auf PCs FÜR die Plattform entwickeln.
Aber selbst, wenn das nicht passiert – so hat die erste Welle der Entwickler-Nutzer ja genau das, was sie haben wollte: Einen Rechner, mit dem man sehr einfach hübsche Spiele entwickeln kann. Ob sie nun Pioniere sind für eine weitere Welle von reinen Konsumenten/Gamern, muss sie ja nicht interessieren.
-
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 SoundchipDanke fuer die Zusammenfassung dessen, um was fuer einen Rechner es hier im Thread aktuell geht
-
sparhawk; Vielen Dank für die ausführliche Erklärung. Habe es jetzt einigermaßen verstanden. Hoffe ich.
Die Vorteile sehe ich – allerdings ist es für Anfänger quälend und für Ex-Basic-Nutzer ungewohnt. Könnte der Editor nicht so einen kleinen Helfer-Dämon haben, der bei vergessenen Deklarationen den Nutzer darauf hinweist und auch gleich hinzufügt (der Typ ist ja oft erratbar, bei For-Schleifen z.B. meistens integer)? Wenn man es richtig macht, sieht man das Helferlein nie und wenn man es falsch macht, wird es einem korrekt beigebracht und auch gleich korrigiert.
Daß es für Ex-Basic-Nutzer ungewohnt ist, mag ja sein. Das wäre bei C oder Python oder Lua oder... aber auch so. Daß es für Anfänger quälend ist, wage ich hingegen sehr zu bezweifeln. Wir haben damals[tm] an unserer Schule als erste Sprache Pascal gelernt, und ich habe keinen gesehen, der dies nicht als einleuchtend und leicht zu handhaben empfand. Von Quälerei keine Spur.
Soweit ich es beobachten konnte, trifft das Nichtdeklarieren von Variablen in Basic nur bei sehr kleinen Programmen zu. Bei allen größeren finde ich zu Beginn des Programms eine Nennung der Variablen in Form einer Zuweisung wie "i=0", damit diese Variable später vom Interpreter schnell gefunden werden kann. Außerdem müssen Arrays mit mehr als 10 Elementen mittels DIM erzeugt werden, was in der Regel ebenso am Anfang geschieht. Pseudokonstanten wie die VICII-Adresse werden ebenfalls gerne ganz am Anfang des Programms definiert. Anders gesagt: Wer wirklich schon längere Programme in Basic geschrieben hat, ist mit dem Konzept der Vorabnennung durchaus vertraut.
Was den Editor anbelangt, darf jeder sich gerne einen Editor wie von Dir beschrieben anfertigen.
Ich finde Semikolons auch eher nervig (werden gerne vergessen und man sucht sich dann einen Wolf und wenn man stattdessen einen Doppelpunkt eingegeben hat, findet das Auge den Fehler auch nur mit Mühe)
Ein Semikolon in Pascal/Oberon wird nicht häufiger vergessen als ein Semikolon in C/Java... oder ein Doppelpunkt in Basic. Und man sucht sich auch keinen Wolf, weil der Compiler sagt, an welcher Stelle er es vermißt.
Lua-Code, bei dem ein Return ein Befehlstrenner ist, viel übersichtlicher und weniger Fehlerträchtig
Daß jedes Statement sich nur über eine Zeile erstrecken darf, ist eine unnötige Einschränkung bei der optischen Gestaltung des Programms. In der Praxis kommt es häufig vor, daß umfangreiche Ausdrücke (= Berechnungen) oder Funktionsaufrufe mit vielen Parametern sich über mehrere Zeilen erstrecken. Und auch wenn mein persönlicher Stil so aussieht, daß ich jedem Statement eine eigene Zeile zuweise, gibt es immer Situationen, in denen dies unpassend ist und anders gehandhabt werden muß.
Ich dachte, darüber wären wir schon hinaus. Dein (besser-als-68000er-) "Fantasie"-Prozessor war doch, glaube ich, sogar ein 32 Bit-Prozessor.
Wie gesagt, ich bin schon lange davon ausgegangen, dass eine 8-Bit-CPU nicht ausreichen wird. Aber 8 Bit war für den Prozessor auch gar nicht "gesetzt" – es ging von Anfang an um den 8-Bit-STYLE, also um die Wirkung, die Multimedia-Fähigkeiten.
Ja, klar bin ich persönlich längst von dem Gedanken an einen 8 Bit-Computer weg. Aber Du siehst ja, daß es genügend 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.
Das wäre auch die Lösung gegen das Henne/Ei-Problem
Sehe ich auch so. Nutzer schreiben Programme für andere Nutzer. In der Anfangszeit von VC20 und C64 konnte man das noch so beobachten. Da wurden kleine Spiele in Basic geschrieben und herumgereicht (oder sogar verkauft!). Als dann die Assemblerspiele immer besser wurden, sahen Basicprogramme dagegen zu mickrig aus, und leider waren sie auch zu langsam für Actionspiele.
An der Stelle sei der Hinweis gestattet auf das ApplePascal, das wir an der Schule benutzten. Da unsere Programme in einen P-Code übersetzt wurden, waren sie erheblich schneller als das interpretierte Basic. Außerdem bot das Pascal mächtige Grafikbefehle an, so daß wir in der Lage waren, kleine Spiele in Pascal zu schreiben, die schon besser aussahen als die von Basic. Natürlich war der Abstand zu den Assemblerspielen immer noch recht groß, aber nicht mehr so sehr, daß der Eindruck entstand, das eigene Werk sei im Vergleich dazu totaler Mist. Im Gegensatz zu den vielen hier im Forum, die mit Commodore Basic angefangen haben, habe ich daher schon früh die Erfahrung gemacht, daß man mit einer Hochsprache leicht eigene Spiele schreiben kann. Und genau dieses Gefühl sollte meiner Meinung nach ein moderner Retrorechner von heute ebenfalls vermitteln.
-
-
Overkill.
Definitiv Nischenprodukt.
-
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 SoundchipDanke fuer die Zusammenfassung dessen, um was fuer einen Rechner es hier im Thread aktuell geht
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):
Screenshot während des Programmablaufs, bevor Sprite 1 diagonal über den Bildschirm fliegt:
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):
Code- 100 rem sprite-demo
- 102 rem ===========
- 110 :
- 120 rem sprechende konstanten
- 122 rem ---------------------
- 130 cs$="{clr}":bo=53280:bg=53281:co=646:v=53248
- 140 :
- 150 rem spritepos-regs in spr. arrays
- 152 rem -----------------------------
- 160 for i=0to7
- 170 x(i)=v+i*2
- 180 y(i)=v+1+i*2
- 190 next
- 200 :
- 210 rem byte-tabelle (revers)
- 212 rem ---------------------
- 220 j=7:for i=0to7:by(i)=2^j:j=j-1:next
- 230 :
- 240 rem sprite-data-zuordnung
- 242 rem ---------------------
- 260 data 2040,11,704,2041,13,832,2042,14,896,2043,15,960
- 280 for i=0to3
- 290 :for j=0to2
- 300 :read sd(i,j)
- 310 :next
- 320 next
- 330 :
- 340 rem hauptprogramm
- 342 rem =============
- 350 :
- 360 print cs$
- 370 poke bo,0:poke bg,0:poke co,5
- 380 print"this is an example{down}"
- 390 :
- 400 for i=1to5
- 410 poke co,i
- 420 print"gemuese":rem plausibler als bunte wurst
- 430 next
- 440 :
- 450 sp=1:x=50:y=150:gosub 900
- 460 rem 8x8num sprite
- 470 data 32,64,73,254, 77, 80,24,57
- 480 :
- 490 sp=2:x=100:y=150:gosub 900
- 510 data 70,50,20, 30,128,144,27, 0
- 520 :
- 530 sp=3:x=150:y=150:gosub 1000
- 540 rem string sprite
- 550 data"........................
- 560 data"......QQQQ..............
- 570 data".....Q....Q.............
- 580 data".....Q....Q.............
- 590 data"......Q..Q..............
- 600 data".....Q....Q.............
- 610 data"....Q......Q............
- 620 data"...Q.QQ..QQ.Q...........
- 630 data"..Q.Q.Q..Q.Q.Q..........
- 640 data"...Q..Q..Q..Q...........
- 650 data"......Q..Q..............
- 660 data".....Q.QQ.Q.............
- 670 data"....Q.Q..Q.Q............
- 680 data"....Q.Q..Q.Q............
- 690 data"...QQQQ..QQQQ...........
- 700 data"........................
- 710 data"........................
- 720 data"........................
- 730 data"........................
- 740 data"........................
- 750 data"........................
- 760 :
- 770 x=64:y=48:rem sprite 1 position:
- 780 poke x(1),x:poke y(1),y
- 790 x=x+2
- 800 y=y+1
- 810 if x>240 or y>216 then end
- 820 goto780
- 830 :
- 890 rem unterprogramme
- 892 rem ==============
- 893 :
- 894 rem 8x8num sprite
- 895 rem -------------
- 900 poke sd(sp,0),sd(sp,1)
- 910 dc=sd(sp,2):rem init data counter
- 920 for i=0to7
- 930 read ds:poke dc,ds
- 940 poke dc+1,0:rem auffuellen
- 950 poke dc+2,0
- 960 dc=dc+3
- 962 next
- 964 for i=1to39:rem auffuellen
- 966 poke dc+i,0
- 968 next
- 972 poke v+21,peek(v+21) or 2^sp
- 974 poke x(sp),x:poke y(sp),y
- 976 :
- 978 return
- 980 :
- 990 rem string sprite
- 992 rem -------------
- 1000 poke sd(sp,0),sd(sp,1)
- 1070 dc=sd(sp,2):rem init data counter
- 1080 for i=1to21
- 1090 :read ds$
- 1100 :for j=0to2
- 1110 : for k=8to1 step-1
- 1120 : bi$=mid$(ds$,k+j*8,1)
- 1130 : if bi$="."then bi=0:goto1150
- 1140 : bi=1
- 1150 : by%=by%+bi*by(k-1)
- 1160 : next
- 1170 : poke dc+j,by%:by%=0
- 1180 :next:dc=dc+3
- 1190 next
- 1200 poke v+21,peek(v+21)or 2^sp
- 1210 poke x(sp),x:poke y(sp),y
- 1220 return
PRG-Datei:
-
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.
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.