Posts by daybyter

daybyter · Nov 7th 2011

Quote from peiselulli

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

daybyter · Nov 7th 2011

Quote from sauhund

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

daybyter · Nov 7th 2011

Quote from sauhund

ä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

daybyter · Nov 7th 2011

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

Code

float sqrt_heron(float a) {
float x = a; /* Startwert = a */
int i;
if( _fsgn( a) == 0) {
return _itof( 0);
}
for(i = 1; i <= 8; ++i) {
x = _fdiv( _fadd( x, fdiv( a, x)), _itof(2));
}
return x;
}

Display More

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...

daybyter · Nov 7th 2011

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

daybyter · Nov 7th 2011

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

daybyter · Nov 7th 2011

Ich weiss nicht...ein ZX 81 ist für mich nur echt, wenn er ne Folientastatur hat, auf der ich praktisch nicht tippen kann...mit PS/2 Tastatur geht mir da das Retro-Feeling komplett ab...

daybyter · Nov 7th 2011

Quote from polluks

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

daybyter · Nov 6th 2011

Wieder da...

Nächstes Problem:

Code

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

liefert -1.27605888e+38 als Wurzel von 144?

Ciao,
Andreas

PS: folgender Code malt mal was:

C

#include <stdio.h>
#include <stdlib.h>
#include <conio.h>
#include <modload.h>
#include <tgi.h>
#include "float.h"
#include "math.h"
int main (void) {
unsigned char Border;
int XRes, YRes;
float xf, xfMin, xfMax, xfDelta, yf, yfMin, yfMax, yfDelta, radiusf, zf, zScale;
int x,y;
/* Load and initialize the driver */
tgi_load (TGI_MODE_320_200_2);
/* CheckError ("tgi_load"); */
tgi_init ();
/* CheckError ("tgi_init"); */
/* Get stuff from the driver */
XRes = tgi_getxres();
YRes = tgi_getyres();
/* Set the palette, set the border color */
Border = bordercolor(COLOR_BLACK);
/* Clear the background. */
tgi_setcolor( COLOR_WHITE);
tgi_bar( 0, 0, XRes - 1, YRes - 1);
tgi_setcolor( COLOR_BLACK);
/* Compute and draw a 3d function. */
yfMin = itof( -144);
yfMax = itof( 144);
yfDelta = _strtof( "2.25");
zScale = _itof( 20);
for( yf = yfMin; _ftoi( _fsgn( _fsub( yfMax , yf))) >= 0; yf = _fadd( yf, yfDelta)) {
/* xfMax = _ftoi( _fadd( _strtof( "0.5"), ( fsqr( _fsub( _fmul( yfMax, yfMax), _fmul( yf, yf)))))); */
xfMax = itof( 144);
xfMin = _fneg( xfMax);
xfDelta = _itof( 1);
for( xf = xfMin; _ftoi( _fsgn( _fsub( xfMax, xf))) >= 0; xf = _fadd( xf, xfDelta)) {
/* tgi_outtextxy( 10, 20, debugOutput); */
/* tgi_outtextxy( 30, 20, debugOutput); */
radiusf = _fmul( _strtof( ".0327"), _fsqr( _fadd( _fmul( xf, xf), _fmul( yf, yf))));
zf = _fmul( zScale, _fadd( _fadd( _fcos( radiusf), _fcos( _fmul( radiusf, _itof( 2)))), _fcos( _fmul( radiusf, _itof(5)))));
/* Scale to screen coordinates */
x = _ftoi( _fmul( _fadd( _fadd( xf, _fdiv( yf, yfDelta)), _itof( 160)), _strtof( ".85")));
y = _ftoi( _fmul( _fsub( _itof( 199), _fadd( _fsub( zf, _fdiv( yf, yfDelta)), _itof( 90))), _strtof( ".9")));
if( y > 0 && y < 200) {
tgi_setpixel( x ,y);
/* Clear horizon under y. */
if( y < 199) {
tgi_setcolor( COLOR_WHITE);
tgi_line( x, y + 1, x, 199);
tgi_setcolor( COLOR_BLACK);
}
}
}
}
while (!kbhit());
/* Unload the driver */
tgi_unload ();
/* Reset the border */
bordercolor (Border);
/* Done */
printf ("Done\n");
return EXIT_SUCCESS;
}

Display More

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?

daybyter · Nov 6th 2011

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

daybyter · Nov 6th 2011

Hab den Vergleich in der Schleife jetzt hinbekommen, So klappt er:

Code

