Using DOS routines after a system take over

[hooverphonique]

Originally Posted by remz

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.

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.

[Olaf Barthel]

Originally Posted by remz

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.

The file write operation will start a timeout of about three seconds during which the drive motor will keep spinning just in case more data needs to be written.

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.

[remz]

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!

[Olaf Barthel]

Originally Posted by remz

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?

The responsibility for changing and, if necessary, restoring the pr_WindowPtr value rests with the Process which owns it. If you launch a program from the Workbench, then a Process will be created for it. But if you start a program from the CLI (or shell) then it will be running as part of that CLI, which loaded the program. Until that program exits, it will remain the owner of the CLI Process and can change/restore the pr_WindowPtr value as needed.

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.

[remz]

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?

[Olaf Barthel]

Originally Posted by remz

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?

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.