Using DOS routines after a system take over

[mark_k]

CMD_UPDATE is a no-op with some device drivers. What about ACTION_INHIBIT or Inhibit()?

[Toni Wilen]

Originally Posted by mark_k

CMD_UPDATE is a no-op with some device drivers. What about ACTION_INHIBIT?

Why would it make any difference when the problem is device driver that fails to follow specs?

Only documented way to flush device driver buffers is CMD_UPDATE and filesystem is supposed to do it as a last step, after writing all data. ACTION_INHIBIT probably internally does ACTION_FLUSH first.

[Asman]

@roondar - Thanks again, now I understand why I think in wrong way. Indeed its very pity with writing. So I usually call Write (to write higscore or configuration file) after user decide to quit from my game. Furthermore these files are both short.
@Toni - I am very weak with AmigaDOS Packets. But perhaps other types can be used to determine if writing is finished.

By the way are there any docs about AmigaDOS packets and how to use it ?

Another idea: Can we use Lock with access mode ACCESS_WRITE to test if we have full access to file ? (I assume that if Lock fails then something is done with file right now and I should wait a bit and test Lock again). Of course I can be wrong, then please correct me.

edit:
Another idea 2: What about Info function from dos.library which return pointer to InfoData and there is a field id_InUse.

[Leffmann]

I think ACTION_FLUSH is the way to go, from the Amiga Guru Book:

This function forces the writing of all blocks or other writes still pending and the turning off of the motor. The handler should also send a CMD_UPDATE to subordinate devices. The packet will not be replied to until all of these operations have been performed fully, i.e. it is synchronous. ACTION_FLUSH is used by AmigaDOS to ensure that all data have been written before the user is asked to change a medium. This packet usually has an effect only under filesystems, although it might prove useful with any handler that implements deferred actions or buffering.

[Toni Wilen]

Originally Posted by Asman

@roondar - Thanks again, now I understand why I think in wrong way. Indeed its very pity with writing. So I usually call Write (to write higscore or configuration file) after user decide to quit from my game. Furthermore these files are both short.
@Toni - I am very weak with AmigaDOS Packets. But perhaps other types can be used to determine if writing is finished.

Another idea: Can we use Lock with access mode ACCESS_WRITE to test if we have full access to file ? (I assume that if Lock fails then something is done with file right now and I should wait a bit and test Lock again). Of course I can be wrong, then please correct me.

Not going to work.

