Wurden nicht schon früher Spiele wie Turrican am PC entwickelt und der fertige Code dann nur noch zum C64 übertragen?
Hallo Besucher, der Thread wurde 242k mal aufgerufen und enthält 1853 Antworten
letzter Beitrag von Retrofan am
Neuer Retro-Computer im 8-Bit Style
- Retrofan
- Erledigt
-
-
Wurden nicht schon früher Spiele wie Turrican am PC entwickelt und der fertige Code dann nur noch zum C64 übertragen?
Zumindest ist es mittlerweile der gebräuchliche Weg, wenn man für die alten 8 Bitter ein halbwegs größeres Projekt entwickelt.
Insofern ist es ja auch schwierig, einen Kompromiss bei der Ausstattung zu finden, wenn der Wunsch geäußert wird, dass man AUF dem Retrorechner auch die Entwicklung der Software vornehmen will. Oder zumindest kleinere Projekte damit machen will.
Ansonsten bräuchte ein Retrorechner für Spiele - überspitzt formuliert - nicht einmal eine Tastatur, sondern nur Joystickports, weil das Spiel auf dem PC mit Entwicklertools erstellt wird und dann nur noch auf den Retrorechner "raufgeschoben" wird.
Das wird ja gerade hier im Thread diskutiert, wie man diesen "Interessenkonflikt" am besten lösen kann. Limitierte technische Daten für ein "echtes" 8bit-Feeling, aber gleichzeitig "gut genug" für - zumindest einfachere - Entwicklungstools.
-
Ansonsten bräuchte ein Retrorechner für Spiele - überspitzt formuliert - nicht einmal eine Tastatur, sondern nur Joystickports, weil das Spiel auf dem PC mit Entwicklertools erstellt wird und dann nur noch auf den Retrorechner "raufgeschoben" wird.
Das nennt man dann ja Konsole.
Natürlich sollte es beides geben (in einer perfekten Welt) – eine IDE für den PC/Mac, mit der man vorwiegend in Assembler die großen Projekte umsetzen kann – UND die kleine IDE mit einer Hochsprache AUF dem Retro-Computer, mit der u.a. Anfänger kleinere Projekte recht spontan umsetzen können.
Wir bleiben aber nach wie vor im Sumpf der möglichen Specs stecken und niemand konnte bisher eine Lösung präsentieren, die einerseits das komfortable und performante Hochsprachen-Programmieren AUF der Maschine ermöglicht, andererseits (durch Einschränkungen bei Performance und RAM) bei Assembler-Programmierung (auf dem PC) das nötige Retro-Feeling erzeugt.
Ich hoffe immer noch darauf, dass irgendwer in der Lage ist, diesen gordischen Knoten zu zerschlagen.
-
Das nennt man dann ja Konsole.
Und wenn ein Tastatatur-Anschluss dran ist? Ein PC hat ja auch keine Tastatur eingebaut und ist keine Konsole, und jeder kann sich die Tastatur selbst aussuchen. Auf eingebaute Tastatur könnte ich deswegen durchaus verzichten. Ein Anschluss für eine Tastatur wäre dann aber ein Muss, USB oder PS/2 wäre mir egal. Spiele sollten in solch einem Fall aber auch konsequent auf Tastaturabfrage verzichten bzw. immer Alternativen für Pad/Stick anbieten.
Man sieht, wie hier die Vorstellungen auseinander gehen: Von der puren Daddelkiste (nenne ich mal Compusole ^^) bis zum vollwertigen Rechner à la MEGA65 und darüber hinaus.
-
Damit waere man wieder hier
Neuer Retro-Computer im 8-Bit Style -
Auf eingebaute Tastatur könnte ich deswegen durchaus verzichten.
Ich auch. Schon alleine wegen der zu erwartenden Kosten.
Man sieht, wie hier die Vorstellungen auseinander gehen: Von der puren Daddelkiste (nenne ich mal Compusole ^^) bis zum vollwertigen Rechner à la MEGA65 und darüber hinaus.
Wenn ich mir die Umfrage angucke, dann kann man daraus schon ein paar Schlüsse ziehen. Natürlich liegt der Fokus, wie bei jedem Retro-Rechner oder jeder Retro-Konsole, auf dem Starten fertiger Spiele, die irgendwer anders programmiert hat. Ergänzend soll der Rechner natürlich auch interessant für semi-professionelle Entwickler sein (die wahrscheinlich mit Cross-Compilern am PC arbeiten werden, um die heiß ersehnten Games zu programmieren). Für beides braucht das Gerät nicht unbedingt ein Keyboard. Aber ein weiterer Nutzungs-Zweck wurde auch sehr oft genannt: Das Programmieren direkt auf der Kiste. Dafür braucht man ein Keyboard – meines Erachtens kann das aber gerne ein externes sein – um die Kosten gering zu halten. Beim Formfaktor sehe ich die geringsten Probleme – ob nun mit oder ohne internem Keyboard.
Den größten Knackpunkt beim Zusammenführen der unterschiedlichen Wünsche sehe ich weiterhin darin, dass die Semi-Pro-Entwickler eigentlich nur geringe Hardware-Specs benötigen, während die BASIC-auf-der-Kiste-Kompilierer (zwischenzeitlich) recht viel MHz und MB bräuchten, um einigermaßen vernünftige Games entwickeln zu können.
-
... während die BASIC-auf-der-Kiste-Kompilierer (zwischenzeitlich) recht viel MHz und MB bräuchten, um einigermaßen vernünftige Games entwickeln zu können.
Ich habe ja weiter oben (Neuer Retro-Computer im 8-Bit Style) schon Beispiele gepostet, wo mit Hilfe des cc65-Cross-Compilers ganz brauchbare Actionspiele geschrieben wurden. Gibt es auch vergleichbare Games auf dem C 64, wo ein Basiccompiler zum Einsatz kam? -
..., weil sich so ein Retro-Rechner nun mal nach dem Einschalten mit einem BASIC-Prompt o.ä. melden sollte – und nicht nur mit einem Monitor.
Na ja, solange wir kein Lochkartenstanze organisieren müssen um mit dem Rechner zu kommunizieren ist doch alles im Butter, oder?
-
Den größten Knackpunkt beim Zusammenführen der unterschiedlichen Wünsche sehe ich weiterhin darin, dass die Semi-Pro-Entwickler eigentlich nur geringe Hardware-Specs benötigen, während die BASIC-auf-der-Kiste-Kompilierer (zwischenzeitlich) recht viel MHz und MB bräuchten, um einigermaßen vernünftige Games entwickeln zu können.
Ich sehe hierfür nur die Möglichkeit, zwei verschiede Modi im Rechner zu vereinen. Mehr oder weniger strikt getrennt: Ein Modus zum Entwickeln und ein Modus, der der eigentliche Rechner ist. Der erste mit mehr "Power" und Speicher und der zweite mit den gewünschten Limitierungen. Natürlich mit der Möglichkeit, Daten zwischen den Modi auszutauschen (z.B. über RAM-Disc oder SD-Karte).
Nur sind das halt dann irgendwie "zwei Rechner" und dann kann man genausogut den PC zum Entwickeln nehmen und sich den "Entwicklermodus" und dadurch Kosten sparen. Dann landet man wieder beim reinen 8bit-Rechner mit den gewohnten Einschränkungen.
Oder man sagt sich eben "knallhart": "Das ist dein gewünschter 8bit-Rechner und nun lebe auch mit den dadurch bedingten Limitierungen. Punkt." Compilieren auf einer 8bit-Maschine mit paar KB Speicher dauert halt mal seine Zeit. Also quasi "Entschleunigung inklusive".
-
Ein Modus zum Entwickeln und ein Modus, der der eigentliche Rechner ist. Der erste mit mehr "Power" und Speicher und der zweite mit den gewünschten Limitierungen.
Mein Lösungsvorschlag wäre dazu: Da auch ein einfach gestrickter 80-Zeichenmodus gewünscht wird, kann in dieser Betriebsart der Turbo gezündet werden. Dadurch wird auch der Editor fluffiger und der Compiler kann richtig loslegen. Im Multicolor-40-Zeichen- und -Bitmapmodus dagegen wird gebremst. Nun könnte man einwenden, dass dann auch monochrome Textadventures beschleunigt werden. Aber damit lässt sich leben. finde ich. -
Wurden nicht schon früher Spiele wie Turrican am PC entwickelt und der fertige Code dann nur noch zum C64 übertragen?
Bei Turrican weiß ich es nun nicht, aber Andrew Braybrook beispielsweise programmierte später seine Spiele auf einem PC. Bei Interplay wurde mittels DMA-Hardware der Code direkt von einem Arbeitsrechenr (wahrscheinlich eher ein Apple//(gs)) in den Speicher des C64 assembliert. Bekannt ist die Entwicklungssoftware von Lucasfilm Games, die auf einem Großrechner lief und eine etwas merkwürdige Assemblersyntax erforderte.
Auf dem Amiga sah es teilweise ein wenig anders aus. Braben entwickelte "Virus" noch mit Devpac, aber schon "Elite" von Mr. Micro wurde auf dem PC geschrieben. Anders gesagt: Crossdevelopment ist älter, als man denkt.
Ansonsten bräuchte ein Retrorechner für Spiele - überspitzt formuliert - nicht einmal eine Tastatur
Kommt halt darauf an, was für Spiele man entwickeln will. Adventures brauchen eine Tastatur, komplexe Flugsimulationen oder Spiele wie "Elite" auch. Nicht jeder spielt zudem gerne mit dem Joystick. Einige bevorzugen die Tastatur für die Steuerung.
Auf eingebaute Tastatur könnte ich deswegen durchaus verzichten. Ein Anschluss für eine Tastatur wäre dann aber ein Muss
Würde ich auch so sehen. Was die Gesamtausstattung der Hardware anbelangt (Gehäuse, Tastatur usw.) kann sich jeder sein Modell zusammenbauen bzw. ein zusammengebautes für Andere anbieten.
Wir bleiben aber nach wie vor im Sumpf der möglichen Specs stecken und niemand konnte bisher eine Lösung präsentieren, die einerseits das komfortable und performante Hochsprachen-Programmieren AUF der Maschine ermöglicht, andererseits (durch Einschränkungen bei Performance und RAM) bei Assembler-Programmierung (auf dem PC) das nötige Retro-Feeling erzeugt.
Ein 32 Bit-System in der Leistungsfähigkeit des AtariST oder Amiga500 wäre ein guter Kompromiss. Es ist auch für Anfänger leicht in Assembler zu programmieren, bietet aber genügend Power, um in einer Art Basic auf dem Rechner selbst Programme zu schreiben. Doch damals wie heute gilt, daß Basic-Programme mit den in Assembler geschriebenen nicht mithalten können. Eine Sprache wie Basic ist nun mal eher geeignet, um darin Adventures, Wirtschaftssimulationen, Rollenspiele o. ä. zu schreiben und keine schnellen Shooter. Es gibt einen Abstand zwischen Basic und Assembler, der sich nicht wirklich gut überbrücken läßt, schon gar nicht, indem man die Prozessorleistung so weit ankurbelt, daß dann die Assemblerprogramme lächerlich schnell laufen. Von daher wäre es vielleicht besser, sich von der Vorstellung einer Programmierung von schnellen Arcade-Spielen auf gleicher Höhe mit Assembler zu verabschieden und den Anspruch etwas weniger hoch zu stellen. Eines dürfte jedoch sicher sein: Im Verhältnis zum C64 wäre ein Programm in Basic auf einem 68000-ähnlichen Prozessor schon deutlich leistungsfähiger.
Aber hat eigentlich auch jemand daran gedacht, dass wir für die neue CPU auch mindestens eine Hochsprache (nennen wir sie mal (Compiler-freundliches) BASIC) benötigen?
Ja, natürlich. Ein Basic-Interpreter/-Compiler wäre gar nicht so schwierig zu schreiben, wenn Basic nicht so eine nervige Sprache wäre. Zum einen benötigt man, wenn es ein Basic im Stil des Microsoft-Basic sein soll, ein Fließkommapaket. Würde man sich auf Integer beschränken, wäre es schneller und einfacher zu implementieren. Zum anderen müßte man einige syntaktische Elemente ändern wie die NEXT-Anweisung. Sofern die Programmierer bereit sind, sich auf solche Änderungen einzulassen, wäre eine Hochsprache in der Form von Basic möglich. Mein Eindruck ist aber immer wieder, daß viele Leute gerne Microsoft-Basic hätten, nur dann halt mit mehr Graphikbefehlen, und das läßt sich halt wesentlich schlechter realisieren.
Ich sehe hierfür nur die Möglichkeit, zwei verschiede Modi im Rechner zu vereinen. Mehr oder weniger strikt getrennt: Ein Modus zum Entwickeln und ein Modus, der der eigentliche Rechner ist. Der erste mit mehr "Power" und Speicher und der zweite mit den gewünschten Limitierungen. Natürlich mit der Möglichkeit, Daten zwischen den Modi auszutauschen (z.B. über RAM-Disc oder SD-Karte).
Das wären dann faktisch zwei Rechner in einem, also doppelte Arbeit bei der Entwicklung und doppelte Kosten bei der Herstellung, denn wie sollte man beide Modi so trennen, daß sie wirklich unüberbrückbar getrennt bleiben? Es dürfte keine Woche dauern, daß jemand daherkommt und das erste Spiel für den schnellen Entwicklungsmodus schreibt. Dann wäre es vielleicht doch besser, die natürliche Trennung zwischen PC und Rechner zu nehmen. Komplexe Programme wird man ohnehin auf dem PC entwickeln wollen. Die Programmierung auf dem Gerät selber ist auch denkbar, und wer will, darf es selbstverständlich gerne tun, aber es dürfte sich dann wie auch bei anderen Rechnern heutzutage eher um sowas wie Basicprogramme handeln und weniger um Arcadeshooter und dergleichen. Für Basic wäre aber der "normale" Modus eines 32 Bit-Rechners mit 512kb schon ausreichend genug. Anders als beim AmigaBasic bestände der Trick ja darin, daß man nicht eine Ebene wie das Fenstersystem von AmigaOS dazwischengeschaltet bekommt, sondern wie beim C64 direkt mit der Hardware in Kontakt treten kann, also Zeichensatz laden, per Poke oder Befehl Videoregister ansprechen usw.
Mein Lösungsvorschlag wäre dazu: Da auch ein einfach gestrickter 80-Zeichenmodus gewünscht wird, kann in dieser Betriebsart der Turbo gezündet werden.
Eigentlich ist es ja genau andersherum.
80 Zeichen benötigen mehr Speicherzugriffe und bremsen damit den Prozessor eher aus als 40 Zeichen. Ich denke aber, daß man auch in Basic eine 80 Zeichenausgabe haben sollte (, sofern man möchte,) ähnlich wie beim AppleII.
Nur sind das halt dann irgendwie "zwei Rechner" und dann kann man genausogut den PC zum Entwickeln nehmen und sich den "Entwicklermodus" und dadurch Kosten sparen.
Am Ende läuft es wohl darauf hinaus.
Oder man sagt sich eben "knallhart": "Das ist dein gewünschter 8bit-Rechner und nun lebe auch mit den dadurch bedingten Limitierungen.
Bei 8 Bit wäre es in der Tat knallhart, denn bei 8 Bit wäre es mit dem Kompilieren oder Assemblieren sowieso nur eine Qual. Aber bei 32 Bit ist dies durchaus noch denkbar, wenn man nicht gerade umfangreiche C-Compiler im Stil von gcc erwartet.
-
Würde man sich auf Integer beschränken, wäre es schneller und einfacher zu implementieren. Zum anderen müßte man einige syntaktische Elemente ändern wie die NEXT-Anweisung. Sofern die Programmierer bereit sind, sich auf solche Änderungen einzulassen, wäre eine Hochsprache in der Form von Basic möglich.
Auf dem 8-Bit Atari gibt es die Sprache Action. Das ist eine Entwicklungsumgebung mit Compiler, der recht guten 6502-Code erzeugt. So etwas könnte ich mir gut vorstellen.
-
Eigentlich ist es ja genau andersherum.
80 Zeichen benötigen mehr Speicherzugriffe und bremsen damit den Prozessor eher aus als 40 Zeichen.
Ich dachte da wirklich an einen sehr primitiven 80-Zeichenmodus. Also keine Sprites möglich, nur eine globale Hintergrundfarbe, wenn überhaupt, dann nur monochromes 640x200-Bitmap und je 8x8-Pixel-Zeichen maximal eine individuelle Farbe. Wäre dieser Modus dann immer noch langsamer als zum Beispiel ein vollwertiger Multicolor-40-Zeichenmodus mit allem Pipapo?
Ich denke aber, daß man auch in Basic eine 80 Zeichenausgabe haben sollte
Kann man ja, aber dann halt sehr, sehr einfach gestrickt. -
Auf dem 8-Bit Atari gibt es die Sprache Action. Das ist eine Entwicklungsumgebung mit Compiler, der recht guten 6502-Code erzeugt. So etwas könnte ich mir gut vorstellen.
So eine spezielle Sprache wäre sicherlich möglich. Ein kleiner Blick in Wikipedia zeigt, daß es in dieser Sprache keine Fließkommazahlen gibt. Fließkommazahlen lassen sich leider schlecht kompilieren, und eine Übersetzung ist kaum schneller als der Interpreter, da die aufwendigen Berechnungen von den gleichen Routinen durchgeführt werden wie bei der Interpretation. Zusätzlich werden Variablen vorab deklariert (wie in Pascal), und die Sprache verfügt über ein genau definiertes Ende einer FOR-Schleife oder anderer Strukturen, so daß ein Compiler zur Compilezeit bereits weiß, wohin das Programm springen soll. Wie gesagt: Wenn Programmierer bereit sind, sich mit einer Spezialsprache anzufreunden, die nicht identisch ist mit dem vertrauten Microsoft-Basic, ist einiges möglich, wenn auch mit der Einschränkung, daß der Abstand zu Assembler weiter bestehen bleibt. Was man jedoch alles aus einer solchen Sprache herausholen kann, läßt sich schwer einschätzen. Möglich, daß die Leistung höher ist als gedacht, da man mit einer Sprache wie "Action" die Hardware ohne irgendwelche Zwischenschichten direkt ansprechen kann. Man bräuchte wohl ein reales System und ein paar Programmierer, um das wirklich festzustellen.
Wäre dieser Modus dann immer noch langsamer als zum Beispiel ein vollwertiger Multicolor-40-Zeichenmodus mit allem Pipapo?
Ja. Angenommen man hätte einen 40 Zeichen-Modus in der Auflösung 320x200 und 4 Farben und 640x200 und 2 Farben. So benötigt man pro Zeichenreihe
- 40 Zeichen: 40 Buszugriffe für die Zeichen und 8 * 2 Zugriffe (16 Bits pro Zeile für 8 Pixel mit 4 Farben) auf den Zeichensatz, d. h.
40 + 40 * 8 * 2 = 680 Buszugriffe.
- 80 Zeichen: 80 Buszugriffe für die Zeichen und 8 Zugriffe auf den Zeichensatz, ad. h.
80 + 80 * 8 = 720 Buszugriffe.
Verfügt der Videocontroller über keinen Cache für die Zeichen, erhöht sich die Anzahl pro Zeichenreihe auf
- 40 Zeichen: 40 * 8 + 40 * 8 * 2 = 960
- 80 Zeichen: 80 * 8 + 80 * 8 = 1280.
Verwendet man bei einem 16/32 Bit-Prozessor einen 16 Bit-Datenbus ergibt sich mit Cache Folgendes:
- 40 Zeichen: 20 + 40 * 8 = 340.
- 80 Zeichen: 40 + 80 * 8 = 680.
Ohne Cache:
- 40 Zeichen: 20 * 8 + 40 * 8 = 480.
- 80 Zeichen: 40 * 8 + 80 * 8 = 960.
Sprites sind hierbei getrennt zu betrachten, da diese während der horizontalen Austastlücke geladen werden unabhängig von der Anzahl der Zeichen.
nur eine globale Hintergrundfarbe
Man kann auch ohne Farbram ein paar mehr Farben erzeugen, indem man ähnlich wie beim ECM-Modus des C64 Zeichengruppen (z. B. jeweils 32 aufeinanderfolgenden Zeichen) eigene Vorder- und Hintergrundfarben zuordnet. Damit lassen sich Großbuchstaben anders einfärben als Kleinbuchstaben oder graphische Symbole. Das wäre nicht so bunt wie bei einem gesonderten Farbram, würde aber für einfache Effekte schon reichen.
-
Ein 32 Bit-System in der Leistungsfähigkeit des AtariST oder Amiga500 wäre ein guter Kompromiss.
Schauens doch bitte mal auf dem Threadtitel.
8-Bit-Style, dafür braucht es keine 32-Bit Maschine.Und was diese ganze Grafik-Modi angeht: ein 80-Zeichen-Modus wäre heutzutage schon ein 'muß'.
Schon MSX und cp/m-Rechner als auch die cpc's & Co hatten ein 80-Zeichen-Modus.Wenn ich die ganze Diskussion hier so verfolge, sehe ich eigentlich ein MSX2 bzw. MSX3 (Plus) Rechner. Höchstens mit ein paar MHz mehr und ein größeren Arbeitsspeicher.
Apropos Speicher: für ein 8-Bit System reichen wirklich 128 bis 256kB aus. Alles was darüber hinaus geht ist nur effektiv als RAM-Disc nutzbar, aber bei heutiger Technik (SD2IEC z.B.) ist der bedarf an so ein RAM-Disc eigentlich obsolet, weil man (für'n 8-Bitter) genau so schnell direkt von SD lesen kann.
Apropos Compiler auf 8-Bitter bzw. 'keine' Hochsprachen auf 8-Bitter: Schon unter cp/m gab es alle Sprachen die man nur erdenken konnte. Auch als Compiler. Also was soll das? Daß diese ältere System nicht dem Komfort modernere Systeme haben liegt einfach an der Entwicklung. Heute würden auch auf 8-Bit durchaus moderne Komfort einzug halten.
Und last but not least: Es wurde immer noch nicht genau gesagt welche Usern nun angesprochen werden sollten.
Ich denke 90% wären Retro-Zockern, 5% 'Anwender' und wenn es hoch kommt 5% Entwicklern.
Und wie die Geschichte uns zeigt: die meisten 'professionelle Software' wird in der Regel mittels Cross-Compiling entwickelt. -
Ich habe ja weiter oben (Neuer Retro-Computer im 8-Bit Style) schon Beispiele gepostet, wo mit Hilfe des cc65-Cross-Compilers ganz brauchbare Actionspiele geschrieben wurden.
Aber zum einen war das ein Cross-Compiler (also nicht auf der Maschine selbst), zum anderen ist nicht geklärt, wie nah an der Maschine denn die C-Programme gebaut wurden.
Von daher wäre es vielleicht besser, sich von der Vorstellung einer Programmierung von schnellen Arcade-Spielen auf gleicher Höhe mit Assembler zu verabschieden und den Anspruch etwas weniger hoch zu stellen.
Ich mag mich davon aber noch nicht verabschieden, weil das einfach eine (meines Erachtens) große Gruppe von Interessenten abschrecken würde. Nicht wenige wollen so einen Retro-Rechner nutzen, um direkt auf der Maschine etwas zu realisieren (zumindest ist das auch der Ansatz des 8-Bit-Guys). Und es ist klar, dass mit BASIC oder PASCAL nicht das gleiche geht, wie mit Assembler. Aber ich würde den Unterschied halt möglichst gering halten wollen. Beim C64 ist es ja so, dass einen die BASIC-Performance schon nach kurzer Zeit frustriert. So eine Erfahrung wäre für den Retro-Rechner sub-optimal.
Ich sag mal so: Von einem Sam's Journey-Port würde ich auch auf der neuen Maschine erwarten, dass er in Assembler programmiert wird. Aber ein Pac-Man oder Space-Invaders oder Jumpman sollte man schon noch in BASIC (kompiliert) schaffen können.
Würde man sich auf Integer beschränken, wäre es schneller und einfacher zu implementieren.
Ja, ein Integer-Basic hat ja auch Steve Wozniak noch selbst (quasi nebenbei) für seinen Apple II programmiert. Für ein Floating-Point-Basic brauchte es dann aber schon Microsoft als Partner.
Zum anderen müßte man einige syntaktische Elemente ändern wie die NEXT-Anweisung. Sofern die Programmierer bereit sind, sich auf solche Änderungen einzulassen, wäre eine Hochsprache in der Form von Basic möglich. Mein Eindruck ist aber immer wieder, daß viele Leute gerne Microsoft-Basic hätten, nur dann halt mit mehr Graphikbefehlen, und das läßt sich halt wesentlich schlechter realisieren.
Ich glaube nicht, dass die Leute hier (im Gegensatz zum 8-Bit-Guy) unbedingt Commodore/Microsoft-BASIC haben wollen. Aber was die Leute bestimmt gerne sehen wollen, ist eine Sprache (und ein Editor), mit dem sofort auf der Kiste loslegen kann, sein Rest-Wissen aus den 80er-Jahren aufzufrischen. Wenn ein Befehl etwas anders funktioniert, als beim C64, ist das meines Erachtens nicht schlimm. Aber vorhanden sollte er sein. PRINT und (irgend)eine FOR-NEXT-Schleife sollte man schon vorfinden, der Rest ist verhandelbar.
wie sollte man beide Modi so trennen, daß sie wirklich unüberbrückbar getrennt bleiben?
"Schlimmstenfalls" könnte man es als 2 getrennte Rechner auf dem FPGA realisieren, bei dem der eine schnell ist, viel RAM hat und einen (schwarzweißen) 80-Zeichen-Modus – der andere hingegen langsam ist, aber Farbe, Softscrolling, Sprites etc. kennt. Und der schnelle Rechner kompiliert dann für den langsamen und startet ihn für die Ausführung. Ideal wäre das aber nicht – aber halt eine harte Trennung, die auch nicht zu leicht überbrückbar wäre. Ein Programm wäre halt schnell ODER "bunt".
Vorteil gegenüber einem PC-Cross-Compiler: Man säße weiterhin an der gleichen Kiste, würde die gleiche Tastatur benutzen und auf den gleichen Bildschirm gucken.
sondern wie beim C64 direkt mit der Hardware in Kontakt treten kann, also Zeichensatz laden, per Poke oder Befehl Videoregister ansprechen usw.
Wobei ich bei dem neuen BASIC die Peek- und Poke-Orgien des C64 gerne verlassen würde. Man sollte einfach deutlich mehr Befehle für Grafik, Scrolling, Sprites, Joysticks, Sound etc. haben, sodass man in deutlich weniger Fällen auf Pokes zurückgreifen muss.
8-Bit-Style, dafür braucht es keine 32-Bit Maschine.
Allerdings 8-Bit-Style. Mit dem 65816 setzen ja auch andere Projekte auf z.B. 16 Bit. Es geht halt vor allem darum, das richtige Gefühl beim User zu treffen. Auf die reale Bit-Breite kommt es dabei weniger an.
Wenn ich die ganze Diskussion hier so verfolge, sehe ich eigentlich ein MSX2 bzw. MSX3 (Plus) Rechner.
Ich nicht. Hier wurde z.B. fast nie von Z80-CPUs gesprochen und auch dediziertes VRAM (Standard bei MSX) wurde als eher untypisch abgelehnt.
Apropos Speicher: für ein 8-Bit System reichen wirklich 128 bis 256kB aus. Alles was darüber hinaus geht ist nur effektiv als RAM-Disc nutzbar
Allerdings wird hier meistens eher von mehr als 8 Bit gesprochen (wenn man von ALeX' Ansatz einmal absieht). Und da kann man dann schon streiten, ob man 512 KB haben möchte oder doch lieber 1, 2, 4 oder 16 MB.
Apropos Compiler auf 8-Bitter bzw. 'keine' Hochsprachen auf 8-Bitter: Schon unter cp/m gab es alle Sprachen die man nur erdenken konnte. Auch als Compiler.
Laut M. J. waren die aber höchst ineffektiv.
Und last but not least: Es wurde immer noch nicht genau gesagt welche Usern nun angesprochen werden sollten.
Doch, das wurde schon mehrfach gesagt bzw. diskutiert. Wie bei jeder Retro-Maschine überwiegen die reinen Gamer. Wie bei jedem Computer überwiegen die reinen Anwender deutlich gegenüber den Programmierern. Aber es sollen halt trotzdem nicht nur die Gamer angesprochen werden, weil die auch mit einer Retro-Konsole oder einem Emu glücklich werden könnten. Es soll auch das Publikum angesprochen werden, dass gerne mal (wieder) versuchen möchte, so eine Kiste (casual-mäßig) zu programmieren. Dafür muss das Konzept halt auch passen. Deswegen die gewünschte IDE AUF der Kiste, deswegen die erhoffte schnelle und einfach zu erlernende Programmiersprache, deswegen die dafür ausreichende Performance und Ausstattung.
Denn neben den geplant harten Einschränkungen im Bereich der Grafik (und vielleicht auch des Sounds) soll sich der Rechner vor allem darüber von der Konkurrenz abheben, dass er wirklich gut zu programmieren wäre. Und damit ist nicht gemeint, dass da nur ein umfangreiches BASIC integriert sein soll (das wäre ja auch beim Mega65 der Fall), sondern nach wie vor eher so etwas, wie man es vom PICO-8 her kennt – also eine richtige, kleine IDE auf der Kiste. Das wäre meines Erachtens die Quintessenz aus dem, was die meisten hier so gepostet haben. Natürlich ist das nicht der Wunsch von ALLEN (manchen würde es anscheinend auch reichen, ein kleines Keyboard an einen existierenden Handheld anzuschließen
) aber doch von vielen. -
Schauens doch bitte mal auf dem Threadtitel.
8-Bit-Style, dafür braucht es keine 32-Bit Maschine.Schauens doch bitte mal auf die aktuellen Projekte:
- 8 Bit-Guy: 65816 (16 Bit)
- Foenix256: 65816 (16 Bit)
- Mega256: Nach Informationen von Paul soll der Prozessor Befehle enthalten, mit denen man direkt auf Speicher > 64kb zugreifen kann. Auch kein 8 Bit.
Und schauens doch bitte auch mal in die vorherigen Posts.
Ich bin wahrlich nicht der erste, der einen 32 Bitter ins Spiel bringt. Jeder Wunsch nach
a) Programmierung auf dem Rechner selbst, sei es Hochsprache oder Assembler,
b) einer Sprache, die besser als Basic ist,
c) einer Programmierumgebung mit zusätzlichen Tools
verlangt nach einem Rechner mit mehr als 8 Bit.
Apropos Compiler auf 8-Bitter bzw. 'keine' Hochsprachen auf 8-Bitter: Schon unter cp/m gab es alle Sprachen die man nur erdenken konnte. Auch als Compiler. Also was soll das? Daß diese ältere System nicht dem Komfort modernere Systeme haben liegt einfach an der Entwicklung. Heute würden auch auf 8-Bit durchaus moderne Komfort einzug halten.
Nein.
1.) Niemand behauptet, es hätte damals[tm] keine Hochsprachen mit Compiler gegeben. Ich selber habe zu Beginn auf einem AppleII in UCSD-Pascal programmiert.
2.) Nein, unter cp/m gab es nicht alle Sprachen, die man sich nur erdenken konnte. Die Sprachen, für die es Compiler gab, waren so aufgebaut, daß sie in einer überschaubaren Anzahl von Durchläufen (bei Pascal 1 Durchlauf!) übersetzt werden konnten und keine umfangreichen Datenstrukturen dafür anlegen mußten. Alles, was an Sprache darüber hinausgeht (und dazu würden heutzutage nicht nur die objektorientierten Sprachen gehören), läßt sich nicht mittels 64kb kompilieren.
3.) Nein, auch heute gäbe es nicht mehr Komfort auf 8 Bit. Für Komfort braucht man nicht nur Geschwindigkeit, sondern auch mehr Speicher.
Ein typischer Arbeitsschritt beim Schreiben von Programmen sieht auf einem 8 Bit-System so aus:
a) Schreibe Code im Editor.
b) Speichere den Code in eine Datei.
c) Verlasse den Editor und rufe den Compiler auf.
d) Der Compiler übersetzt (langsam) den Code und stößt dabei auf einen Fehler. Ups.
e) Compiler beenden und Editor aufrufen.
f) Textdatei laden.
a) Fehler korrigieren.
b) Speichere den Code in eine Datei.
usw....
Das Prozedere habe ich damals[tm] zig Mal durchgemacht. So möchte man heutzutage nur noch als Masochist arbeiten.
Hinzukommt noch das Problem, daß der Speicher nicht ausreicht, um einen längeren Text im Editor zu editieren oder mehrere Textdateien gleichzeitig im Speicher zu halten. Ein Projekt für den C64 geschrieben in Assembler verschlingt bei mir locker mal eben über 400kb für die Quelldateien, und Andrew Braybrook hat mal erzählt, daß das übersetzen des Spiels "Uridium" auf dem C64 eine halbe Stunde gedauert hat. Zum Vergleich: Das schafft heutztutage ein PC in ein bis zwei Sekunden und erstellt dabei gleichzeitig ein lauffähiges Diskettenimage sowie ein komplettes Listing zur Kontrolle.
Kurz: 8 Bit-Rechner sind für ernsthafte Programmierung völlig ungeeignet. Da aber viele hier den Wunsch danach geäußert haben, auch kleine Spiele komfortabel auf dem Rechner selbst gestalten zu wollen, kommt man um 16 oder besser 32 Bit nicht herum. 32 Bit sind darum besser, weil 16 Bit-Rechner mit ihrem eingeschränkten 16 Bit-Adreßraum den Speicher auch nur häppchenweise ansprechen können, s. 65816 oder 8086. Das ist im Gebrauch äußerst umständlich, weil es unnötige Restriktionen auferlegt, und für den Assemblerprogrammierer eine Qual. Wenn, dann soll man es bitte von vornherein richtig machen. Und ja, das heißt auch, daß für mich persönlich ein Rechner mit 65816-Prozessor nicht attraktiv ist.
Ich sag mal so: Von einem Sam's Journey-Port würde ich auch auf der neuen Maschine erwarten, die er in Assembler programmiert wird. Aber ein Pac-Man oder Space-Invaders oder Jumpman sollte man schon noch in BASIC (kompiliert) schaffen können.
Bei einem 32 Bit-Rechner mit der ungefähren Leistung eines AtariSTs halte ich dies durchaus für machbar, denn hier kann der größere Speicher effektiv genutzt werden.
Geht man mal von "nur" ca. 512kb aus als Basis, dann würde man den Speicher so aufteilen:
- 64 kb für Bildschirmanzeige (zweimal 320x200x16 Bitmap für DoubleBuffering)
- 128 kb für System/Editor/Interpreter (notfalls auch mittels Swapping von SD-Karte)
- 128 kb für Text
- 64 kb für Programmdaten des Spiels
- 128 kb für "übersetzten Code"
Neben wir an, wir haben eine Sprache wie das erwähnte "Action", in der einfache Spiele geschrieben sind, wobei der Quellcode als Textdatei vorliegt. Die Ausführung des Programms kann auf verschiedene Weise erfolgen:
1.) Ein Scriptinterpreter übersetzt in Echtzeit den Text immer wieder neu und führt ihn dabei aus. Vorteil: Benötigt wenig Platz (die letztgenannten 128 kb schrumpfen stark zusammen). Nachteil: Ist sehr langsam, weil alle Befehle, Zahlen usw. stets neu identifiziert werden müssen.
2.) Vor der Ausführung wird ein Tokenizer gestartet, der den Quelltext umwandelt in Tokens wie beim C64-Basic. Ein Token enthält dabei folgende Angaben: a) Typ, b) Wert, c) Zeiger auf den Quelltext für mögliche Fehlerausgaben usw. Diese Tokenliste wird in den 128 kb für "übersetzten Code" gespeichert und für die Ausführung verwendet. Anders als beim C64-Basic werden hierbei jedoch weitere wichtige Schritte erledigt, die eine starke Beschleunigung bewirken:
a) Zahlen (als Folge von Ziffern) werden umgewandelt in ihren Zahlenwert.
b) WhiteSpace, Kommentare als auch für die Ausführung überflüssige Symbole wie ":" werden entfernt.
c) Alle Bezeichner, die nicht Teil der Sprache selbst sind wie Namen von Variablen oder Konstanten, werden (vorübergehend) in einer Namensliste gespeichert und erhalten daraufhin als Tokenwert nur noch den Index in diese Liste.
Allein diese Schritte bei der Tokenisierung erlauben schon eine extrem beschleunigte Ausführung, obgleich immer noch Interpreter basiert.
Mit dieser einfach durchführbaren Methode erreicht man bereits eine Sprache, mit der sich im Verhältnis zum C64-Basic auf einem 32 Bit-Rechner angenehm programmieren läßt. Es gibt allerdings die Möglichkeit, noch weitere Maßnahmen zu ergreifen. Hierfür ist jedoch eine flexiblere Tokenstruktur notwendig, da man in die Tokenliste eingreifen muß, d. h. Tokens müssen aus der Liste gelöscht und neue hinzugefügt werden. Um dies zu erreichen, setzt man für gewöhnlich eine doppelt-verkettete Liste ein, d. h. jedes Element bekommt einen Zeiger auf den Vorgänger und auf den Nachfolger.
Zu diesen Maßnahmen gehören:
a) Identifizieren von benutzerdefinierten Konstanten wie z. B. "MaX_ANZAHL" und ersetzen aller "MAX_ANZAHL"-Tokens durch den echten Wert.
b) Ausdrücke wie "(x + 3) * 4" werden umgewandelt in die UPN: x 3 + 4 * und können dadurch ohne weitere Verrenkungen ausgeführt werden.
c) Zusammenfügen von Konstanten zu einer Konstante wie z. B. "MAX_ANZAHL - 1" über "100 - 1" zu "99".
d) Dazu gehört auch die Auswertung von eingebauten Funktionsaufrufen mit Konstanten, z. B. "CHR$(33)" ==> "!"
e) Weitestgehende Auflösung von Bezeichnern, z. B. das Token "Variable" verweist auf eine Struktur, in der der Wert festgehalten ist oder die Adresse bzw. das Offset für den Wert steht.
f) Einfügen von internen Sprungmarkern und Sprunganweisungen bei IF-, FOR- und sonstigen Strukturen.
...
Jede dieser Maßnahmen kann einen Zuwachs an Geschwindigkeit erbringen. Wie weit man diese Optimierungstricks treibt, ist am Ende eine Frage des Speichers, denn sie kosten Platz im Interpreter, und die notwendige interne Datenstruktur zur Bearbeitung der Tokenliste wird aufwendiger. Dazu verlangsamen sie die Dauer bis zur eigentlichen Ausführung.
Nichtsdestoweniger wäre all dies bei einem 32 Bit-Rechner denkbar, da dieser die Grundvoraussetzung hierfür erfüllt: großer direkt (über Zeiger) ansprechbarer Speicher.
Wie schnell das am Ende wird, läßt sich schwer abschätzen, aber es dürfte - wie erwähnt - deutlich schneller sein als C64-Basic, und vielleicht bastelt jemand dann später auf dieser Vorstufe dann einen vollständigen Compiler (d. h. ein Backend für die genannte Struktur), der dann in einem weiteren Schritt direkt Assemblercode erzeugt. Machbar ist es jedenfalls. -
Ist mir zuviel text. Hab nicht alles gelesen.
Nur zwei Sachen möchte ich anmerken:
Ersten: mit Komfort meine ich z.B. das man heute kein ed (edlin bei DOS) nützt, sondern ein Editor mit Menü und Syntax highlighting nützt.
Das schafft ein 8-Bitter ohne probleme.Zum MEGA256 Den gibts noch lange nicht, aber ich gehe davon aus daß du den MEGA65 meinst.
Der hat ein Microcontroler mit 65CE02 als CPU Kern und 2 CIA sowie ein UART und ein MMU für bis zu 1MB RAM.
DIe CPU (65CE02) kann trotz alledem nur 64KB ansprechen. Sie hat ein paar zusätzliche 16bit Register bekommen (unter anderem der Stackpointer wurde auf 16bit erweitert). Im Kern ist er immer noch ein 8-Bitter.
Der C65 verwaltet dank sei DMAgic bis zu 8MB Ram, wobei der Microcontroller immer nur 1MB davon direkt 'sieht' (und der CPU Kern 65CE02 davon auch nur jeweils 64kB sieht).
CBM war auf dem Weg nach 16bit, aber noch lang nicht so weit wie Bill Mensch mit seinem 65816er. -
Ist mir zuviel text. Hab nicht alles gelesen.
Sorry, aber in solch einem Fall kann ich wirklich nicht anders als
.
Das schafft ein 8-Bitter ohne probleme.
Warum es nicht geht, hatte ich geschrieben, aber wenn Du Dich weigerst, Argumente zur Kenntnis zu nehmen, kann man halt nichts machen. Auf Deutsch: Du bist an einer Diskussion überhaupt nicht interessiert.
Der hat ein Microcontroler mit 65CE02 [..]
Du mußt mir nicht erzählen, was der 65CE02 ist und wie der funktioniert. Aber Du könntest selber mal das, was ich geschrieben habe, heraussuchen, doch nehme ich mal an, daß auch diese Tätigkeit Dir zu viel Arbeit bereitet. Also bitte, hier der Link sowie hier noch einmal die Bestätigung.
