Hallo,
hat jemand zufällig ein Locomotive-BASIC-Listing zur Hand, mit dem man eine mehrfarbige Mandelbrot-Menge auf dem CPC generieren kann? Bräuchte ich kurzfristig und wäre sehr dankbar! 
µP
Fraktale mit BASIC
- Microprofessor
- Erledigt
-
Hallo,
hat jemand zufällig ein Locomotive-BASIC-Listing zur Hand, mit dem man eine mehrfarbige Mandelbrot-Menge auf dem CPC generieren kann? Bräuchte ich kurzfristig und wäre sehr dankbar!
µP
... ja, habe ich. Bis wann brauchst du das? Bis morgen komme ich auf jeden Fall dazu.
-
Bis heute um 10 Uhr.
Morgen ist es aber auch noch gut.
-
Es gibt einen Basic-Einzeiler von demoniak im CPC-Wiki Forum.
-
Es gibt einen Basic-Einzeiler von demoniak im CPC-Wiki Forum.
Ja, das war echt lustig, daß man es so kurz hinbekommt
Hier ist quasi genau die selbe Version in aufgeblasen:
Code
Alles anzeigen1000 MODE 0 1010 MAXMAGSQUARED = 4 1020 MaxIterations = 16 1030 mXmin = -2.2 1040 mXmax = 1 1050 mYmin = -1.2 1060 mYmax = 1.2 1061 Zr = 0 1062 Zim = 0 1063 Z2r = 0 1064 Z2im = 0 1070 scrxl = 160 1080 scryl = 200 1090 wdt = scrxl 1100 hgt = scryl 1110 wantaspect = (mYmax - mYmin) / (mXmax - mXmin) 1120 picaspect = scrYL / scrXL 1130 IF wantaspect>picaspect THEN wdt=(mYmax-mYmin)/picaspect:md=(mXmin+mXmax)/2:mXmin=md-wdt/2:mXmax=md+wdt/2 1140 IF wantaspect<=picaspect THEN hgt=(mXmax-mXmin)*picaspect:md=(mYmin+mYmax)/2:mYmin=md-hgt/2:mYmax=md+hgt/2 1150 dReaC = (mXmax - mXmin) / (scrxl - 1) 1160 dImaC = (mYmax - mYmin) / (scryl - 1) 1170 ReaC = mXmin 1180 FOR X = 0 TO scrxl - 1 1190 ImaC = mYmin 1200 FOR Y = 0 TO scryl - 1 1210 ReaZ = Zr 1220 ImaZ = Zim 1230 ReaZ2 = Z2r 1240 ImaZ2 = Z2im 1250 clr = 0 1260 WHILE clr<MaxIterations AND ReaZ2+ImaZ2<MAXMAGSQUARED 1270 ReaZ2 = ReaZ * ReaZ 1280 ImaZ2 = ImaZ * ImaZ 1290 ImaZ = 2 * ImaZ * ReaZ + ImaC 1300 ReaZ = ReaZ2 - ImaZ2 + ReaC 1310 clr = clr + 1 1320 WEND 1330 PLOT X*4,Y*2,clr MOD 16 1340 ImaC = ImaC + dImaC 1350 NEXT Y 1360 ReaC = ReaC + dReaC 1370 NEXT X
(wurde von einem VB.NET Programm "portiert")- Durch Ändern des Werts in Zeile 1020 kann man die Tiefe der Feinstrukturen (Fransen) vergrößern oder verkleinern (z.B. erhöhen auf 64); macht es dann natürlich auch langsamer
- Über die Zeilen 1030-1060 kann man in das Fraktal hinein- (Werte verkleinern) oder herauszoomen (Werte vergrößern).
- Über die Zeilen 1061-1064 kann man das Erscheinungsbild verändern, damit hab ich allerdings noch nicht rumgespieltTipp: In WinApe "Turbo Mode" und "Display Every 50 Frames" (Settings -> General) aktivieren, damit man nicht ewig auf das Ergebnis warten muß.
Irgendwie hab ich gerade große Lust, das mal in Assembler auszuprobieren...
CU,
Prodatron -
Es gibt einen Basic-Einzeiler von demoniak im CPC-Wiki Forum.
Cool!
Und: Danke Prodatron!
-
Tipp: In WinApe "Turbo Mode" und "Display Every 50 Frames" (Settings -> General) aktivieren, damit man nicht ewig auf das Ergebnis warten muß.
Irgendwie hab ich gerade große Lust, das mal in Assembler auszuprobieren...
1. Das ewige Warten ist mit das Wichtigste am Fraktalgenerieren. Ich erinnere mich da an Tage und Nächte ... ohne das Warten ist es bloß Computergrafik.
2. Das ist wirklich mal eine tolle Anwendung für Assembler.
(Ich habe meinen Studenten heute die Aufgabe gestellt, zu erklären, wie es sein kann, dass der Computer mit komplexen Zahlen rechnen kann, obwohl er unter BASIC eigentlich nur reelle und ganze Zahlen - und auf der Maschinenebene sogar nur die beiden natürliche Zahlen 0 und 1 kennt. Ich bin gespannt auf die Antworten.)
-
1. Das ewige Warten ist mit das Wichtigste am Fraktalgenerieren. Ich erinnere mich da an Tage und Nächte ... ohne das Warten ist es bloß Computergrafik.
2. Das ist wirklich mal eine tolle Anwendung für Assembler.
(Ich habe meinen Studenten heute die Aufgabe gestellt, zu erklären, wie es sein kann, dass der Computer mit komplexen Zahlen rechnen kann, obwohl er unter BASIC eigentlich nur reelle und ganze Zahlen - und auf der Maschinenebene sogar nur die beiden natürliche Zahlen 0 und 1 kennt. Ich bin gespannt auf die Antworten.)
... wie versprochen
10 ink 1,2
20 ink 2,6
30 ink 3,21
40 ink 4,24
50 ink 5,8
60 left=150:top=380:w=360:m=0.0883
70 r=2.64:s=2*r/w
80 recen=0:imcen=0
90 MODE 1
100 ORIGIN 10,10
110 for y=0 to w
120 for x=0 to w
130 rec=s*(x-w/2)+recen:imc=s*(y-w/2)+imcen
140 re=rec:im=imc
150 re2=re*re. im2=im*im:j=0
160 WHILE re2+im2<=256 AND j<15
170 im=2*re*im+imc
180 re=re2-im2+rec
190 re2=re*re:im2=im*im:j=j+1
200 WEND
210 if j<3 then GOTO 270
220 IF j>=3 AND j<6 THEN PLOT x+left,(top-y)*m,1
230 IF j>=6 AND j<9 THEN PLOT x+left,(top-y)*m,2
240 IF J>=9 AND j<12 THEN PLOT x+left,(top-y)*m,3
250 IF j>=12 AND j<15 THEN PLOT x+left(top-y)*m,4
260 IF j>15 THEN PLOT x+left,(top-y)*m,5
270 NEXT x
280 NEXT y
290 SAVE"apfel",b,&C000,&4000 -
In Zeile 150 muß der Punkt durch einen Doppelpunkt ersetzt werden, und in Zeile 250 fehlt ein Komma hinter dem Left.
Das Apfelmännchen wird ganz unten zusammengequetscht, da sollte man vielleicht die Parameter etwas optimieren?CU,
Prodatron -
Sehr cool!
Das könnte ich glatt auf den PET portieren.
Aber haut der sich nicht unter Umständen irgendwann den Stack kaputt, wenn er immer mit GOTO aus der For-Schleife herausspringt? Ich würde da lieber I% auf I1% setzen, damit die sauber beendet wird. Scheinbar ist das Basic da aber sehr robust?CU,
Prodatron*EDIT* Sorry, da war ich nicht mehr richtig im Basic-Thema drin. Der CPC macht da auch keine Probleme. Scheinbar resetten die den Stack, wenn die Schleife erneut aufgerufen wird.
-
Beitrag gelöscht
-
In Zeile 150 muß der Punkt durch einen Doppelpunkt ersetzt werden, und in Zeile 250 fehlt ein Komma hinter dem Left.
Das Apfelmännchen wird ganz unten zusammengequetscht, da sollte man vielleicht die Parameter etwas optimieren?CU,
Prodatron... ja, sorry. Habe heute nur ein ipad zur Hand gehabt. die parameter können und sollen geändert werden - das siehst du ja auch an den vier zeilen mit den ink befehlen, die könnten ja auch zusammengefasst werden. ist halt nur ein schnellschuss gewesen, ich hatte den algorithmus und habe das programm in der mittagspause auf locomotive umgestrickt ...
(*schäm*)
-
Irgendwie hab ich gerade große Lust, das mal in Assembler auszuprobieren...
Hihi, irgendwie kenn ich das Gefuehlt.H.
-
Tolle Sammlung, die hier gerade entsteht.
Prodatron: Das nenne ich mal ne tolle Fehlleistung mit dem Stack.
BASIC ist da extrem gutmütig. Das einzige, was es nicht mag, ist, zurück in FOR-NEXT-Schleifen springen, wenn die schon abgearbeitet sind.Mit dem WHILE-Konstrukt aus dem Einzeiler ist es aber sehr viel eleganter.
Hier übrigens vom selben PDP-Menschen die FORTRAN-Variante:
[Blockierte Grafik: https://fbcdn-sphotos-a.akamai…990068064_421836763_n.jpg]
... und die Variante in "Lang 5" - der Interpreter(!)-Programmiersprache, die er selbst entwickelt hat:
[Blockierte Grafik: https://fbcdn-sphotos-a.akamai…190907821691_632038_n.jpg]
P.S.
Der Autor (Bernd Ulmann sein Name) dürfte auch für Z80-Freunde interessant sein: http://www.vaxman.de/projects/tiny_z80/
Und für VAX-Freunde: http://www.vaxman.de/
Und natürlich für Analogcomputer-Freunde: http://www.analogmuseum.org/ -
Es gibt einen Basic-Einzeiler von demoniak im CPC-Wiki Forum.
http://www.cpcwiki.eu/forum/pr…c-line/msg29620/#msg29620
Oh, der ist niedlich ... hmm waer das nicht was fuer die CC2012?Ich mein, es koennte ja mal jeder auf seinem Rechner den Einzeiler, ohne grundsatzliche Aenderungen, umsetzen, und dann schauma uns die Ergebnisse an. Wenn die Laufzeit einigermassen lang ist kann man die ja messen und eine Liste mit der Mandelbrotperformance der jeweiligen Rechner/BASIC-Kombination machen. Das waer niedlich. Ggf. dann mit Vergleich mit Assemblerversionen (Juhu Proda). Vieleicht versuch ich mich mal am CPC in Assm.
H.
-
Ich mein, es koennte ja mal jeder auf seinem Rechner den Einzeiler, ohne grundsatzliche Aenderungen, umsetzen, und dann schauma uns die Ergebnisse an. Wenn die Laufzeit einigermassen lang ist kann man die ja messen und eine Liste mit der Mandelbrotperformance der jeweiligen Rechner/BASIC-Kombination machen. Das waer niedlich. Ggf. dann mit Vergleich mit Assemblerversionen (Juhu Proda). Vieleicht versuch ich mich mal am CPC in Assm.
Coole Idee, ich geb schonmal für die Basic-Versionen Wetten ab
- der MSX wird total abloosen
- der TI/994A erst recht ohne Extended Basic
- der CPC wird wohl einer der schnellsten sein
- BBC/Mallard Basic könnte ebenso gut abschneiden
- die Commodores dagegen würden wohl höchstens im Mittelfeld landen, ist ja auch der unoptimierte Microsoft Kram wie beim MSX
- der Apple II könnte mit Steves Integer Basic Chancen haben, wenn man schummelt und es einer darauf portiert kriegt (Fest- statt Fließkommazahlen)
- vom Spectrum Basic hab ich leider gar keine Ahnung, was die Performance betrifft?Vielleicht sollte man wegen den Basic-Benchmarks nochmal die alten Happy Computer durchwühlen, da waren doch noch ein paar drin
Ein Vergleich Basic <-> Assembler ist zwar immer interessant, aber wenn man halt schon die riesigen Unterschiede nur zwischen den Basic-Interpretern sieht (z.B. CPC <-> MSX, Faktor 4), dann ist das halt nicht so exakt aussagekräftig.
CU,
Prodatron -
Zeile 301: Hat der keinen Modulo Operator??
-
Alles anzeigen
Coole Idee, ich geb schonmal für die Basic-Versionen Wetten ab
- der MSX wird total abloosen
- der TI/994A erst recht ohne Extended Basic
- der CPC wird wohl einer der schnellsten sein
- BBC/Mallard Basic könnte ebenso gut abschneiden
- die Commodores dagegen würden wohl höchstens im Mittelfeld landen, ist ja auch der unoptimierte Microsoft Kram wie beim MSX
- der Apple II könnte mit Steves Integer Basic Chancen haben, wenn man schummelt und es einer darauf portiert kriegt (Fest- statt Fließkommazahlen)
- vom Spectrum Basic hab ich leider gar keine Ahnung, was die Performance betrifft?Vielleicht sollte man wegen den Basic-Benchmarks nochmal die alten Happy Computer durchwühlen, da waren doch noch ein paar drin
Hmm, weiss nicht Also wenn man es als Vergleich macht, dann sollte das Programm natuerlich so nah wie moeglich an selbigem Einzeiler sein. Ein Ausweichen auf Integerrechnung ist da eher nicht passend. Was die Einzelnen Rechner anbelangt, so duerfte sich Appel und Commodore nicht viel nehmen. Den TI unterschaetzt Du aber gewaltig. Gerade bei solchen Basic-Sachen ist er ueberraschend schnell. Ich muesste ih nmal ausgraben.
Ein Vergleich Basic <-> Assembler ist zwar immer interessant, aber wenn man halt schon die riesigen Unterschiede nur zwischen den Basic-Interpretern sieht (z.B. CPC <-> MSX, Faktor 4), dann ist das halt nicht so exakt aussagekräftig.
Aber relativ zur jeweiligen Basic-Version durchaus. Letztendlich gibts 3 Ansaetze wie man es in Assembler umsetzen kann:
a) unter benutzung der FP Routienen des Basic
b) mit eigener FP (aber immer noch GP-FP)
c1) mit angepassten (speziellen) FP Funktionen.
c2) mit Integer.Fuer einen Vergleich ist a) das interessanteste, da da zwar die Gesammte Programmlogik umgesetz wird, die 'FPU' (sprich die FP-Lib) die gleiche bleibt.
H.
-
Den TI unterschaetzt Du aber gewaltig. Gerade bei solchen Basic-Sachen ist er ueberraschend schnell. Ich muesste ih nmal ausgraben.
Trotz des 9918-16KB-Ram Gewurschtel? Die 16bit CPU ist sicherlich schnell, aber ohne Erweiterung (wie Extended Basic) war das Gemurkse mit dem 256byte Scratch-Pad-Ram doch schon sehr lahm, für mich war er damals gefühlt ohne Extended Basic deutlich langsamer als ein CPC. Ok, ist jetzt leider schon 30 Jahre her (der TI war mein "erster" ).Fuer einen Vergleich ist a) das interessanteste, da da zwar die Gesammte Programmlogik umgesetz wird, die 'FPU' (sprich die FP-Lib) die gleiche bleibt.
Da stimme ich Dir zu, wenn es um den Vergleich der Betriebssysteme bzw. deren Libraries geht (die dann halt entweder von Basic oder Assembler genutzt werden können). Aber dann beschränkt man sich zum Teil auf die eingebaute Software, ohne die Hardware voll auszunutzen.
Ansonsten müßte man trotzdem jeden Optimierungstrick akzeptieren. Basic zwingt einen halt dazu, die eingebauten Routinen zu nutzen, während man sich in Assembler notfalls alles selbst neu-programmieren kann und optimiert bis zum geht-nicht-mehr. Assembler soll ja eigentlich immer die 100%ige Power des HARDWARE-Systems zeigen und nicht durch die Limitierungen der eingebauten Roms gebremst werden.
Daher fände ich bei einem Assembler-Vergleich schon den anarchistischen Ansatz am bestenCU,
Prodatron -
Trotz des 9918-16KB-Ram Gewurschtel? Die 16bit CPU ist sicherlich schnell, aber ohne Erweiterung (wie Extended Basic) war das Gemurkse mit dem 256byte Scratch-Pad-Ram doch schon sehr lahm, für mich war er damals gefühlt ohne Extended Basic deutlich langsamer als ein CPC. Ok, ist jetzt leider schon 30 Jahre her (der TI war mein "erster" ).
Ohhhh, huebsch War auch ein netter Rechner. Ich hab den mal vor Jahren fuers XzX rausgekramt, und dann in 2x 1/2 Tag (Sa so von 14-2 Uhr und So von 12-15 Uhr) was Froggeraehnliches in Assembler programmiert. Nicht perfekt, war aber erstaunlich klein (weniger als 4k). Wenn man die Moeglichkeiten der Hitnergrundroutienen verwendete, dann hat es sich fast wie Atari XL angefuehlt. Man merkt bei dem Rechner einfach, dass er von Profies entwickelt wurde.Und gerade das Basic ist durch seine interpretative Struktur sehr gut auf die Hardware angepasst. Ich mein schau Dir doch mal den Kern eines jeden Basic Interpreters an: da gibt es eine innere Schleife, die das nachste Token holt und dekodiert. Alleine dieser Next-Zugriff ist in manchen Systemen 10-25 Befehle, beim TI nur einer, weil der 9918 den Pointer in Hardware fuehrt. Und Basic-Programme werden auf prakisch jedem System seriell durchgekaut.
Was richtig ist, ist dass die interpretierte Strukturt des Normalen Basics nicht sehr effektiv ist - aber auch nicht ueberragend schlecht. Da Extended Basic hat da kraeftig aufgeraeumt. Gerade was aber FP Rechnen und die Grafik anbelangt, da ist der TI recht gut geruestet. Lass es uns einfach ausprobieren.
Da stimme ich Dir zu, wenn es um den Vergleich der Betriebssysteme bzw. deren Libraries geht (die dann halt entweder von Basic oder Assembler genutzt werden können). Aber dann beschränkt man sich zum Teil auf die eingebaute Software, ohne die Hardware voll auszunutzen.
Ansonsten müßte man trotzdem jeden Optimierungstrick akzeptieren. Basic zwingt einen halt dazu, die eingebauten Routinen zu nutzen, während man sich in Assembler notfalls alles selbst neu-programmieren kann und optimiert bis zum geht-nicht-mehr. Assembler soll ja eigentlich immer die 100%ige Power des HARDWARE-Systems zeigen und nicht durch die Limitierungen der eingebauten Roms gebremst werden.
Daher fände ich bei einem Assembler-Vergleich schon den anarchistischen Ansatz am besten
Die Frage ist, was 'Ausnuetzen der Hardware' wirklich bedeutet. Das optimalste Programm ist immer eines was nicht nur sich auf die Funktionen beschraenkt die es braucht, sondern diese auch nur so implementiert wie es fuer die Aufgabe benoetigt wird. Bei dem Fraktalprogramm wird das dann besonders gefaehrlich, da man dann letztendlich Aepfel mit Birnen vergleicht. Nicht die bessere Implementation der Programmlogik schlaegt durch, sondern die Optimierung der 'Lib'. Nicht wirklich ein Ruhmesblatt.Und ein Assemblerprogramm das die FP-Lib verwendet kann trotzdem deutlich mehr gewinnen, als nur den Interpreter einzusparen. Kuck dir den Einzeiler an, da werden z.B. bestimmte Rechnungen doppelt gemacht, in Assembler laesst sich das leicht einsparen. Klar, das kann man auch in Basic optimieren, aber da ist nicht sicher ob die zusaetzlich noetigen Anweisungen die Werte zwischenzuspeichern auch wirklich viel Einsparen. in Assembler kann ichs garantieren. Auch bietet Assembler natuerlich die Moeglichkeit die FP-Lib besser einzusetzen. Z.B. indem man (wenn es die Lib erlaubt) mit mehreren FP-Akkus arbeitet und so die Kopiererei einspart, oder wenn das nicht geht zumindest ueber die Parameterreihenfolge nachdenkt, und so einen Teil der Moves einspart. Und die Moves kann man natuerlich mit fixen Adressen auch noch optimieren. Basic kann das nicht, das bedient die FP-Lib immer nach Schema F. Oder nimm die beiden (FP-)Konstanten die verwendet werden, je nach Basic werden die bei jeder Verwendung aus dem Programmtext nach FP umgewandelt (MS) oder zumindest rumkopiert. In Assembler legt man die direkt in das entsprechende FP-Argument per immideate Befehle. Schneller gehts nicht. Eine der Konstantenoperationen ist eine Multiplikation mit 2 - viele FP-Sammlungen bieten dafuer sogar eine eigene Funktion an, die das optimiert ausfuegt. Vom BASIC her wird das nicht genutzt, da wird die FP-Konstante 2 erzeugt, in (ein) FP-Argument kopiert und dann so richtig die komplette Multiplikation durchgezogen. Also ich seh da ne ganze Menge ptential - und all das ohne das FP-Rad neu zu erfinden.
Na ja, ich bin halt ein Assemblerfreak, also hab Nachsicht.
H.
-
... dann werfe ich mal den nächsten Stein ins Wasser:
Wie wäre es mit Pascal?
-
... dann werfe ich mal den nächsten Stein ins Wasser:
Wie wäre es mit Pascal?
Klar, warum nicht, wenn Du damit Assembler schlagen willst, gerne
Wobei, da ists dann eine andere FP-Implementierung als im Basic ... platsch.H.
