Posts by BlondMammuth

    Egal, wie man es betrachtet, man hat hier diese Diskrepanz zwischen dem, was man gerne hätte, und dem, was dann wirklich geht, und damit muss man irgendwie eine Balance finden. Man kann sich mit dem bescheiden, was die CPU und der Bus (und der Speicher) hergeben, oder man kann sich überlegen, ob man Zusatzhardware konzipiert, wie eine Graphikkarte, die dann viel mehr können könnte (!). Wobei da natürlich auch wieder gilt, dass in der Theorie Theorie und Praxis einander entsprechen, in der Praxis allerdings .. Da stößt man auch sehr schnell an Grenzen, weil man erstens das ja auch emulieren können will - und dann müsste man wohl auf moderne GPUs setzen, weil auch eine emulierte Graphikkarte sehr bald in die Knie gehen würde - und zweitens die Hardware, wenn man sie wirklich bauen will, sehr bald sehr komplex und sehr teuer würde.


    Wir sind gegenüber den 80er-Jahren schon in der privilegierten Lage, es bei genug Sturheit, Willen, und Ressourcen vorausgesetzt irgendwie erreichen zu können. Aber viel realistischer, und vor allem praktischer, wird es dadurch nicht, und auch in den 80ern gab es bereits High End Systeme (nicht im Homecomputer-Bereich), die zu sowas theoretisch in der Lage gewesen wären, halt viel teurer als heute.

    Ich lehne mich soweit aus dem Fenster, zu sagen: Wir erreichen die totale Nostalgie einfach schon dadurch, dass wir an dieselben Grenzen stoßen, dieselben Diskussionen führen, und denselben Frust erleben dürfen wie die Hersteller damals auch. :LOL

    Eine Laien-Frage dazu: Ein Sprite ist ein beweglicher winziger "Bildschirm", der über einen anderen gelegt wird, und dabei bitweise verschoben werden kann. Ein so beschriebener Layer ist ein riesiges (bildschirmgroßes) Sprite, das man in vielen Fällen nicht bewegen kann. Warum nicht die Konzepte verheiraten und grundsätzlich in verschiedenen Größen Bildschirmbereiche definieren, die man übereinander legen und bitweise positionieren kann?

    Ach, und bevor ich's vergesse: da es ein NeoRetro sein soll, muß die Tastatur natürlich Klickety-Klack machen & und schon erhelichen Widerstand leisten wenn man auf die Tasten 'reinhaut.

    Könnt sogar sein das die Krankenkassen Zuschüsse geben wegen aktives Vorbeugen von Muskelschwund in den Fingern ;-)

    Herrliche Idee! Aktivwiderstandstastaturen zur Gesundheitsförderung. :D Man könnte, um die Idee noch auszubauen, jede Taste mit einem länglichen Metallgerüst koppeln. Und dann könnte man sogar - he, es wird immer schöner - ein Farbband so montieren, dass man mit den Tasten und dem Metalldings direkt auf das Farbband haut, und einen Druckerschwärze-Abdruck auf Papier hinterlässt. Wenn man dann noch das Charset auf diesen Metalldingern codiert .. da hätte man dann etwas .. na wie könnte man es nennen .. "Direkt-Drucker", vielleicht, mit dem man dann gleich ein Log der Eingaben auf Papier erzeugt, so dass man später nicht mühsam durch Logfiles scrollen müsste? Man könnte einen ganz neuen Industriezweig mit den Dingern eröffnen! :done::lol23:

    Zum anderen ist eine längere Verfügbarkeit nicht gewährleistet und beim nächsten Modell muß wieder alles portiert werden.

    Ich will deiner Argumentation nicht prinzipiell entgegentreten, nur dieses Detail ist mir aufgefallen: Wenn es um den reinen Emulator geht, sehe ich eigentlich keinen Grund, warum man den neu portieren müsste. Erstens kann man ihn schon auf Hochsprachenebene ziemlich exakt gestalten, zweitens ändert sich die Grund-Architektur nicht, sondern es sind bloß neuere Generationen derselben CPU-Familie und mehr Speicher, jedenfalls aber weitgehend kompatibel, und drittens bleibt auch das OS kompatibel.

    Wenn man stattdessen dann auf einen Intel portiert, ja, dann muss man neu kompilieren. Aber wenn man den Emu auf Hochsprachenebene hinreichend gut implementiert, sollte das eigentlich auch keinen Unterschied mehr machen. Vielleicht irgendwo im Zeitverhalten, wenn man es nicht sauber löst, aber ich denke, das sollte eigentlich möglich sein.

    War wie gesagt nur eine Anmerkung. Deine Vorliebe für die FPGA-Lösung kann ich trotzdem verstehen, wobei mir das Konzept einer gemeinsamen Architektur, die völlig unabhängig auf verschiedene Weise implementiert weden kann, auch sehr gut gefällt. Dann wärs eher egal, weil beides existieren kann.

    Folgendes Blog-Posting ist auch lesenswert: https://lemonspawn.com/ok64/

    :D

    Do you know what the best part of creating our very own computer is? No nosy poignant ambitious pedantic opinionated brigands of cacophonic fellow nerds who constantly tell you what is possible or not, or the best way, or fastest, or what has been done before, or that this can’t be done, or this is stupid, or that you’re stupid, or change the processor, or it needs BASIC, or does it run “Far Cry”, more ram, less ram, bigger better smaller.

    Diese "nosy poignant ambitious pedantic opinionated brigands of cacophonic fellow nerds" sind wir alle selber. :thumbsup:

    Es gibt duzende Ein-Personen Bastelprojekte. Warum auch nicht.


    Aber die bleiben halt Unikate und es gibt wenig Software und keine Community.


    Genau das könnte der Knackpunkt sein: schafft man es im Team, etwas zu machen, was für eine größere Menge Anwender attraktiv wird.

    Will man also ein wenig requirement engineering (tut leid, scheints auf deutsch dort nicht zu geben) betreiben - was wir ja im Grunde hier alle seit Wochen tun - dann wäre das Ziel, ein Produkt für größere Zielgruppen attraktiv zu machen, ganz eindeutig ein solches Requirement.

    Zum Programmieren Lernen von heutigen Kindern und Jugendlichen sehe ich einen neuen oder alten Retro Computer nicht realistisch.


    Da gibt es mit der ganzen Welt rund um Raspi Pi einfach zuviele Alternativen, die auch mehr Spass machen, weil man z.B. mit LEDs und Roboter Schields einfach gleich "live" was sieht.

    Mit Python geht das ja auch sehr einfach, viel einfacher als der PEEK/POKE oder Assembler "Mist", den wir durchmachen mussten. So stellt sich schnell ein Erfolgsergebnis ein.

    Genau so habe ich auch über das Projekt hier von Anfang an gedacht. Noch nie war Programmieren lernen so einfach wie heute. Aber die Diskussion hatten wir schon irgendwo.

    hier

    Aber noch was anderes: in der damaligen goldenen Zeit der Computer-Anfänge (Apple2, c64 usw) war das docj auch kein Wunschkonzert der Software-Entwickler. Die konnten auch nicht so einfach entscheiden, ob sie nun lieber 16 oder 32 Sprites haben wollen. Die Hardware Entwickler haben entschieden, dass 8 Sprites in den VIC passen und de Software-Entwickler hatten damit gefälligst klar zu kommen! Dann war es deren Aufgabe mit der existierenden Hardware halt das Maximum aus dem Rechner zu holen.


    Also: wenn M. J. eine tolle VGA Grafik aus dem kleinen FPGA Boardlein holt, warum kann man sich nicht einfach freuen und schauen, was man aus dieser Hardware herausholen könnte? Die Programmierer damals haben doch auch die Auflösung benutzt, welche die Rechner damals boten und ihre Spiele entsprechend angepasst, dass es gut aussah?

    Klingt grundvernünftig, ja. Allerdings kam von Retrofan ein ganz dezitierter Wunsch, und das wohl auch nicht aus Jux und Tollerei. Wenn jemand Ahnung von FPGAs und Hardware hat, wie M.J., nehm ich den sehr ernst, wenn es um das Thema geht. Wenn jemand wie Retrofan Ahnung im graphischen Bereich hat (was ich von mir auch nicht behaupten könnte), möchte ich auch vorher erst einmal verstehen, wie es zu diesen Wünschen kommt, bevor ich mir da irgendein abschließendes Urteil bilde.

    So grade jetzt kenn ich mich nicht sonderlich gut aus, um ehrlich zu sein. Das Argument mit VGA hab ich zwar verstanden (weil das einfach eine existierende, leicht verwendbare Norm ist), aber warum ein anderes Format besser wäre, und warum es in VGA nicht gehen sollte, ist mir zur Zeit noch ein Fragezeichen.

    :ilikeit::thnks::dafuer:

    Na, man kann ja (versuchen) den FPGA Code möglichst modular und sauber abstrahiert vom FPGA Board zu entwickeln. Dann könnte ein User sich entscheiden, ob er lieber möglichst preiswert einsteigt, oder doch eher ein teures Board kauft, welche ihm dann mehr Möglichkeiten bietet (HDMI, mehr Speicher, höherer Takt usw).


    Es gibt durchaus schon Projekte, welche für mehrere Boards übersetzt werden können. Ist halt mehr Arbeit.

    Das hätte einen entscheidenden Effekt, der schon die Homecomputer-Hersteller der 80er geplagt hat:

    Wenn die eine kompatible Familie von Rechnern verkauft haben, haben die SW-Häuser fast immer nur für die untersten Versionen entwickelt, weil das die größten Märkte gewesen sind. Besonders Spiele. Das ist z.B. beim VC20 so gewesen. Kaum ein Spiel hat je eine Speicher-Erweiterung genutzt. Für den "neuen" Modus des C128 ist kaum ein Spiel entstanden, weil ja alle für den C64-Markt entwickelt haben. Und so weiter.

    Wenn man mehrere aufwärtskompatible Rechner in einer bestimmten Preissspanne rausbringt, werden die allermeisten Entwickler sich logischerweise auf das kleinste Modell konzentrieren.

    Ich habe aber langsam auch den Eindruck, dass der kleinste gemeinsame Nenner der ganzen Vorstellungen zu einem Retro-System so klein ist,

    dass es im Endeffekt niemand begeistern kann, und daher auch keiner was machen wird.

    Das wäre schon wieder ein Argument für maximale Erweiterbarkeit. Z.B. die Möglichkeit, eine Graphikkarten einzubauen (oder sonstiges, was man unbedingt drin haben will). Bloß hab ich absolut keine Ahnung, wie teuer das für HW und SW wäre. Und es wäre natürlich eine starke Motivationsbremse, müsste man graphische SW-Anteile dann extra noch einmal neu entwickeln. Das wäre wirklich blöd.


    [Grafik] Das wäre seeeehr unbefriedigend. Damit könnte ich NICHTS anfangen. (Schon ein Grafiker weniger, der sich für den Computer interessiert.)


    Kann es sein, dass ihr aneinander vorbeigeredet habt? Denn die letzten Auflösungen sind ja nur ein paar Beispiele, und nicht alle? Ich muss sagen, dass meine Schmerzgrenze die 80 Zeichen wären, die das System auf jeden Fall beherrschen sollte (alleine schon, um vernünftig Texte schreiben zu können). Was die Graphik betrifft .. wie hoch waren die Auflösungen in den 80ern? Retro wäre 1800x1200 nicht gerade.

    Was ist daran nicht ausreichend? Auflösung oder Farben?

    Und übrigens: Mir täts leid, wenn ihr beide da raus wärt.

    Natürlich kann man eine Sprache auch als Interpreter UND Compiler-Sprache gestalten, was Vorteile hat.

    [Sprache] Ich meine, M. J. hätte davon gesprochen, dass er es so machen würde. Fände ich natürlich besonders gut. Die Turn-Around-Zeiten beim Entwickeln wären gering – und am Ende könnte man doch recht schnellen Code bekommen.


    Aber wenn sie nicht als Standard-Sprache im ROM wären

    [Architektur] Ein wirkliches ROM gäbe es ohnehin nicht. Die Sprache und IDE würden von SD-Karte o.ä. geladen werden. Ich denke, das wäre in wenigen Sekunden passiert. So kann man die ganze Sache aber pflegen und verbessern.

    Eine Meta-Frage an dich (und kannst gern nachher wieder löschen): Du verwendest diese Tags wie [Sprache], [Architektur] .., und die sehen recht gut aus. Haben die den Zweck der Lesbarkeit oder sind sie auch für Suchfunktionen gedacht? Und bringts was, wenn wir die allgemein verwenden?

    Seid ihr eigentlich mehrheitlich für BASIC als Standard-Sprache?

    Ich bin da eher leidenschaftslos. Ich weiß aber, dass unser CPU-Entwickler eher etwas in Richtung Pascal favorisiert (nicht Pascal aber halt schon in der Richtung). Ich fände das von der Strategie nicht schlecht, weil es wahrscheinlich gut für einen sauberen Stil wäre. Ich persönlich könnte mich aber auch mit einer wilden Mischung anfreunden – Hauptsache, der Einstieg ist leicht und sie ist leistungsfähig genug, um auch anspruchsvollere Aufgaben (wobei das vorwiegend Games aller Art sein werden) zu bewältigen.

    Ja, er hat da sehr detaillierte und gut ausgearbeitete Vorstellungen. Die letzten Jahre habe ich mit ihm (kann man eh noch finden, z.B. zum Thema Virtuelle Maschinen) so einiges ausdiskutiert, und ihm zuguterletzt oft recht geben müssen, wo er mit ziemlich fundierten Argumenten ein paar meiner halbgaren Vorlieben fachkundig abmontiert hat. :versohl:


    Ich sehe auch da einen Unterschied zwischen Interpreter und Compiler. Natürlich kann man eine Sprache auch als Interpreter UND Compiler-Sprache gestalten, was Vorteile hat. Aber ich vermute einmal, dass die Standard- (also Einschalt- und Losleg)-Sprache eher ein Interpreter sein sollte. Grade die können so viel flexibler sein als reine Compiler-Sprachen.

    Ich würde sagen: Hier geht der Spaß (für mich zumindest) los: Wie sollte so eine Sprache letztlich aussehen? FORTH wäre z.B. ein Kandidat. LISP könnte man sich vorstellen. Sogar PROLOG (Ich würde aber keine von denen für Einsteiger empfehlen, im Vergleich zu BASIC extrem schwer zu lernen :krank:). Oder ganz neue Konzepte. Alte Sprachelemente, benutzerfreundlich kombiniert.

    Aber wenn sie nicht als Standard-Sprache im ROM wären - man sollte sie trotzdem (nachladbar) haben, denn irgendwer hätte sie immer gerne dabei, nach meiner Erfahrung. Aber da gilt natürlich: "Mach selber, wenn du es erledigt haben willst!"

    Eine andere Frage, die sich mir aufdrängt: Seid ihr eigentlich mehrheitlich für BASIC als Standard-Sprache? Ich bin kein BASIC-Fan (ausser zum Lernen und Verstehen der Grundlagen), und könnte mit einer ganz anderen (bequemeren, reichhaltigeren) Sprache auch leben. Aber ich habe das Gefühl, dass ich da eher einer Minderheit angehöre. Ist das so?

    Naja sobald Du auf Zeilennummern verzichtest, brauchst Du sowieso in irgendeiner Form einen Editor. Weil Du dann ja auch scrollen koennen musst usw. Und Du musst BASIC-Zeilen von Direktbefehlen unterscheiden koennen. Wenn man mit Zeilennummern arbeitet, kann man das so wie jetzt auch auf dem C64 machen, also mit LIST und RUN und eben Zeilennummern. Fehlen die, dann braucht man einen anderen Editor. Und dann braucht man auch eine Taste fuer RUN und sowas.

    Man braucht nicht drauf verzichten. Auch im Editor gibt es Zeilennummern. Es geht wirklich nur darum, die als Sprungziele zu eliminieren, stattdessen Labels zu verwenden.

    Damit will ich mich nicht für einen Zeileneditor einsetzen. Ich habe dazu keine ausgeprägte Meinung, und nicht wirklich viel drüber nachgedacht, ehrlich gesagt. Aber es wäre prinzipiell immer noch machbar, auch wenn daneben ein Editor existiert. Der würde dann halt bloß immer die Zeilennummer um 1 rauf setzen und nach Insert und Delete entsprechend anpassen.

    Was aus meiner Sicht für einen Text-Editor spricht: So einer ist auch für ASCII-Texte zu verwenden, und das ist beim C64 wirklich schon sehr abgegangen. Aus meiner Sicht ein Muss, egal obs daneben einen Zeileneditor noch gibt oder nicht.

    Der Grund, warum ich dennoch irgendwie Zeilennummern toll finde, ist einfach dieser "10 PRINT bla, 20 GOTO 10"-Faktor, der halt direkt verloren geht, wenn man die ganz abschafft.

    Vielleicht kann man ja eine Art Legacy-Einsteiger-Mode mit Zeilennummern voreinstellen und dem User die Möglichkeit geben (vielleicht nur einmalig in eine Richtung) in einen "Profi"-Mode zu wechseln, wo dann die Zeilennummern wegfallen und dem vorhandenen Code Sprung-Labels und noch ein paar Einrückungen hinzugefügt werden (mal so ganz flapsig gesagt). Dann lernt er auch gleich, wie man es "richtig" macht.

    Das müsste man nicht abschaffen. Man könnte ja stattdessen z.B. (Syntax ist eine Hausnummer, die ich grad erfinde, auf der bestehe ich nicht) schreiben


    Code
    1. @start PRINT bla,:GOTO @start

    Das mit dem Legacy Mode bräuchte man dann auch nicht unbedingt, sofern man Einsteiger dazu bringen kann, es eventuell auch so zu akzeptieren:

    Code
    1. @10 PRINT bla,:GOTO @10

    Ist aber wieder auch Geschmachssache. Wenn man einen Zeilen-Editor wie im C64 haben will, kann man theoretisch auch einführen:


    Code
    1. 10@ PRINT bla,
    2. 20 GOTO @10

    und so erlauben, dass z.B. ein Klammeraffe direkt nach der Zeilennummer die zum Label macht. Sollte aber dazusagen, dass man das im Allgemeinen eher vermeiden sollte, weil es mit Renummerierung zum Chaos führen kann, und als Alternative eher das empfehlen:

    Code
    1. 10 @start PRINT bla,
    2. 20 GOTO @start

    Zeilennummern wuerde ich vielleicht optional machen, oder so dass der Editor die automatisch vorgibt und anpasst bei Sprungbefehlen oder so... aber keine Ahnung ob das sinnvoll ist

    Wie wäre es, Zeilennnummern überhaupt nicht als Sprungpunkte zu verwenden, sondern die üblichen Strukturen (ca. wie in Pascal oder C) einzubauen, und für GOTO eigene (alphanumerisch) Labels zu verwenden? Dann wären die Zeilennummern überhaupt nur mehr ein Mittel zur Organisation des Quelltexts, und man könnte den dann alternativ auch mit jedem Text-Editor bearbeiten.

    Falls man natürlich eine gewisse Kompatibilität zu Commodor-Basic beibehalten will, könnte man das alternativ auch erlauben, oder entsprechende Transformationen implementieren. Ich bin da jetzt mit mir selbst nicht ganz einig, ob das erstrebenswert wäre.

    Wobei man auch da zunächst unterscheiden müsste, ob man auf dem Gerät selber eine Entwicklungsumgebung haben will.

    [IDE] Das ist schon entschieden, da es DIE zentrale Eigenschaft ist, über die der Computer "vermarktet" werden würde (sollte es ihn geben). Wie schon oft gesagt: Stell dir den PICO-8 vor – auf echter (aber deutlich schwächerer) Hardware.


    Darüber hinaus wäre ich sehr für "mehr ist besser", insofern, als da ja schon das Abenteuer beginnt: Wer das gerne tut, kann ja auch neue Programmiersprachen entwerfen, oder irgendwelche alten abwandeln und anpassen. Dass es "die Programmiersprache" nicht gibt, und sich sowas nie durchsetzen lässt, hat schon IBM in den 60er-Jahren lernen müssen. Ich mache mir über sowas sehr gerne Gedanken, und ich bin sicher, M.J. hätte da noch mehr beizutragen.

    [Sprache] Da bin ich voll bei dir. Also haut rein.

    Ja klar, die OnBoard-Programmiersprache muss es natürlich geben, und ich vermute, sie wäre dann so eine Art BASIC-Dialekt, vermutlich aber etwas benutzerfreundlicher konstruiert als das Commodore-Basic. Wobei - das ist jetzt einer meiner Träume, nur vermute ich, dass er sich nicht durchsetzen würde - ich eine eher funktionale Sprache an der Position bevorzugen würde, weil sie sowieso interpretiert werden muss und einfach viel mehr kann (Ausdrucksstärke macht den Code "schöner" und dichter).

    Mir gehts schon auch darum, andere Sprachen zur Verfügung zu haben, mit denen manches leichter geht, und da kann man ruhig auch auf Cross-Compiler setzen, die auf den großen, schnellen Systemen viel besser optimieren können. Die wären aus meiner Sicht für die OS-Entwicklung ein großartiges Asset, ausser natürlich, man bevorzugt die Entwicklung in reinem Assembler. Gut, das kann man auch so oder so argumentieren.