Hi,

ich kriegs nicht hin und ich weiss nicht wieso.

Code: Alles auswählen

MODULE
BYTE ARRAY DLI=[70 70 70 42 00 00 42 00 00 42 00 00 41 00 00]

PROC MAIN()
 CARD DLIPTR=560
 CARD C
 CARD POINTER PTR

 PTR=@DLI ;setze PTR auf die adresse von DLI
 PTR=PTR+13 ; ich will die beiden letzten bytes der DLI auf die Adresse der DLI setzen (Rücksprung) daher Zeiger 13 Bytes vorrücken
 PTR^=DLI ; geht nicht, wenn ich das Array anzeige sind die beiden letzen Bytes immer noch 00 00

 DLIPTR=DLI ;das scheint zu gehen (OS Pointer auf die Adresse meines DLI.Array legen, die DLI wird angezeigt
RETURN


ich habe auch schon
C=DLI
PTR^=C
versucht. Geht auch nicht.

Was mache ich falsch?

Ich habe nicht wirklich verstanden, was du vorhast.
willst du den Wert aus 560 in den letzten zwei Bytes des Arrays speichern?

Code: Alles auswählen

PTR^=DLIPTR

Oder woher nimmst du die Rücksprungadresse?

Ich programmiere zwar nicht Action, aber hier würde ich einen Compile-Error in der Zeile PTR^=DLI wegen Typ-Inkompatibilität erwarten. PTR^ ist ein Pointer auf ein CARD, zeigt aber in ein BYTE-Array. Aber ACTION ist wahrscheinlich nicht typsicher?!?

Also evtl. Low- und Hibyte getrennt zuweisen. Oder besser den Array per Index-Zugriff ändern (warum mit Adresspointern hantieren, wenn es nicht sein muss). Es könnte ja schließlich sein, dass ACTION den Array intern anders speichert - z.B. die Länge als die ersten beiden Bytes des Arrays im Speicher. Da Du den Inhalt als DL verwenden willst, musst Du die genaue Organisation des Arrays im Speicher kennen.

Die Zuweisung PTR=@DLI muss evtl. durch PTR=DLI ersetzt werden. Möglicherweise ist nämlich DLI schon die Adresse des Arrays (einen "einfachen Wert" für DLI gibt's ja nicht). Dasselbe würde ich auch für Strings erwarten. Lass Dir am besten die Byte-Werte ab PTR und DLI mal ausgeben.
Gerade sehe ich's: Unten steht ja schon DLIPTR=DLI. Da das funktioniert, ist DLI also tatsächlich bereits die Adresse des Arrays, @DLI ist also unnötig.

Außerdem würde ich in der Deklaration
BYTE ARRAY DLI=[70 70 70 42 00 00 42 00 00 42 00 00 41 00 00]
die Werte als Dezimalzahlen ansehen - gemeint sind aber offensichtlich Hex-Zahlen?!?

Und schließlich ist eine solche DL gefährlich, da sie potentiell die 1K-Grenze überschreitet, womit Überraschungen vorprogrammiert sind. Besser also eine feste Adresse für die DL vorsehen. Oder wenn das nicht möglich ist, Abfrage-Direktiven einsetzen, z.B. mache ich das in meinem 6502-Code bei DLs immer so (bei Display-Daten analog für die 4K-Grenze):

DLSTART
; hier kommt die DL
.if */1024 <> DLSTART/1024
.error "DL kreuzt 1K-Grenze"
.endif

Gruß Dietrich (der lieber Assembler programmiert)

Hi,

ja, die Zahlen sollen Hex sein, habe die $ vergessen. Macht aber hier fürs Beispiel nichts.

Pointer in Action

sei $4000 der Beginn des Programms
BYTE POINTER ptr ; Zeiger auf BYTE
BYTE NUM ; ein Byte namens Num

NUM=0 ; NUM ist nun 0
PTR=NUM ; PTR enthält nun den Wert von NUM und zeigt auf die Adresse (Wert von Num) PTR zeigt also auf $0000
PTR=@NUM ; PTR enthält nun die Adresse von NUM , also $4002
PTR^=50 ; schreibt 50 in die Adresse, auf die PTR zeigt, also $4002, d.h. NUM ist nun 50

soweit zur Syntax.

Arrays werden wie Pointer behandelt. Sagt man
PTR=DLI wie im Programm ganz oben, enthät PTR die Anfangsadresse von DLI
das kann man auch machen mit PRT=@DLI, macht keinen Unterschied.

Dem Pointer ist es egal, ob er ein BYTE- oder CARD-Pointer ist und auf was er zeigt (in diesem Fall ein BYTE ARRAY).
CARD Pointer schreiben daher 2 BYTES wenn man PTR^=zahl macht

Das mit der 1k Grenze war mir bekannt, macht aber hier im Beispiel auch nichts, weil ja nicht mal die Werte ankommen.

Ziel des ganzen war es, möglichst einfach die Anfangsadresse der DLI in die beiden letzten Werte zu schreiben, damit per Sprung+Warten-Befehl ($41) der DLI-Befehlszeiger wieder an den Anfang springt.

@EDA: ich nehme die DLI Anfangsadresse vom ARRAY. Später kommt die per Befehl DLIPTR=DLI auch in den DLI-Pointer 560,561. Die CARD Variable DLIPTER habe ich per CARD DLIPTR=560 gesetzt.

@Dietrich: ich wünschte ich könnte auch Assembler so virtuos programmieren wie Du. Aber eigentlich kann ich wirklich gut nur TURBO-Basic. Selbst bei Action! muss ich immer viel nachdenken, wie man Sachen macht.

Das ganze sollte eigentlich eine DisplayListe mit Hor/Ver-Scrolling geben, mein erster Versuch. In GR.2 über 2*3 Bildschirme. Und später sollte dann mal Haunted House draus werden. Aber ob das jemals was wird wenn ich schon so früh scheitere?

FlorianD hat geschrieben:@EDA: ich nehme die DLI Anfangsadresse vom ARRAY. Später kommt die per Befehl DLIPTR=DLI auch in den DLI-Pointer 560,561. Die CARD Variable DLIPTER habe ich per CARD DLIPTR=560 gesetzt.

Ja, das habe ich gesehen. Wenn ich es richtig verstehe, willst du die Rücksprung-adresse in die letzten 2 Byte des Array speichern, oder?
Wo nimmst du die Rücksprungadresse?

eda70 hat geschrieben:

FlorianD hat geschrieben:@EDA: ich nehme die DLI Anfangsadresse vom ARRAY. Später kommt die per Befehl DLIPTR=DLI auch in den DLI-Pointer 560,561. Die CARD Variable DLIPTER habe ich per CARD DLIPTR=560 gesetzt.

Ja, das habe ich gesehen. Wenn ich es richtig verstehe, willst du die Rücksprung-adresse in die letzten 2 Byte des Array speichern, oder?
Wo nimmst du die Rücksprungadresse?

die Rücksprungadresse ist die Startadresse der DLI, also auch die Startadresse des Arrays.

Hi,

warum das nicht geht habe ich auch nach langer Tüftelei nicht rausgefunden.
Aber eine Lösung entdeckt.

Ich mache eine leere Procedure auf und lege einen Codeblock rein.

Code: Alles auswählen

PROC DLI()
[$80 $80 $80 $42 $0 $0 $2 $2 ... $2 $41 $0 $0]
RETURN


und dann kann ich den DLI-Pointer setzen und auch Werte per Zeiger ändern

Code: Alles auswählen

CARD DLIPTR=560

DLIPTR=DLI


Viele Erkenntnisse habe ich gleich hier untergebracht:
http://wiki.strotmann.de/wiki/Wiki.jsp? ... ist_topics

es fehlt aber noch sehr viel im WiKi. Mag nicht noch wer helfen? Jeder nur 1 oder 2 Adressen und es ist viel geholfen.

@Florian: Wir können uns das ja auf der Fuji mal ansehen.

Leider kriege ich ACTION! auf dem Ultimate Utility Cartridge nicht richtig zum Laufen. Ich kann zwar ein Hello-World-Programm eintippen (PROC hello() PrintE("hallo") RETURN), aber nach Ctrl-Shift-M und COMPILE gibt's nur ein lautes Tröööööt, sonst passiert nichts - es wird kein Fehler oder OK-Meldung angezeigt.

Wiki: Ich weiß nicht recht, ob sich das lohnt. Ich habe es lieber auf Papier zum Nachgucken. Wenn schon, dann ein PDF-Dokument, dann drucken und mit Fadenbindung versehen, damit die Seiten auch aufgeschlagen liegenbleiben, wenn man am Tippen ist. Ich benutze (immer noch) ATARI intern von DataBecker, das ich handschriftlich mit allen Korrekturen und Infos versehen habe, die ich so brauche.

Gruß Dietrich (der noch nie ACTION programmiert hat)

Dietrich hat geschrieben:@Florian: Wir können uns das ja auf der Fuji mal ansehen.

Leider kriege ich ACTION! auf dem Ultimate Utility Cartridge nicht richtig zum Laufen. Ich kann zwar ein Hello-World-Programm eintippen (PROC hello() PrintE("hallo") RETURN), aber nach Ctrl-Shift-M und COMPILE gibt's nur ein lautes Tröööööt, sonst passiert nichts - es wird kein Fehler oder OK-Meldung angezeigt.

Wiki: Ich weiß nicht recht, ob sich das lohnt. Ich habe es lieber auf Papier zum Nachgucken. Wenn schon, dann ein PDF-Dokument, dann drucken und mit Fadenbindung versehen, damit die Seiten auch aufgeschlagen liegenbleiben, wenn man am Tippen ist. Ich benutze (immer noch) ATARI intern von DataBecker, das ich handschriftlich mit allen Korrekturen und Infos versehen habe, die ich so brauche.

Gruß Dietrich (der noch nie ACTION programmiert hat)

dann tipp mal nach dem "Tröt" "R" oder "RUN" ein dann sollte "Hello Kitty" o.ä. erscheinen.

Das INTERN finde ich so grauenhaft schlecht, dass ich es nicht mehr nutzen mag. Meins ist ebenfalls so mit Korrekturen voll, dass ich es kaum noch lesen kann. Ausserdem fehlen mir Beispiele und "die großen Zusammenhänge". Und dass die die Labels frech umbenannt haben, macht es auch nicht leichter. Daher nehme ich lieber das Wiki. (basierend auf Mapping the ATARI, und DeReATATRI, ...)

Fuji geht leider nicht, da bin ich nicht da (Auslandsreise)

FlorianD hat geschrieben:dann tipp mal nach dem "Tröt" "R" oder "RUN" ein dann sollte "Hello Kitty" o.ä. erscheinen.

Oh, der Tröööt ist gar keine Warnung/Fehler? Mist, da hätte ich auch selber drauf kommen können, beim Drücken von Ctrl-Shift-M trötet es ja schließlich auch.

Find ich etwas seltsam, das ACTION-Getröte - aber wahrscheinlich nur eine Gewohnheitssache

Die Umbenennung der ATARI-Labels in ATARI intern ist natürlich doof. Ich hab mir die richtigen Namen dazu geschrieben. Ansonsten fand ich das Buch gar nicht schlecht (abgesehen von den vielen Fehlern), es stehen einige Sachen drin, die in anderen Büchern gar nicht stehen, z.B. das Handling für nachladbare CIO-Handler. Erst dadurch bin ich darauf gekommen, mal den Code genauer anzuschauen und stellte fest, dass diese Handler sogar automatisch vom Lader reloziert werden. Coole Sache, die aber nie jemand benutzt hat, deswegen ist dieser Code im QMEG-OS auch nicht mehr drin.

Memory Map: Letztendlich sind im unteren RAM-Bereich gar nicht soviele Adressen wirklich wichtig, z.B. die genaue Bedeutung der Stellen 48-60 ist für den Programmierer uninteressant, da sie nur vom SIO temporär genutzt werden und gar nicht manipulierbar sind. Ähnliches gilt für die meisten Adressen von 67 bis 127, die nahezu alle nur intern temporär belegte Variablen des Screen-Handlers sind.

Es gibt auch mehrere Blinkwinkel für eine Memory Map:

1) Ich habe ein fremdes 6502-Programm und will es verstehen. Da hilft die klassische Memory Map (unter Weglassung aller Adressen, die nicht manipulierbar bzw. sinnvoll verwendbar sind). Nachteil: Manchmal ist die Beschreibung doppelt, da viele Speicherstellen zusammenhängen.

2) Ich will ein Programm schreiben und habe ein Thema und will alle Adressen wissen, die zum Thema gehören. Dann will ich eine Liste der relevanten Adressen mit Kurzbeschreibung genau zum Thema - und nicht die Memory Map von vorn bis hinten durchgucken müssen. Z.B. der Reset: Da sind wichtig: 2/3,8,9,10/11,12/13,1016 (mehr fällt mir jetzt nicht ein).

