Beiträge von SuperIlu im Thema „z80 Assembler Anfaengerfragen“

    Aber eventuell noch folgende Korrektur:
    Wenn EADDR mitkopiert werden soll, muss man EADDR-SADDR+1 als Anzahl der zu übertragenden Bytes für BC setzen. Also nach dem SBC ein INC BC ergänzen.

    Danke, ich hab's mir mal als TODO rangeschrieben und werd erst einmal gucken was ich bei der Benutzung intuitiver finde (incl./excl. Endadresse).

    Jetzt mach ich mich mal an den I2C-Zugriff...

    ReTach,

    nach einigen Ausfluegen in die DOS-Welt und einem kurzen Urlaub hab ich mal wieder Zeit fuer den Z80 gehabt.
    Ich habe Eure Anregungen aufgegriffen und umgesetzt und will jetzt mal das Ergebnis praesentieren.

    Der Code ist zwar nicht unbedingt kleiner geworden, aber an einigen Stellen doch lesbarer/praegnanter.

    Danke nochmal
    Ilu

    Tut mir leid, das ich mich erdreistet habe, etwas Konkretes anzugeben statt vielleicht noch ein Buch zur Lektüre zu empfehlen...

    Du hast meine Antwort scheinbar falsch verstanden. Ich wollte nur meine Motivation und die Gruende fuer meine Art der Implementation darlegen und nicht kritisieren das Du Vorschlaege machst oder Alternativen anbietest. Ich bin Dankbar fuer Vorschlaege, ich moechte aber trotzdem darlegen wie und warum ich zu meinen Loesungen gekommen bin. Wenn meine Art der 'Diskussionsfuehrung' aneckt, dann tut mir das leid.


    Das ist ja üblich, dass Monitore eine Start- und Endadresse für einen Bereich erwarten. Das schließt ja nicht aus, dass man die Länge berechnen kann. Umständlich? Der Z80 hat doch 16-Bit-Arithmetik, wo das ziemlich unaufwändig geht, oder.

    Genau solche Infos hatte ich mir aus der Diskussion erhofft. Das SBC mit 16-Bit Registern war mir voellig entgangen weil ich in den Referenzen immer nach 'sub' gesucht habe. Mit der Info sieht Dein Vorschlag gleich wieder anders aus.


    [...] SPACE-Parsing [...]

    An Macros hab ich auch schon gedacht, 'Optimierungen' vertage ich aber auf 'spaeter' wenn ich die Funktionalitaet mal im Kasten habe. An die Version mit dem INC HL hab ich noch nicht gedacht, da muss ich noch mal genauer nachsehen. Auc hier gilt wieder: Ich hab nur meine Gruende dargelegt warum ich das mit der Unterfunktion nicht gemacht habe. Ich bin beim ersten Nachrechnen drauf gekommen das der Platzgewinn minimal bis nicht vorhanden waere und auch die Anzahl Codezeilen bei der SPACE Erkennung nicht sinkt. Ich wollte nur rausfinden ob Du evtl. noch mehr Potential siehst als ich.

    Danke fuer die Anmerkungen.

    Das Parsing der Argumente: da wiederholt sich die Überprüfung auf BLANK immer wieder. Das würde ich auch in ein Unterprogramm auslagern. Da kann man dann auch in einer Schleife auch mehrere Leerzeichen akzeptieren, was die Syntax etwas entspannt. Einen Fehler kann man ja mit dem Carry retournieren und individuell behandeln.

    Was wuerde das Unterprogramm im Ablauf verbessern? AFAIK verbraucht der SPACE-check 5-6 Byte, ein einzelnes CALL benoetigt schon 3 Byte, der bedingte Sprung wg. CF dann noch mal 2-3 Byte. Ausser der von Dir angesprochenen Funktionalitaet das ich auch mal mehrere SPACE weg'parsen' kann gewinne ich also nichts.
    Da ich auf absehbare Zeit der einzige Anwender fuer den Monitor bin kann ich auf die entspannte Syntax erst mal verzichten. Zumal ich das vermutlich eh sehr schnell mit Python scripten werde :)

    Beim Kopieren sollte man generell auch eine etwaige Überlappung berücksichtigen und entsprechend "von oben" oder "von unten" kommend übertragen, sonst artet eine solche Aktion in eine mehr oder weniger arge Datenvernichtung aus.

    Du hast voellig recht, ich schau mal das ich eine Fallunterscheidung fuer SADDR>DADDR und SADDR<DADDR einbaue. Ich sehe mich naemlich schon Fehler jagen wenn ich das das erste Mal falsch benutze. Da hab ich ein Haendchen fuer :)


    Beim Durchlesen der Frage fiel mir doch noch etwas zu der Endebedingung ein, weil ich das immer wieder gesehen habe bzw. auch für andere CPUs oft gilt: Für solche Schleifen am Besten einen Zähler für die Anzahl der Durchläufe (zu übertragenden Bytes) ermitteln. Denn kann man dann bequem runterzählen und relativ "billig" auf 0 überprüfen (wenn man nicht gerade LDIR und Verwandte verwendet)

    Bitte melde dich an, um diesen Link zu sehen. erwaehnte ja schon LDIR und LDDR. Die Kommandozeilensyntax mit SADDR und EADDR habe ich mir bei einem anderen Monitor abgeguckt und finde die recht nett so, deswegen habe ich mich fuer Endadressen statt Groessenangaben entschieden. Sowohl fuer die LDIR/LDDR, als auch fuer Deine Variante muesste ich jetzt die Endadresse erst "umstaendlich" in eine Groesse umrechnen.
    Dein Codebeispiel mit dec, ld und or habe ich an anderer Stelle (wo ich mit Groessen arbeite) genau so stehen :)

    ah danke, LDDR und LDIR waren mir bisher entgangen :)

    Literatur habe ich Offline und Online eine Menge, nur DEN passenden Befehl in einer 700-Seiten Referenz finden ist nicht ganz so einfach.
    Ausserdem warnt einen so ein Buch auch nicht vor Dummheiten *g*

    Moins,

    ich lerne grade Z80-Assembler am Beispiel eines ROM-Monitors fuer meinen Z80-Selbstbau.
    Dabei stosse ich hin&wieder auf Fragen wie man bestimmt Dinge am besten in Z80-Assembler implementiert.
    Aktuell: Ich habe eine Kopierfunktion die bekommt drei Adressen uebergeben (Start, Ende und Ziel) und soll jetzt von Start bis Ende laufen.

    Wie kann ich am besten das Endekriterium abfragen? Ich habe keine Moeglichkeit gefunden zwei 16-Bit Register mit einander zu vergleichen.
    Meine derzeitige Loesung siehtwie unten aus, geht das eleganter? :hae: