English Amiga Board Amiga Lore


Go Back   English Amiga Board > Coders > Coders. General

 
 
Thread Tools
Old 03 June 2017, 21:31   #21
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,481
CMD_UPDATE is a no-op with some device drivers. What about ACTION_INHIBIT or Inhibit()?
mark_k is offline  
AdSense AdSense  
Old 03 June 2017, 21:40   #22
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 42
Posts: 19,542
Quote:
Originally Posted by mark_k View Post
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.
Toni Wilen is offline  
Old 03 June 2017, 21:58   #23
Asman
68k

Asman's Avatar
 
Join Date: Sep 2005
Location: Somewhere
Posts: 627
@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.

Last edited by Asman; 03 June 2017 at 22:06.
Asman is offline  
Old 04 June 2017, 00:31   #24
Leffmann

 
Join Date: Jul 2008
Location: Sweden
Posts: 2,010
I think ACTION_FLUSH is the way to go, from the Amiga Guru Book:

Quote:
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.
Leffmann is offline  
Old 04 June 2017, 15:39   #25
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 42
Posts: 19,542
Quote:
Originally Posted by Asman View Post
@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.

Quote:
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.

Quote:
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..
Toni Wilen is offline  
Old 04 June 2017, 16:31   #26
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,481
Quote:
Originally Posted by Asman View Post
By the way are there any docs about AmigaDOS packets and how to use it ?
See the AmigaDOS Packet Interface Specification.

Quote:
Originally Posted by Toni Wilen View Post
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.

Last edited by mark_k; 04 June 2017 at 16:39.
mark_k is offline  
Old 04 June 2017, 21:46   #27
Asman
68k

Asman's Avatar
 
Join Date: Sep 2005
Location: Somewhere
Posts: 627
@Toni, mark_k - Thanks for explanation

Quote:
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.


Quote:
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 ?
Asman is offline  
Old 05 June 2017, 10:15   #28
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 42
Posts: 19,542
Quote:
Originally Posted by Asman View Post
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?

Quote:
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).
Toni Wilen is offline  
Old 05 June 2017, 11:17   #29
Asman
68k

Asman's Avatar
 
Join Date: Sep 2005
Location: Somewhere
Posts: 627
@Toni - asm example .
Asman is offline  
Old 11 June 2017, 18:57   #30
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 42
Posts: 19,542
Late reply, sorry..

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

Code:

	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.

Last edited by Toni Wilen; 11 June 2017 at 22:15.
Toni Wilen is offline  
Old 27 June 2017, 16:12   #31
Asman
68k

Asman's Avatar
 
Join Date: Sep 2005
Location: Somewhere
Posts: 627
@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.
Code:
;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
Asman is offline  
Old 27 June 2017, 18:29   #32
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 42
Posts: 19,542
Quote:
Originally Posted by Asman View Post
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.

Last edited by Toni Wilen; 27 June 2017 at 19:19. Reason: added packet system
Toni Wilen is offline  
Old 05 July 2017, 21:10   #33
Asman
68k

Asman's Avatar
 
Join Date: Sep 2005
Location: Somewhere
Posts: 627
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.
Asman is offline  
Old 05 July 2017, 21:12   #34
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 42
Posts: 19,542
BCPL and Tripos strikes again. All dos structures (at least those that were introduced before 2.0) must be long word aligned.
Toni Wilen is offline  
Old 06 July 2017, 10:30   #35
meynaf
68k wisdom
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon (France)
Age: 44
Posts: 2,370
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.
meynaf is offline  
Old 06 July 2017, 11:14   #36
Asman
68k

Asman's Avatar
 
Join Date: Sep 2005
Location: Somewhere
Posts: 627
@Toni, meynaf - Thanks a lot.
Asman is offline  
Old 06 July 2017, 17:47   #37
ross
Vae victis!

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Posts: 442
Quote:
Originally Posted by meynaf View Post
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
ross is online now  
Old 06 July 2017, 17:58   #38
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 42
Posts: 19,542
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)
Toni Wilen is offline  
Old 06 July 2017, 18:12   #39
ross
Vae victis!

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Posts: 442
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
ross is online now  
AdSense AdSense  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
decompression routines Toni Wilen Coders. General 12 17 May 2017 00:30
Using System DOS commands within SAS-C Zetr0 Coders. System 5 23 April 2017 18:14
Cd32 audio read routines using hardware jotd Coders. Asm / Hardware 23 23 March 2017 17:00
OSTER's assembler routines & tricks Shoonay Coders. Tutorials 8 17 November 2016 15:41
Checksum routines in games Joejoe Coders. Tutorials 11 26 December 2009 20:24

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 01:51.


Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2017, vBulletin Solutions, Inc.
Page generated in 0.26366 seconds with 12 queries