3) Ich will ein Programm schreiben und kenne mich nicht gut aus. Dann brauche ich eine Einführung in jedes Thema, d.h. relativ viel Text mit Beispielen und keine Liste von Speicherstellen mit Kurzbeschreibung.

Dietrich hat geschrieben:2) Ich will ein Programm schreiben und habe ein Thema und will alle Adressen wissen, die zum Thema gehören. Dann will ich eine Liste der relevanten Adressen mit Kurzbeschreibung genau zum Thema - und nicht die Memory Map von vorn bis hinten durchgucken müssen. Z.B. der Reset: Da sind wichtig: 2/3,8,9,10/11,12/13,1016 (mehr fällt mir jetzt nicht ein).

3) Ich will ein Programm schreiben und kenne mich nicht gut aus. Dann brauche ich eine Einführung in jedes Thema, d.h. relativ viel Text mit Beispielen und keine Liste von Speicherstellen mit Kurzbeschreibung.

Na klar kann eine Memory-Map nicht alles leisten. Aber für Punkt 2 kann man doch im Wiki einfach eine Seite Reset anlegen und dann auf die relevanten Speicherzellen verweisen. Das ist ja gerade das tolle an einem Wiki, dass man die Inforamtionen immer wieder verlinken kann.
Punkt 3 kann man auf die gleiche Weise abhandeln. Aber dafür braucht man erstmal eine komplette MM.
Je mehr an einem Wiki mitarbeiten und je verschiedener der Blickwinkel ist, um so besser wird das ganze.

