Hello, Guest the thread was viewed51k times and contains 642 replies

last post from Snoopy at the

MEGA65 - BASIC 65-Referenzhandbuch

    Quote from MC64

    Ich würde mir das mit dem Druck derzeit noch überlegen. Da Befehle wie z.B. EDMA nicht vollständig sind.

    Ich habe mal nachgeschaut, bei EDMA ist in der Tat eine Bemerkung mit hinzugekommen. Da muss ich mal ran. :loet


    Aber ansonsten hat sich nichts geändert. Hätte mich auch gewundert, da das ROM fix ist. Wo sollen da plötzlich neue Sachen herkommen? :)

    Quote from Snoopy
    Quote from MC64

    Ich würde mir das mit dem Druck derzeit noch überlegen. Da Befehle wie z.B. EDMA nicht vollständig sind.

    Ich habe mal nachgeschaut, bei EDMA ist in der Tat eine Bemerkung mit hinzugekommen. Da muss ich mal ran. :loet


    Aber ansonsten hat sich nichts geändert. Hätte mich auch gewundert, da das ROM fix ist. Wo sollen da plötzlich neue Sachen herkommen? :)

    Ich habe versucht Bit Shifter zum kontaktieren, leider ohne Erfolg. Es gab glaube ich noch ein oder zwei Bugs, die mal reportet wurden. Ich habe das Ganze aber auch nicht mehr in der Tiefe verfolgt.

    Quote from Targas

    Ich habe das Ganze aber auch nicht mehr in der Tiefe verfolgt.

    Ich lasse mir hin und wieder die Veränderungen im LaTeX-Quellcode des englischen Referenzhandbuchs anzeigen und seh zumindest, was sich dort von einer Version zur nächsten verändert hat. Die Ergänzung bei EDMA muss relativ neu sein. Und bei MID$ ist die Änderung, dass der Startindex erst ab 1 beginnen darf und nicht, wie bislang im Buch steht, ab 0. Sonst habe ich noch keine Änderung in den Befehlsbeschreibungen gefunden.


    Ich gehe das demnächst mal an, sobald ich bisschen mehr Luft dafür habe. :)

    Quote from Targas
    Quote from Snoopy
    Quote from MC64

    Ich würde mir das mit dem Druck derzeit noch überlegen. Da Befehle wie z.B. EDMA nicht vollständig sind.

    Ich habe mal nachgeschaut, bei EDMA ist in der Tat eine Bemerkung mit hinzugekommen. Da muss ich mal ran. :loet


    Aber ansonsten hat sich nichts geändert. Hätte mich auch gewundert, da das ROM fix ist. Wo sollen da plötzlich neue Sachen herkommen? :)

    Ich habe versucht Bit Shifter zum kontaktieren, leider ohne Erfolg. Es gab glaube ich noch ein oder zwei Bugs, die mal reportet wurden. Ich habe das Ganze aber auch nicht mehr in der Tiefe verfolgt.

    Die ROM Entwicklung wurde unter die Kontrolle eines Steering Committee gestellt. Da wurde entschieden, dass Bugfixes und Erweiterungen nur noch in den Development Branch (Versionsnummern 99xxxx) committet werden dürfen und eventuell nach einer Prüfung des Steering Committee in den Master Branch (92xxxx) übernommen werden.

    Ich habe nach dieser Änderung noch diverse Bugfixes (U1/U2 Befehle, Monitor BRK, STOP-RESTORE Verhalten, CHARDEF) und Erweiterungen (80x50 Text, D64 Images) programmiert und wie gewünscht in den Development Branch geschickt. Da jedoch keine dieser Bugfixes oder Erweiterungen in den ROM übernommen wurden, sehe ich keinen Sinn mehr darin, weiter an einer Fertigstellung des ROM zu arbeiten.

    Bit Shifter Das ist aus meiner Sicht sehr schade aber auch konsequent und ich habe Verständnis für deine Entscheidung.

    Im Nachhinein haette man einfach von offizieller Stelle sagen sollen, dass 920377 das finale ROM ist (mit Bugs und unveraenderbar) und dann wie gewohnt mit 920378 weitermachen sollen. Das waere vermutlich ein Kompromiss gewesen, mit dem alle haetten leben koennen. Die konservativen User haetten ihr stabiles ROM und alle anderen koennten sich motiviert an den Neuerungen erfreuen. Das haette auch viele Diskussionen und Frustmomente vermieden. Hinterher ist man immer schlauer. Evtl. kann man das an anderer Stelle nochmal intern und auch mit den Usern diskutieren.

    Quote from crsc

    Im Nachhinein haette man einfach von offizieller Stelle sagen sollen, dass 920377 das finale ROM ist (mit Bugs und unveraenderbar) und dann wie gewohnt mit 920378 weitermachen sollen. Das waere vermutlich ein Kompromiss gewesen, mit dem alle haetten leben koennen. Die konservativen User haetten ihr stabiles ROM und alle anderen koennten sich motiviert an den Neuerungen erfreuen. Das haette auch viele Diskussionen und Frustmomente vermieden. Hinterher ist man immer schlauer. Evtl. kann man das an anderer Stelle nochmal intern und auch mit den Usern diskutieren.

    Das waere aus meiner Sicht dennoch verkehrt, denn es ist sinnvoller zwei Schienen zu fahren, einmal eine Bugfix-Schiene fuer das "finale ROM" (denn Bugfixes sind sehr wohl erwuenscht), und einmal eine "Development"- oder "Experimental"-Schiene, in der neue Features eingebaut und getestet werden, die nix mit dem "finalen ROM" zu tun haben. So funktioniert das eigentlich bei den meisten Software-Projekten.

    Quote from ZeHa
    Quote from crsc

    Im Nachhinein haette man einfach von offizieller Stelle sagen sollen, dass 920377 das finale ROM ist (mit Bugs und unveraenderbar) und dann wie gewohnt mit 920378 weitermachen sollen. Das waere vermutlich ein Kompromiss gewesen, mit dem alle haetten leben koennen. Die konservativen User haetten ihr stabiles ROM und alle anderen koennten sich motiviert an den Neuerungen erfreuen. Das haette auch viele Diskussionen und Frustmomente vermieden. Hinterher ist man immer schlauer. Evtl. kann man das an anderer Stelle nochmal intern und auch mit den Usern diskutieren.

    Das waere aus meiner Sicht dennoch verkehrt, denn es ist sinnvoller zwei Schienen zu fahren, einmal eine Bugfix-Schiene fuer das "finale ROM" (denn Bugfixes sind sehr wohl erwuenscht), und einmal eine "Development"- oder "Experimental"-Schiene, in der neue Features eingebaut und getestet werden, die nix mit dem "finalen ROM" zu tun haben. So funktioniert das eigentlich bei den meisten Software-Projekten.

    Da stimme ich dir zu. Das war auch die Grundidee dahinter. Nur! Wenn man kein Entwicklerteam, sondern nur einen einzigen ROM-Entwickler mit begrenzter Zeit hat, dann sind diese zwei Schienen vermutlich zu viel Arbeit um zwei Branches gleichzeitig zu pflegen. Man haette dann evtl. bugifxes auch unter 920377-p1, 920377-p2 usw. anbieten koennen. Wenn dann noch alles durch ein Komitee abgesegnet werden muss und einfach keine Rueckmeldungen (vom Komitee und den Usern) kommen, kann ich auch verstehen, dass die Motivation den Bach runtegeht. Ein (Hobby-)Projekt soll letztendlich spass machen.

    Klar, es geht nur um die Versionierung. Ob da jetzt ein Komitee oder mehrere Entwickler beteiligt sind oder ob einer alles alleine macht, ist dafuer in erster Linie mal nicht entscheidend. Es geht einfach nur drum, dass die Entwicklungsschiene getrennt ist in "stable" und "development" und dass es eben fuer "stable" auch nach wie vor Bugfixes geben kann und darf. WIe die Versionsnummer dann lautet ist eine andere Frage, ob da jetzt ein "p1" hinten dranhaengt oder ob es dann doch 920378 wird und die Dev-/Experimental-Schiene einfach von Haus aus einen anderen Nummernbereich bekommt (z.B. 920400 oder direkt 921000 etc) ist auch nicht entscheidend.

    Quote from Bit Shifter

    Ich habe nach dieser Änderung noch diverse Bugfixes (U1/U2 Befehle, Monitor BRK, STOP-RESTORE Verhalten, CHARDEF) und Erweiterungen (80x50 Text, D64 Images) programmiert und wie gewünscht in den Development Branch geschickt. Da jedoch keine dieser Bugfixes oder Erweiterungen in den ROM übernommen wurden, sehe ich keinen Sinn mehr darin, weiter an einer Fertigstellung des ROM zu arbeiten.

    Wurde das mal begründet wieso deine Bugfixes nicht übernommen wurden ? Jedenfalls ist es schade das du nicht weiter machst, weil du in meinen Augen da eine ziemlich große Lücke hinterlässt.

    Aber verstehen kann ich es dennoch.

    Quote from Snoopy

    Ich habe mal nachgeschaut, bei EDMA ist in der Tat eine Bemerkung mit hinzugekommen. Da muss ich mal ran.

    Es ging mir nicht darum was dazu gekommen ist, sondern das, was fehlt. Der EDMA Befehl kann derzeit nur Copy und Fill.

    Swap kann er nicht. Man kann ihn eingeben, aber es passiert nichts. Des weiteren kann man noch anstatt "EDMA 0," auch "EDMA 4," eingeben. Die 4 macht das selbe

    wie 0, allerdings treten dann Timing Probleme auf. Ich habe für meinen Char Editor eine kleine Assembler Routine geschrieben die den VSYNC Befehl ersetzt.

    Diese klinkt sich in den Service IRQ ein und man kann das daran sehr deutlich sehen.


    Beim TRAP Befehl ist es so das man diesen unbedingt mit RESUME beenden muss. Das wird im Handbuch nicht erwähnt.

    Bei mir sind hier die lustigsten Dinge passiert. Unter anderem Abstürze oder Programmabbruch mit RUN/STOP funktioniert nicht mehr.


    Wie Bit Shifter schon schrieb funktionieren die U1 und U2 Befehle im Basic nicht richtig. Ich wollte eine Routine schreiben um das Directory in Variablen zu übertragen.

    Daran hab ich mir die Zähne aus gebissen und bin einen anderen Weg gegangen. Im Monitor hingegen konnte ich auf die Sektoren einwandfrei zugreifen.

    Quote from MC64

    ... funktionieren die U1 und U2 Befehle im Basic nicht richtig.

    Das hat mir keine Ruhe gelassen, da ich diese Befehle schon selbst korrekt in einem BASIC-Programm für den MEGA65 verwendet habe. Ich bin hoffentlich noch nicht so senil! :alt:


    Gerade mal durchgetestet! Die kleinen Beispielprogramme zum Schreiben und Lesen in Sekoren habe ich von dieser Seite entnommen:


    https://wpguru.co.uk/2016/01/h…ommands-in-commodore-dos/

    Code: Writing data to a sector
    1. 115 input "message to write";a$
    2. 120 input "track to write";t
    3. 130 input "sector to write";s
    4. 140 open 15,8,15
    5. 150 open 5,8,5,"#"
    6. 160 print#5,a$
    7. 170 print#15,"u2";5;0;t;s
    8. 180 close 15:close 5
    9. 190 end
    Code: Reading data from a sector
    1. 120 input "track to read";t
    2. 130 input "sector to read";s
    3. 140 open 15,8,15
    4. 150 open 5,8,5,"#"
    5. 160 print#15,"u1";5;0;t;s
    6. 170 for i=1 to 20
    7. 180 get#5,a$:if a$="" then a$=chr$(0)
    8. 190 print a$
    9. 200 next
    10. 210 close 5:close 15


    Mit dem originalen Commodore-C65 ROM 911001 klappt es:




    Den Sektor mit DirMaster angeschaut:




    Mit dem BASIC 65.EX, das auf dem ROM 920300 basiert, klappt es auch:




    Mit DirMaster kontrolliert:




    Nur mit dem aktuellen MEGA65-ROM 920377 klappt es nicht mehr:



    Da wirft das Leseprogramm das aus:



    Und DirMaster zeigt diesen Sektorinhalt:



    Der Fehler muss also definitiv nach dem ROM 920300 reingekommen sein.


    Das ist eher ein Beispiel dafür, was "kaputt" gehen kann, wenn man am ROM arbeitet. Und dass man dann nie genug testen und prüfen kann, ob dann noch alles so funktioniert wie vorher. :prof:

    Quote from MC64

    Der EDMA Befehl kann derzeit nur Copy und Fill.

    Swap kann er nicht. Man kann ihn eingeben, aber es passiert nichts.

    Gerade mal mit dem 920377 getestet:



    mega65_edma_b.png


    Nach einem Tastendruck dann:


    mega65_edma_c.png


    In dem Beispiel funktioniert das SWAP-Kommando (2).


    Vielleicht war das bei dir ein Fall, wo es nicht geklappt hat?