ASM: Probleme mit dem Abspeichern

[pps]

Ich habe gerade ein Problem, wo ich nicht weiterkomme. Eine Datei, die ich problemlos öffnen und lesen kann, möchte ich nun auch wieder beschreiben. Dazu nutze ich folgenden Code (von @Dietrich) zum Öffnen der entsprechenden Datei:

Code: Alles auswählen

	ldx #kanal*16   ; Kanalnr. * 16 in X-Register setzen
	lda #3
	sta iccmd,x     ; CIO-Kommando 3 = Open
	lda <fname
	sta icadr,x     ; icadr muss auf fname ziegen
	lda >fname
	sta icadr+1,x
	lda #8          ; AUX1=4 für Open read (8 für write, 12 für update)
	sta icaux,x
	jsr ciov        ; CIO aufrufen
	bmi error       ; Returncode prüfen (steht in Y und icsta)
	rts
error
	sty 712	;Fehler auch "sehen können"
	jmp *

Dateiname ist dieser und er funktioniert auch ohne Probleme beim Laden aus der Datei:

Code: Alles auswählen

fname	.byte "D1:SCORES",eol			;filename to operate with

Egal, ob ich nun @Dietrich´s uDOS oder DOS 2.5 nehme, es kommt schon hier beim Öffnen für write der Fehler 130 (NOT EXISTENT DEVICE)
Muss man doch mehr machen um eine Datei zum Schreiben zu öffnen als nur die #4 nach #8 zu ändern vor sta icaux,x?
Ach so, auch das Öffnen eines 2. Kanals zum Schreiben hat nichts gebracht, auch nicht, gleich am Anfang mal statt zum Lesen, zum Schreiben zu öffnen - immer ERROR 130. Anfangs dachte ich der Dateiname wäre schuld, da ich nur D: dort stehen hatte, D1: bringt aber auch nichts.

Edit: Ach so, kanal ist natürlich definiert (=1), genauso, wie alle Systemadressen.

[DjayBee]

Fehlt da nicht ein #?

lda <fname
lda >fname

lda #<fname
lda #>fname

[pps]

Fehlt da nicht ein #?

lda <fname
lda >fname

lda #<fname
lda #>fname

Wie ich vermutet und auch eigentlich immer erlebt habe, ist es das nicht. MADS setzt definitiv beide Male den korrekten LDA Befehl ein ($a9). Diese low/high mnemonic kann man da also definitiv ohne # nutzen und es wird immer so assembliert.

[DjayBee]

Wär zu einfach gewesen.

Schau doch in Altirra mal, was CIO denn tun soll/will.

.tracecio on

[Dietrich]

Sieht OK aus (abgesehen von lda <fname - diese Syntax finde ich echt schräg).
Ich vermute mal eine MADS-Besonderheit. Oder das DOS ist nicht richtig initialisiert (kann aber nicht sein, wenn derselbe Code mit AUX1=4 funktioniert).
Poste mal den assemblierten Hexcode (a9 01 8d 00 06 usw.) - oder ein Screenshot des Debug-Assembler-Fensters in Altirra oder hänge das XEX an oder ein ATR mit dem assemblierten XEX.

Edit: Was für einen Emulator verwendest du? Gibt der evtl. Error 130 statt Error 144 zurück, wenn das ATR (als Datei oder im Emulator) schreibgeschützt ist?

[pps]

Der Emulator ist Altirra. Das atr habe ich extra mit r/w also komplett offen "eingelegt". Standard ist da normal vrw wo er am Ende fragt, ob man das atr aktualisieren möchte.

Fahre jetzt zur Arbeit. Heute Abend kann ich mit code dienen.

[LarsImNetz]

Du hast vergessen ICBLEN auf die Länge des Dateinamens zu setzen (ohne das eol) also 9.

LG
Lars

[Dietrich]

