OT aus LocoBasic vs. Basic 3.5/7.0: Vergleiche Schneider CPC vs. C64, Demo´s, Rasterinterrups usw.

Zitat von oobdoo

Wobei man bei Z80 nicht vergessen sollte, der Registersatz ist doppelt vorhanden und läßt sich mit einem Befehl umschalten.

Beim CPC allerdings nur, sofern man auf das Betriebssystem verzichten kann. Dieses legt in den Schattenregistern Werte ab, die es benötigt z. B. für die schnelle Abwicklung der Interrupts.

Zitat von oobdoo

Wenn ich meiner Exceltabelle trauen kann, dann hat der Z80 2536 Befehle einschließlich der undokumentierten.

Ja, und darunter sind so tolle wie RLD und RRD. Was bei den 2536 Befehlen dafür fehlt sind z. B. "CLC" (Clear Carry) oder "SUB HL, <reg>". (Es gibt "ADD HL, <reg>", "ADC HL, <reg>" und "SBC HL, <reg>", aber kein "SUB HL, <reg>". Wer denkt sich bloß sowas aus?)

Zitat von Tale-X

Und dass sich der CPC angenehm in ASM programmieren lässt, kann ich schwer bestreiten - wenn ich mir so anschaue, was der Z80 an Registern und Funktionen bietet und das mit dem 6502 vergleicht... da ist der 6502 gelebte Askese.

Nun ja, das ist Ansichtssache. Zwar hat der Z80 auf den ersten Blick mehr Register, jedoch können diese nicht universell eingesetzt werden. Ein Nadelöhr ist der Akkumulator A, über den alle 8-Bit-Operationen laufen müssen. Es gibt keine Möglichkeit ein anderes Register mit einem Wert zu vergleichen wie beim 6502, z. B. cpx #12. Daraus wird notgedrungen ein: LD A, <reg>:CP 12. Man muß also stets dafür sorgen, daß A frei ist und kann dort, anders als beim 6502, Werte nicht über einen längeren Zeitraum ablegen.

Zitat von Tale-X

die einzige Möglichkeit, ohne selbstmodifizierenden Code

Wer auf einem 6502 (oder auch Z80) keinen selbstmodifizierenden Code verwendet, ist selber schuld.

Zitat von Tale-X

dann ist der Zähler gerade im falschen Register

Nein, mit ein bißchen Erfahrung kann man dies meist vermeiden. Da die Adressierungsart "STA (zp), y" eben nur mit Y funktioniert ("STA (zp, x)" ist ein Witz), wird man von vornherein darauf achten, daß das Y-Register den Index für diese Adressierungsart bereithält. X nimmt man folglich dann vermehrt als Zähler oder temporären Zwischenspeicher usw.

Zitat von ogd

Hast du auch praktische, nicht triviale Beispiele aus der Realwelt, die diese oft behauptete These belegen?

Beispiele? Na klar. Ich habe aus Spaß den Parser aus meinem Adventure auf den CPC portiert. Läuft dort tatsächlich schneller, und der Code ist auch kürzer. Zur Zeit schreibe ich an einem anderen Programm, bei dem das Ergebnis ähnlich ausfällt: Code um 1KB kürzer und gleichzeitig schneller.

Zitat von ogd

Welche Demoeffekte gehen auf einem CPC besser (im Sinne von einfacher, unkomplizierter, schneller, atemberaubender ...)?

Zum Beispiel diese tolle Demo, bei der sich ein Objekt mit vier Farben in einer Auflösung von 320x200 Punkten dreht, wobei drei von den 4 Farben ständig blinken... Ach, das kann der C64 gar nicht, weil er a) keine Farbpalette hat, b) im 320x200-Modus pro 8x8 Kachel nur 2 Farben zur Verfügung stehen? Sowas... sowas... Mit anderen Worten: Demovergleiche zwischen verschiedenen Systemen sind schlicht Unsinn. Eine Demo dient dem Zweck zu demonstrieren, zu welcher Leistung eine ganz bestimmte Hardware fähig ist, mehr nicht. Daß sich typische vom C64 bekannte Effekte mit dem VIC auf einem CPC nicht nachbilden lassen, dürfte wohl logisch sein. Umgekehrt gilt es genauso. Um eine Demo richtig bewerten zu können, muß man also wissen, wie ein System funktioniert. Es hilft nichts zu sagen: Ich kenne den C64 und daraus schließe ich, daß die Demo für den CPC MIst ist (und umgekehrt).