Einige von den temporär benutzten Speicherzellen kann man ja für eigene Zwecke nutzen, wenn sie gerade nicht gebraucht sind. z.B. für Pointer in Action!, die auf der Zeropage ja wesentlich schneller sind.

@Dietrich: das "Trööt" ist nach dem COMpilieren das Wecksignal. Bei längeren Programmen dauert das nämlich auch etwas, obwohl Action! im Vergleich rasend schnell ist.

Zum Wiki: das RESET Thema, und andere Themen wie DLI, Display List, SIO, usw. versuche ich über die "Themen"/"Topics" zusammenzufassen.
Guck mal hier zB: Topic-Liste http://wiki.strotmann.de/wiki/Wiki.jsp? ... pic%20list
oder Topic Player Missile (noch nicht komplett) http://wiki.strotmann.de/wiki/Wiki.jsp?page=Pm_topics

PS Das Trööt kann man auch abschalten:
im Monitor (CTRL-SHIFT M) "O" wie "OPTIONS" eingeben und RETURN
dann kommt eine Liste von Parametern. RETURN läßt den Wert, sonst neuen Wert eingeben und Return. Der gesuchte ist "Bell?" Y/N
Hier ist das prima Handbuch: http://wiki.strotmann.de/wiki/Wiki.jsp? ... 20Handbuch

