Hello, Guest the thread was called52k times and contains 416 replays

last post from GoDot at the

GoDot Infos

  • Na ja, ["080" anstelle von "80"] hat mir allerhand Gerödel erspart

    Bei nur drei verschiedenen Headern kann man diese als feste Zeichenkette ablegen. So hast Du es im Prinzip ja auch gemacht. Mit einer Ausgaberoutine, die mit 3 verschiedenen Pointern aufgerufen wird, oder einer PRIMM Routine *) wäre der Teil auch gut einzukürzen.


    Sobald natürlich beliebige Dezimalzahlen nach links ausgerichtet ausgegeben werden sollen, hat man besser eine allgemeine Routine mit im Boot: in MINIPAINT werden die aktuellen Cursor-Koordinaten mit einer 8-Bit-Ausgabe erstellt, und für das Directory brauchte ich eine vergleichbare Routine für 16-Bit-Zahlen. Insofern kann ich gut abschätzen, welcher Programmieraufwand dahinter steckt. Vor allem, wenn es im Fall von MP nicht halbe Ewigkeiten bis zum Output brauchen soll (da hab' ich dann mit Tabellen gearbeitet).


    ...


    Noch eine Anmerkung zu deiner Anmerkung in der Beschreibung des MP-Loaders auf der Webseite:

    Quote from GoDot

    Bilder, die von anderen Rechnern zum VC20 nach MiniPaint portiert wurden, gewinnen jedoch durch die GoDot-Konvertierung, da die Pixel dann oft wieder im richtigen Aspekt angezeigt werden (die Fotografie-Bilder hier sind Beispiele dafür).

    Die meisten Bilder *werden* auf einem PAL-VC-20 bereits im richtigen Pixel-Aspekt angezeigt. Es ist nicht besonders schwierig, das bei der Auswahl eines geeigneten Bildausschnitts gleich mit zu berücksichtigen, sofern man das Bild auf dem PC vorbereitet: Mit dem Pixel-Aspekt-Verhältnis von 5:3 und der Auflösung von 160x192 ergibt sich ein Breite-zu-Höhe-Verhältnis des Gesamtbildes von 1,389:1 - was z.B. in IrfanView bei der Auswahl des Bildausschnitts in der Titelleiste mit angezeigt wird. Diesen Ausschnitt bringt man nun durch Rescale (unter absichtlicher Deaktivierung der Beibehaltung des Pixelaspekts) auf 160x192 (oder 80x192) und speichert ihn als *.pgm für die Import-Tools ab.


    Einen Tod stirbt man hier trotzdem: der NTSC-VIC-20 hat ein anderes Pixel-Aspekt-Verhältnis - 1,5:1 (oder 3:2 in kleinen ganzen Zahlen) - damit sehen Bilder beim V(I)C-20 auf der jeweils anderen TV-Norm immer verzerrt aus.


    Die Abweichung bei Konvertierung in GoDot von PAL VC zu PAL C64 relativiert sich aber dann doch noch aus einem anderen Grund: der PAL C64 hat nämlich auch keine quadratischen Pixel, sondern hier liegen wir bei 0,9365:1 - mit verdoppelten Pixeln sind das dann 1,873:1


    Und zu 1,667:1 ist das eine Verbreiterung um lediglich 12%. :)


    Gruß,


    Michael



    *) so wie die hier mit vorigem CHKOUT auf die Ausgabedatei. Hinter JSR steht direkt die 0-terminierte Zeichenkette, wonach dann die Ausführung des aufrufenden Programms direkt hinter der 0 fortgesetzt wird:

  • sd2iec: Kann mal einer ausprobieren, ob GoDot schon ganz ohne irgendwelche Klimmzüge darauf läuft? CMD-Geräte werden ja auch klaglos akzeptiert. Wahrscheinlich gibt's da gar keinen Handlungsbedarf!

    Woran macht GoDot denn fest, bei welchem Laufwerk ein ChangeDir zur Verfügung steht? Und hatten CMD-Geräte auch unterstützung für "mountbare" D64 Disk-Images so wie das SD2IEC? Ich würde gerne im "nativen" Modus arbeiten können.
    Was gehen könnte (bei Nachladern weiß man ja nie, was da getrieben wird) ist mit gemounteten Images wie mit einer 1541 zu arbeiten. Schön wäre aber, wenn ein SD2IEC erkannt würde und man unter GoDot z.B. Verzeichnisse wechseln und Disk-Image auswählen könnte.

  • Verzeichnisse wechseln und Disk-Image auswählen

    Mit diesen beiden Modulen ausprobieren: ChangeParts und ChangeDir.


    Ich hab mir die Easyflash-Texte angeschaut: Das EasyFS hat verdammte Ähnlichkeit mit meinem dev.REU! (Hier der Source-Code.) Ich könnte mir vorstellen, dass für GoDot ein dev.EasyFlash machbar wäre (um also Module und vor allem Bilddaten zwischenspeichern zu können). Aber GoDot als Easyflash-Cartridge: muss ich noch drüber nachdenken, ob das Sinn macht.


    Arndt

  • Mit diesen beiden Modulen ausprobieren: ChangeParts und ChangeDir.

    Ich dachte, die stehen nur zur Verfügung, wenn ein entsprechendes LW erkannt wurde?!
    Wenn mein Arbeitszimmer wieder begehbar ist, werde ich es testen. ;)


    muss ich noch drüber nachdenken, ob das Sinn macht.

    Sinn? GoDot und alle seine Module pfeilschnell "geladen", kein Diskettenwechsel mehr und 1MB Platz. Das nenne ich mal Sinnvoll! ;)
    Die eigentliche Frage ist, wie aufwendig die nötigen Anpassungen sind (Kosten/Nutzen halt) und ob du Bock drauf hast.

  • oder einer PRIMM Routine

    Ach ja! Die hatte ich nicht auf dem Schirm! Kommt bei Bild-Speichervorgängen auch eher selten vor... ;-) Header sind meiner Erfahrung nach fest in ihrer Länge. Aber danke! Ist notiert für spätere Wiederverwendung! :-)


    Arndt

  • Die eigentliche Frage ist, wie aufwendig die nötigen Anpassungen sind (Kosten/Nutzen halt) und ob du Bock drauf hast.

    Müsste man sehen. Ich tendiere dazu, dass der Aufwand eher gering ist. Man müsste die Hardware nur zur Verfügung haben. Das wird bei mir ein Problem, denn ich hab nur noch einen C64 (meinen allerersten!) und der hängt an der Wand, Ehrenplatz. Kein Monitor, kein Laufwerk, Netzteil... müsste ich suchen. Ich arbeite ausschließlich auf VICE, reicht für GoDot völlig.


    Arndt

  • Hättet ihr was dagegen, wenn ich hier von Mal zu Mal neue oder überarbeitete Module in GoDot sozusagen "verkünde"? Auf meiner News-Seite mache ich das zwar sowieso, aber vielleicht findet man von hier aus ja doch eher den Weg dorthin... Und weil ich in letzter Zeit ziemlich viel an neuen Dingen zusammengebastelt habe, ginge das auf diese Weise ja doch nicht ganz und gar unter. Würde mich freuen.


    Arndt


    (Ich hab nämlich gerade zwei Module fertig, in denen ich zum allerersten Mal mit Fließkomma-Arithmetik arbeite (die Routinen aus dem C64-BASIC, die sehen für mich Unbedarften eigentlich ganz aufgeräumt aus. War doch eine nette Erfahrung! :-) )

  • Hättet ihr was dagegen, wenn ich hier von Mal zu Mal neue oder überarbeitete Module in GoDot sozusagen "verkünde"?

    Zwar hab ich in dieser Hinsicht nichts zu entscheiden, würde die News hier im Forum aber begrüßen.



    Ich hab nämlich gerade zwei Module fertig, in denen ich zum allerersten Mal mit Fließkomma-Arithmetik arbeite (die Routinen aus dem C64-BASIC, die sehen für mich Unbedarften eigentlich ganz aufgeräumt aus.

    Da gab es irgendwelche Bugs. Leider kann ich mich nicht mehr erinnern, welche das waren. In einer 64'er gab's mal fehlerbereinigte Fließkommaroutinen. Auf die Schnelle konnte ich die Ausgabe aber nicht finden.

  • Danke, dann mach ich das so. Das heißt, dass dieser Thread sozusagen ein Dauerleben erhalten wird. Ich bin aber sehr an solchen Wünsche und Hinweisen wie die von Mike (zum VC20) interessiert, also ruhig auch hier antworten und Wünsche äußern, ich denke da genau wie Endurion mit seinem C64 Studio.


    [Fließkomma:]

    Da gab es irgendwelche Bugs.

    Ich schau mal nach. Mit "aufgeräumt" meinte ich, dass man sehr schnell reinfinden kann. Ist ja auch nicht immer der Fall, hehe... ;-)


    Arndt

  • Da gab es irgendwelche Bugs. Leider kann ich mich nicht mehr erinnern, welche das waren. In einer 64'er gab's mal fehlerbereinigte Fließkommaroutinen. Auf die Schnelle konnte ich die Ausgabe aber nicht finden.

    Na, das hätte ich aber auch bitte gerne genauer erhärtet.


    Die unvermeidlichen Rundungsfehler, die manchmal etwas offensichtlich zu Tage treten (wie etwa bei PRINT 7^2 - gibt 49.0000001 aus ... kein Wunder wenn man weiß wie der Potenz-Operator implementiert ist) zählen für mich nicht als Bugs. Und wer sich wundert, daß beim 100-maligen Aufaddieren von 0.1 nicht exakt 10 herauskommt, hat (noch) nicht verstanden, wie Fließkommaarithmetik arbeitet.


    Der einzige echte glatte Bug der mir bekannt ist, ist eben der in der Multiplikationsroutine, der immer dann auftritt, wenn die mittleren zwei Mantissenbytes eines der beiden Faktoren 0 sind. Dann kommt ein echt falsches Ergebnis raus - in einem Zwischenschritt der Berechnung wird die Mantisse dann statt um 8 Bits um 9 Bits verschoben und damit ist dann das Zwischenergebnis schon falsch und das Ergebnis damit auch. Das hab' ich Anfang 2014 mal herausgefunden und letztens in meinem VC-20 mit einem gepatchten BASIC-ROM behoben.

  • Na, das hätte ich aber auch bitte gerne genauer erhärtet.

    Wie geschrieben, kann ich dazu aus der Erinnerung nichts mehr sagen. Muss wohl doch noch mal in Ruhe verschiedene 64'er-Ausgaben durchgehen.


    Mir schwebt zwar immer ein Datei-/Programmname wie "ARITH13" vor, konnte dazu aber in den 64'er-Jahresübersichten nichts finden.



    Die unvermeidlichen Rundungsfehler

    Ich würde jetzt einfach mal bis zur Widerlegung davon ausgehen, dass es schon etwas Gravierenderes war, denn sonst hätte ich mir das vielleicht nicht gemerkt. Aber wer weiß, mein Gedächntnis kann mich natürlich trügen.


    Damals™ in den 90'ern™ habe ich für die Firma, in der mein Vater arbeitete, in alter Tradition geodätische Berechnungen auf dem C64 ausgeführt. In alter Tradition deshalb, weil die zu DDR-Zeiten einen Mitarbeiter hatten, der das bis dahin auch auf einem C64 erledigt hatte. Da ich dann irgendwann (neben einem C64, selbstverständlich) einige alte 64'er-Ausgaben in die Hände bekam, hatte ich daraufhin auch das entsprechende Programm zur Fehlerbereinigung der Fließkommaroutinen abgetippt. Leider weiß ich nicht mehr, wo ich das heute habe.

  • ARITH13

    Also, damit kann ich schon was anfangen. :)


    Dieses Programmpaket ist in der 64'er 3/87 drin. Es erweitert die Mantisse von 32 auf 48 Bits, damit können intern 14 Dezimalstellen gehalten werden und ein spezieller PRINT-Befehl gibt dann 13 signifikante Stellen aus.


    Ich hab's gerade mal kurz angetestet. Es bringt komplett eigene Arithmetikroutinen mit und implementiert auch die Winkelfunktionen mit höherer Genauigkeit. Steckt also in der Tat eine Menge guter Arbeit drin.


    Trotzdem ist auch ARITH13 nicht vor Rundungsfehlern gefeit. Es verliert genau wie andere Fließkommabibliotheken immer Genauigkeit, wenn sehr viele Zahlen mit Nachkommastellen aufaddiert werden oder wenn zwei nahezu gleich große Zahlen voneinander subtrahiert werden. Sowas "spült" die kleinen Rundungsfehler der Einzeloperationen unvermeidlich nach oben.


    Als Beispiel für letzteres: mit A=.2345678 und B=.23456789 liefert ARITH13 mit PRINT&(B-A) nicht 9E-8, sondern 9.000000211756E-8


    Pakete, die intern nicht binär sondern mit BCD arbeiten sind da grundsätzlich nicht besser dran. Die Aufakkumulierung von Rundungsfehlern und Auslöschung von Stellen passiert auch da, nur etwas subtiler. Man kann Rechenverfahren entwerfen, die weitgehend robust gegen diese Problematik sind. Damit beschäftigt sich aber gleich ein ganzes Teilgebiet der Informatik, die Numerische Mathematik. :)


    Da wird dann aber schon vorausgesetzt, daß die Grundrechenarten so implementiert sind, daß deren Berechnungsergebnisse nach Rundung innerhalb von +/- 1/2 des letzten Mantissenbits stimmen. Bei dem von mir oben erwähnten Bug der Multiplikationsroutine im originalen BASIC V2 ist das eben nicht mehr der Fall.

  • Die unvermeidlichen Rundungsfehler, die manchmal etwas offensichtlich zu Tage treten

    Die umgehe ich eh, da die ich Pixelwerte, mit denen ich bei GoDot umgehe, immer mit .5 aufaddiere und dann nach INT wandle. Natürlich fällt da bei manchen Operationen ab der n-ten Stelle (sicherlich unterschiedlich) was hinten runter. Das stört bei Squeeze und Stretch aber nicht weiter. Von daher bin ich ganz zufrieden der C64-Float-Implementation. Reicht völlig.


    Arndt


    Edit: Die Sources zu Stretch und Squeeze sind hier: Github.

  • Die umgehe ich eh, da die ich Pixelwerte, mit denen ich bei GoDot umgehe, immer mit .5 aufaddiere und dann nach INT wandle.

    Das ist ohnehin vernünftig. Bei den Werten, die Du in den Filtern aufsummierst, bzw. bei deren Anzahl wird es eher selten vorkommen, daß Du da dann ein anderes Ergebnis erhältst, als was mit infiniter Präzision herauskäme.


    Nur in ganz seltenen Fällen dürfte es mal vorkommen, daß deine Rundung "verkehrt" rundet, etwa wenn mit den C64-Float-Routinen 25.5000001 rauskommt, bei infiniter Präzision aber 25.4999999 - das ergäbe dann 26 (C64) zu 25 (Inf.). Davon geht die Welt aber nicht unter. :)


    ...


    Man kann auch z.B. die Quadratwurzel mit "Bordmitteln" problemlos um den Faktor 4 beschleunigen und dabei immer noch genauer machen. Stichwort Heron-Verfahren - hab' ich hier im Forum auch schon mal iwo angebracht.

  • Neu:


    Ich hab jetzt auf Github ein Makefile gepostet, mit dem man die ganze Fuhre (per ACME) in ein D81 hineinassemblieren kann. Das Makefile bietet mehrere Optionen dafür. Das README hab ich entsprechend aufgemöbelt. Danke an @Rapid Eraser, der mir die Makefilesyntax beigebracht hat (und gleich das meiste davon programmiert hat). Ich konnte nicht auf Linux testen, unter Windows 10 läuft's prima. Vielleicht bräuchte ich noch einen Hinweis darauf, wie ich den VICE-Autostart-Aufruf so hinkriege, dass MAKE nicht darauf wartet, bis VICE beendet wird.


    Das Repository enthält noch nicht alle GoDot-Module, nur die, die ich inzwischen nach ACME konvertiert habe.


    Wäre für Rückmeldungen dankbar!


    Arndt

  • Neu:


    Ich hab darüber nachgedacht, wie ich Bilder, die im Speicher rückwärts gepackt wurden (bekannt sind mir die von FLIGraph und von Flip) in GoDot wieder entpacken kann. Bisher fehlte mir die zündende Idee, schließlich belegt ein GoDot-Bild 32000 Bytes und das Konvertieren von FLI nach GoDot funktioniert nicht in einem Rutsch, sondern wird in mehreren Durchgängen erledigt, die den ganzen Bereich auch verwenden (Quellcode hier). Jetzt fiel mir ein, dass mit einer angeschlossenen REU das Problem doch erschlagen wäre: Ich lade das gepackte Bild in den 4Bit-Speicher, entpacke es da, schiebe das Ganze in die REU und hole dann zum Konvertieren die Bilddaten einfach dort ab.
    Täräh! Genauso geht's jetzt! :-)


    Die Lader für FLIGraph und FLip können ab sofort auch gepackte Dateien einlesen! (Download als ZIP von hier: godot.zip)


    Hehe... :-)


    Arndt