Zitat von ogd

Die CPCs vor der viel späteren Plusmodellen beherrschen keinen Rasterinterrupt in engeren Wortsinne.

Ja, wenn man eine Defintion von vornherein so aufstellt, daß sie nur zu einem ganz bestimmten Sachverhalt paßt, kann man nachher schön sagen: "Schaut, es geht nicht." Daß auf dem CPC tatsächlich Rasterinterrupts möglich sind, zeigt z. B. das Spiel "Koronis Rift" (neben vielen anderen 3d-Spielen, die Double Buffering verwenden).

Zitat von ogd

Hier mal ein Vergleich zwischen C64 und Spectrum

Okay, hab mir den Text mal durchgelesen. Was sofort auffällt: Der Autor schreibt zwar "a number of code snippets were compared.", benennt aber nicht konkret, welche Programme er da untersucht hat. Eine etwas dubiose Vorgehensweise. Formulierungen wie "Absolute operations (ADC #$21) are significantly faster (2 cycles on 6510 vs. 7 on Z80)." sind zumindest fragwürdig. Wenn der Z80 viermal schneller getaktet ist als ein 6502, absolviert er die 8 Takte also im Vergleich zum 6502 sogar in weniger als 2 Zyklen (, die auf dem CPC dann aufgrund der Hardware auf 2 bzw. 8 gestreckt werden).
Des weiteren bezieht der Autor in seinen Untersuchungen das Suchen und Vergleichen von Strings mit ein. Aber welches zeitkritische Programm (sprich: 3d-Spiel oder allgemein Actionspiel) verwendet denn Stringoperationen? Diese Untersuchung hat überhaupt keine Relevanz. Selbiges gilt auch zum großen Teil für die meiner Ansicht nach völlig überschätzten Kopierbefehle. In einem Spiel gibt es (mit Ausnahme des Scrollings) in der Regel kaum Möglichkeiten, diesen Befehl sinnvoll einsetzen zu können. So werden z. B. Shapes nicht direkt in die Graphik gehauen, sondern aufwendig mittels eines zweiten Maskenshapes in den Bildhintergrund gestanzt. Für ein 3d-Spiel ist dieser Befehl und damit die Untersuchung absolut irrelevant.
Keine Angaben macht der Autor ebenfalls, was er unter "fast-multiply" versteht. Ich kenne viele Wege, Zahlen zu multiplizieren. Welchen man nimmt, hängt von solchen Faktoren ab wie Häufigkeit in der Verwendung vs. Größe des freien Speichers. Für eine Routine, die nur paar Mal aufgerufen wird, lohnt es sich nicht, 1 oder 2 KB im Speicher für Tabellen et. al. zu verschwenden. Das ist eine individuelle Entscheidung, die man nicht verallgemeinern kann. Ich habe selbst (nicht nur) auf dem C64 eine Menge an 3d-Programmen gesehen, von denen einige mit guten 3d-Routinen ausgestattet waren (Elite) und einige mit absolut haarsträubenden (Freescape). Da liegt eine sehr große Bandbreite vor, die es unmöglich macht, daraus einen gültigen Mittelwert zu berechnen. Anders gesagt: Der ganze Untersuchungsansatz ist von vornherein schon mißlungen. Die Zahlen haben keine wirklich signifikante Datenbasis und bleiben zudem völlig ungeklärt. Diese Untersuchung erfüllt nicht im geringsten die Anforderungen einer soliden wissenschaftlichen Arbeit (sorry, ich bin hier etwas penibel). Auf solch einer Grundlage kann man wirlich alles schlußfolgern. Und nur noch so nebenbei: Wer ernsthaft glaubt, daß 3d-Spiele nur aus 3d-Berechnungen zum Malen von Objekten bestehen, glaubt auch, daß bei Spielen mit Scrolling allein das Scrolling zählt.

