Ich habe mal Hires optional ergänzt. Das passt nicht für alle Bilder gut, manches wird sehr blockig, aber manches wirkt ganz gut. Die Bilder werden dann natürlich nicht im Koala-Format gespeichert, sondern im Hi-Eddi-Farbformat. Mit dem Unterschied, dass sie bei $6000 statt $2000 beginnen, aber das ist zumindest Hi-Eddi egal.
Beispiele Multicolor vs. Hires:
Hires
MC
Hires
MC
Hires
MC
Wenn man den Remote Image Viewer im Portal aufruft, bekommt man schon die neue Version.
Ich glaube sehr daran, dass eben Marketing und Bekanntheit sehr viel ausmachen würden.
Nehmen wir Sam's Journey. Wer kennt es? Wir, die jeden Tag mit der Bubble zu tun haben hier.
Für das ein oder andere Kleinst-Medium in diesem Dunstkreis hat es für einen Artikel gelangt.
Das ist ein super Beispiel, wie ich finde. Als die NES-Version kam, dachte ich, das müsste in den USA steil abgehen. Ist aber nicht passiert. Das wirkt so, als hätte man das in einen(!) Onlineshop gestellt und dann das Beste gehofft. Ich habe bei keinem der großen NES-Youtuber aus USA was dazu gesehen. Wenn man nach einem Reviewvideo sucht, dann kommt (im Inkognitomodus gesucht) mein Video dazu an erster Stelle. Und das ergibt so gar keinen Sinn. Da wäre mit gutem (oder überhaupt...) Marketing sicher mehr drin gewesen.
Display MoreZu einem gewissen Grad hängt das auch von den Optimierungsfähigkeiten eines Compilers ab.
Ein
IF A>0 AND A < 40 THEN ...
wird mit
IF A>0 THEN IF A < 40 THEN ...
auch bei jenen Compilern schneller, die nicht eine bedingte Auswertung erkennen und von sich aus die Kaskade wie im 2. Beispiel erzeugen.
Das macht keiner, nicht einmal meiner. Ich habe es mal versucht, aber das Problem ist, dass in BASIC V2 nicht unterschieden wird, ob logisches AND oder bitweises AND "gemeint" ist. Hier hatten wir das mal diskutiert: Die Fehler des Basic V2
Display MoreHallo Leute,
was mich mal interessieren würde: Wenn ich meinen Basic-Code optimiere und diesen dann durch einen Compiler übersetzen lasse. Ist der Maschinencode dann auch schneller, als wenn man einen nicht optimierten Code durch einen Compiler übersetzen lässt?
Liebe Grüße!
ThomBraxton
In den meisten Fällen nicht.
mir ist da noch nie einer abgegangen.
Kann auch nicht, falls man den Knüppel als Rechtshänder mit Links bespielt.
Ich hab mir das mal angesehen. Dein Algo arbeitet natürlich ganz anders, mit Peek & Poke lässt sich natürlich saumäßig viel gewinnen. Trotzdem "Danke!" für das Beispiel!
Ja, das Ding ist ein bisschen merkwürdig, aber es sieht dafür nett aus. Ist auch nicht von mir, ich weiß nicht mehr, wo ich das her habe.
Die FOR T ist derzeit die schnellste bekannte Möglichkeit (Zähler sind immer langsamer). Kannst gerne austauschen, wenn deines schneller ist nehme ich das gerne auf.
(Ich hatte mit Zählern getestet, war langsamer bei allen Tests) Außerdem kann man überall NEXT reinwerfen ohne GOTO zu benutzen.
(ungetestet ist es schnller als GOSUB - vielleicht nicht in allen Fällen, aber 90% in der Hauptschleife)
Angeblich sind FOR NEXT Schleifen in FOR NEXT noch schneller (habe ich nur mal ganz simpel geprüft, weiß aber nicht warum sie wirklich schneller sind)
Ja, klar kannst du ein FOR und 35 NEXTs haben und auch anders herum. Weil FOR und NEXT im BASIC V2 unabhängige Befehle sind, die quasi "aus Versehen" eine Schleife bilden, weil sie auf demselben Stack rumorgeln. Meine Anmerkung bezog sich eher darauf, dass das den Code unleserlicher und unverständlicher macht. Mag sein, dass es für diesen Fall schneller ist.
Wieso hast Du EgonOlsens Cross-Compiler ausgelassen?
Weil der als Cross-Compiler nicht in sein Beuteschema fällt ... 
Ich habe für meine Tests ein eigenes QSORT-Beispiel im Bestand, das dürfte von den Performancecharakteristiken (geiles Wort, wenn man das so ausgeschrieben sieht...) natürlich ziemlich anders sein, aber ich hänge das dennoch mal an. Auf dem Image sind die Ergebnisse diverser Compiler zu finden.
Was macht eigentlich das FOR T in Zeile 1? Wenn ich das richtig verstehe, dann soll die das Spielende nach 2000 Durchläufe einläuten, oder? Ich würde die entfernen und durch einen einfachen Zähler ersetzen. So wie es jetzt ist, ist das ziemlicher BASIC-Spaghetti-Code mit GOTO-Sprüngen innerhalb der Schleife und zwei NEXTs, je nach dem, welcher GOTO-Pfad eingeschlagen worden ist.
(was könnte man noch ändern um es schneller zu bekommen?)
Kompilieren halt ...
Also ich habe eine DD Diskette genommen war früher eine Amiga Diskette. So formatieren probiert oder auch mit Greaseweazle ein Demoscene Image vorbereitet. Leider keine Chance das er sie laden kann. Das Laufwerk hat keine Gummiriemen. Rattern wie ein Diskettenlaufwerk rattert tut es auf alle Fälle.
Hast du es mal offen betrieben und geschaut, ob sich der Kopf bewegt?
Wenn ja, kann es an der Drehzahl liegen oder der Schrittmotor muss neu justiert werden. Oder, wenn es ein doppelseitiges Laufwerk ist, kann es auch sein, aber der obere und der untere Kopf nicht mehr richtig zusammenfinden.
Bei einem Direktantrieb ist oft auf der Platine neben dem Motor ein kleiner Kondensator. Der läuft bei manchen Modellen gerne mal aus oder geht anderweitig kaputt. Manchmal reicht es, den zu tauschen.
Schrittmotor und Kopf kann man mit viel Zeit und einer richtig beschriebenen Diskette (also einer,.von der man weiß, dass sie in einem funktionierenden Laufwerk beschrieben worden ist) ohne weitere Hilfsmittel justieren. Beim Schrittmotor kann man die Schrauben lösen, die den festhalten und ihn ein kleines Stück drehen (und wieder leicht festdrehen). Dann gucken, ob das was besser macht. Wenn nicht, weiterdrehen oder in die andere Richtung drehen. Wenn es dann läuft, die Schrauben festdrehen ohne ihn wieder zu verdrehen.
Ist fummelig, besonders wenn man nach jeder Änderung wieder händisch auf Verbesserung testen muss. Kopf ausrichten ist noch fummeliger und kostet auch mal die ein oder andere Diskette das Leben (frag mich mal, woher ich das weiß...).
Petspeed müsste noch älter als 1982 sein, oder? Der Name sagt es ja schon, den gab es für die PETs ursprünglich.
Der Basic-Boss schaut im Sortier-Test gar nicht gut aus ohne Optimierungen, wie ich finde. Selbst der Basic64, der ca. 1985 war, schlägt den Boss, selbst im P-Mode und auch Austro, ursprünglich auch für PET, ist schneller.
Das Compilat vom Petspeed ist deswegen so groß, weil der ja sämtliche Variablen und Felder mitschleppt.
Petspeed ist ziemlich gut bei Arrayzugriffen. Und Basic-Boss ist im Verhältnis eher langsam bei Arrayzugriffen. Vermutlich kommen die Unterschiede daher.
Bin auch erst am Anfang wie der Atari ST so funktioniert. Hab zwei zu Hause. Einen habe ich komplett gereinigt. Bei einem läuft das Diskettenlaufwerk wohl problemlos an, kann jedoch keine Disketten lesen. An den Disketten liegt es nicht. Kann jemand von euch so ein Atari ST Diskettenlaufwerk reparieren?
Es gibt einseitige und doppelseitige Laufwerke für den ST. Wenn du eine doppelseitig beschriebene Diskette in einem einseitigen Laufwerk lesen willst, dann klappt das nicht. Nur so als Hinweis, vielleicht ist es ja einfach das. Ansonsten sind die Laufwerke mechanisch nicht wirklich anders als PC- oder Amigalaufwerke. Manche haben Direktantrieb, andere Gummiriemen. Wenn der kaputt oder ausgeleiert ist, klappt auch nichts. Das könntest du auch prüfen.
Display MoreDas Bild unten zeigt ein Beispiel:
1. Oberes Teil vom Bild ist der Speicherbereich bevor ich was eingebe.
2. Dann kommen die Assemblerzeilen:
$07eb lda #$00
$07ed sta $d021
$07f0 sta $d020
$07f3 rts
Also soweit keine Hexerei. Ein SYS 2027 und Bildschirmfarben werden blau {nicht unter COMAL, das ist nur als Beispiel damit es klar wird wo das Problem von Zuverlässig ist}
Allerdings, wenn man den Bereich direkt nochmals auflistet, dann ist $07eb lda #$00 nicht mehr vorhanden!
Unteres Teil vom Bild.
Auch ohne COMAL Modul passiert das, somit kann nur gesagt werden, das VICE hier ein Problem hat {es sein denn es geht in die 'das ist halt so' Kategorie}
Wenn ich bei $07e8 anfange, dann wird der Code korrekt angenommen.
Praktisch muss ich immer schauen wie der 'zuverlässiger' Speicherbereich aussieht bevor ich was mache, bzw. die Startadresse bestimmen kann.
Nein, du interpretierst das falsch. Der Disassembler weiß ja nicht, welche Bytes ein Befehl sind und welche nicht. Die 00 in $07e8 und $07e9 sieht er als BRKs, $FF $A9 $06 ab $07ea dann als (illegalen) Opcode ISB. Damit "verschluckt" er quasi dein LDA #$06. Das ist aber mit $A9 $06 schon noch da, nur jetzt eben verpackt in $FF $A9 $06 und vom Disamembler nicht richtig angezeigt. Wenn dein Programm ab $07eb anfängt, dann solltest du auch ab dort den Disassembler aufrufen und nicht einfach ein paar random Bytes vorher. Dann hängt es vom Inhalt dieser Bytes ab, was er dir anzeigt.
Display MoreNaiverweise dachte ich, dass es so "hochoptimierende" Compiler gab oder zumindest heutzutage gibt.
Aber da ist wohl tatsächlich zu viel Wunschdenken mit dabei.
Danke jedenfalls für alle Hinweise und Anmerkungen!
Bei MOSpeed ist das auch FAST so. Allerdings linke ich immer den Code für das Initialisieren der Variablenbereiche dazu, auch wenn es gar nichts zu initialisieren gibt.
Edit: Und die von der Runtime verwendeten Speicherbereiche für virtuelle Register und so Gedönse hängen auch immer mit dran. Wenn du von Hand Assembler schreibst, kannst du natürlich auf den Einzelfall hin programmieren. Das ist immer kürzer als eine generische Umsetzung von BASIC in irgendwas.
Das ist auch wieder unterschiedlich. Bei manchen Compilern (Austro-Familie, Basic64 im P-Mode) ist das quasi der Interpreter, bei anderen Compilern (da fällt mir der Petspeed mit 33 Blocks ein) eher eine Library. Wobei ich zugeben muss, mich mit dem Internas des Petspeed noch nie beschäftigt habe, ob der P-Code oder M-Code erzeugt. Könnte durchaus sein, dass das auch eine Runtime ist.
Petspeed ist auch P-Code. Ich würde das immer Runtime nennen, auch bei sowas wie Blitz!. Aber das ist Geschmacksache.
So wie ich es verstanden habe, schleppen viele Compiler eine mehr oder weniger umfangreiche Bibliothek o.ä. mit. So wird aus einem kurzen BASIC-Progrämmlein mit 1 Block ratzfatz ein PRG mit 16 Block oder mehr. Und dabei sollte man meinen, dass Machinenspracheprogramme eher kürzer sind.
Wenn du die von Hand schreibst, dann vielleicht. Aber als Kompilat eher nicht. Eine Runtime brauchst du immer, selbst der oben erwähnte Microcompiler hat eine kleine Runtime. Wie soll das sonst gehen? Du musst ja Dinge tun, die ansonsten der Interpreter bzw. der Kernal tun würde. Das kompilierte Programm ruft natürlich ROM-Routinen auf, aber das kann es ja nicht direkt sondern muss dafür Dinge vorbereiten. Garbage Collection, Variablenverarbeitung, FOR-GOSUB-Stack und solche Dinge wird das Kompilat je nach Implementierung auch autonom erledigen.
Ich dachte, es gibt deutlich mehr Compiler, die einfach BASIC -> PRG machen. Ist wohl nicht so üblich und mit Bibliotheken einfacher umzusetzen.
Was genau meinst du mit BASIC -> PRG? Das machen doch alle ... 
Sozusagen außer der Wertung, weil Cross-Compiling, ist der MOSpeed, der linkt, soweit ich das sehe, auch nur Libraries, die er auch braucht.
Ja, das ist so. Allerdings kommen da, wenn man sie nicht wegkonfiguriert, z.B. die eigenen Floatingpoint-Routinen mit rein und alleine die haben schon ein gewissen Umfang. In Snoopys Testprogramm aber nicht, weil MOSpeed die Variablen, ihre Zuweisung und die Berechnung wegoptimiert, so dass am Ende nur eine Kette von PRINTS mit Konstanten überbleibt und die braucht nicht so viel Runtime. Aber so wirklich repräsentativ für ein "normales" Programm ist das dann nicht. Wer misst, misst eben Mist ...
