writing data with CIO (mads) doesn't work on device D1: but on S:

[patjomki]

Hello,

 

I try to write some data to disk. Unfortunately the data isn't written. What is wrong?

 

org $0600

EOL equ $9B ;ATASCII CODE FOR END OF LINE CHARACTER
OPEN equ $03 ;TOKEN FOR OPENING A DEVICE OR FILE
OWRIT equ $08 ;TOKEN FOR "OPEN FOR WRITE OPERATIONS"
PUTCHR equ $0B ;TOKEN FOR "PUT CHARACTER"
CLOSE equ $0C ;TOKEN FOR CLOSING A DEVICE OR FILE

IOCB2 equ $20 ;OFFSET FOR IOCB NO.2
ICCOM equ $0342 ;COMMAND BYTE (CONTROLS CIO OPERATIONS)
ICBAL equ $0344 ;BUFFER ADDRESS (LOW BYTE)
ICBAH equ $0345 ;BUFFER ADDRESS (HIGH BYTE)
ICBLL equ $0348 ;BUFFER LENGTH (LOW BYTE)
ICBLH equ $0349 ;BUFFER LENGTH (HIGH BYTE)
ICAX1 equ $034A ;AUXILIARY BYTE NO.1
ICAX2 equ $034B ;AUXILIARY BYTE NO.2

CIOV equ $E456 ;CIO VECTOR

DEVNAM dta c "D1:HIGHSCOR.TXT",EOL
TXTBUF dta "123456abc",EOL

start

LDX #IOCB2 ; open file
LDA #OPEN
STA ICCOM,X

LDA <DEVNAM
STA ICBAL,X

LDA >DEVNAM
STA ICBAH,X

LDA #OWRIT ; we want to write some data to disk
STA ICAX1,X
LDA #0
STA ICAX2,X
JSR CIOV

LDA #PUTCHR ; character by character
STA ICCOM,X

LDA <TXTBUF
STA ICBAL,X
LDA >TXTBUF
STA ICBAH,X

LDA #$0a ; 10 bytes are planned to be written "123456abc" and EOL
STA ICBLL,X
LDA #0
STA ICBLH,X
JSR CIOV ; finally let's write the data

LDA #CLOSE ; don't forget to close the file
STA ICCOM,X
JSR CIOV

loop jmp loop

 

When I change devnam to <devnam dta c "S:",EOL"> everything is written fine to the screen, but obviously I want to write to disk d1: instead.

[Rybags]

When CIOV returns to you the Y register contains the status/error code for the operation.

To help debugging you could store it from each occurrence into a work area then check it over when the run is complete.

 

Being that it's an open output to disk, the OPEN command should do some I/O to the disk. Especially if the file exists already, it should delete it before the write operation is able to start. If using emulation, turning off stuff like SIO patch and enabling IO sounds can help there.

Also note of course you need a Dos loaded, or if using the D: device in the emulator, have writes enabled for it.

Edited May 1, 2016 by Rybags

[patjomki]

When CIOV returns to you the Y register contains the status/error code for the operation.

To help debugging you could store it from each occurrence into a work area then check it over when the run is complete.

 

Being that it's an open output to disk, the OPEN command should do some I/O to the disk. Especially if the file exists already, it should delete it before the write operation is able to start. If using emulation, turning off stuff like SIO patch and enabling IO sounds can help there.

Also note of course you need a Dos loaded, or if using the D: device in the emulator, have writes enabled for it.

 

Thanks for your reply. As with altirra and wudsn I am able to have source level debugging so I can check the Y register immediately. I am also going to try your other suggestions.

 

I am using MyDos and as an .atr in Altirra with read/write operations enabled.

 

In the meantime I found out that when I write a different TXTBUF for example "abcdefghi" everything is running fine. Strange.

[Rybags]

In the code you post you don't have c" for TXTBUF so maybe it's only assembling it as a hex sequence of several bytes.

But really, that shouldn't matter anyway. You're doing command $0B which is PUT CHARACTERS where you supply a bufffer address and buffer length.

The EOL isn't essential either, it has no special properties when used for disk files or with that command.

 

The Status bytes you get back should give a clue though... I get the feeling it's not a problem with your program.

[flashjazzcat]

DTA is indeed writing out the original string as internal character codes, although according to the documentation it should default to "byte" if no type is specified. Since lowercase letters have the same ATASCII and internal codes, the alternative string is written correctly despite the lack of data type.

Edited May 1, 2016 by flashjazzcat

[patjomki]

The Status bytes you get back should give a clue though... I get the feeling it's not a problem with your program.

Well, actually it is a combination of several things. First it was a problem of internal character code/ATASCII. Now that I corrected the code it is running fine with both Altirra/Original hardware.

 

Unfortunately when I use the above corrected code snippet in my complete program it doesn't work on original hardware but on Altirra. So there still IS a bug in my complete programm. When I change my complete programm that I jmp to the subroutine it works on both Altirra/original hardware but not when I jmp to the subroutine at the intended moment (well, when there is a new highscore saved).

 

Have to investigate that later when the rest of the program is finished.

Edited May 2, 2016 by patjomki

[Rybags]

The data you're passing to PUT shouldn't matter. It could equally be all zeros.

 

OK, it seems the obvious has been overlooked. There's some glaring errors in the program.

 

Where you're setting up addresses for DEVNAM and TXTBUF are the problem. You need # to specify immediate mode. As it is you're probably generating a z-page instruction.

 

ie, not:

    LDA <DEVNAM

    STA ICBAL,X

    LDA >DEVNAM

    STA ICBAH,X

What's needed:

    LDA #<DEVNAM

    STA ICBAL,X

    LDA #>DEVNAM

    STA ICBAH,X

[flashjazzcat]

OK, it seems the obvious has been overlooked. There's some glaring errors in the program.

 

Where you're setting up addresses for DEVNAM and TXTBUF are the problem. You need # to specify immediate mode. As it is you're probably generating a z-page instruction.

 

That's the first thing I spotted but immediate mode is implied for '<' and '>' with or without the hash in MADS.