Posts by Freudentaumel

    Wäre es nicht evtl. eine gute Idee für die Badge-Sammelbestellung einen Extra-Thread aufzumachen, damit auch Leute, die nicht mitlabern, das mitbekommen?

    Oder ist das ein Spezialangebot nur für Labertaschen? ;)

    Ich frage mich wie sich die Erwartungen der Käufer des MEGA65 gebildet haben. Bei mir war das so. Als ich zum ersten Mal davon gehört habe es könnte einen Nachfolger des Cevi geben habe ich alle Informationen förmlich verschlungen die damals zu finden waren. Über die Jahre gab es immer mehr über ihn zu gelesen. Als dann immer mehr Details ans Tageslicht kamen reifte in mir der Entschluss, den will ich haben. Der Preis war dann geradeso machbar und ich hab mir ihn geleistet. Alle Infos die ich hatte sagten mir, dass ich etwas bekomme was wahrscheinlich niemals fertig wird.

    Also zumindest Rückwärtskompatibilität der ROMs wurde eine zeitlang explizit so kommuniziert, das war eine bestimmte ROM-Version, and da wurde gesagt, es kommen zwar Bugfixes und Features, aber alle alten Programme werden weiterhin tun, wenn nicht, is das ein Bug.

    Vielleicht war es ein Fehler, das so kommunizieren, aber man kann sich nicht jetzt darüber aufregen, dass sich manche Leute darüber beschweren, dass die neuen ROMs nicht rückwärtskokmpatibel sind.

    1. deft18/01/2022

      i dont see having old versions as a thing, we have come past the point were we do low level changes that affect any existing software and I am happy about that
    2. [21:45]we agreed to test new roms and bitstream against the community disk and to stay backwards compatible, so developers must not worry at all

    Leider ist das wohl so. Ohne regelmäßigen Internetkontakt zum Synchronisieren der Uhrzeit geht die Uhr im MEGA65 ja schon nach paar Wochen spürbar falsch. :|

    Das ist sicher so. Aber wie ZeHa schon schrieb: Der MEGA65 ist damit nicht allein. Auch beim Ultimate-64 sind solche Abweichungen zu sehen. Allerdings gibt es dort noch die Möglichkeit zum "fine tuning".

    Letztlich stellt sich wirklich die Frage: Wozu die RTC im MEGA65? Es werden ja keine Zeitstempel im Directory abgelegt. Warum sollte der Computer jemals eine korrekte Zeit benötigen?Wie macht das der Ultimate-64? Der RTC benötigt ja eine Batterie/Knopfzelle und hat meist einen Oszillator bereits eingebaut.

    Wie macht der Ultimate-64 das? Ein RTC muss ja laufend mit Batterie/Strom versorgt werden.

    Eine Änderung der Abweichung kann meines Wissens nicht im IC selbst geschehen ( mit Ausnahme von diesem Temeratur Sensor Flag). Da muss ja beim Einschalten ein Algorithmus die unterschiedliche Ausschaltdauer mit der gewünschten Abweichkorrektur verknüpfen, usw.

    Man kann da schon dran drehen. Eigentlich sollte das ab Fabrik passieren, aber daran wurde wohl angesichts der Teileknappheit etwas gespart. (?)

    (Siehe S. 13 im Datasheet: https://www.renesas.com/us/en/…t/dst/isl12020m-datasheet )

    Es wird aber naturgemaess komplexer, da man hier eben auch auf Speicherbereiche achtgeben muss, und da solche Zeichen auch weitaus mehr Speicher benoetigen. Anstatt 8 Byte mit Chardef zu setzen, muesstest Du hier bereits 64 Byte setzen. Ich wuenschte auch, man koennte ganz einfach mit BASIC alles machen, aber ich kann durchaus nachvollziehen dass nicht alles so einfach gehen kann, rein prinzipbedingt.

    Solange es keine Zeitkritischen Sachen sind, lässt sich das auch alles in BASIC bewerkstelligen. CHARDEF kann auch jetzt schon mehr als 8 Bytes als Parameter haben. Und ich sehe hier keine grundsätzlichen zeitlichen Probleme.


    Gerade wenn man solche Erweiterungen im MEGA65 eingebaut hat, würde ich alles Mögliche versuchen, diese auch der breiten Masse an Anwendern mit Hilfe von BASIC-Befehlen zur Verfügung zu stellen. Ist doch schade, wenn das Features bleiben, die 90% nicht mal kennen und von den restlichen 10% dann nur 5 Leute überhaupt wissen, wie man nutzt. ;)

    Aber das widerspricht diametral dem "Wir wollen schnell ein fixes ROM ohne ständige Änderungen", was Du ja auch vertreten hast. ;-)


    Meine Idealvorstellung wäre, dass das closed ROM einigermaßen zeitig fix ist, und dass man dann die weiterführenden Dinge in das Open ROM einbaut, da hat man ja mehr Freiheit dann. Da wäre dann auch ein vernünftiges Basic (BBC?) drin. Aber das is natürlich reine Theorie.

    Willst Du mich auf den Arm nehmen? Das weiß man bei Dir nie so genau. ;-)

    Es wurde doch bereits der exakte Wert als Mantisse und Exponent gepostet, und auch wenn ich das für das Mega 65 ROM nicht überprüft habe, nehme ich Bit Shifter beim Wort, dass er den Wert im Mega 65 ROM geändert hat.

    Eine wie auch immer geprintete Dezimalzahl kann prinzipbedingt immer nur eine Annäherung der Binärrepresentation sein, und kann nie zur Überprüfung der Gleichheit verwendet werden.

    Du warst doch in der Diskussion involviert, Du hast Bit Shifter bestätigt, dass in Amstrad Rom der gleiche Wert für Pi verwendet wird wie im Mega65 ROM, während das alte Commodore Rom ein falsches Pi verwendet hat.

    Es wird langsam kritisch! Jetzt bin ich wohl schon in dem Alter, in dem Andere denken, sie müssten mich daran erinnern, was ich mal getan habe. :alt::D

    Vielleicht sollte ich nicht von mir auf andere schließen. :P

    Der Amstrad CPC verwendet genau den selben Wert für PI wie der C64 und C65: 3,14159265. Der MEGA65 weicht nach den Änderungen hiervon bei der Ausgabe ab: 3,1415927. Ist ja auch nicht schlimm, es stimmt jetzt der Wert bei SIN(PI), nämlich 0. :D

    Ist das nicht nur ein Resultat des Prints, wo beim Mega65 aus welchem Grund auch immer eine Nachkommastelle weniger ausgegeben wird?

    Snoopy17/01/2022

    .FLO_CONST_PI ;=PI db #a2,#da,#0f,#49,#82

    Bit Shifter17/01/2022

    Thanks. The mantissa is little endian, apart from that the format is the same.
    So they use already the correct value for π, that I'll use for future ROM versions too.

    Ich habe gerade mal einfach aus Interesse, da ich an anderer Stelle beim Programmieren damit zu tun hatte, die Werte angeschaut, die COS und SIN bei den verschiedenen Commodore-Rechnern ausgeben.

    [...]

    C64 bis C65 geben jeweils die gleichen Werte aus, der MEGA65 hat veränderte Berechnungsroutinen und gibt deshalb leicht andere Werte aus.


    Keine Sorge, die Werte sind beim MEGA65 nicht "falsch", sie sind nur etwas anders genähert als bei den Commodore-Computern. Ist trotzdem immer noch ein Kreis auf dem Bildschirm, wenn man COS und SIN verwendet. ;)

    Es gab da eine Diskussion im Discord, bevor das geändert wurde. Die Werte, die vom Commodore-ROM ausgegeben wurden, sind an manchen Stellen so "falsch", dass in bestimmten Situation unerwartete Dinge passieren. Deswegen hat Bishifter das geändert.


    Du warst doch in der Diskussion involviert, Du hast Bit Shifter bestätigt, dass in Amstrad Rom der gleiche Wert für Pi verwendet wird wie im Mega65 ROM, während das alte Commodore Rom ein falsches Pi verwendet hat.

    In Maurice und Bit Shifters Testprogramm von damals war der Unterschied noch deutlicher, insbesondere ist cos(Pi/2) = 0 und tan(Pi/2) = INF, während es beim Commodore Rom eine kleine und eine große Zahl ist.

    Ich benutze eine Intenso 32GB vom Kaufland, die funktioniert einwandfrei.

    Da es doch relativ viele Kauflands in Deutschland gibt, erwähne ich das mal. Es gab dort auch SanDisk 16GB und 32GB, aber der Schwabe hat durgeschlagen und ich habe zwei Euro gespart.

    ... dass das Bug-Forum hier nicht beachtet wird.

    Und ich dachte, nur ich denke manchmal zu kompliziert. :D


    Die Beiträge im Forum werden auch von den meisten Teammitgliedern gelesen. Und ich kann mir beim besten Willen nicht vorstellen, dass ausgerechnet die Bug Reports dann komplett ignoriert werden. ;)

    So oder so braucht man eine zentrale Stelle, an der die Bugs gesammelt werden, anders funktioniert es nun mal nicht in der Softwareentwicklung.


    Von daher finde ich das Angebot von crsc sehr gut, dass er die Bugs übertragen kann, dann müssen es die Teammitglieder nicht selber machen.


    Also: Wenn man einen Github-Account hat, dann den Bug auf Github posten. Wenn nicht, dann im Forum (aber am besten vorher schauen, ob er schon in Github ist).

    Toll wäre es, wenn crsc dann noch einen Link auf den Github-report als Antwort im Forum setzt, dann kann der Original-Poster nachverfolgen, wie es mit dem Bug weitergeht.

    Bei meinem Spektrum Next ist das mir nicht aufgefallen. Aber den habe ich inzwischen verkauft, so dass ich das nicht nachstellen kann. Den Monitor möchte ich nicht tauschen, weil dieser mit 50 Hz Signale per HDMI keine Probleme macht wie zB. bei meinem Amiga mit D520 bzw. Indivision MK3 wie auch mit dem MEGA65. Der VGA-Ausgang ist mir beim MEGA65 zu unflexibel (Bildposition ist schlecht - zu weit auf eine Seite verschoben), so dass ich den Monitor-Ausgang nicht nehmen kann.

    Es steht auch im Spectrum Next FAQ:

    https://wiki.specnext.dev/FAQ


    Wie gesagt, es bleibt dir nur, das HDMI-Kabel abzuziehen, einen HDMI-Switch einzubauen, oder den Monitor mit einem Netzstecker abzustellen.

    Mir ist bei meinem MEGA65 folgendes aufgefallen, dass im ausgeschaltetem Zustand die Drive LED ca. alle 1,5 Sekunden vier mal schnell rot blinkt (Blinkdauer insgesamt ca. 0,7s). DaS ganze geht auch ohne Stromstecker! Abschalten läßt sich das Blicken nur, wenn der HDMI-Stecker gezogen wird. Anscheinend wird der MEGA65 über HDMI vom Monitor mit Strom versorgt. Verwendet habe ich ein 8“ LCD mit Treiberboard von Pollin (LS-8) aus dem Jahr 2016. Andere Monitore müsste ich jetzt noch testen.

    Hat jemand von euch so etwas ähnliches beobachtet und was bedeutet das viermalige rote Blinken der Drive LED beim MEGA65 ?

    Das ist ein bekanntes Problem (HDMI Ghost Power oder so ähnlich heißt das).
    Manche Monitore schicken tatsächlich Strom über das HDMI-Kabel raus.

    Im Moment hilft da nur abstecken. Einen HDMI-Switch dazwischenschalten löst das Problem wohl auch.

    Das größere Problem als die LED ist wohl, dass es passieren kann, dass das Ram nicht gelöscht wird, und dann beim Wiederanschalten komische Dinge passieren.


    Das Problem gab es wohl beim Spectrum Next in der ersten Version auch. Es hat wohl bei beiden Projekten niemand damit gerechnet, dass manche bestimmten Monitore sich so verhalten.

    Es fehlt die Klappe, die an jedem normalen Diskettenlaufwerk ist.

    Kleb dir ein paar blaue LEDs ins obere Gehäuseteil. Dann siehts nicht nur gut aus, sondern du hast

    ein Unikat. Aber bitte mit Vorsicht, nicht dass das Gehäuse verformt. :rolleyes:

    Eine LED hält aber keinen Staub aus dem Laufwerk fern. Da bräuchte ich dann einen Laser, der die Staubkörner einzeln pulverisiert.

    Wieso soll das nicht sinnvoll sein?

    Naja, ich finde den Schlitz nicht so ästhetisch wenn mein Bier darauf steht.

    Hab schon überlegt ob ich das zu gipsen soll. 8o

    Aber mal ganz im Ernst, der Schlitz stört mich tatsächlich. :-P

    Es fehlt die Klappe, die an jedem normalen Diskettenlaufwerk ist.

    Ich habe tatsächlich schon überlegt, ob es wohl möglich ist, ein Diskettenlaufwerk zu schlachten, und diese Klappe von innen an das Mega65-Gehäuse zu montieren.

    This is not a bug, it works as specified in the basic reference.


    The load address, which is stored in the first two bytes of the file is
    ignored. The loaded program does not replace a program in memory
    (which is what DLOAD does), but is appended to a program in memory.
    After loading, the program is re-linked and ready to run or edit.
    It is the user’s responsibility to ensure that there are no line number conflicts among the program in memory and the merged program. The first
    line number of the merged program must be greater than the last line
    number of the program in memory.

    Stimme dir völlig zu, mMn bräuchte es sowohl einen Issue Tracker als auch ein Wiki.

    Nochmal zum Thema fragmentierung und nicht mehr lesbaren D81 images ...


    Für Linux gibt es ein File basiertes DEFRAG : https://sourceforge.net/projects/defragfs/


    Das defragmentiert nicht das Filesystem sondern die Dateien in einem angegebenen Verzeichnis. hat bei mir wunderbar funktioniert :)

    Ein ähnliches Tool gibt es für Windows:

    https://docs.microsoft.com/en-…nternals/downloads/contig


    Ich habe es nicht ausprobiert, führe es nur der vollständigkeit halber auf. Vielleicht kann jemand anderes schreiben, ob er damit erfolg hat.