Danke für die Aufklärung, das war mir nicht bewusst. Für mich ist der C64 ein Retrocomputer bis heute gewesen.
Hallo Besucher, der Thread wurde 180k mal aufgerufen und enthält 1853 Antworten
letzter Beitrag von Retrofan am
Neuer Retro-Computer im 8-Bit Style
- Retrofan
- Erledigt
-
-
-
Jeder erwartet bei so einem neuen Retrocomputer(geht so was überhaupt?) was anderes.
Mit "neu" meinte ich hier "zukünftigen", "kommenden". Retro beinhaltet ja auch so schon eine Kombination aus "jetzt" und "zurückliegend". Der Rest ist eine Plattitüde. "Jeder" erwartet auch von seinem zukünftigen Auto oder T-Shirt etwas anderes – trotzdem kann man Zielgruppen definieren, für die man etwas baut. Natürlich formuliert hier "jeder" andere Ideen bei dieser Brainstorm-artigen Diskussion. Trotzdem kann man auch Gemeinsamkeiten herausfiltern und letztlich würde ohnehin der, der sowas wirklich angeht, seine Quintessenz aus den Vorschlägen umsetzen.
So etwas wie den Mist(er) nur wirklich fix und fertig und in schön mit Handbücher, Supportseite, Shop mit neuer Software etc.
Ich glaube nicht, dass das funktioniert. Erstens spricht der MISTer schon vom Konzept her nur ein paar Bastelfreunde an – daran werden auch eine hübsche Verpackung oder Handbücher nichts ändern – denn nach dem Auspacken bleibt es eine Bastelkiste. und das ist dann auch gleich der nächste Nachteil: Der MISTer kann "alles" sein: Dem technisch weniger versierten ist das zu beliebig und für was will man dann Software entwickeln?
Ein Computer definiert sich durch sein Softwareangebot
Meine Idee des Jedermann-Spiele-Entwicklungs-Rechners kam ja nicht von ungefähr – ist auch etwas geklaut von Linux. Ich glaube nicht, dass irgend einer der kommenden Retro-Rechner (und auch der schon erschienenen) mit einer Flut professioneller Software-Titel rechnen kann. Wenn die Software-Entwicklung einigen "Profis" vorbehalten bleibt (weil BASIC für nix großes taugt und Assembler den meisten zu sperrig ist), dann bekommt man halt ein dutzend Spiele-Umsetzungen und Demos und Tools und das war's dann. Reich kann man mit Software für Retro- und Vintage-Computer ohnehin nicht werden, also ist das alles mit viel Enthusiasmus verbunden und die Stückzahlen reichen meistens nicht, um die Entwicklungen zu rechtfertigen.
Also ist mein Plan, den Retro-Computer so zu konzipieren, dass letztlich jeder User auch ein kleiner Programmierer wird. Wir machen die (wahrscheinliche) Not zur Tugend und entwickeln hier einen Selbst-Programmier-Computer. Es soll gar keine tolle 3rd-Party-Software geben (bis vielleicht ein paar Leuchtturm-Projekte, um die Leistungsfähigkeit zu zeigen) – der User soll gleichzeitig Entwickler sein und sehr schnell kleine Spielchen programmieren (und verteilen) können. Daraus soll letztlich der ganze Spaß mit der Kiste entstehen. Deshalb ist die leichte Zugänglichkeit so wichtig – wir wollen aus Noobs kleine Helden machen.
und mal um das Drumherum eines Computers zu reden, also Software, Shops, Support, Community, YouTubeKanal (alles jetzt nur zufällige Beispiele) ...
Ich bekomme ja schon fast Haue, wenn ich nur von Gehäuseform oder Zielgruppen spreche.
Ich denke, dass der YouTube-Kanal und alles andere von dir genannte automatisch kommen wird, wenn man erst einmal einen Computer (zumindest auf dem Papier) hat. Momentan haben wir nur eine Diskussion mit ein paar wirklich guten Ansätzen – Außer M. J. gibt es aber noch niemanden, der Zeit investiert hat, mal wirklich etwas im kleinen umzusetzen oder zu testen. Ich könnte jetzt noch nicht sagen: Hier ist das Team aus Fachleuten, die das stemmen könnten. Gerade im Hobby-Bereich benötigst du ein Team, weil immer irgendwer aus Zeitnot das Projekt zur Seiten legen wird. Der 8-Bit-Guy hat sich ja auch über das Veröffentlichen seiner Ideen ein Team zusammengesucht – alleine hätte er nichts machen können.Bitte nicht übel nehmen, das ist hier die Sicht eines Software-Menschen
Dann solltest du den oben genannten Ansatz ja eigentlich gut finden. Denn es geht bei diesem Konzept um Software – und zwar die, die die "DevUser" selbst auf der Kiste entwickeln. Dafür braucht es eine definierte Hardware (nicht drölfzig Cores auf einem FPGA) und eine tolle kleine Entwicklungsumgebung (inkl. Programmiersprache, Compiler und Editoren für Code, Grafik, Sound) AUF der Kiste (aber auch für den PC inkl. Emulation).
-
Denn die Hardware allein löst doch kaum einen Kaufreiz aus.
Das sehe ich ein bisschen anders.
Kein Softwareangebot für einen neuen "alten" Rechner - und damit meine ich wirklich keinen - kann auch nur annähernd an die Softwareanzahl rankommen, die es z.B. für den C64 gibt. Selbst wenn hunderte Entwickler sich dahinterklemmen würden.
Und wenn es um die Möglichkeiten von Software geht, sind die aktuellen Plattformen und Konsolen unschlagbar. Da reden wir von Echtzeit-Raytracing-Spiele und solche Kaliber. Um Software zu schreiben benötigt niemand einen "neuen alten" Rechner.
Es geht tatsächlich um das "Ausprobieren", das "Spielen" mit den (beschränkten) Möglichkeiten eines neuen "alten" Rechner. Das "Ausforschen", was geht. Und dafür benötigt man kaum fertige Software. Die wird man sich dann schon selbst zusammenbasteln, das ist ja auch Teil des Hobbys.
Aber niemand wird sich einen Retrorechner XYZ kaufen, weil es dafür "so gute" Software gibt. Keine Software könnte es so nicht auch auf einen aktuellen PC oder Konsole geben. Ob es für einen neuen Rechner "zig fertige" Spiele gibt, ist kein (oder kaum) Kaufanreiz.
-
Meine Idee des Jedermann-Spiele-Entwicklungs-Rechners kam ja nicht von ungefähr – ist auch etwas geklaut von Linux. Ich glaube nicht, dass irgend einer der kommenden Retro-Rechner (und auch der schon erschienenen) mit einer Flut professioneller Software-Titel rechnen kann. Wenn die Software-Entwicklung einigen "Profis" vorbehalten bleibt (weil BASIC für nix großes taugt und Assembler den meisten zu sperrig ist), dann bekommt man halt ein dutzend Spiele-Umsetzungen und Demos und Tools und das war's dann. Reich kann man mit Software für Retro- und Vintage-Computer ohnehin nicht werden, also ist das alles mit viel Enthusiasmus verbunden und die Stückzahlen reichen meistens nicht, um die Entwicklungen zu rechtfertigen.
Also ist mein Plan, den Retro-Computer so zu konzipieren, dass letztlich jeder User auch ein kleiner Programmierer wird. Wir machen die (wahrscheinliche) Not zur Tugend und entwickeln hier einen Selbst-Programmier-Computer. Es soll gar keine tolle 3rd-Party-Software geben (bis vielleicht ein paar Leuchtturm-Projekte, um die Leistungsfähigkeit zu zeigen) – der User soll gleichzeitig Entwickler sein und sehr schnell kleine Spielchen programmieren (und verteilen) können. Daraus soll letztlich der ganze Spaß mit der Kiste entstehen. Deshalb ist die leichte Zugänglichkeit so wichtig – wir wollen aus Noobs kleine Helden machen.
Diese Idee halte ich auch fuer die beste Idee. Ein MISTer in einer schoenen Verpackung spricht eine ganz andere Zielgruppe an, das waere dann eher eine Multi-Emulations-Kiste in einem neuen Tastaturgehaeuse. Aber ein moderner Retro-Rechner, der nicht alles in einem sein will, sondern eine neue Plattform darstellen soll fuer Jedermann-Programmierung (daher am besten in einer BASIC-artigen Sprache (ich sage bewusst "BASIC-artig" und nicht BASIC, denn auch ich finde 8bitguy's Idee, dass sein Rechner Commodore BASIC koennen soll, eher suboptimal)), das waere wirklich etwas, was spannend waere und vielleicht sogar einen gewissen Anklang finden koennte. Im Grunde sind wir da wieder bei der Idee "Sowas wie PICO-8, aber halt nicht direkt PICO-8, und auf einem eigenen Hardware-Rechner statt primaer als Software"
-
Meine Idee des Jedermann-Spiele-Entwicklungs-Rechners kam ja nicht von ungefähr – ist auch etwas geklaut von Linux. Ich glaube nicht, dass irgend einer der kommenden Retro-Rechner (und auch der schon erschienenen) mit einer Flut professioneller Software-Titel rechnen kann. Wenn die Software-Entwicklung einigen "Profis" vorbehalten bleibt (weil BASIC für nix großes taugt und Assembler den meisten zu sperrig ist), dann bekommt man halt ein dutzend Spiele-Umsetzungen und Demos und Tools und das war's dann. Reich kann man mit Software für Retro- und Vintage-Computer ohnehin nicht werden, also ist das alles mit viel Enthusiasmus verbunden und die Stückzahlen reichen meistens nicht, um die Entwicklungen zu rechtfertigen.
Also ist mein Plan, den Retro-Computer so zu konzipieren, dass letztlich jeder User auch ein kleiner Programmierer wird. Wir machen die (wahrscheinliche) Not zur Tugend und entwickeln hier einen Selbst-Programmier-Computer. Es soll gar keine tolle 3rd-Party-Software geben (bis vielleicht ein paar Leuchtturm-Projekte, um die Leistungsfähigkeit zu zeigen) – der User soll gleichzeitig Entwickler sein und sehr schnell kleine Spielchen programmieren (und verteilen) können. Daraus soll letztlich der ganze Spaß mit der Kiste entstehen. Deshalb ist die leichte Zugänglichkeit so wichtig – wir wollen aus Noobs kleine Helden machen.
Diese Idee halte ich auch fuer die beste Idee. Ein MISTer in einer schoenen Verpackung spricht eine ganz andere Zielgruppe an, das waere dann eher eine Multi-Emulations-Kiste in einem neuen Tastaturgehaeuse. Aber ein moderner Retro-Rechner, der nicht alles in einem sein will, sondern eine neue Plattform darstellen soll fuer Jedermann-Programmierung (daher am besten in einer BASIC-artigen Sprache (ich sage bewusst "BASIC-artig" und nicht BASIC, denn auch ich finde 8bitguy's Idee, dass sein Rechner Commodore BASIC koennen soll, eher suboptimal)), das waere wirklich etwas, was spannend waere und vielleicht sogar einen gewissen Anklang finden koennte. Im Grunde sind wir da wieder bei der Idee "Sowas wie PICO-8, aber halt nicht direkt PICO-8, und auf einem eigenen Hardware-Rechner statt primaer als Software"
Vielleicht sollte man Software und Hardware getrennt betrachten?
Zum einen eine Software wie z.B. in der Art von PICO-8 zum leichten Erstellen von Spielen und als Hardware z.B. einen Raspi in ein schönes Gehäuse, evtl. mit Tastatur, auf dem dann diese Software läuft und man auch was "zum Anfassen" hat. Also dass die Software der Hauptaspekt ist, die auch auf allen Plattformen (Win, Mac, Linux) läuft und somit Zugang für wirklich jeden bietet. Und zusätzlich ein "schönes Gehäuse", in das man den Raspi einsetzen kann.
Ich denke, dass man für das Ziel "leichte Softwareerstellung" nun wirklich keinen extra Computer entwickeln muss. Da würde ich lieber die Zeit und das Hirnschmalz in ein "geniales" Softwaretool stecken.
-
Ja Leute zum Programmieren zu animieren und das besser als es eh schon im Browser geht oder mit Sachen wie Arduino. Echt schweres Unterfangen, aber nun gut. Man kann ja über viele Projekte sprechen, was dann wirklich realisiert, steht auf einem anderen Blatt.
Kein Softwareangebot für einen neuen "alten" Rechner - und damit meine ich wirklich keinen - kann auch nur annähernd an die Softwareanzahl rankommen, die es z.B. für den C64 gibt. Selbst wenn hunderte Entwickler sich dahinterklemmen würden.
Nein und selbst der C64 Markt ist eine Nische.
-
Ja, das kann man so machen, also erstmal das Teil in Software entwickeln, weil die eigentliche Hardware vielleicht gar nicht so wichtig ist und es dann in der finalen Ausbaustufe auch auf einem Raspi in einem schoenen Gehaeuse mit Tastatur angeboten werden kann.
Aber es gibt hier ja auch die andere Fraktion, die eher dafuer ist, dass man etwas ueber die Hardware bzw. Funktionsweise eines Computers lernt, da ist es natuerlich eher wichtig, dass die Hardware-Komponenten ausgesucht sind und sich gut fuer diesen Zweck eignen.
Ich persoenlich bin da aber eher auf der "die Software/Programmiersprache ist das entscheidende"-Seite.
Letztendlich denke ich aber dass ein Gesamtpaket das ist, was einen zum Kauf verleiten wuerde, denn es hat eben schon was, so ein tolles, liebevoll gestaltetes Gesamtsystem zu haben. Daher sollte man das nicht erst am Schluss "zusammenschustern", sondern vielleicht schon von Anfang an in der Planung mit beruecksichtigen. Bei PICO-8 gibt es auch die Moeglichkeit, es auf "Hardware" laufen zu lassen, es gibt z.B. auch den PocketCHIP usw, aber letztendlich wird PICO-8 halt hauptsaechlich doch eher als Software-System angesehen.
-
In der MSX-Welt gibt es uebrigens ein sehr schoenes neues Gehaeuse, welches dafuer gedacht ist, intern eine Emulations-Loesung laufen zu lassen, um sich quasi so einen MSX-Clone zu bauen. Das finde ich wirklich cool (bin aber kein MSX-Experte und kann daher nicht sagen, ob MSX-Fans das genauso cool finden):
[Externes Medium: https://www.youtube.com/watch?v=LKKX6roL3Nk]
Im Prinzip steckt darin eine ganz normale PC-Tastatur (bis auf die Pfeiltasten), aber das faellt auf den ersten Blick gar nicht auf, da es durch das Gesamtbild doch eher wie ein Retro-Rechner ausschaut. In dieser Form koennte man auch ein Gehaeuse fuer "unseren" neuen Retro-Rechner bauen, mit einer modernen Tenkeyless-PC-Tastatur drin. Im Gehaeuse wuerde dann ein Raspi stecken, welches direkt in "unsere" Software-Plattform hineinbootet (vielleicht sogar Bare Metal, damit da eben nix erst booten muss).
Und darauf liefe dann ein simuliertes 320x200-16-Farben-System mit einer einsteigerfreundlichen Programmiersprache und ohne kuenstliche Geschwindigkeitsbegrenzungen, sodass man in diesem BASIC-artigen System auch was schnelles coden kann.
Tatsaechlich habe ich solch eine Software mal angefangen, habe es dann aber auf Eis gelegt da es einfach doch viel Aufwand ist.
-
Und darauf liefe dann ein simuliertes 320x200-16-Farben-System mit einer einsteigerfreundlichen Programmiersprache und ohne kuenstliche Geschwindigkeitsbegrenzungen, sodass man in diesem BASIC-artigen System auch was schnelles coden kann.
Sowas würde mir sehr gut gefallen. Eine Softwarelösung hätte einfach den unschlagbaren Vorteil, dass sie für wirklich jeden, der daran interessiert ist, sofort und ohne Zusatzkosten als Download verfügbar wäre. Man bräuchte keine extra Hardware kaufen.
Und es gibt dann noch die Leute, denen es genau um diese "extra Hardware" ginge. Nur sehe ich das als eine andere Zielgruppe an.
Wenn man allerdings unbedingt diese Zielgruppen für ein Produkt zusammenbekommen will, dann wird es unnötig schwer.
-
Naja wenn das Produkt erfolgreich genug waere, dann wuerden es die einen halt in Software nutzen und die anderen in Hardware, ich denke sowas koennte schon funktionieren. Aber man sollte es halt von Anfang an als Hardware-System bewerben, welches es aber auch in "Lite" gibt nur als Software
-
Wenn man allerdings unbedingt diese Zielgruppen für ein Produkt zusammenbekommen will, dann wird es unnötig schwer.
Das sehe ich nicht unbedingt so. Auch die Hardware-Fraktion (zumindest die, die was tun wollen) hat eigentlich immer gesagt, dass eine Emulation unerlässlich ist. Und weil es einfacher ist, einen Emu zu schreiben, als die Hardware zu bauen, wäre der Emu auch bei den Hardware-Vertretern zuerst da. Aber eben nicht alleine und nicht als Haupt-Attraktion. Daher bricht man sich keinen Zacken aus der Krone, wenn man zuerst die potentielle (realistische*) Hardware definiert, die dann emuliert wird. Damit ist beiden "Lagern" geholfen.
Und rein virtuelle Umgebungen (mit guten IDEs) ohne Aussicht auf Hardware haben wir auch schon mit PICO-8 und Co. Da braucht es keine weitere Lösung.
*) M. J. hat dafür einen (natürlich noch nicht in Stein gemeißelten) Vorschlag gemacht.
-
Mal so zum Thema booten. Ich meine selbst ein C64 bootet doch und ist nicht sofort bereit. Gut das geht sehr schnell, aber auch hier müssen ja ein paar Dinge im OS erst vorbereitet werden bis das READY erscheint. Daher die Frage: Welche Bootzeit würde man denn für den Retrocomputer akzeptieren, 1 Sekunde, 3 Sekunden, 10 Sekunden? Könnte man ein RaspPi dazu bringen in dieser akzeptierten Bootzeit was auf den Bildschirm zu zaubern?
Dann stellt sich mir die Frage welche Lernprogrammiersprache nimmt man? BASIC ist ja nicht gerade toll, aber so etwas wie Pascal könnte ich mir schon gut vorstellen
Wie sieht es mit der IDE auf dem Gerät selbst aus, was muss die können? Reichen diese rudimentären Monitorfunktionen aus, um wirklich zu lernen, oder wäre es nicht toller wenn man wie beim C64 Debugger wirklich visuell sieht was da gerade abgeht? Aber wenn man so einen hochwertigen Debugger hat, reicht dann die Rechenzeit dieses Retrocomputers überhaupt aus um das alles zu stemmen? Gut, kann man ja dann am PC entwickeln, aber wozu dann der Lerncomputer zum Programmieren, wenn es doch am PC mit IDE + Emu viel komfortabler geht und man leichter lernt?
Wäre ein RaspPI nicht dann der bessere Lerncomputer, da hier die Emu + eine tolle IDE parallel laufen könnte? Der Emu sorgt für die starke Retro Limitierung und der Rest kümmert sich um eine schöne IDE mit visuellem + Text-Debugging.
Oder ist gerade dieses Retroprogramming interessant, also man hat nur Text, wenig Komfort und ist auch hier auf die Limits des Retrorechners begrenzt, also wenig Tabs offen usw. All das was größere Projekte zur persönlichen Hölle machen würde.
Das alles bringt mich zur Frage: Für welche Projekte soll der RetroLernComputer konzipiert sein? Vielleicht nur Grundlagen der Programmierung, die man in ein paar Wochen komplett durch hat, oder doch mehr wie Spieleprogrammierung?
Hat sich wer schon Gedanken gemacht wann die ganze Diskussion beendet sein wird und das Konzept mit konkreten Spezifikationen eingefroren werden, damit dann mal los gelegt werden kann? Und wenn losgelegt wird, wer arbeitet daran und an was und mit welcher Toolchain etc.? Wieviele Jahre soll daran entwickelt werden, denn wenn man nur ein paar Stunden und mit wenig Mann daran werkelt, wird das sicher kein Projekt von ein paar Monaten?
-
Ich finde a) von der Auflösungen nicht schlecht. Und wenn nur Bitmap dann muss die CPU oder ein ZusatzBlitter schnell genug sein um das per Frame komplett umkopieren zu können und zwar so, dass noch genug Rechenzeit für Spiellogik und andere Sachen übrig bleibt.
-
Hat sich wer schon Gedanken gemacht wann die ganze Diskussion beendet sein wird und das Konzept mit konkreten Spezifikationen eingefroren werden, damit dann mal los gelegt werden kann?
Sobald jemand loslegt.
Und wenn losgelegt wird, wer arbeitet daran
Immer der, der fragt.
Oder anders: Bist du Teil des Teams und wirst du mitarbeiten?Und wenn nur Bitmap dann muss die CPU oder ein ZusatzBlitter schnell genug sein um das per Frame komplett umkopieren zu können und zwar so, dass noch genug Rechenzeit für Spiellogik und andere Sachen übrig bleibt.
Klar. Oder anders: Ja, es wird Scrolling geben.
-
Immer der, der fragt.
Oder anders: Bist du Teil des Teams und wirst du mitarbeiten?Interesse ist schon da, Zeit im Moment sehr wenig. Zu dem habe ich noch nie eine Programmiersprache für einen Rechner portiert oder eine IDE entwickelt. Frage ist also eher für was ich in dem Projekt geeignet wäre.
-
Das Konzept des internen Stacks hatte ich auch mal auf dem FPGA umgesetzt. Doch leider gilt auch hier, daß die Werte nur nacheinander geschrieben werden können. Selbst wenn man den Stapelzeiger entkoppelt vom normalen Registersatz (A, X, Y ...), muß man wegen des Registerbus die zu speichernden Register einzeln nacheinander anwählen. Da man außerdem den Stack selbst als Blockram umsetzen wird, kann auch dieser nur einen Speicherzugriff pro Zyklus durchführen. Mit etwas Aufwand könnte man es vielleicht hinkriegen, daß ein Speicherzugriff pro Phase (und nicht pro Taktzyklus) durchgeführt wird, also doppelt so schnell, doch ergibt dies auch nicht die Anforderung, alle 3 Werte in einem Rutsch zu sichern.
Das verstehe ich nicht so ganz, habe allerdings auch von Hardware nicht soviel Ahnung. Das einzige, was ich jemals programmiert habe, ist ein Atmel - aber der hat doch auch ein paar KB internen Speicher. Wo genau ist das Problem die als Registerstack zu verwenden? Die Register beim 65xx gelangen doch nie nach "außen", oder? Deswegen verwirrt mich das Wort "Registerbus" etwas. Wenn du nochmal genau erklären kannst, warum es trotzdem nicht funktioniert A, X und Y in einem Taktzyklus zu sichern, würde ich mich freuen.
Nur hier liegt - wie gesagt - die Gefahr, daß man als Programmierer dann komplett auf den Originalbefehlssatz des 6502 verzichtet und nur noch die erweiterten Befehle verwendet. Wenn es allein darum geht, einen neuen Retrorechner zu haben, der auch C64-kompatibel ist, wäre dies kein Problem. Wenn man das Gerät aber verstehen will als Nachfolger des C64, könnte zu viel Flair vom Brotkasten verloren gehen, als daß es sich dann noch um einen würdigen Nachfolger handelt.
Du hast schon recht - man hätte zwei Computer in einem und würde entweder den einen oder den anderen Nutzen. Erinnert dann ein bisschen an den C128 oder die SuperCPU. Da haben für viele aber auch schon eine handvoll Spiele ausgereicht um den C64 "aufzurüsten".
Wenn auch der "echte" C64 von einer neuen CPU profitieren soll, wäre dann nicht folgendes denkbar: die CPU ist eine 100% kompatible 6510, besitzt 64KB internen Speicher und schreibt nur noch Werte "nach draußen", die für VIC, CIA und SID notwendig sind, d.h. die CPU läuft völlig entkoppelt vom System und passt sich nur kurz dem Takt an, wenn z.B. ein VICII-Register geschrieben oder gelesen wird. Das würde viele Anwendungen und Spiele dramatisch beschleunigen. Wäre so etwas technisch möglich? So eine neue Vampire-Karte für den Amiga funktioniert doch vermutlich ganz ähnlich oder? Die ersetzt ja auch einfach die CPU und kommt mit eigenem Speicher.
-
Würdest du, um dieser "Gefahr" zu begegnen, deshalb auch dem Sprites-Charset-Prinzip weiter den Vorzug geben?
Das ist eine sehr gute Frage.
Was eine Weiterentwicklung des C64 anbelangt, so würde ich weiter bei dem Sprites-Charset-Prinzip bleiben. Wie man immer wieder an Äußerungen hier im Forum erkennt, sind diese beiden Elemente (neben dem SID) für viele das Markenzeichen des C64. Ein Fortführung des C64 müßte daher zwangsweise ebenfalls auf diesen beiden Features beruhen. Nun war mein erster Rechner damals[tm] der AppleIIe an der Schule. Und auch die Leute, die früher z. B. einen CPC gehabt haben, wissen, daß Sprites und Zeichensatz nicht unbedingt notwendig sind, um gute Spiele zu schreiben. Sie greifen einem leistungsschwachen System ein wenig unter die Arme, sind aber keine echte Notwendigkeit. Vielmehr erschweren sie oft die Programmierung, behindern den Blick auf andere Gestaltung (alle Figuren müssen in das Spriteschema passen...) oder blockieren gar eine leichte Rechner-Umsetzung im FPGA oder Emulator. Daher hauen mich bei neuen Retrosystemen solche Ankündigungen wie "DIeser Rechner hat X Sprites mit vielen bunten Farben" nicht gerade vom Hocker.
Was eine "reale" Umsetzung eines Retrosystems anbelangt, habe ich bei meinem Design absichtlich nicht auf Sprites oder Charset gesetzt, sondern verwende immer noch reine Bitmap. (Lediglich anfangs, als der FPGA noch kein externes SRam hatte, sondern nur 12 kb internes Blockram, mußte ich aus Platzmangel auf Zeichensatz zurückgreifen.) Wie ich an anderer Stelle schon schrieb: Bevor man nach spezieller Hardware ruft wie Sprites oder Blitter, sollte man erst einmal versuchen, überhaupt ein Programm zu erstellen, und schauen, wie weit man ohne kommt. Nur wenn sich herausstellen sollte, daß die Extrahardware absolut notwendig ist, macht ein Einbau wirklich Sinn, doch diese Notwendigkeit kann ich mir bei einer 8 Mhz 32-Bit-CPU aller Erfahrung nach nicht vorstellen.
Würde nicht ein Allround FPGA Computer besser sein?
Tatsächlich finde ich es erstaunlich, daß solch ein Angebot noch nicht existiert: Ein einigermaßen leistungsstarker FPGA in einem Gehäuse mit Tastatur und diversen Anschlüssen, weniger als Retrocomputer, sondern generell zum Experimentieren. FPGAS werden immer nur als einzelnes Board angeboten, doch findet man selten bis kaum dabei die Anschlüsse, die man wirklich braucht. Wenn man Glück hat, ist ein Videoausgang mit dabei. Bei Audio sieht es hingegen sehr schlecht aus. Daß FPGA-Programmierung und -Anwendung auch ein Bereich wäre für einen (kleinen, aber immerher) Consumer-Markt, hat man noch nicht richtig wahrgenommen.
Welche Bootzeit würde man denn für den Retrocomputer akzeptiere
Da müßte man unterscheiden zwischen der Bootzeit nach dem echten Einschalten, was für meinen Geschmack durchaus ein paar Sekunden dauern kann, und einem späteren Kalt- oder Warmstart, der dann - sofern es sich um eine Emulation handelt - schneller durchgeführt wird als das einmalige Booten des Emulationssystems zu Beginn.
wie beim C64 Debugger wirklich visuell
Damit wäre ein Retrosystem sicherlich überfordert. Solche Dinge sollte man besser einer Emulation auf dem PC überlassen. Auch wäre ein visueller Debugger für mich auch keine notwendige Voraussetzung fürs Programmieren an sich, so daß m. M. n. die Entwicklung eher der Community überlassen werden könnte.
Dann stellt sich mir die Frage welche Lernprogrammiersprache nimmt man? BASIC ist ja nicht gerade toll, aber so etwas wie Pascal könnte ich mir schon gut vorstellen
Daher hatte ich schon mehrfach eine Oberon ähnliche Sprache vorgeschlagen. Oberon ist so etwas wie ein entschlacktes Pascal, d. h. reduziert auf die wirklich benötigten Sprachelemente (= wenig zu lernen) bei verbesserter, klarer Syntax. Letztere ist sogar in etwa vergleichbar mit den Strukturelementen, wie man sie von den weiterentwickelten Basic-Versionen des Commodore Basic kennt. Ein Umstieg ist daher relativ leicht. Hier zur Probe ein kurzer Vergleich:
Alles anzeigenCodeDer einzige große Unterschied zu einem aufgebohrten Basic wäre, daß man Variablen vor ihrer Verwendung deklarieren muß, was jedoch gut dabei hilft, bei einem Programm die Übersicht zu behalten.
Ein wesentlicher Vorteil ergibt sich darin, daß man auf dem Zielrechner einen Oberoncode interpretieren kann wie einen Basiccode, aber mit Prozeduren usw. Diese Interpretation wäre natürlich recht langsam (jedoch nicht langsamer als Basic). Wenn das Programm aber steht, kann man es ähnlich wie bei Basic und z. B. dem Austro-Compiler später kompilieren. Das Kompilieren kann dann auch auf dem PC stattfinden, da nur dieser den nötigen Speicherraum zur Verfügung stellt, um alle möglichen Optimierungen auf dem Zwischencode auszuüben.
Kurz: Eine Oberon ähnliche Programmiersprache bietet einen sehr leichten Einstieg in die Programmierung wie Basic, eignet sich aber auch für größere Projekte (Tools, Spiele...), kann interpretiert oder kompiliert und nach Belieben um X Bibliotheken mit Y Befehlen (z. B. für Grafik und GUI) erweitert werden.
Hat sich wer schon Gedanken gemacht wann die ganze Diskussion beendet sein wird und das Konzept mit konkreten Spezifikationen eingefroren werden, damit dann mal los gelegt werden kann?
Öhm... Ja...
Könnten sich alle (die sowas überhaupt haben wollen, also ohne die Berufs-Nörgler) grundsätzlich mit einer der 3 Vorschläge anfreunden? Falls ja, welche fändet ihr am Besten?
Hmm... Nun möchte ich ungerne als Nörgler dastehen, aber ich halte alle drei Varianten für schwierig. Die normale VGA-Auflösung, die von den meisten Monitoren akzeptiert wird, beträgt 640 Pixel horizontal. Die dafür notwendige Frequenz läßt sich auf einem FPGA aus einer Basisfrequnz von 50 Mhz recht sauber ableiten. Alle anderen Auflösungen sind technisch schwieriger zu meistern. Bei einer Reduzierung auf 180 Zeilen hat man auf alten VGA-Bildschirmen zudem einen noch dickeren schwarzen Rand oben und unten. Desweiteren läßt sich 180 nicht wirklich gut durch eine Zahl wie 8 teilen (z. B. für eine Textanzeige mittels einem klassischen 8x8-Font). Gestaltet man die Buchstaben größer (10 statt 8 Zeilen pro Buchstabe), kommt man auf nur 18 Zeilen, also satten 7 Textzeilen weniger als bei 200 Zeilen. DIe genannten Auflösungen mögen daher vielleicht für ein rundes Ergebnis sorgen beim Kreismalen, aber praktisch sind sie schwer zu handhaben, sowohl technisch bei der Erzeugung als auch der softwareseitigen Anwendung. Daher würde ich eher für ein Verhältnis von 16:10 plädieren (bzw. 16:5) also den klassischen 160x200, 320x200 und 640x200.
-
Daher hatte ich schon mehrfach eine Oberon ähnliche Sprache vorgeschlagen. Oberon ist so etwas wie ein entschlacktes Pascal, d. h. reduziert auf die wirklich benötigten Sprachelemente (= wenig zu lernen) bei verbesserter, klarer Syntax.
Sieht nicht schlecht aus und viiiiel besser als dieses misslungene Basic, was marketingtechnisch als Beginner Sprache verkauft wurde und viele das heute noch für bare Münze nehmen, dabei lernt man mit Basic viel was man ganz schnell wieder vergessen sollte wenn man auf andere Programmiersprachen umsteigen möchte. Wie schon erwähnt hat GOTO und GOSOUB nichts in einer Beginner Programmierspache verloren. Das sind für mich eher direkte Abbildungen von Assemblerbefehlen wie jmp und jsr und haben in einer Hochsprache nichts verloren, da sie zu schnell zu Spaghetticode führen und den Lernenden in eine völlig falsche Denkweise lenken.
Tut mir leid wenn ich immer wieder auf BASIC rum hacke, aber diese Sprache ist fürchterlich und untauglich um das Programmieren zu lernen.
