Hi,

ich möchte nach und nach immer 2 Hex-Zahlen auf dem Bildschirm ausgeben, ohne daß ich erst alles zwischenspeichern muß. Folgende Routine macht mir aber immer automatisch einen Zeilenumbruch nach den 2 Zeichen:

Code: Alles auswählen

   LDX   #iocb      ;open editor
   LDA   #$03
   STA   $0342,X
   LDA   #<device
   STA   $0344,X
   LDA   #>device
   STA   $0345,X
   LDA   #$08
   STA   $034A,X
   JSR   $E456

   LDX   #iocb
   LDA   #$09
   STA   $0342,X
   LDA   #<linebuf
   STA   $0344,X
   LDA   #>linebuf
   STA   $0345,X
   LDA   #<linebuflen
   STA   $0348,X
   LDA   #>linebuflen
   STA   $0349,X
   JSR   $E456
[...]

linebuf .dsb 2
linebuflen      = *-linebuf

device  .byte "E",0


Gibts dazu ne Möglichkeit, ohne jetzt den Framebuffer direkt beschreiben zu müssen?

Danke,
Klaus

Moin,

Du verwendest zum Schreiben von Zeichen den Befehlsparameter "9 - Put Record". Ein Record ist immer ein String mit EOL Markierung. Das OS fügt den ein, wenn Dein zu sendender String keine EOL Markierung enthält.

Verwende stattdessen "11 - Put Characters", dann wird´s klappen.

Gruß, Jürgen

Guter Tipp, das klappt soweit, nur bekomm ich jetzt gar kein newline mehr hin. Bei $0d $0a macht er mir jetzt die Sonderzeichen auf den Bildschirm. Muß ich dazu immer den Schreibmodus wechseln?

PS: Hier http://www.atariarchives.org/mapping/memorymap.php steht bei 11 "Put binary record (buffer)", das hatte mich zunächst irritiert.

Moin,

kbr hat geschrieben:Guter Tipp, das klappt soweit, nur bekomm ich jetzt gar kein newline mehr hin. Bei $0d $0a macht er mir jetzt die Sonderzeichen auf den Bildschirm. Muß ich dazu immer den Schreibmodus wechseln?

- EOL beim Atari 8-Bit ist hex $9B (dez. 155), ein einzelnes Zeichen, nicht CR/LF wie in der PC-Welt.

kbr hat geschrieben:PS: Hier http://www.atariarchives.org/mapping/memorymap.php steht bei 11 "Put binary record (buffer)", das hatte mich zunächst irritiert.

Nimm das deutsche Profibuch in der ABBUC-Version. Es enthält auch diesbezgl. genaue Hinweise und Hints.

Gruß, Jürgen

tfhh hat geschrieben:Moin,

kbr hat geschrieben:Guter Tipp, das klappt soweit, nur bekomm ich jetzt gar kein newline mehr hin. Bei $0d $0a macht er mir jetzt die Sonderzeichen auf den Bildschirm. Muß ich dazu immer den Schreibmodus wechseln?

- EOL beim Atari 8-Bit ist hex $9B (dez. 155), ein einzelnes Zeichen, nicht CR/LF wie in der PC-Welt.

äh ja, das hab ich bisher noch nirgends gelesen. In einer ATASCII-Tabelle stand das nur als invertiertes ESC drin. Das ist halt alles noch bischen Neuland für mich. Am Amiga, wo ich das erste mal programmiert habe, war es glaub auch schon $0d $0a.
Ich weis auch nicht, warum ich mir das alles noch antuh, der 68000er war da doch viel einfacher zu programmieren
Aber es reizt mich eben gerade...

kbr hat geschrieben:PS: Hier http://www.atariarchives.org/mapping/memorymap.php steht bei 11 "Put binary record (buffer)", das hatte mich zunächst irritiert.

Nimm das deutsche Profibuch in der ABBUC-Version. Es enthält auch diesbezgl. genaue Hinweise und Hints.

ja, werd ich mir anschauen, vielen Dank!

Vielleicht gäbe es hierzu ja sogar noch eine einfachere "putchar" Routine. Das wäre mir in dem Fall sogar lieber, als 2-byteweise über putstring zu gehen.

kbr hat geschrieben:Vielleicht gäbe es hierzu ja sogar noch eine einfachere "putchar" Routine. Das wäre mir in dem Fall sogar lieber, als 2-byteweise über putstring zu gehen.

Dann nimm zB mal folgendes (A mit dem Character laden und dann JSR PUTCHAR):

Code: Alles auswählen

PUTCHAR TAY
        LDA $E407
        PHA
        LDA $E406
        PHA
        TYA
        RTS


so long,

Hias

Das ist ja dreckig, warum nicht gleich JSR $F2B0?

Und das mit dem $9b macht mir gleich noch ne Leerzeile dazwischen

Klaus

kbr hat geschrieben:Das ist ja dreckig, warum nicht gleich JSR $F2B0?

Ab $E400 liegen die offiziell dokumentierten Einsprungtabellen (siehe auch Profibuch & co). Das funktioniert mit dem alten (400/800er) OS genauso wie mit allen neueren (XL/XE). $F2B0 o.ä. kann an die falsche Stelle springen.