Fazit: Äpfel mit Birnen vergleichen lohnt sich nicht. Und ob man den Z80 oder den 6502 mag, ist schlicht Ansichtssache. Beide haben ihre Stärken und Schwächen. Da ich ursprünglich vom 6502 komme, möchte ich beim Z80 sehr häufig . Aber andersherum düfte es den an den Z80 gewöhnten Leuten beim Umstieg auf den 6502 ebenso ergehen. Ob ein Prozessor gut geeignet ist zur Programmierung, liegt oftmals allein an der Vertrautheit mit dem System und am richtigen Entwicklungstool. (Seitdem mein Assembler dank oobdoo auch Z80 versteht, fällt es mir jedenfalls wesentlich leichter, mal was für den CPC zu coden. )

Zitat von ogd

Der C64 hat im Multicolormodus drei Palettenregister.

Ich sprach vom 320x200 Bitmap-Modus. Du redest vom Zeichensatzmodus. Wie ich sagte: Äpfel mit Birnen.

Zitat von ogd

Was willst du dann vergleichen, etwa die Basicinterpreter?

Es gibt da so komische Dinge, die nennt man Programme, auf neudeutsch "Applikationen". Demos sind wahrlich am wenigsten geeignet, weil sie viel zu hardware spezifisch sind. Demos erfüllen außer dem Gutaussehen und Gutanhören keinen weiteren Zweck. Sie sind für den produktiven Einsatz eines Geräts völlig unbedeutend. Bei "ernsthaften" Programmen (und gerne auch ernsthaften Spielen) kommt es auf die Umsetzung von Algorithmen an. Für Programmierer ist es entscheidend, mit wieviel Aufwand sich ein Algorithmus X auf dem Rechner umsetzen läßt. Und in dem Sinne: Ja, man könnte sich ansehen, wie effizient sich ein Basicinterpreter auf der jeweiligen Zielmaschine gestalten läßt. Oder ein Compiler. Oder ein Wordprocessor. Oder ein Rollenspiel. Etwas Nichttrivales, das auf mehr beruht als Hardwareeffekte und unrolled-loops. Aber um das leisten zu können, müßte man a) schon sehr viel Know-How haben auf beiden Systemen, b) für beide Systeme unter gleichwertigen Bedingungen und gleichwertigem Einsatz die Programme entwickeln. Da für die Umsetzung von Spielen gleichen Namens auf dem CPC und dem C64 jedoch normalerweise andere Programmierteams eingesetzt wurden, entfällt auch hier eine faire Vergleichsmöglichkeit.

Zitat von ogd

Jetzt bin ich mal auf deine Definition gespannt. Wie gesagt, Polling zählt nicht. Und Bildwechselinterrupts wie VBI oder ähnbliches Gedöns auch nicht. Also was ist ein Rasterzeileninterrupt für dich?

Sofern die Möglichkeit besteht, einen Interrupt einzurichten, der zu einem bestimmten Zeitpunkt während des Bildschirmaufbaus regelmäßig aufgerufen wird, handelt es sich um einen Rasterinterrupt, d. h. ein Interrupt, der sich am Zeilenraster des Bildschirms orientiert. Wie feinmaschig dieser Interrupt gesetzt werden kann (jede Zeile oder nur ausgesuchte Zeilen), ist dabei irrelevant. Aber mir scheint, Du denkst zu sehr vom C64 her. Von daher wird Dich eine solche Definition kaum zufrieden stellen. Aber okay, wenn Du meinst, daß es auf dem CPC keinen Rasterinterrupt gibt, dann kannst Du mir sicherlich erklären, wie das Spiel "Elite" auf dem CPC es schafft, im 320x200 Modus mehr als 4 Farben anzuzeigen, und wieso zum Kuckuck die Farben plötzlich verschwinden, wenn das Spiel nachlädt und dabei alle IRQs ausschalten muß.