Nein, das CIO interessiert sich nicht für icblen beim open. Error 130 kommt, wenn das CIO das per icadr angegebene Gerät in hatabs nicht findet. Diese Suche findet bei 59154=$E712 statt (Original-XL-OS v2). Da könnte man einen Breakpoint setzen. Wenn der Fehler an dieser Stelle entsteht, ist entweder icbalz=$24/25 nicht richtig gesetzt (sollte Inhalt von icadr,x/icadr+1,x haben) oder in hatabs=$31A ist das Gerät "D" nicht vorhanden.
Ansonsten fällt mir als Ursache nur ein, dass der Assembler nicht richtig wie erwartet assembliert oder in Altirra irgendwo eine Besonderheit für D: oder das CIO gesetzt ist.

[DjayBee]

Evtl. ein SIO Patch in Altirra.

Aber daher kam mein Vorschlag, CIO in Altirra zu tracen (.tracecio on im Altirra Debugger). Dann sieht man wenigstens, was der Atari "meint, tun zu müssen".

Wenn er das Richtigen meint, ist es vermutlich irgendwas im Altirra.
Wenn er etwas Falsches meint, dann liegt's am Aufruf von pps.

[atarixle]

Mal ganz naiv aus BASIC-Sicht gefragt: hast du den Kanal auch wieder geschlossen? (Das würde aber nicht den Fehler 130 erklären)

[pps]

Du hast vergessen ICBLEN auf die Länge des Dateinamens zu setzen (ohne das eol) also 9.

LG
Lars

OK, das teste ich gleich mal. Komisch, dass das beim Öffnen zum Lesen scheinbar nicht stört.

Der Emulator ist es aber zu 100% nicht, da das Problem. Auch am 600XL da ist.

Auch habe ich den Kanal nach dem Öffnen zum Lesen wieder geschlossen

Edit: icblen setzen hat nichts gebracht.

[pps]

Hier mal der Code mitsamt dem Hexcode, der erzeugt wird:

Code: Alles auswählen

   				;------------
 				.proc open_read
   				; Datei für Lesen (AUX1=4) auf Kanal 1 öffnen: open #1,4,0,"D:NAME"
   				; für Schreiben (AUX1=8) und Update (AUX2=12) genauso
   A2 10			ldx #kanal*16   ; Kanalnr. * 16 in X-Register setzen
   A9 03			lda #3
   9D 42 03			sta iccmd,x     ; CIO-Kommando 3 = Open
   A9 9D			lda #<fname
   9D 44 03			sta icadr,x     ; icadr muss auf fname ziegen
   A9 39			lda #>fname
   9D 45 03			sta icadr+1,x
   A9 04			lda #4          ; AUX1=4 für Open read (8 für write, 12 für update)
   9D 4A 03			sta icaux,x
   20 56 E4			jsr ciov        ; CIO aufrufen
   30 01			bmi error       ; Returncode prüfen (steht in Y und icsta)
   60				rts
  			error
   8C C8 02			sty 712
   4C 6F 3A			jmp *
  				;	rts
  				.endp
   				;------------
  				.proc open_save
   				; Datei für Lesen (AUX1=4) auf Kanal 1 öffnen: open #1,4,0,"D:NAME"
   				; für Schreiben (AUX1=8) und Update (AUX2=12) genauso
   A2 10			ldx #kanal*16   ; Kanalnr. * 16 in X-Register setzen
   A9 03			lda #3
   9D 42 03			sta iccmd,x     ; CIO-Kommando 3 = Open
   A9 9D			lda #<fname
   9D 44 03			sta icadr,x     ; icadr muss auf fname ziegen
   A9 39			lda #>fname
   9D 45 03			sta icadr+1,x
   A9 08			lda #8          ; AUX1=4 für Open read (8 für write, 12 für update)
   9D 4A 03			sta icaux,x
   A9 09 8D 48 03		mva #9 iclen
   20 56 E4			jsr ciov        ; CIO aufrufen
   30 01			bmi error       ; Returncode prüfen (steht in Y und icsta)
   60				rts
  			error
   C0 83			cpy #131
   F0 05			beq @+
   84 95			sty cbak
   4C C5 3A			jmp *
   60			@	rts
   				.endp
  

