Hello, Guest the thread was called182k times and contains 4805 replays

last post from Snoopy at the

Der MEGA65-Laber-Stammtisch

    Ich denke, man muss hier zwischen mindestens zwei Sachen unterscheiden:


    1.) Die Fehlerbereinigung im ROM


    und


    2.) Das Hinzufügen von neuen Befehlen und Features in das ROM



    Punkt 1 ergibt letztendlich erst wirklich Sinn, wenn Punkt 2 abgeschlossen ist.


    Man hat ja erst gestern gesehen, dass ein Fehler im VERIFY-Befehl gemeldet worden ist und ich hier Stein und Bein geschworen hätte, dass VERIFY einwandfrei funktioniert. Das hat es auch, allerdings eben nur bis zur Version 920314. Danach wurde was im ROM verändert und der Befehl ging nicht mehr.


    Dass Bit Shifter das ROM kennt und damit umgehen kann, das steht völlig außer Frage. Er macht hier einen mehr als super Job und das nun schon seit Monaten. Man kann hier einfach immer nur den Hut ziehen! :thumbup:


    Allerdings sollte - wie ich schon öfter hier und auch bei Discord erwähnt habe - meiner Meinung nach irgendwann (möglichst bald) der Punkt kommen, wo man die Features vom ROM nun so lässt, wie sie eben im Moment sind. Da kommt schlicht und einfach nichts mehr Neues mit dazu. Punkt.


    Und dann kann man sich dransetzen und das ROM, so wie es dann ist, auf Herz und Nieren prüfen. Und da hat man sicherlich noch genug zu tun, die gemeldeten Fehler auszubügeln und zu korrigieren. Und so hat man dann nach einiger Zeit ein(!) stabiles und geprüftes ROM, mit dem die Community dann auch verlässlich arbeiten und programmieren kann. Ohne dass man immer schauen muss, ob es nun für das ROM 920310, 92350 oder 920987 ist.


    Ich halte es nach wie vor für wichtig, dass die Community ein "Basis-ROM" hat, das quasi als Standard für den MEGA65 gilt.


    Man kann ja trotzdem andere ROMs noch basteln, da wird ja niemand daran gehindert, hier seinen Wünschen und Ideen freien Lauf zu lassen. :)


    Nur sollte eben das Team meiner Ansicht nach daran denken, dass man mal einen "Schlußstrich" unter das "offizielle" ROM zieht. Ansonsten läuft man einfach die Gefahr, dass man die Situation hat, dass man zu jedem Programm angeben muss, auf welchem ROM es lauffähig ist (z.B. weil sonst verwendete Features fehlen). Und die Nutzer müssen dann schauen, welche ROM-Version sie dann jeweils für ein Programm verwenden sollen. Das halte ich für die Programmierer und auch Nutzer des MEGA65 eher nachteilig. Ich würde hier eine "Versioneritis" eher vermeiden. ;)

    Eigentlich.. sind in den letzten Versionen nur Bugfixes gewesen. Eigentlich weil, da noch eben zum VERIFY Befehl die Info zum ersten Unterschied im Speicherplatz kam, oder LEFT SHIFT und RIGHT SHIFT als Operator eingefügt wurde. Ja, ich hin auch dafür die Feature Updates zu Gunsten eines stabilen ROMs einzufrieren. Oft ist es so, das mit einer Fehlerkorrektur noch Schönheitsverbesserungen einhergehen. Solange der MEGA65 nicht bei jedem Anwender steht, wird es sicher noch Feature Änderungen geben. Auch darum ist es wichtig, das der MEGA65 mal von einer breiten Masse getestet werden kann.

    Soweit mir bekannt ist, soll am ROM laufend gearbeitet werden, was ich auch nicht gut finde. Das haben wir ja lang und breit schon diskutiert. Ich möchte auch wie beim C64 auf einen festen Featurestand zählen. Ich weiß nur nicht, ob schon alle notwendigen Features integriert worden sind. Zum Nibble Colour Text Mode gibt es z.B. noch so gut wie keine Infos. Kann schon sein, das hier nur ein halbes Grundgerüst steht. Kann halt keiner beurteilen, weil es keiner ausprobieren kann. 🙂

    Man muss halt ein stueckweit akzeptieren dass es sich hierbei um ein freiwilliges Projekt handelt und nicht um ein professionelles Produkt. Daher muss man es einfach ein bisschen "lockerer" sehen. Zudem ist das Updaten heute einfacher als zu C64-Zeiten.


    Dennoch waere es sicherlich nicht verkehrt, wenn man seitens des Projektes eine entsprechende Update-Strategie faehrt. Man koennte z.B. 1x im Jahr ein grosses Release machen, das man entsprechend gross ankuendigt, sodass alle "auf Stand" sind. Zwischendrin koennen ebenfalls Updates kommen, aber diese sollte man dann eher als "Bleeding Edge" oder "Experimental" (oder meinetwegen "Beta") bezeichnen - da kann dann jeder updaten, der Lust hat, neues Zeug zu probieren; derjenige weiss dann aber auch, dass er sich nicht drauf verlassen kann, dass alles 100% geht und dass alle anderen User das auch haben. Und wer darauf keine Lust hat, der laesst es einfach bleiben. Wer ein Spiel entwickelt, der koennte mit den Jahres-Releases testen und sagen "mein Spiel laeuft mit dem 2023er ROM" (eine reine Jahreszahl waere auch tatsaechlich eine sehr leicht zu merkende Versionsnummer - die man zudem zeitlich einordnen kann). Auch sollte natuerlich auf Abwaertskompatibilitaet geachtet werden, sodass alles, was auf einem alten ROM mal lief, IMMER auch auf neueren (stable)-ROMs laeuft.

    Quote from Snoopy

    Allerdings sollte - wie ich schon öfter hier und auch bei Discord erwähnt habe - meiner Meinung nach irgendwann (möglichst bald) der Punkt kommen, wo man die Features vom ROM nun so lässt, wie sie eben im Moment sind. Da kommt schlicht und einfach nichts mehr Neues mit dazu. Punkt.

    Wie bei anderen Projekten auch. Ein Feature-Freeze. Dann werden allfaellige Bugs gesucht und behoben und dann gibt's einen Major-Release oder so. Allenfalls mit Release-Party. :)


    Und danach kann man dann fuer die naechste Version, neue Features einbauen etc.


    So wuerd ichs machen, wenn ich programmieren koennte undoder Ahnung haette. (Habbich aber nicht wirklich.)

    Quote from ZeHa

    Auch sollte natuerlich auf Abwaertskompatibilitaet geachtet werden, sodass alles, was auf einem alten ROM mal lief, IMMER auch auf neueren (stable)-ROMs laeuft.

    Das wird schwierig und lässt sich noch am besten für reine BASIC-Programme umsetzen. Das bekommt man denke ich noch gut hin. Geht aber im Moment auch nicht bei allen ROMs, da sind teilweise noch Änderungen gemacht worden, die ein altes Programm nicht auf einem neueren ROM zu 100% laufen lassen. Aber das ist ja quasi noch "in Entwicklung". Es wäre nur mal ein Feature-Freeze sinnvoll.


    Sobald ein Programm direkt auf ROM-Routinen zugreift (z.B. ein Compiler o.ä.), dann ist eine "100% Abwärtskompatibilität" nicht möglich. Das geht nur, wenn das ROM wie z.B. beim C64 fix bleibt. Ansonsten ist mehr oder weniger Anpassungsarbeit notwendig, falls das der Autor des Programms möchte.

    Naja es reicht ja wenn die Einsprungadressen fix bleiben. Theoretisch koennte man dazu sogar eine Tabelle im ROM ablegen, mit den Funktionsnamen (sowas wie GETKEY) und der zugehoerigen Adresse. Dann kann ein Programm sich die holen und die dann dynamisch aufrufen.

    Quote from umueller-wsw

    Offen ist noch das Thema, dass beim Schreiben in REL-Dateien ab ROM 920315 beim Auslesen des Fehlerkanales Fehler 66 erscheint.

    mit <ROM 920314 bringt das Programm keinen Fehler

    mit ROM 920340 bringt das Testprgr. Fehler 66

    Der Fehler wurde dank deiner Hilfe im neuen ROM 920341 korrigiert! :)



    Es gab aus diesem Anlass auch noch einen Tipp mit auf dem Weg:


    Ich lasse es der Bequemlichkeit wegen einfach mal von DeepL übersetzen: :D

    Quote from ZeHa

    Naja es reicht ja wenn die Einsprungadressen fix bleiben. Theoretisch koennte man dazu sogar eine Tabelle im ROM ablegen, mit den Funktionsnamen (sowas wie GETKEY) und der zugehoerigen Adresse. Dann kann ein Programm sich die holen und die dann dynamisch aufrufen.

    Für ein paar Kernal-Routinen gibt es die im ROM. Aber z.B. nicht für "normale" BASIC-Befehle.


    Es gibt keine fehlerfreien Programme. Und gerade darin liegt der Reiz das System ständig zu verbessern und zu optimieren.

    Ich freue mich wenn neue Funktionen dazu kommen und auch die Geschwindigkeit permanent verbessert wird. Wenn ich mit dem Ausgangs ROM vergleiche liegen hier beispielsweise Welten dazwischen.


    Ich kann den Entwickern und besonders Bit Shifter nur meinen allerbesten Dank und Anerkennung entgegen bringen. Weiter so.


    Übrigens das Problem mit dem Fehlermeldung beim Schreiben in REL Datenbanken wurde mit ROM 920241 super gelöst. DANKE.

    Quote from ZeHa

    Naja es reicht ja wenn die Einsprungadressen fix bleiben. Theoretisch koennte man dazu sogar eine Tabelle im ROM ablegen, mit den Funktionsnamen (sowas wie GETKEY) und der zugehoerigen Adresse. Dann kann ein Programm sich die holen und die dann dynamisch aufrufen.

    Das funktioniert nur eingeschränkt, weil du (zumindest für einen Compiler) nicht zwingend an die Stelle springen kannst, an der der Befehl oder die Funktion an sich liegt. Manchmal springst du ein paar Bytes später rein, weil da vorher noch was gemacht wird, was du nicht gebrauchen kannst. Ich habe das beim CommanderX16-ROM z.B. so gelöst (per Programm, nicht von Hand....), dass ich meine Einspünge ins C64-ROM nehme, die im dokumentierten Quellcode suche, das nächste Label suche, ggf. einen Offset berechne, dann in der Symboltabelle, die beim Übersetzen des X16-ROMs entsteht (wenn sie nicht wieder mal vergessen wird, weil die niemanden außer mir interessiert), dort die passenden Labels suche (geht, weil die meistens den Namen behalten habe), dann basierend auf dem Offset "unscharf rate" wo ich dort hinspringen müsste und das Ergebnis als Einsprung ins X16-ROM nehme. Das klingt krude, hat bisher aber gut funktioniert. Nur gab es schon über ein Jahr lang kein Release mehr, also wie das da jetzt aussehen würde...keine Ahnung. Wenn jemand z.B. die Label umbenannt hat, dann bin ich raus und schmeiße den Support aus dem Compiler. Das tue ich mir dann nicht mehr an...