20 July 2023, 11:07 | #41 | |
ex. demoscener "Bigmama"
Join Date: Jun 2012
Location: Fyn / Denmark
Posts: 1,643
|
Quote:
Floppy motor running is not really an indication of anything as it is turned off on a timeout basis after the drive hasn't been used for a while. |
|
20 July 2023, 12:38 | #42 | |
Registered User
Join Date: Aug 2010
Location: Germany
Posts: 537
|
Quote:
When you close the file, the trackdisk.device Task will keep waiting for another three seconds during which the motor will be spinning. If you shut down multitasking and select interrupts at that point, the trackdisk.device Task will never get the chance to be notified of the timeout having elapsed and the motor will keep running. ACTION_FLUSH and ACTION_INHIBIT have something in common. Basically, ACTION_INHIBIT will eventually execute the same shutdown code which ACTION_FLUSH invokes directly (postpone packet processing, write the bitmap to disk, push any dirty write buffers back to disk, clear the disk cache, turn off the motor). But ACTION_INHIBIT does more: it checks if there are currently any files still open and, if so, it will tell you it cannot proceed, returning FALSE. Otherwise, it will basically do what ACTION_FLUSH does. There is no single reliable bullet-proof approach to get the file system to safely write anything yet unwritten to disk. Sure, ACTION_FLUSH will write any buffered data to disk and shut down the drive motor. It's designed to be called while the file system is still active and has not been told to take its hands off the wheel through ACTION_INHIBIT. What could work is this: 1. invoke ACTION_FLUSH after you have closed the file you wrote data to, 2. invoke ACTION_INHIBIT with dp_Arg=1 and verify that it has succeeded (dp_Res1 is not 0), 3. if it has succeeded, invoke ACTION_INHIBIT with dp_Arg=0 and that should be it!, 4. if ACTION_INHIBIT failed (dp_Res1 is 0), delay for a bit (half a second?) and try again until ACTION_INHIBIT succeeds, then go back to step 3. The catch here is that ACTION_INHIBIT with dp_Arg=1 may never take effect, or it may take longer than is acceptable for you. Some "spoilsport" may just be running in the background and open & read files on its own. Hm... on second thought, it might not be a bad idea to use ACTION_INHIBIT (with dp_Arg=1) when your program starts, and ACTION_INHIBIT (with dp_Arg=0) when you want to save something to disk, then to use ACTION_INHIBIT (with dp_Arg=1) before you return to game state and multitasking, etc. disabled. Last edited by Olaf Barthel; 21 July 2023 at 10:12. |
|
22 July 2023, 00:47 | #43 |
Registered User
Join Date: May 2022
Location: Canada
Posts: 140
|
Thank you, using ACTION_FLUSH appears to work fine!
I do have a small follow-up question: According to what I saw in this thread, setting pr_WindowPtr to -1 on my process is good because it allows the I/O functions from getting the errors instead of showing a requester (which wouldn't be visible since the copper and screen are taken over.) My question is: The documentation mentions a program that modified pr_WindowPtr should restore its original state upon quitting. I can confirm that when my game is launched from CLI, once I exit, the original CLI window no longer displays requesters. But if a program restores it to the original value, how could we guarantee that this "old previous value" is still valid? I mean, the window or screen could have belonged to someone else, that was closed in the meantime? This might be an edge case not worth considering, and perhaps just restoring to its previous value would be good enough? Thank you again! |
22 July 2023, 09:24 | #44 | |
Registered User
Join Date: Aug 2010
Location: Germany
Posts: 537
|
Quote:
While other Processes or even Tasks may change the pr_WindowPtr value of any other Process, the standard approach remains valid: if your program changes this value, it ought to restore it before it exits. It does make sense, though, to check if the current value of pr_WindowPtr is still what your program expected it to be at this point before restoring it. If the pr_WindowPtr value was changed to something else, it may be prudent not to restore it to the value your program found there when it started. |
|
22 July 2023, 16:13 | #45 |
Registered User
Join Date: May 2022
Location: Canada
Posts: 140
|
Thank you very much Olaf, your explanation is helpful.
What could we say about using "run" to launch the program? (I'll need to go test it): would this also allow affecting the CLI parent process, or in this scenario, run is spawning a separate process? |
23 July 2023, 10:11 | #46 |
Registered User
Join Date: Aug 2010
Location: Germany
Posts: 537
|
The Run command will create a new CLI process which will share the input/output streams with its parent. It will also inherit the Process pr_WindowPtr value from its parent.
|
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 |
|
|