open_read erzeugt keine Fehler, die Datei wird danach auch korrekt gelesen. Am close kann es auch nicht liegen, denn wenn ich open_save zuerst aufrufe, kommt auch immer der Fehler. Ich stehe also weiterhin auf dem Schlauch

[Dietrich]

fname .byte "D:SCORES" fehlt da noch. (Und die Adressen, an die es assembliert wurde.)
Sieht ansonsten OK aus.
Sonst hänge mal ein ATR an, wo man den Fehler reproduzieren kann. Das kriegen wir bestimmt raus.

[pps]

Code: Alles auswählen

 44 31 3A 53 43 4F 52 45 53 9B		fname	.by "D1:SCORES",eol			;filename to operate with

Das steht direkt bei $399D.

Eine Diskette zum Testen erstelle ich dann morgen. Will nicht schon vor dem release ein Programm veröffentlichen... Zum Testen sollte ja eigentlich ein "dummy" Programm genügen.

[Dietrich]

Sieht OK aus. Habe das Programm gerade unter DOS 2.5 mit dem Synassembler eingetackert. Funktioniert!
Klar, ein Testprogramm reicht. Jetzt bin ich aber echt gespannt, woran es liegt ...

[pps]

Ich muss für heute Schluss machen. Morgen geht's wieder früh raus.

Ich habe aber eben nochmal das direkt bei Programmstart versucht - da ist wirklich nichts an Code vorher gestartet. Dort kommt Error 129 - selbst wenn ich vor open_save noch close_file starte:

Code: Alles auswählen

;------------
	.proc close_file
; Kanal schließen
	ldx #kanal*16   ; Kanalnr. * 16 in X-Register setzen
	lda #12
	sta iccmd,x     ; CIO-Kommando 12 = Close
	jsr ciov
	bmi error       ; will man eigentlich nur beim Schreiben prüfen
	rts
error
	sty 712
	jmp *
;	rts
	.endp

[DjayBee]

Ganz doof gefragt:
Verwendest du ein Game- oder Mini-Dos, das nicht schreiben kann?

*wegduck-und-renn*

[pps]

uDOS hatte ich zuerst, jetzt DOS 2.5

[Dietrich]

