Posts by daybyter

    Ich habe sowas mal für den H8/300 in Assembler implementiert.
    http://en.wikipedia.org/wiki/H8_Family
    Hat bei + - * / Faktor 10 gegenüber der C-Lösung (das war der Default in der "libm") gebracht.
    sqrt und sin / cos / atan hab ich mir dann auch noch gegeben, da war dann nochmal Faktor 50 drin.
    Aber schön ist der Code nicht gerade ...
    Und kurz auch nicht, also wahrscheinlich bring das auf dem C64 nix ...


    Wo würdest Du die grössten Vorteile vom Assembler-Code sehen? Meine erste Idee wäre z.B. das Checken von Flags, wie Übertrag bei Addition etc., was in C schlecht (nicht effizient) zu machen ist. Oder z.B. Rollen durchs Carry-Bit, und dann in Abhängigkeit davon zu springen. Also denke ich schon, dass man am Ende Teile in Assembler brauchen wird. Am sogar dann würde ich es wohl vorziehen, wenn man das in einen Rahmen von C-Code einfügt, der die Algorithmen beschreibt.


    Ciao,
    Andreas

    was willst du da gross optimieren? eine derartige library müsste in erster linie eins sein: möglichst kurz. schnell wird sie sowieso nie werden. nene. falsche reihenfolge. optimierung kommt grundsätzlich immer ganz zum schluss, alles andere ist sinnfrei.


    Ich wollte eigentlich das Zeichenprogrämmchen optimieren, damit man mal sieht, welcher Anteil da nun float ist, und wo z.B. nur gemalt wird. Also z.B. die Linien-Routine beschleunigen etc.


    Quote

    wenn du etwas über floats lernen willst ist das sicher eine gute idee - wenn dabei aber etwas in der praxis sinnvoll nutzbares rauskommen soll gibt es keine alternative zu den basic roms. und in C will man solche funktionen schon garnicht schreiben, die sind so schon langsam genug :)


    Aber die Basic-Geschichte wird Uz niemals in den cc65 aufnehmen, weil sie auf den anderen Rechnern ja nicht läuft. Und ehrlich gesagt, glaub ich auch nicht, dass Commodore nun sooo einen Wahnsinns-Job bei den Matheroutinen gemacht hat. Da kann man bestimmt noch was optimieren...


    Wie stellst Du Dir die weitere Entwicklung vor? Willst Du Uz überzeugen, dass er die Basic-Roms unterstützt?


    Ciao,
    Andreas


    äh ganz ehrlich? bevor die nicht in einem compiler zur anwendung kommt fasse ich die nicht an =P


    Ach komm...es ist doch nur eine Kleinigkeit! :) Die _fcmp Funktion muss benutzbar werden und die Wurzel müsste gehen...dann noch schnell ne Zeitmessung rein, und wir könnten anfangen systematisch zu optimieren. Wir erwähnen das auf der cc65-Mailing-Liste, Uz ist beeindruckt und startet vielleicht den float-Einbau in cc65. Ich würde ja auch selbst damit anfangen, aber bis jetzt hat sich ja noch niemand geäussert, dass er daran interessiert ist...


    Quote


    nach "aussen" sind das 32bit ieee floats. intern wird natürlich in das krude format umgerechnet das das basicrom benutzt, sonst geht ja nix =)


    Ich hätte gesagt, dass wir das Basic-Rom mal vergessen und vielleicht folgende Routinen selbst implementieren:
    +,-,*,/,cast auf long und andere Richtung, <,>,==. Damit könnte man doch schon einen guten Teil der Math-Lib implementieren. Ich würde, wie schon gesagt, gerne möglichst viel in C machen, weil ich das besser zu lesen finde, besser wartbar finde usw. Wie man das aus dem cc65 aufruft, weiss ich allerdings zugegebenermassen auch noch nicht genau.


    Ciao,
    Andreas

    Ich versuch zu wurzeln, aber es kommt irgendwie immer 0 raus... :(



    Oben muss ich den Fall arg == 0 abtesten, damit ich keine Division durch 0 bekomme. Da _fcmp nicht tut, wollte ich auf fsgn ausweichen, was aber wohl auch nicht geht. Jedenfalls wurzelt da nix...muss man wohl warten bis Stefan (sauhund) ne neue Release macht...


    Ciao,
    Andreas


    PS: polluks: mit der tgi-Doku hast Du offensichtlich recht, aber logisch find ich es immer noch nicht...

    polluks: Ich hab jetzt Deine Lösung zum Löschen genommen und sie ist wirklich viel schneller. Aber es passiert was ulkiges: tgi_setcolor arbeitet jetzt umgekehrt. D.h. wenn ich tgi_setcolor(COLOR_WHITE) nehme, mal er schwarz und umgekehrt. Da werden vermutlich einfach nur Paletteneinträge indiziert und setcolor bekommt nicht mit, dass diese Einträge nun vertauscht wurden. Wenn man also COLOR_WHITE mit COLOR_BLACK vertauscht, läuft das Programm wieder. Aber so arg schön ist es ja nicht...


    enthusi: also man kann an dieser Stelle was über den 64er lernen (wie man z.B. effektiv für den 6510 coded), man lernt was über maschinendarstellung von floats (ieee-Darstellung z.B.), man kann was über Mathe lernen uvm. Und Spass macht es mir eigentlich auch. Es ist doch gerade der Reiz mit beschränkten Mitteln viel zu erreichen. Deshalb gibt es ja z.B. auch 4k-Coding Wettbewerbe u.ä. Natürlich könnte ich nativ auf meine AMD Quadcore hier die Funktionen locker in Echtzeit berechnen. Aber auf einem Brotkästchen find ich es halt spannender... :)


    Ciao,
    Andreas

    Hallo!


    Ich dachte sauhund heisst Stefan? Deshalb dieses @stefan vor dem Kommentar.


    Das mit dem schnellen Löschen sieht gut aus. Bau ich gleich mal ein.


    Die 144 war tatsächlich nur ein Workaround. Im Original (in dem Data Becker Buch mit Tipps und Tricks zum 64er ist diese Wurzel-Geschichte verwendet worden, damit die ganze Grafik eine runde Grundfläche hat. Nimmst Du die 144 mal raus und ersetzt sie durch die Originalzeile, dann wird für jeden yf-Wert nur 1 xf-Wert geplottet, d.h. Du bekommst quasi einen Querschnitt der Grafik, die Du siehst.


    Mir ist gestern als Workaround eine Konstruktion dieser Art eingefallen: xfMax = 144 * sin( acos( yf / 144); wobei die 144 halt yfMax sind. Problem: acos ist noch nicht implementiert. Man könnte ihn durch eine Formel mit atan ersetzen, braucht dann aber wieder eine Wurzel dazu. Die ja anscheinend nicht geht. Also hab ich gestern mal nach sqrtf Implementierungen geguckt, um sowas mal provisorisch einzubauen. Aber alle schnellen Implementierungen stützen sich auf das Binärformat der floats, rechnen also die Wurzel Bit für Bit aus. Das wollte ich ehrlich gesagt nicht unbedingt machen, weil dieses 6-Byte Format aus meiner Sicht keine grosse Zukunft hat, und vermutlich eh durch ein 32-Bit IEEE-Format ersetzt wird. Und dann würde ich das lieber in C schreiben, weil ich es leichter lesbar und wartbar finde.


    Ciao,
    Andreas

    Bei mir scheint die Wurzel zu gehen ...


    Aber das sieht doch auch nicht wirklich rund aus? Hast Du die xfMax-Zeile geändert? Vom Bild her würde ich sagen, sieht das aus, wie xfMax = itof( 144);


    @stefan: Könntest Du ggf. eine neue Release Deiner Lib machen, wo fcmp ein unsigned zurückgibt? Ich hab nur kurz in die Sources geguckt, aber Du verwendest wirklich so ein 6-Byte Format mit 4 Byte Mantisse, 1 Byte Exponent und 1 Byte Vorzeichen? Ich befürchte, dass man das nicht in cc65 integriert bekommt. 4 Byte scheinen mir von der Performance her besser zu sein, und ich bin mir nicht sicher, ob Double mit 8 Byte soooviel langsamer wie Dein Typ wäre?


    Ciao,
    Andreas

    Wieder da...


    Nächstes Problem:


    Code
    1. x = fsqr( itof( 144));
    2. _ftostr( debugOutput, x);
    3. printf( "Wurzel ist: %s \n", debugOutput);


    liefert -1.27605888e+38 als Wurzel von 144?


    Ciao,
    Andreas


    PS: folgender Code malt mal was:



    Sieht noch nicht so gut aus, weil die xfMax-Zeile mit der Wurzel nicht tut.


    Was tgi wohl fehlt:


    - Hintergrundfarbe setzen und dann schnelles Löschen (mit memset, oder so).
    - Spezielle Funktionen zum Zeichnen von senkrechten und waagrechten Linien. Die kann man auf den meisten Systemen gut optimieren.
    - Ich will noch die Rechenzeit ausgeben, aber bisher klappt das nicht. Muss man dazu immer einen Font laden? Auch in dem alten tgi?

    polluks: Danke für den Patch! Muss jetzt leider weg, aber schau es mir später oder Morgen mal an.


    Was ich schon ne Weile überlege: muss das wirklich Assembler sein? Sogar im cc65 müsste es doch möglich sein, sogar die grundlegenden Operationen in C zu schreiben, indem man natürlich nur int-Typen verwenden könnte. Wenn man diese Funktionen so schreibt, dass sie ohne Argumente aufgerufen werden, sondern einfach nur die Akkus (die an festen Adressen sind) benutzen, müsste der Compiler ja nur die Argumente in die Akkus bringen und dann ein jsr <operation> machen, oder?


    Ciao,
    Andreas

    @stefan: also im Original C gibt ja anscheinend diese fcmp Funktion nicht, weil es dort ja die Operatoren <, == und > gibt. Also hab ich mich mal an die strcmp Funktion gehalten:


    http://home.htw-berlin.de/~jun…ref/FUNCTIONS/strcmp.html


    Danach müsste sie nur <0, 0 oder eine Zahl > 0 zurückgeben, um das Verhältnis der beiden Argumente zu bestimmen. Ich hatte das irgendwie so im Kopf, dass sie -1, 0 oder 1 zurückgibt. Allerdings hab ich mich zum letzten Mal unter Zorland C so richtig mit den Funktionen beschäftigt. Was also eeeewig her ist.


    Wenn Du die Funktion wirklich nur als Gleichheits-Test nutzen willst, bräuchte man noch eine Methode, um auch kleiner und grösser testen zu können...


    Sollen wir jetzt mal versuchen, den cc65 zu patchen? Einen Einstiegspunkt hätten wir ja schonmal.... Oder erst Uz anhauen?


    Ciao,
    Andreas

    Hallo!


    @stefan: Ich habe erstmal noch einen Fehler in den Schleifen gefunden. Aber in allen Fällen werden die Schleifen nur _einmal_ durchlaufen, was eigentlich nicht sein darf.
    Problem: folgender Vergleich am Schluss liefert 0, obwohl ja -144 kleiner ist als 144. Das Ergebnis müsste also doch -1 sein, oder?



    Ciao,
    Andreas

    Ich glaub, Commodore hatte da einfach das Problem, dass sie für Geschäftsleute in dem Moment kein Angebot hatten. dbase z.B. war gerade so in der Anfangsphase des Kommens, und Commodore hatte ja z.B. noch keinen PC im Angebot. Amiga gab es ja auch noch nicht. Und so hatten die Commodore Leute wohl die Idee, dass man das ja auf dem 64er machen könnte. Aber im rauhen Geschäftsalltag hätte das nach meiner Ansicht niemals funktioniert. Wenn da jemand an die Kiste gestossen wäre, wären halt gleich ein paar Artikel weg gewesen. Da waren z.B. die Apple-Clone schon die wesentlich robustere Alternative.


    Hat der 128er die TPA an der richtigen Adresse? D.h. laufen Wordstar und Co dort ohne grosse Anpassungen? Damit wurde ja u.a. mal für das CP/M-Modul geworben, aber ich hab niemals einen Händler gesehen, der solche Software im Angebot gehabt hätte. D.h. ob z.B: dbase auf dem 64er lief, ist für mich ungeklärt....


    Ciao,
    Andreas

    Nicht ersetzen. Ergänzen. Wenn der Compiler eine float-Var sieht, soll er sie einfach mal als long behandeln.


    Wobei die floats ja schon an fast allen Stellen drin stehen. Wenn wir z.B. erstmal den Error in codegen.c Zeile 74 rausnehmen.


    Dann das Laden und Speichern implementieren. Ab Zeile 645 könnten wir die floats wie longs behandeln. Sind ja ebenfalls 4 Byte.

    Wenn man wirklich die 32-Bit Typen nimmt, dann könnte man ja erstmal die float-Ops als Long implementieren und dann schrittweise die korrekten Ops einbauen. Damit würde zumindest mal das Pushen und Poppen der Variablen auf den Stack funktionieren. Auch Zuweisungen müssten identisch funktionieren.


    Ich les gleich mal ein bischen in den cc65 Sources...


    Ciao,
    Andreas

    Wenn man sich für CP/M interessiert, gibt es wohl einige Rechner, die interessanter sind. Mir fällt da z.B. ein Apple-kompatibles Gerät ein, was hier mal von einem Laden verkauft wurde. Hatte eine abgesetzte Tastatur, Floppies im Gehäuse und einiges mehr. War ähnlich, wie die Basis-Geräte:


    http://de.wikipedia.org/wiki/Basis_108


    Damit hätte man zumindest mal nicht die TPA-Probleme.


    Aber auch der MZ-800 war interessant. Hatte z.B. höhere Auflösung für 80 Zeichen.


    Ciao,
    Andreas

    Ich wollte mir in der Schleife mal per TGI die aktuellen Koordinaten ausgeben lassen. Geht auch nicht. Als ob die Schleifen gar nicht laufen. Vermutlich ist es am Besten, wenn man die Grafik mal komplett abschaltet, und erstmal im Testmodus debugged.


    Hier die Version, die nicht tut:



    Ciao,
    Andreas


    PS: jetzt mal ohne Grafik probiert...


    _ftoi scheint schonmal nicht richtig zu funktionieren. Der Ausdruck


    xfMax = _ftoi( _fadd( _strtof( "0.5"), ( fsqr( _fsub( _fmul( yfMin, yfMin), _fmul( yf, yf))))));


    ergibt 0, obwohl der Ausdruck _fadd .... 5 ergibt. Was wiederum auch falsch sein müsste, weil yfMin am Anfang doch gleich yf ist, also der Ausdruck in der Wurzel 0 wäre.


    Vielleicht wäre es sinnvoll, mal eine Testsuite für die Funktionen zu schreiben, damit man mal sieht, welche Funktion welche Ergebnisse bringt?