for( yf = yfMin; _ftoi( _fsgn( _fsub( yfMax , yf))) >= 0; yf = _fadd( yf, yfDelta)) {

Ist trotzdem noch ein Bug drin. Muss ich noch ein wenig suchen...

Ciao,
Andreas

daybyter · Nov 6th 2011

Wenn Du den C64 ganz weglässt und Dir z.B. nen echten Z80 Rechner holst, hättest Du vermutlich einen _noch_ schnelleren Rechner mit weniger Problemen...?

daybyter · Nov 5th 2011

@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

daybyter · Nov 5th 2011

Da hast Du eigentlich recht. Hab auch schon nach dem TPA-Problem gesucht, aber nichts mehr dazu gefunden. Hier steht das übrigens auch mit der richtigen Adresse:

http://www.zock.com/64er/8404/0009.html

, aber ich bin mir ziemlich sicher, dass es dieses TPA-Problem gab, weil ich da nämlich zum ersten Mal gehört hab, was TPA ist...

Ciao,
Andreas

daybyter · Nov 5th 2011

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?

Code

yfMin = itof( -144);
yfMax = itof( 144);
yfDelta = _strtof( "2.25");
zScale = _itof( 20);
_ftostr( debugOutput, yfMin);
printf( "yfMin: %s \n", debugOutput);
_ftostr( debugOutput, yfMax);
printf( "yfMax: %s \n", debugOutput);
_ftostr( debugOutput, yfDelta);
printf( "yfDelta: %s \n", debugOutput);
printf( "Compare yf: %d\n", _fcmp( yfMin, yfMax));

Display More

Ciao,
Andreas

daybyter · Nov 5th 2011

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

daybyter · Nov 4th 2011

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.

daybyter · Nov 4th 2011

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

daybyter · Nov 4th 2011

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

daybyter · Nov 4th 2011

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:

C

#include <stdio.h>
#include <stdlib.h>
#include <conio.h>
#include <modload.h>
#include <tgi.h>
#include "float.h"
#include "math.h"
int main (void) {
unsigned char Border;
int XRes, YRes;
float xf, xfMin, xfMax, xfDelta, yf, yfMin, yfMax, yfDelta, radiusf, zf, zScale;
int x,y;
char debugOutput[80];
/* Load and initialize the driver */
tgi_load (TGI_MODE_320_200_2);
/* CheckError ("tgi_load"); */
tgi_init ();
/* CheckError ("tgi_init"); */
/* Get stuff from the driver */
XRes = tgi_getxres();
YRes = tgi_getyres();
/* Set the palette, set the border color */
Border = bordercolor(COLOR_BLACK);
/* Clear the background. */
/* tgi_setcolor( COLOR_WHITE);
tgi_bar( 0, 0, XRes - 1, YRes - 1); */
/* tgi_setcolor( COLOR_BLACK); */
/* Compute and draw a 3d function. */
yfMin = itof( -144);
yfMax = itof( 144);
yfDelta = _strtof( "2.25");
zScale = _itof( 20);
for( yf = yfMin; _fcmp( yf, yfMax) < 1; yf = _fadd( yf, yfDelta)) {
xfMax = _ftoi( _fadd( _strtof( "0.5"), ( fsqr( _fsub( _fmul( yfMin, yfMin), _fmul( yf, yf))))));
xfMin = _fneg( xfMax);
xfDelta = _itof( 1);
for( xf = xfMin; _fcmp( xf, xfMax) < 1; xf = _fadd( xf, xfDelta)) {
_ftostr( debugOutput, xf);
tgi_outtextxy( 10, 20, debugOutput);
_ftostr( debugOutput, yf);
tgi_outtextxy( 30, 20, debugOutput);
radiusf = _fmul( _strtof( ".0327"), _fsqr( _fadd( _fmul( xf, xf), _fmul( yf, yf))));
zf = _fmul( zScale, _fadd( _fadd( _fcos( radiusf), _fcos( _fmul( radiusf, _itof( 2)))), _fcos( _fmul( radiusf, _itof(5)))));
/* Scale to screen coordinates */
x = _ftoi( _fmul( _fadd( _fadd( xf, _fdiv( yf, yfDelta)), _itof( 160)), _strtof( ".85")));
y = _ftoi( _fmul( _fsub( _itof( 199), _fadd( _fsub( zf, _fdiv( yf, yfDelta)), _itof( 90))), _strtof( ".9")));
if( y > 0 && y < 200) {
tgi_setpixel( x ,y);
/* Clear horizon under y. */
if( y < 199) {
tgi_setcolor( COLOR_BLACK);
tgi_line( x, y + 1, x, 199);
tgi_setcolor( COLOR_WHITE);
}
}
}
}
while (!kbhit());
/* Unload the driver */
tgi_unload ();
/* Reset the border */
bordercolor (Border);
/* Done */
printf ("Done\n");
return EXIT_SUCCESS;
}

Display More

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?

Posts by daybyter

Real-Zahlen und Funktionen im cc65 nutzen...zur Umsetzung

Real-Zahlen und Funktionen im cc65 nutzen...zur Umsetzung

Real-Zahlen und Funktionen im cc65 nutzen...zur Umsetzung

Real-Zahlen und Funktionen im cc65 nutzen...zur Umsetzung

Real-Zahlen und Funktionen im cc65 nutzen...zur Umsetzung

Real-Zahlen und Funktionen im cc65 nutzen...zur Umsetzung

CP/M-Cartridge mit eingebautem Z80 für C64?

Real-Zahlen und Funktionen im cc65 nutzen...zur Umsetzung

Real-Zahlen und Funktionen im cc65 nutzen...zur Umsetzung

Real-Zahlen und Funktionen im cc65 nutzen...zur Umsetzung

Real-Zahlen und Funktionen im cc65 nutzen...zur Umsetzung

CP/M-Cartridge mit eingebautem Z80 für C64?

Real-Zahlen und Funktionen im cc65 nutzen...zur Umsetzung

CP/M-Cartridge mit eingebautem Z80 für C64?

Real-Zahlen und Funktionen im cc65 nutzen...zur Umsetzung

CP/M-Cartridge mit eingebautem Z80 für C64?

Real-Zahlen und Funktionen im cc65 nutzen...zur Umsetzung

Real-Zahlen und Funktionen im cc65 nutzen...zur Umsetzung

CP/M-Cartridge mit eingebautem Z80 für C64?

Real-Zahlen und Funktionen im cc65 nutzen...zur Umsetzung