Das Trööt kann man auch abschalten:

Ja, aber ich nehme an, diese Einstellung kann man nicht abspeichern?!? ... dann müsste ich sie ja jedesmal beim ACTION starten wiederholen ... naja ich denke, man kann sich an das Getröte durchaus gewöhnen ... ist halt nur unüblich, dass getrötet wird, ohne dass eine Warnung/Fehler vorliegt.

Habe jetzt das WIki mal angegeguckt. Ist ja deutlich besser und schneller als das alte, das bei mir auch arge Darstellungsprobleme im Browser hatte. Kann man da auch ohne Anmeldung schreiben wie bei wikipedia (keine Lust auf noch einen Account)?

Dietrich hat geschrieben:

Das Trööt kann man auch abschalten:

Ja, aber ich nehme an, diese Einstellung kann man nicht abspeichern?!? ... dann müsste ich sie ja jedesmal beim ACTION starten wiederholen ... naja ich denke, man kann sich an das Getröte durchaus gewöhnen ... ist halt nur unüblich, dass getrötet wird, ohne dass eine Warnung/Fehler vorliegt.

Habe jetzt das WIki mal angegeguckt. Ist ja deutlich besser und schneller als das alte, das bei mir auch arge Darstellungsprobleme im Browser hatte. Kann man da auch ohne Anmeldung schreiben wie bei wikipedia (keine Lust auf noch einen Account)?

