GoDot Infos

Zitat von GoDot

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:

Zitat von 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:

Zitat von GoDot

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.

Zitat von GoDot

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.

Zitat von GoDot

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.

Zitat von GoDot

Ich arbeite ausschließlich auf VICE, reicht für GoDot völlig.

Hat Vice nicht auch eine EasyFlash Emulation?

Zitat von Cyberdyne

Hat Vice nicht auch eine EasyFlash Emulation?

Türlich. Der einzige relevante Emulator ohne Easyflash ist CCS64 (warum auch immer, man mag's kaum glauben...).

Zitat von GoDot

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.

Zitat von GoDot

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.

Zitat von GoDot

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

Updates auch hier direkt zu verkünden macht durchaus Sinn.
Also, weitermachen

Zitat von GoDot

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

Sehe auch nichts was dagegen spricht...

sl FXXS

Zitat von -trb-

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.

Zitat von Mike

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.

Zitat von Mike

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.

Zitat von -trb-

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.

Zitat von GoDot

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.