Posts by WTE

    Also ich habe zwei Examplare (unterschiedliche DOS Versionen). Von "im Einsatz" würde ich aktuell aber nicht reden wollen.
    Als ich damals vor der Wahl stand FD-2000 oder FD-4000 habe ich mir gedacht: wenn schon, denn schon! ;-)
    So eine FD-4000 hatte ja die "gefühlte" Kapazität einer Festplatte (die CBM D9060 hatte auch "nur" 4 MB).

    Die Disketten waren halt deutlich teurer und man bekommt sie heute nicht mehr. Aber ich habe heute noch ein paar unbenutzte rumliegen.

    Meist benutzte ich dann doch einfache 1,6MB-Disketten (1,44 MB am PC), da war der Datenaustausch mit PC einfacher.

    1581 Disks kann man lesen, schreiben würde ich nicht empfehlen, da weiß man nicht, ob das jede 1581 noch erkennen kann (wobei ich dazu keine Experimente durhcgeführt habe).

    Dein Beispiel aus dem Handbuch bildet nicht ein komplettes Bedingungsgefüge ab (der ELSE-Zweig hat kein Ende! Das ist eher sowas wie IF..THEN..ELSE auf einer Zeile.)

    Das Beispiel ist aus dem C128-Handbuch und auch wenn ich, wenn ich das Beispiel selbst geschrieben hätte, jeweils einen vollen THEN- und ELSE-Block verwendet hätte, ist es gerade so wie im Handbuch beschrieben besonders deutlich wie es funktioniert. Und damit ist es letztlich das bessere Beispiel.


    Zu Deiner Kritik:

    Der ELSE-Zweig hat nicht nur kein Ende, er hat auch keinen Anfang! Und ohne Anfang braucht er auch kein Ende. Die BEGIN...BEND-Struktur ist nur erforderlich, wenn der THEN und/oder ELSE-Zweig über mehrere Zeilen geht. Ist das nicht der Fall braucht es keinen Block. Sowohl THEN als auch ELSE sind bzgl. der Verwendung eines Blocks vollkommen autark. Ich kann auch den THEN-Teil "blockfrei" gestalten und nur den ELSE-Teil in einen Block packen. Alles ok:


    100 If A = 1 THEN A=2
    200 ELSE:BEGIN

    300 A=0:BEND

    400 PRINT A


    Was Du machst, ist kein Block für THEN oder für ELSE, sondern einer für IF. Da die Übersicht zu behalten bei DO und DONE dürfte für Programmierer tatsächlich ein Problem sein. Ich würde davon abraten.

    Um es schwieriger zu machen :D , hat GoDot einzeilige IF THEN ELSE (also alles in einer Zeile) mit eingebaut. Die fallen aus der DO...DONE-Struktur heraus.

    Naja, die hab ich schon berücksichtigt. Aber ich merke gerade, dass die ganze Struktur daran hakt, dass DO...DONE, also was "implementiert ist", folgendermaßen (nicht) funktionieren soll:


    if... then do
    else
    done


    was implementiert werden müsste, um so einen Murks zu verhindern wäre


    if... then do

    done: else do

    done


    Dann wäre jeder Block für sich abgeschlossen und man käme beim Zählen nicht durcheinander, weil immer klar ist, die ELSE kommt nach dem Ende des IF-Blocks


    So macht es auch Basic 7 mit BEGIN und BEND. Erkennbar am Beispiel aus dem Handbuch:

    pasted-from-clipboard.png


    Die aktuelle TSB-Testimpementation nutzt ELSE hingegen wahlweise als ein "DONE:ELSE:DO" Äqivalent. Nur kann man das der ELSE ja beim Schnelldurchlauf nicht anmerken.
    Und was passiert, wenn nach dem ELSE gar kein Block benötigt wird?

    Also ich würde die Basic 7-Methode verwenden, die hat zumindest schon mal jemand zum Laufen gebracht! ;-)

    Natürlich haben die keine Dateiendung. Sowas gibt es ja auf C64/C128 auch nicht.

    Die LZH-Archive enthalten die C128-Dateien, so wie sie auf einer 1541-Disk enthalten sind. Das LZH wurde wohl auch auf einem C64/128 erstellt.

    Auf dem PC nimmst Du ein Tool wie DirMaster (o.ä.) [ https://www.c64-wiki.de/wiki/Liste_von_Disk-Image-Tools ] erstellst dort ein Image und kopierst die Files aus dem LZH da hineien. Schon ists fertig!

    Ist nicht vielleicht einfach das Beispiel Murks?
    Sehe ich das falsch oder ist hier der Block nicht richtig definiert?

    Nochmal zur Verdeutlichung mein konkretes Testprogramm:

    Das rote "else" sollte doch zum roten "if...then" gehören. Dazwischen gibt es das gleiche in blau.

    Zum blauen "if...then" gehört ein "do" zu dem in Zeile 180 ein "done" gehört. Der erste (rote) "if"-Block müsste vor dem roten "else" jetzt ebenfalls mit einem "done" abgeschlossen werden. Wo ist das?


    Edit: Oh, Mist, die Farben verschwinden nach dem Posten (hätt: ich mir ja denken können).

    Also "rot" meint Zeile 110 und 190, "blau" meint Zeile 150 und 165. Es fehlt z.B. in 162 ein "done".

    Wieso erinnert mich DO...DONE an das BEGIN BEND vom C128? [Einfach mal da in den Code schauen!]
    Also um das DO...DONE zählen kommt man nicht herum. Wieso auch? Ist nur logisch!

    Und das ELSE bleibt natürlich erforderlich, sonst würden ja beide Zweige den weiteren Code durchlaufen (aber das wurde ja schon erwähnt).


    EDIT: Hätt' ich mir ja denken können, das Mac Bacon mit der einzig richtigen Antwort viel schneller war. ;)

    Warum denn bei ELSE hochzählen? Zähl bei DO hoch und bei DONE runter, dann ist jedes bei Zähler <> 0 gefundene ELSE in einer tieferen Ebene und somit zu ignorieren.

    Wenn du meine Beiträge genau gelesen hättest, dann hättest du die zwei Dokumente von MOS aus dem Jahr 1975, die ich eingestellt habe, gesehen und auch lesen können, die genau die Aussage von Peedle und Mensch bestätigen. ROR spielt zu diesem Zeitpunkt keine Rolle, wird mit keiner Silbe erwähnt.

    Es gab mal eine Zeit, da hat man erst das Produkt gehabt und dann die Dokumentation erstellt... Kannst Du Dir das (heute) vorstellen?

    War nur als witzige Anmerkung gemeint, weil Du das Leerzeichen nicht einmal am fixen Testbaustein anhängst sondern vor jeder Varianz erneut einsetzt. Sieht nach einer Optimierungsmöglichkeit aus. ;-)

    Ich habe mal mit so einer Größenoptimierung rumgespielt. Die durchsucht alle konstanten PRINT-Texte, findet gleiche Teile und zieht diese in eine extra Konstante raus. Die muss dann natürlich in einem zusätzlichen PRINT-Aufruf landen, so dass sich das nur ab einer bestimmten Länge lohnt. Das bringt in diesen inh4.prg etwas über 400 Bytes. Nicht viel, aber immerhin. In den Konstanten sieht das dann z.B. so aus:

    In Deinem Beispiel verschwendest Du 2 Bytes!

    Das glaube ich erst, wenn ich zwei Vergleichprogramme mit gemessener Geschwindigkeit sehe.

    Natürlich hat der Z80 mächtige Befehle, die aber auch mächtig langsam sind.

    So ist das mit der Erinnerung. ;-) Ich habe mir das ganze jetzt mal im Emu angeschaut und es gab auch ein Vergleichprogramm.

    Die Blockbefehle sind sehr komfortabel, aber leider nicht sehr schnell. Aber wenigstens bekommt man kompakten Code.

    Und damit habt Ihr recht. Der Code ist sehr kurz, die Ausführung jedoch deutlich langsamer. Was natürlich (auch) an der Kastration des Z80 im C128 liegt.
    [Unabhängig davon ist ein 6502 Abkömmling bei gleicher Taktrate (!) immer schneller als ein Z80.]

    einfach hier mal die Frage in die Expertenrunde, ob das, was Data Becker im Jahr 1986 zum C128 geschrieben hat, auch nach heutigen Wissensstand so richtig ist?

    Das war auch schon nach damaligem Wissensstand immer mal wieder grober Unfug. Ich habe denen damals mal einen Brief geschrieben, ob sie sich nicht schämen... Natürlich keine Antwort.

    Die 8502 hat mehr Rechenleistung als die Z80, was bedeutet, dass der einzige Grund, die Z80 zu verwenden eine Situation ist, in der man bereits vorhandenen Z80-Code nutzen möchtet.

    Ja, im C128 ist das so. Mit einer kleinen Ausnahme. Der Z80 hat - und ich muss das hier vorsichtig aus der verschütteten Erinnerung formulieren, denn ich bin nun alles nurt kein Z80-Experte - einige mächtige Befehle mir denen man größere Datenmangen bewegen kann. In solchen Spezialfällen ist der Z80 den 6502-Derivaten voraus. Ich habe irgendwo eine kleine Grafikdemo rumliegen, die genau dieses ausnutzt (also teilweise Z80-Code nutzt). Das ganze ist vom gleichen Autor wie Tool Basic [http://www.c128.net/download/toolbasic.htm]. Ich dachte ich hätte das schon mal irgendwo hier gepostet, kann es aber nicht wiederfinden. Da muss ich wohl mal in den Archiven wühlen...

    Meine Vermutung ist, dass es am Banking am C128 liegt.

    Zwischen Programm- und Variablen-Zugriff muss immer die Speicherbank umgeschaltet werden.

    Ich behaupte einmal, dass zusätzlich zu dem Punkt auch noch der komplexere Parser kommt. Es gibt viel mehr Befehle zu interpretieren, dauert eben länger...


    ein wenig einseitig, zumindest der auf Deinem Avatar abgebildete ;-)


    So mut dat: [Zwei 5 14-Zoll-Laufwerke im C128D]

    Wenn das jetzt als echtes Doppellaufwerk (Unit 8 mit Drive 0 und Drive 1) ausgeführt wäre, würde ich nicht nur den Hut ziehen, sondern mich auch noch dafür in den Dreck werfen, um Dir zu huldigen! :verehr:

    Ich bin hier im 64er-Sonderheft 22 fündig geworden.


    Einem Programm den Namen "Doppel-Arsch" (Double-Ass) zu geben hat was. Bleibt hängen und klingt zeitlos! :thumbsup:

    Ich habe daraus die relevanten Seiten 66 bis 73 extrahiert und als PDF hier angehängt.


    Zudem ein D64-Image mit dem dort erwähnten Assembler von der entsprechenden Heftdiskette. :)

    So, dann habe ich erstmal mehr als genug zum Lesen und Auszuprobieren, sobald der C128 hier ist. :D

    Viel Spaß mit diesem Assembler. Ich habe nahezu alle meine Assembler-Programme auf dem C128 mit diesem Tool geschrieben. ;) Den Z80-Teil jedoch nie genutzt. :(
    Er hat leider einen kleinen Bug beim Anzeigen des Assenblierten Codes während des Assemblierens (er verschluckt da nach Pseudocodes manchmal Bytes) aber das ist ein reiner Anzeigefehler (nur etwas unschön, wenn man es für die Doku ausdrucken will).

    Viel Spaß mit dem C128!