Filesystem does not know what driver internally does. For example, when calling dos/Write(), dos sends sends ACTION_WRITE packet to filesystem and then waits for reply. Filesystem processes it, if it is normal block device (ram disks and network filesystems usually don't have driver layer), it does required writes and reads via normal device IO calls. (CMD_WRITE etc or HD_SCSICMD if direct scsi).

But filesystem can't know if CMD_WRITE returned because it was actually written to the disk or if was cached and will be flushed later.

Something like dos/DoPkt(filelock->fl_Task or filehandle->fh_Type, ACTION_FLUSH, 0, 0, 0, 0); should do it. At least if both filesystem and driver is sane.

By the way are there any docs about AmigaDOS packets and how to use it ?

Guru book.. there was also some early amigados manual that included packet descriptions.

AROS sources may be also useful.

Another idea 2: What about Info function from dos.library which return pointer to InfoData and there is a field id_InUse.

It is documented as being DOSTRUE if any lock/handles is open but it looks pointless because you need a lock to get the InfoData structure..

[mark_k]

Originally Posted by Asman

By the way are there any docs about AmigaDOS packets and how to use it ?

See the AmigaDOS Packet Interface Specification.

Originally Posted by Toni Wilen

Why would it make any difference when the problem is device driver that fails to follow specs?

Only documented way to flush device driver buffers is CMD_UPDATE and filesystem is supposed to do it as a last step, after writing all data. ACTION_INHIBIT probably internally does ACTION_FLUSH first.

Leaving the device driver issue aside, ACTION_INHIBIT should be more robust against some other program writing to disk. Sure, you can do ACTION_FLUSH, but what if some other program issues a write just after that? I think ACTION_INHIBIT should protect against that.

At least for FFS, ACTION_FLUSH (and ACTION_INHIBIT) do CMD_UPDATE then TD_MOTOR, so it could be some device drivers flush any internally-cached/pending I/O on TD_MOTOR. And TD_MOTOR is useful for floppy disks to prevent motor-stuck-on when you kill the OS.

[Asman]

@Toni, mark_k - Thanks for explanation

Originally Posted by Toni Wilen

Something like dos/DoPkt(filelock->fl_Task or filehandle->fh_Type, ACTION_FLUSH, 0, 0, 0, 0); should do it. At least if both filesystem and driver is sane.

I have a bit stupid question. DoPkt doesn't exist in kickstart 1.2 ( I mean about at least V33 version). What I should to do in such case.

Originally Posted by Toni Wilen

It is documented as being DOSTRUE if any lock/handles is open but it looks pointless because you need a lock to get the InfoData structure..

What about some dirty trick like first did DupLock() then Write() and then Info() with lock from DupLock ?

[Toni Wilen]

Originally Posted by Asman

I have a bit stupid question. DoPkt doesn't exist in kickstart 1.2 ( I mean about at least V33 version). What I should to do in such case.

I forgot that DoPkt() and friends are v36+. Fortunately emulating DoPkt() is not get that complex. Example code should exist somewhere..

Do you want C or asm example?

What about some dirty trick like first did DupLock() then Write() and then Info() with lock from DupLock ?

DupLock() is filesystem function (ACTION_COPY_DIR, yes, name is confusing..). Also you can't know (and even then, you shouldn't touch them..) if some other program has locks or handles open. For example boot drive has always locks open (SYS: etc assigns).

[Asman]

@Toni - asm example .

[Toni Wilen]

Late reply, sorry..

Warning: very ugly example.. First half is only needed to get the filesystem message port.

	move.l 4.w,a6
	move.l a6,a5
	lea doslib(pc),a1
	moveq #0,d0
	jsr -$228(a6) ;OpenLibrary
	move.l d0,a6
	
	moveq #0,d4
	lea filename(pc),a0
	move.l a0,d1
	moveq #-2,d2
	jsr -$54(a6) ;Lock
	tst.l d0
	beq.s nofile
	move.l d0,d1
	lsl.l #2,d0
	move.l d0,a0
	move.l 12(a0),d4 ;filesystem msgport
	jsr -$5a(a6) ;UnLock
nofile
	move.l a6,a1
	move.l a5,a6
	jsr -$19e(a6) ;CloseLibrary

	tst.l d4
	beq.w end

	sub.l a1,a1
	jsr -$126(a6) ;FindTask
	move.l d0,a2
	add.w #92,a2 ;pr_MsgPort

	lea message(pc),a3
	lea dospacket(pc),a4
	
	move.l a3,(a4) ;dp_link = message
	move.l a4,10(a3) ;message->mn_Node.ln_Name = dospacket
	move.l a2,4(a4) ;dp_Port = pr_MsgPort
	move.l a2,14(a3) ;mn_ReplyPort = pr_MsgPort
	move.l #27,8(a4) ;dp_Type = ACTION_FLUSH

	move.l a3,a1
	move.l d4,a0
	; dospacket -> filesystem msgport
	jsr -$16e(a6) ;PutMsg
	; wait for reply
	move.l a2,a0
	jsr -$180(a6) ;WaitPort
	move.l a2,a0
	jsr -$174(a6) ;GetMsg

end	
	rts

filename
	dc.b "sys:",0
doslib
	dc.b "dos.library",0


	cnop 0,4
	; struct StandardPacket
message
	dcb.b 20,0
dospacket
	dcb.b 48,0

EDIT: msgport = dos/DeviceProc("dh0:") is quicker way to get filesystem port.