Nein, Anmeldung ist leider wegen Spams nötig geworden. Aber macht ja nichts, richte Die den gleichen Account ein wie beim Abbuc, dann musst Du dir nicht so viele merken.

da man damit so viel falsch machen kann und sich immer wieder die Hirnwindungen verrenkt ("zeigt das auf X oder ist das nun X, oder wie jetzt"), hier mal eine Zusammenstellung.

Pointer in "Action!"

CARD DLIPTR=560 ; 560,561 Low/High zeigen auf den Anfang der Display List
; die CARD Variable DLIPTR wird durch "=560" auf die Speicheradresse 560,561 festgelegt.

BYTE POINTER MYDLI ; definiert einen Pointer auf Bytes

MYDLI=DLIPTR ; jetzt zeigt MYDLI auch auf die Adresse, auf die DLIPTR zeigt

X=MYDLI^ ; X enthält jetzt den Wert der Speicherzelle, auf die MYDLI zeigt (also den ersten Wert der Display List)
MYDLI==+1 ; den Zeiger MYDLI eins weiter setzen
X=MYDLI^ ; X enthält jetzt den Wert der Speicherzelle, auf die MYDLI zeigt (also den ZWEITEN Wert der Display List)

ACHTUNG:
X=MYDLI+1^ ; GEHT LEIDER NICHT!!!

X=MYDLI^+1 ; X enthält jetzt den Wert der Speicherzelle, auf die MYDLI zeigt (also den ZWEITEN Wert der Display List) aber plus 1

BYTE ARRAY MEINEDLI=[$70 $70 $70 $40 $9c $02 $02 $02 $02 $02 $02 $02 $42 $20 $9C]
; ein Array, gefüllt mit den in [] angegebenen Werten
CARD P
BYTE J
PROC TUNIX()
;
RETURN

P=MEINEDLI ; P enthält jetzt die (Start-)Adresse von MEINEDLI
P=TUNIX ; P enthält jetzt die (Start-)Adresse der Prozedur TUNIX
; gibt man PROCs, FUNCs oder ARRAYs bei einer Zuweisung als Wert an, wird die Adresse verwendet
; will man die Adresse einer Variablen ermitteln, muss man @ verwenden
P=@J; P enthält jetzt die Adresse von J
P=J; P zeigt auf die Adresse "Wert von J" (also irgendwas in der Zeropage, da J ja ein Byte ist)

MYDLI=MEINEDLI ; der Pointer MYDLI zeigt jetzt auf den ersten Wert von MEINEDLI

sei $4000 der Beginn des Programms
BYTE POINTER ptr ; Zeiger auf BYTE (in Adresse 4000 und 4001)
BYTE NUM ; ein Byte namens NUM (in Adresse 4002)
NUM=0 ; NUM ist nun 0
PTR=NUM ; PTR enthält nun den Wert von NUM und zeigt auf die Adresse (Wert von Num). PTR zeigt also auf $0000
PTR=@NUM ; PTR enthält nun die Adresse von NUM , also $4002
PTR^=50 ; schreibt 50 in die Adresse, auf die PTR zeigt, also $4002, d.h. NUM ist nun 50

