why this gemdos call triggers 4 bombs ?

[Shazz]

Hi...

I guess this is stupid but I cannot see why.. using hatari / STF / TOS 1.02 it crashes in the first trap (Fcreate)

Code: Select all

LC2_create_prg:

        ; create file
        clr.w       -(sp)                           ; attributes = 0 
        lea.l       L1D8_filename(pc), a3           ; 
        move.l      a3, -(sp)                       ; fname = L1D8_filename
        move.w      #$3c, -(sp)                     ; long Fcreate(char* fname, word attr), returns a long, word value is the file handle, if neg, error
        trap        #$1                             ; stack 8

        ; create file with modified DISKBUFP
        move.l      DISKBUFP.w, -(sp)               ; buf = DISKBUFP
        move.l      #$400, -(sp)                    ; count = 1024 bytes
        move.w      d0, -(sp)                       ; handle = d0
        move.w      #$40, -(sp)                     ; long Fwrite(word handle, long count, voidp buf)
        trap        #$1                             ; stack 10
        
        ; close file
        subq.w      #$2, (sp)                       ; call long Fclose(word handle), previous word opcode is set to $3e
        trap        #$1                             ; stack = 0

        ; set file attribute to hidden
        move.l      #$10002, -(sp)                  ; flag = 1 (set) | attr = 2 (hidden file)
        lea.l       L1D8_filename(pc), a3           ; 
        move.l      a3, -(sp)                       ; fname = L1D8_filename
        move.w      #$43, -(sp)                     ; long Fattrib(char* fname, word flag, word attr)
        trap        #$1                             ; stack = 10

        lea.l       $1e(sp), sp                     ; fix all stacks
        
        rts
                
L1D8_filename:
        dc.b        "A:\T.PRG", 0
        

Thanks!

[Greenious]

You cannot use a path in the filename. If you want to specify a path you must first choose it with Dsetpath.

Second, I strongly recommend fixing the stack after each trap, atleast until you have something that works as intended. Fixing it all at the end just begs for problems.

[ThorstenOtto]

Are you sure it is the first call that bombs? You are assuming that the parameters you pushed on the stack are not modified, but this might not be the case. The compendium states:

Code: Select all

GEMDOS may utilize registers D0-D2 and A0-A2 as scratch registers and their
contents should not be depended upon at the completion of a call. In
addition, the function opcode placed on the stack will be modified.

That also means you have to save the handle returned by Fcreate somewhere.

[ThorstenOtto]

You cannot use a path in the filename. If you want to specify a path you must first choose it with Dsetpath.

Huh? What makes you think so?

Fixing it all at the end just begs for problems.

Generally, that should be ok, unless your stack is too small. GCC sometimes does the same (but he is better at counting )

[Shazz]

Some comments:

- providing a full path works (I also tried with only "TEST.PRG", same behavior
- this is not my code, but I checked, fixing the stack after each trap call doesn't change anything (as Fcreate crashes)
- this is not the issue but I agree, keeping the handle in d0 is risky (but in fact... works, maybe it was designed like that for all F*() operations)
- Fattrib() call is useless as the attribute can be passed in Fcreate()

I found the issue, this code is called in a bootsector and it seems Fcreate() crashes if it's called too early (meaning because the TOS is fully initialized?), calling again this code from GEM in fact works.

Question 1: why? is there some Gemdos init to be called first ?

something weird I noticed, even when calling this code from the GEM, with TOS 1.02, after Fcreate() call, the first word of DSKBUF are replaced by 0.
It makes so sense to me, but it happens. So when calling Fwrite(), the buffer is corrupted. For sure using DSKBUF is always risky but I don't get why Fcreate() modifies the floppy buffer.... Any idea ?

[charles]

Doesn't file name have to end truncated with chr$(0)


#0 in asm

Gfa might have me confused

String length too for path and filename
128...13

[charles]

I'll have to go home and look at some of my old files. But I think you also have to open gemdos to have a device driver handle

[charles]

https://www.atari-forum.com/viewtopic.php?t=24168