[Asman]

@Toni - Thanks a lot. Finally I found some time to check and test that solution. On two WinUAE configurations and works fine (Kick1.3 and Floppy, Kick3.1 and HD). My test program working in following manner:
- takeover os
- disable os
- enable os
- load file , close file
- do ACTION_FLUSH
- disable os
- wait for lmb
- restore os

Without ACTION_FLUSH the led was ON all time.

Only one thing is funny/strange for me but I guess is mandatory. ln_Name point to dospacket !

Part of code from test program.

;a4 - dt, dos.library already opened

	;get filesystem message port
		move.l	osDosBase(a4),a6
		lea	filename(pc),a0
		move.l	a0,d1
		jsr	-174(a6)		;dos DeviceProc(d1 - name)
		move.l	d0,d4
		beq.b	.exit

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

	;fill in packet
		lea	message(pc),a1
		lea	dospacket(pc),a0
	
		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
		move.l	#27,(a0)	;dp_Type = ACTION_FLUSH

	;sends packet 
		move.l	d4,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)


filename:	dc.b	"sys:",0
	cnop 0,4
	; struct StandardPacket
message:	dcb.b 20,0
dospacket:	dcb.b 48,0

[Toni Wilen]

Originally Posted by Asman

Only one thing is funny/strange for me but I guess is mandatory. ln_Name point to dospacket !

Yes, it is required. It is how Tripos packet system was hacked to exec messaging system.

[Asman]

One more thing. Struct StandardPacket must be long word aligned. By mistake I did only word aligned and I wasted about two hours to figured out why above routine hangs on WaitPort in Kick1.3 (On Kick3.1 works fine). Frankly I've no idea why this structure must be long word aligned.

[Toni Wilen]

BCPL and Tripos strikes again. All dos structures (at least those that were introduced before 2.0) must be long word aligned.

[meynaf]

Structures must be longword aligned because the pointer will internally be stored as an address divided by 4. A file handle, for example, is an address /4.

[Asman]

@Toni, meynaf - Thanks a lot.

[ross]

Originally Posted by meynaf

Structures must be longword aligned because the pointer will internally be stored as an address divided by 4. A file handle, for example, is an address /4.

Hi meynaf, this make sense.
But how about Asman difference between 1.3/3.1?
If the code is the same (not a different compiled binary) how a BCPL is now a good 'word' pointer?

Toni speak about "structures before 2.0"..
So after 2.0 I suppose there is no more functions returning a BCPL used as a pointer..

Thanks,
ross

[Toni Wilen]

1.3 and older: dos.library was Tripos (with some little camouflage to make it look like exec compatible library. Disassemble dos LVOs 1.x vs 2.x+ to see the difference.), all "normal" pointers are internally converted to BCPL (BPTR) pointers (shifted by 2).

In 2.0 (including 1.4 beta) many dos BCPL functions were converted to C (or assembly), removing the need for pointer shifting. Of course existing BPTRs still need shifting for compatibility reasons but any dos function taking "normal" pointers don't need BPTR and back conversions anymore. Tripos is still there but only needed for compatibility with BCPL programs (for example all KS 1.x C: programs or L: handlers)

[ross]

Yes, I've noticed the TRIPOS layer in 1.3, and all the fancy register parameters passing
Then if i've understood the point is here: '"normal" pointers don't need BPTR and back conversions anymore'.
Argh.. 1bit lost everytime -> crash. I did not think of such unoptimized/odd thing.
This can explain the same binary acting in a different way.

Thanks,
ross

[remz]

Originally Posted by Asman

@Toni, meynaf - Thanks a lot.

Hi @Asman,
Sorry for reviving an old thread, but I am experiencing a similar issue on Hamulet: I'm trying to save the player's progression: I am sending an ACTION_FLUSH packet, but the drive motor stays stuck on once I take back the system & blitter, and the game hangs later on: I still need to investigate more to pinpoint the problem.