Und das mit dem $9b macht mir gleich noch ne Leerzeile dazwischen :(

Das versteh' ich jetzt nicht ganz. Ich (und etliche andere) verwende diese Routine andauernd, ein "LDA #$9B" "JSR PUTCHAR" macht genau einen Zeilenvorschub (wie $0d / $0a am PC), keine Leerzeile dazwischen...

so long,

Hias

HiassofT hat geschrieben:

kbr hat geschrieben:Das ist ja dreckig, warum nicht gleich JSR $F2B0?

Ab $E400 liegen die offiziell dokumentierten Einsprungtabellen (siehe auch Profibuch & co). Das funktioniert mit dem alten (400/800er) OS genauso wie mit allen neueren (XL/XE). $F2B0 o.ä. kann an die falsche Stelle springen.

ok, und dass man die über die Rücksprungadresse im Stack aufruft, ist auch so dokumentiert?
Da stellt es bei mir, da ich im Sicherheitsbereich tätig bin, alle Nackenhaare auf...
Aber daran muss ich mich wohl gewöhnen, dass man absolute Adressen im Code während der Laufzeit überschreibt, war damals wohl auch normal.

Und das mit dem $9b macht mir gleich noch ne Leerzeile dazwischen

Das versteh' ich jetzt nicht ganz. Ich (und etliche andere) verwende diese Routine andauernd, ein "LDA #$9B" "JSR PUTCHAR" macht genau einen Zeilenvorschub (wie $0d / $0a am PC), keine Leerzeile dazwischen...

my fault, ich hatte an einer Stelle in die falsche IOCB geschrieben...

Moin,

kbr hat geschrieben:ok, und dass man die über die Rücksprungadresse im Stack aufruft, ist auch so dokumentiert?
Da stellt es bei mir, da ich im Sicherheitsbereich tätig bin, alle Nackenhaare auf...
Aber daran muss ich mich wohl gewöhnen, dass man absolute Adressen im Code während der Laufzeit überschreibt, war damals wohl auch normal.

Hmm, es wird doch nichts am Code geändert... der Beispiel-Code von Hias ist nur eine elegante und saubere Möglichkeit, einen indirekten JSR auszuführen - den kennt der 6502 leider nicht. Indirekt geht nur bei JMP, aber nicht bei JSR.

Es handelt sich jedoch nicht um selbstmodifizierenden Code und damit ist es "safe".

Gruß, Jürgen

tfhh hat geschrieben:Hmm, es wird doch nichts am Code geändert...

den meinte ich nicht, hab das an anderen Codes schon häufiger gesehen, daß man z. B. zum Kopieren von Speicherbereichen einfach die Adresse vom LDA Befehl incrementiert, und dann nochmal ausführen lässt. Sowas geht mit aktuellen Systemen gar nicht mehr, weil da der Codebereich nur read-only ist.

der Beispiel-Code von Hias ist nur eine elegante und saubere Möglichkeit, einen indirekten JSR auszuführen - den kennt der 6502 leider nicht. Indirekt geht nur bei JMP, aber nicht bei JSR.

Es handelt sich jedoch nicht um selbstmodifizierenden Code und damit ist es "safe".

naja, ich bin da halt generell skeptisch, wenn man mit Rücksprungadressen hantiert, das ist nämlich immer noch ein sehr verwundbarer Bereich...

Ich habs jetzt erstmal so gelöst, nachdem ich gelesen hatte, daß es genügt bei einem Byte die Länge auf Null zu setzen, und das Byte in A zu übergeben:

Code: Alles auswählen

putchar:
        TAY
        LDX     #iocb
        LDA     #$0B
        STA     $0342,X
        LDA     #0
        STA     $0348,X
        LDA     #0
        STA     $0349,X
        TYA
        JSR     $E456
        RTS


Find ich irgendwie doch eleganter, über die IOCB zu gehen. Die Länge bräuchte man vermutlich auch nicht bei jedem Aufruf neu setzen, aber sicher ist sicher.

Den Code von Hias werde ich aber auf jeden Fall im Hinterkopf behalten, für ganz einfache Dinge. Auf jeden Fall hab ich wieder viel dabei gelernt.

Klaus

tfhh hat geschrieben:Aber daran muss ich mich wohl gewöhnen, dass man absolute Adressen im Code während der Laufzeit überschreibt, war damals wohl auch normal.

Hmm, es wird doch nichts am Code geändert... der Beispiel-Code von Hias ist nur eine elegante und saubere Möglichkeit, einen indirekten JSR auszuführen - den kennt der 6502 leider nicht. Indirekt geht nur bei JMP, aber nicht bei JSR.[/quote]
Um genau zu sein handelt es sich bei dem Konstrukt um einen indirekten JMP. Am Stack liegt die Rücksprungadresse zum eigenen Code, der PUTCHAR aufruft. Das RTS in PUTCHAR springt nur zu der Adresse (+1) die vorher per PHA auf den Stack geschrieben wurde. Eine Rücksprungadresse zum PUTCHAR Code liegt nicht am Stack, das RTS in der Editor-Put-Routine kehrt dann also zum eigenen Code zurück (zur Instruktion nach dem JSR PUTCHAR).

Die 16-Byte Treiber Tabelle ist so ausgelegt, daß man das "PHA PHA RTS" Konstrukt verwendet (das OS macht das auch so), mit einem indirekten JMP zu den abgelegten Adressen klappt's nicht:

Beim 6502 wird bei einem JSR die Rücksprungadresse Minus 1 auf den Stack gelegt, das RTS lädt die Adresse vom Stack in den Program Counter, inkrementiert dann den PC um 1 und setzt den Programmablauf wieder bei der richtigen Adresse fort. Ist halt eine Eigenheit des 6502 die man wissen muss (ist aber auch im MOS 6502 Hardware Manual dokumentiert) und liegt am internen Aufbau des 6502.

so long,

Hias

Vielen Dank für die ausführliche Erklärung.

Mir war das allerdings schon bewusst, sonst wäre ich ja nicht auf die $F2B0 gekommen

Klaus