Waiting for disk activity to finish

[losso]

I'm trying to write high scores to disk during a game where I have taken over the system. Restoring the system and the view before the write seems to work ok (to give users an opportunity to react to "XY is write protected" requesters etc.).

As suggested for example by phx in this thread, after the "Write" call to dos.library returns, I call Delay(500) to wait for any disk activity to finish.

(Thanks for the hint, by the way! Before, I was scratching my head why I would end up with invalidated disks...)

Still, waiting an arbitrary amount of ticks seems kind of dirty. I've tried calling Lock and Unlock directly after the Write call, but the proper validation still seems to occur one/two seconds afterwards.

My latest attempt was:

    ;
    ;    file = Open( name, accessMode )
    ;    D0           D1    D2
    ;
    move.l  #hiscore_filename,d1
    move.l  #1006,d2                ; MODE_NEWFILE
    jsr     _LVOOpen(a6)
    tst.l   d0
    beq.b   .err
    ;
    ;   returnedLength =  Write( file, buffer, length )
    ;   D0                       D1    D2      D3
    ;
    move.l  d0,d1
    move.l  d0,-(a7)
    move.l  #scoredata,d2
    move.l  #HISCORES_SIZE,d3
    jsr     _LVOWrite(a6)
    tst.l   d0
    beq.b   .notwritten
    ;
    ;    success = Close( file )
    ;       D0             D1
    ;
    move.l  (a7)+,d1
    jsr     _LVOClose(a6)
    ;
    ;    lock  = Lock( name, accessMode )
    ;    D0            D1        D2
    ;
    move.l  #hiscore_filename,d1
    moveq   #-1,d2                  ; ACCESS_WRITE
    jsr     _LVOLock(a6)
    move.l  d0,d1
    beq.b   .lockfail
    ;
    ;       UnLock( lock )
    ;                D1
    ;
    jsr     _LVOUnlock(a6)
.lockfail
    ;
    ;       Delay( ticks )
    ;               D1
    ;
    move.l  #50*10,d1               ; wait x secs for disk activity
    jsr     _LVODelay(a6)

Is there any way to ask DOS to flush everything to disk/perform necessary disk validation?

[phx]

Originally Posted by losso

Is there any way to ask DOS to flush everything to disk/perform necessary disk validation?

No, unfortunately not. You could try to send an ACTION_FLUSH packet to the filesystem, but there is no DOS-call for it.

Or maybe you can enforce the buffer flush by opening and reading from another file after your write?

Although, I never tried both options myself.

IMHO, reanimating the OS temporarily for disk operations doesn't feel quite right and always has a taste of hack. The two clean and easy solutions would be:
- Delay all write operations until your program is about to return to the, just restored, OS.
- Use a lowlevel trackloader and write data with your own write-routines in your own format.

[alpine9000]

Originally Posted by phx

No, unfortunately not. You could try to send an ACTION_FLUSH packet to the filesystem, but there is no DOS-call for it.

Or maybe you can enforce the buffer flush by opening and reading from another file after your write?

Although, I never tried both options myself.

IMHO, reanimating the OS temporarily for disk operations doesn't feel quite right and always has a taste of hack. The two clean and easy solutions would be:
- Delay all write operations until your program is about to return to the, just restored, OS.
- Use a lowlevel trackloader and write data with your own write-routines in your own format.

Yep - depending on the filesystem etc it seems like there is almost no safe way to do this.

I have used both of the above techniques, and in the end for games running from a HD/CD I used the third option of *gasp* leaving the OS running. This wasn't nearly as painful as I thought it would be and doesn't cause many issues except RAM usage.

[Asman]

Try this. I use it and it works like charm.

;-----------------------------------------------------------------------------
;
;; OsFlush
;
;in	a4 - dt
;out	-
;used	d0/d1/d2/d3/a0/a1/a2/a4
;
	xdef	OsFlush
OsFlush:
		move.l	4.w,a6
		moveq	#72,d0
		moveq	#1,d1
		swap	d1
		jsr	-198(a6)		;exec AllocMem(d0 - size, d1 - attr)
		move.l	d0,d2
		beq.b	.exit
		move.l	d0,a0
		move.l	a0,d1			;device name
		move.l	#'sys:',(a0)

	;get our message port
		move.l	276(a6),a2		;ThisTask
		lea	92(a2),a2		;pr_MsgPort

	;get filesystem message port
		move.l	osDosBase(a4),a6
		jsr	-174(a6)		;dos DeviceProc(d1 - name)
		move.l	d0,d3
		beq.b	.free

	;fill in packet
		move.l	d2,a1
		addq.l	#4,a1		;message
		lea	20(a1),a0	;dos packet
	
		move.l	a0,10(a1)	;message->mn_Node.ln_Name = dospacket
		move.l	a2,14(a1)	;mn_ReplyPort = pr_MsgPort

		move.l	a1,(a0)+	;dp_link = message
		move.l	a2,(a0)+	;dp_Port = pr_MsgPort
		moveq	#27,d0
		move.l	d0,(a0)		;dp_Type = ACTION_FLUSH

	;sends packet 
		move.l	4.w,a6
		move.l	d3,a0
		jsr	-$16e(a6)	;exec PutMsg(a0 - port,a1 - msg)

	;wait for reply
		move.l	a2,a0
		jsr	-$180(a6)	;exec WaitPort(a0 - port)
		move.l	a2,a0
		jsr	-$174(a6)	;exec GetMsg(a0 - port)
.free
		move.l	d2,a1
		moveq	#72,d0
		jsr	-210(a6)	;exec FreeMem(a1 - mem, d0 - size)

.exit		rts

;-----------------------------------------------------------------------------

[ross]

Originally Posted by Asman

Try this. I use it and it works like charm.

Thanks Asman

--
I always thought of an alternative and even if dangerous, a possibility came to my mind..
You cannot write in predefined sectors because of ADOS (file update outside game, disk validating, etc), but there is a zone ever usable and protected: bootblock.
So main idea is use some spare space of the bootblock for the hiscore (better if encrypted ), update bb checksum and use a lowlevel trackwriter.

Just an alternative thinking

EDIT: hmm, I reread what losso written, actually he did not specify on which device the save in needed.
Well, logically my unconventional idea is valid only for floppy.

For other devices, like phx suggested (delay all write operations until your program is about to return, like WHDLoad does), can be acceptable.
Anyone expects to be able to return to the workbench from an hdd installed game, so they require and use a proper exit.

[losso]

@Asman: Cool, will try it out! I'll probably need to add some find-current-directory-and-volume magic; the game is Workbench-loadable and might be started from somewhere else than SYS: (and the "highscore.dat" file will live there, too)

@ross: Heh, the bootblock idea is neat, too... (could even combine that with a custom boot block that shortly displays the current highscores when booting ) But I don't want to force floppy disk usage and try to stay compatible

Talking of which... @phx: I agree, reanimating the OS does not seem very elegant, either. Upside: At least with Kick 1.3 and disk access it works nicely enough to be able to handle a "write protected" requester and return to the game afterwards.

[Asman]

@losso - Just for clarification. 'sys:' used in above osFlush procedure is used to get filesystem message port. Loading/Saving file(s) from location it's a different story I think . I've never tried but I think that CurrentDir from dos.library somewhere where OS is overtaken should help. If I find some time I will do test(s) and post sources.