FlorianD hat geschrieben:P=MEINEDLI ; P enthält jetzt die (Start-)Adresse von MEINEDLI
P=TUNIX ; P enthält jetzt die (Start-)Adresse der Prozedur TUNIX
; gibt man PROCs, FUNCs oder ARRAYs bei einer Zuweisung als Wert an, wird die Adresse verwendet
; will man die Adresse einer Variablen ermitteln, muss man @ verwenden
P=@J; P enthält jetzt die Adresse von J
P=J; P zeigt auf die Adresse "Wert von J" (also irgendwas in der Zeropage, da J ja ein Byte ist)

Macht in dem Fall
P=MEINEDLI und
P=@MEINEDLI einen Unterschied?
oder auch im Falle
P=TUNIX
P=@TUNIX
(Wenn nicht, könnte/ sollte man vielleicht bei der "Adressübergabe" immer das @ verwenden.
Wäre dann auf einen Blick erkennbar und damit der Code leichter lesbar...)

eda70 hat geschrieben:

FlorianD hat geschrieben:P=MEINEDLI ; P enthält jetzt die (Start-)Adresse von MEINEDLI
P=TUNIX ; P enthält jetzt die (Start-)Adresse der Prozedur TUNIX
; gibt man PROCs, FUNCs oder ARRAYs bei einer Zuweisung als Wert an, wird die Adresse verwendet
; will man die Adresse einer Variablen ermitteln, muss man @ verwenden
P=@J; P enthält jetzt die Adresse von J
P=J; P zeigt auf die Adresse "Wert von J" (also irgendwas in der Zeropage, da J ja ein Byte ist)

Macht in dem Fall
P=MEINEDLI und
P=@MEINEDLI einen Unterschied?
oder auch im Falle
P=TUNIX
P=@TUNIX
(Wenn nicht, könnte/ sollte man vielleicht bei der "Adressübergabe" immer das @ verwenden.
Wäre dann auf einen Blick erkennbar und damit der Code leichter lesbar...)

... das muss ich ausprobieren, erwarte aber keine Unterschiede. Besser lesbar ist es definitiv mit "@"

eda70 hat geschrieben:Macht in dem Fall
P=MEINEDLI und
P=@MEINEDLI einen Unterschied?
oder auch im Falle
P=TUNIX
P=@TUNIX
(Wenn nicht, könnte/ sollte man vielleicht bei der "Adressübergabe" immer das @ verwenden.
Wäre dann auf einen Blick erkennbar und damit der Code leichter lesbar...)

Tja scheint leider doch einen Unterschied zu machen. Auch wenn ich nicht verstehen wieso...
Siehe hier!

FlorianD hat geschrieben:[code]
BYTE ARRAY DLI=[70 70 70 42 00 00 42 00 00 42 00 00 41 00 00]

PROC MAIN()
CARD DLIPTR=560
CARD C
CARD POINTER PTR

PTR=@DLI ;setze PTR auf die adresse von DLI
PTR=PTR+13 ; ich will die beiden letzten bytes der DLI auf die Adresse der DLI setzen (Rücksprung) daher Zeiger 13 Bytes vorrücken
PTR^=DLI ; geht nicht, wenn ich das Array anzeige sind die beiden letzen Bytes immer noch 00 00

DLIPTR=DLI ;das scheint zu gehen (OS Pointer auf die Adresse meines DLI.Array legen, die DLI wird angezeigt
RETURN

Ich glaub ich habs: Das Problem ist die Array-Definition: BYTE ARRAY DLI=[...] produziert Bugs bei allen Pointern auf DLI. Ändere das mal in BYTE ARRAY DLI(0)=[...]. Dann sollte es gehen. Siehe auch hier

so geht es jetzt!

Code: Alles auswählen

MODULE
BYTE ARRAY DLI(15)=[70 70 70 42 0 0
42 0 0 42 0 0 41 0 0]

PROC MAIN()
  CARD C
  CARD POINTER PTR
  BYTE I

  PTR=DLI
  PTR=PTR+13
  PTR^=DLI

  PRINTCE(DLI)

  PTR=DLI
  FOR I=DLI TO DLI+15 DO
   PRINTBE(PTR^)
   PTR==+1
  OD
 RETURN


Danke Dietrich!