In der "c't" (Ausgabe 11/1984) findet sich u.a. ein vierseitiger Artikel zur 6502-Programmierung:
Die vier Seiten als PDF im Anhang! 
"Zeit sparen mit 6502" (Artikel aus der "c't" Ausgabe 11/1984)
- Snoopy
- Thread is marked as Resolved.
-
Ich möchte ja behaupten, dass man mit selbstmodifizierendem Code noch ein paar weitere Taktzyklen einsparen kann, da LDA $xxxx,y einen Taktzyklus schneller ist als LDA ($xx),y (dafür ist der INC-Befehl dann langsamer, aber der wird ja nur jedes 256te mal aufgerufen).
PS: Ich schätze die Zeiten für die beiden Tests dann auf ca. 36700 und 53000 Taktzyklen.
-
In dem Artikel wird Bezug zu den Z80 Befehlen genommen. Ein LDIR ist einfach anzuwenden, aber auch beim Z80 gibts schnellere Möglichkeiten, siehe https://retrocomputing.stackex…fast-is-memcpy-on-the-z80.
-
Off topic: Mich würde sehr interessieren, wie die c`t damals gesetzt wurde. desktop publishing kam erst 1985 auf. wahrscheinlich noch gute alte Lichttischmontage. Dafür eigentlich innovatives Layout.
-
Off topic: Mich würde sehr interessieren, wie die c`t damals gesetzt wurde. desktop publishing kam erst 1985 auf. wahrscheinlich noch gute alte Lichttischmontage. Dafür eigentlich innovatives Layout.
Bei Design- bzw. Layoutfragen würde ich als erste Anlaufstelle hier im Forum Retrofan nehmen. Er kommt aus der "Grafikdesignecke".
-
Ich möchte ja behaupten, dass man mit selbstmodifizierendem Code noch ein paar weitere Taktzyklen einsparen kann [...]
Aber nur wenn der Code im RAM sitzt.
-
Eben. Hier geht es um eine universell einsatzbare Routine. Bei den damals verbreiteten Embedded-Systemens (EMUFs) wurde der Code auch mal ins EPROM gebrannt.
Außerdem, wenn die c't selbstmodifizierenden Code propagiert hätte. hätte ich damals sofort das Abo gekündigt.
-
Ich möchte ja behaupten, dass man mit selbstmodifizierendem Code noch ein paar weitere Taktzyklen einsparen kann [...]
Aber nur wenn der Code im RAM sitzt.
Pah. Nur weil das mit dem Selbstmodifizieren im ROM ein bissl schwieriger ist schon von vornherein aufgeben? Echte C64-Programmierer schreiben auch selbstmodifizierende ROM-Routinen! Jawohl!
Frag Chuck Norris, der macht das regelmäßig! 
-
Pah. Nur weil das mit dem Selbstmodifizieren im ROM ein bissl schwieriger ist schon von vornherein aufgeben? Echte C64-Programmierer schreiben auch selbstmodifizierende ROM-Routinen!
Es gab doch von "Data Norris" ein C64-Kombimodul, das EPROMs löschen, programmieren und ausführen lassen konnte.
-
Pah. Nur weil das mit dem Selbstmodifizieren im ROM ein bissl schwieriger ist schon von vornherein aufgeben? Echte C64-Programmierer schreiben auch selbstmodifizierende ROM-Routinen!
Es gab doch von "Data Norris" ein C64-Kombimodul, das EPROMs löschen, programmieren und ausführen lassen konnte.
Da kann man dann immer gleichen den gesamten Code modifizieren. Zumindest temporär.
-
Schon geil, dass man über einen 40 Jahre alten Code-Schnipsel einer Schleife diskutieren kann.
Wobei die letzte Fassung ja wirklich hübsch ist...
-
Schon geil, dass man über einen 40 Jahre alten Code-Schnipsel einer Schleife diskutieren kann.
Wobei die letzte Fassung ja wirklich hübsch ist...
Ich fand das schon ganz anregend. Ich bin ja nicht so der Optimierer und habe es gerne verständlich und gut lesbar.
Ich programmiere aber üblicherweise auch keine zeitkritischen Sachen.
Von daher nochmal ganz interessant.
-
Es gab doch von "Data Norris" ein C64-Kombimodul, das EPROMs löschen, programmieren und ausführen lassen konnte.
Was man nicht alles macht, um ein paar Taktzyklen einzusparen.
(Ich hatte mir das ja eher so vorgestellt, dass man einen Roboter programmiert, der den C64 aufschraubt, das ROM auslötet und das neue ROM einlötet. Und das alles mit Code, der sich auf eben jenem ROM befindet!) -
Off topic: Mich würde sehr interessieren, wie die c`t damals gesetzt wurde. desktop publishing kam erst 1985 auf. wahrscheinlich noch gute alte Lichttischmontage. Dafür eigentlich innovatives Layout.
In dem Video wird der ct-Workflow ab etwa Minute 37:00 beschrieben:
QuoteAndreas Stiller: "DTP bestand in der Schere"
[External Media: https://www.youtube.com/watch?v=v_6LA7KpRDg] -
Mich würde sehr interessieren, wie die c`t damals gesetzt wurde. desktop publishing kam erst 1985 auf.
In dem Video wird der ct-Workflow ab etwa Minute 37:00 beschrieben
So kenne ich das aus den frühen 80ern auch noch. Mit der Schreibmaschine den Text tippen, den dann zur Setzerei bringen. Von da dann einige Stunden später die Satzfahnen abholen, korrigieren und dann den Weg nochmal. Headlines in der Dunkelkammer mit dem manuellen Titelsatzgerät setzen und entwickeln. Fotos in die Litho, notfalls vorher mit dem Pinsel retuschiert. Dort wurden dann die Farbauszüge hergestellt – anfangs analog/fotografisch, später digital mittels Trommelscanner und Filmbelichtung. Am Ende kamen 4 Filme je Bild dabei heraus. Und am Leuchttisch wurden dann alle Filme zusammengeklebt (im Vierfarbdruck natürlich 4 Filme je Seite) und zu Druckbogen montiert. Danach ging es in die Druckplatten-Belichtung. Je nach Auftrag gab es vorab noch einen sog. Proof oder/und man stand früh morgens in der Druckerei (mit zumeist mürrischen Druckern) zur Druckabnahme und musste nach Farbkorrekturen persönlich die abgesegneten Bogen unterschreiben.
Heute mache in die Jobs alleine auf meinem Mac (habe dann aber auch das ganze Risiko und die Verantwortung) und schicke fertige PDFs an die Online-Druckerei. Ein paar Tage später kommen dann Pakete mit den Druckerzeugnissen zurück. Der ganze grafische Bereich wurde in meiner Lebenszeit komplett umgebaut. Was blieb, waren gestalterische Prinzipien und Kenntnisse und der kreative Prozess im Kopf, bevor es handwerklich wird. Aber das ändert sich ja auch gerade – "dank" KI.