Ups, Error 129, bevor irgendwas passiert?! Da kommt mir ein Verdacht: Überschreibst du Page 3 (beim Laden)?
Der Error 129 kommt, wenn $340,x (also $350 für Kanal #1) nicht $ff ist. Und Error 130, wenn der Bereich ab $31A überschrieben wird ...

[JAC!]

MADS distinguishes between single quotes (ATASCII coding) and double quotes (INTERNAL coding), whereas XASM treats both forms the same (ATASCII coding). Of course, the quote types are treated the same in DTA by MADS

Du musst einfache Anführungszeichen nehmen.

[pps]

Du musst einfache Anführungszeichen nehmen.

Ja. Das hate ich auch schon mal. Aber ein schneller Test heute früh von dem Weg zur Arbeit, wo ich das zurück geändert habe, brachte den selben Fehler Ich schaue aber später nochmal in Ruhe (wahrscheinlich erst morgen, da heute Abend nochmal Fußball ansteht), ob ich früh doch was falsch gem8 habe.

Ups, Error 129, bevor irgendwas passiert?! Da kommt mir ein Verdacht: Überschreibst du Page 3 (beim Laden)?
Der Error 129 kommt, wenn $340,x (also $350 für Kanal #1) nicht $ff ist. Und Error 130, wenn der Bereich ab $31A überschrieben wird ...

Das klingt interessant. Aber mein Programm belegt extra keine Bereich unter $2000 mehr für DOS 2.5 (vorher hatte ich den screen und die pmg noch ab $1000.

Ha. Ich habe ja in page 0 meine ganzen zp-register... Ich schlacke die mal aus. Kann sein, dass ich zu weit gekommen bin. Ich nutze ja selber keinen stack, aber cio bestimmt... Vielleicht habe ich ja was, was garnicht mehr zp ist...

[Dietrich]

Du musst einfache Anführungszeichen nehmen.

Den Verdacht hatte ich auch schon - hatten wir aber schon oben ausgeschlossen, da pps den assemblierten Code gepostet hat, der eindeutig ATASCII zeigt, was korrekt ist.

Zeropage: Da braucht das CIO ein paar Adressen (so etwa $20-$2F) und das SIO belegt auch was (so etwa $30-$4F). Definitiv frei ist $80-$FF. $00-$7F belegt das OS. Da sollte man nix machen, wenn man das OS (hier CIO und SIO) braucht. Oder man weiß, was man tut. Es ist i.A. kein Problem, wenn man den unteren Bereich des Stacks belegt (so etwa $100-$1A0), denn der 6502-Stack wird von $1FF abwärts benutzt.

Noch was: Machst du den OPEN in einem Programmabschnitt des XEX, den du per INIT-Adresse aufrufst? Dann ist Kanal 1 noch offen, da das DOS diesen Kanal zum Laden des XEX benutzt. Das würde den Error 129 bei Programmstart erklären (aber nicht den Error 130). Erst vor Ausführen der RUN-Adresse schließt das DOS Kanal 1 wieder.

[DjayBee]

Zeropage: Da braucht das CIO ein paar Adressen (so etwa $20-$2F) und das SIO belegt auch was (so etwa $30-$4F).

Meines Wissens werden die nur temporär benutzt, während(!) ein CIO-/SIO-Aufruf stattfindet.
Somit könnte das Programm von pps dadurch crashen weil das OS irgendwas reinschreibt, umgekehrt darf die "unberechtigte" Verwendung dieser Adressen aber keinen Einfluss auf die SIO-/CIO-Aufrufe haben.

[pps]

Ich habe eigentlich gerade per copy paste das Programm nur zum Testen der Routinen ohne alles andere drumherum bauen wollen...

Ja, was oll ich sagen - ich habe glaube ich - den Fehler gefunden. Schaut selbst:

Code: Alles auswählen

data	.ds 11*4
;------------
fname	dta c'D1:SCORES'			;filename to operate with
	.by eol
amount	.wo 49

Wenn man 49 Bytes lädt, aber nur 44 Bytes Platz reserviert, könnte das zu Problemen führen, wenn direkt danach irgendwas im Speicher steht... Ja, was steht denn da? Richtig "D1:SCORES"
Klar, dass das Device nicht existiert, wenn man dann später speichern möchte.

[pps]

So, nun habe ich es auch ausgiebig am "lebenden Objekt" getestet. Die Funktion funktioniert. Vielen Dank für die viele Hilfe, auch wenn Ihr diesen Fehler wirklich nicht finden konntet

As usual: The error sits just in front of the screen!

[Dietrich]

Oh mann! Das erinnert mich daran, als ich für jemanden eine Ultraspeed-Routine geschrieben hatte und sich beschwerte, dass die Routine nicht funktioniert. Und es kam dann raus, dass er die Routine einfach mit anderen Daten überschrieben hatte ...

[JAC!]

Tipp: Ich nutze in MADS immer .LOCAL und beziehe mich dann mit .LEN darauf. So passt es sich dynamisch an.

.local data
.ds 123123
.endl

mwa #.len data address

[Bernd]

Oh mann! Das erinnert mich daran, als ich für jemanden eine Ultraspeed-Routine geschrieben hatte und sich beschwerte, dass die Routine nicht funktioniert. Und es kam dann raus, dass er die Routine einfach mit anderen Daten überschrieben hatte ...

Wer das wohl war
Danke für deine Hilfe bei der Programmierung

[Dietrich]

Noch ein Tipp, um Bereichsüberschreitungen (z.B. bei Display List/Data die 1K/4K-Grenze) zu vermeiden. Einfach per .IF abfragen, ob die Grenze eingehalten wird und wenn nicht mit .ERROR das Assemblieren mit einer Fehlermeldung abbrechen. Z.B. habe ich im Code von uDOS am Ende folgendes stehen, damit uDOS in die 3 Bootsektoren = $180 Bytes passt:

Code: Alles auswählen

     .if * > boothead+$180
        .error "uDOS darf max. $180 Bytes = 3 Sektoren gross sein"
     .endif