03 June 2017, 21:40 | #22 | |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,583
|
Quote:
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. |
|
03 June 2017, 21:58 | #23 |
68k
Join Date: Sep 2005
Location: Somewhere
Posts: 829
|
@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. |
04 June 2017, 00:31 | #24 | |
Join Date: Jul 2008
Location: Sweden
Posts: 2,269
|
I think ACTION_FLUSH is the way to go, from the Amiga Guru Book:
Quote:
|
|
04 June 2017, 15:39 | #25 | |||
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,583
|
Quote:
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:
AROS sources may be also useful. Quote:
|
|||
04 June 2017, 16:31 | #26 | ||
Registered User
Join Date: Aug 2004
Location:
Posts: 3,351
|
Quote:
Quote:
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. |
||
04 June 2017, 21:46 | #27 | ||
68k
Join Date: Sep 2005
Location: Somewhere
Posts: 829
|
@Toni, mark_k - Thanks for explanation
Quote:
Quote:
|
||
05 June 2017, 10:15 | #28 | ||
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,583
|
Quote:
Do you want C or asm example? Quote:
|
||
05 June 2017, 11:17 | #29 |
68k
Join Date: Sep 2005
Location: Somewhere
Posts: 829
|
@Toni - asm example .
|
11 June 2017, 18:57 | #30 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,583
|
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 Last edited by Toni Wilen; 11 June 2017 at 22:15. |
27 June 2017, 16:12 | #31 |
68k
Join Date: Sep 2005
Location: Somewhere
Posts: 829
|
@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 |
27 June 2017, 18:29 | #32 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,583
|
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 |
05 July 2017, 21:10 | #33 |
68k
Join Date: Sep 2005
Location: Somewhere
Posts: 829
|
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.
|
05 July 2017, 21:12 | #34 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,583
|
BCPL and Tripos strikes again. All dos structures (at least those that were introduced before 2.0) must be long word aligned.
|
06 July 2017, 10:30 | #35 |
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,366
|
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.
|
06 July 2017, 11:14 | #36 |
68k
Join Date: Sep 2005
Location: Somewhere
Posts: 829
|
@Toni, meynaf - Thanks a lot.
|
06 July 2017, 17:47 | #37 | |
Defendit numerus
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 54
Posts: 4,508
|
Quote:
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 |
|
06 July 2017, 17:58 | #38 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,583
|
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) |
06 July 2017, 18:12 | #39 |
Defendit numerus
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 54
Posts: 4,508
|
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 |
20 July 2023, 00:56 | #40 |
Registered User
Join Date: May 2022
Location: Canada
Posts: 143
|
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. |
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Cd32 audio read routines using hardware | jotd | Coders. Asm / Hardware | 40 | 23 January 2024 18:07 |
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 |
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 |
|
|