System takeover and multi floppy mess

[ross]

Take this situation:
- bare metal game with multiple floppy but hdd installable
- system take over but reanimated when needed
- files loading through standard Open(diskname:dir/filename)/Seek()/Read() DOS functions
- task->pr_WindowPtr=-1 so all the requesters are suppressed
- if Open() fail then a request (in my private non-system screen) to insert proper disk is displayed

All work as it should and compatibility for an hdd usage is guaranteed.
But there is a big contraindication.

If you swap floppys during system takeover Open() call never return to the caller and you are stuck with no possibilities to regain program control!
This sure is due to system that is not aware of the disk change and use now invalid structures.

Ok, a low level file loader can be used but for various reason (also 'academic') I want to avoid this.
Or a message for the user to not change the discs unless requested.. also no.

So after thinking about it I thought about simulating a disk change using an ACTION_INHIBIT packet to the file system before the takeover
and then, after the reanimation, uninhibit.

Before trying I have some questions:
- has anyone already tried this way and it works?
[EDIT] it works
- The ACTION packet to the file system need to be sent for each device separately? (DF0, DF1, DF2, DF3)
[EDIT] yes, to each device
- there are better/faster way, maybe sending a command directly to trackdisk.device?

Thanks.

[EDIT] forgot to mention that I need to support also <KS2.0

[Toni Wilen]

Do you modify CIA registers or floppy state when you restore system?

Floppy removal is remembered until drive is stepped at least once. System should still detect the change immediately when system is restored.

btw, packets are send to filesystem process, not to device.

[ross]

Originally Posted by Toni Wilen

Do you modify CIA registers or floppy state when you restore system?

CIA registers untouched.

Floppy removal is remembered until drive is stepped at least once. System should still detect the change immediately when system is restored.

True for >KS2.0, but on KS12/KS13 is totally unreliable.
Most of the time disk inserted during takeover is not recognized at all (or sometime partially, like wrong icon on WB and bad access).
Tried not only inside game, but also from a standard hdd KS/Workbench 1.3 install.
Anyway Open() get stuck.

btw, packets are send to filesystem process, not to device.

Yes, I get filesystem process handler with DeviceProc(DF0).
I'm forced to call it for every device.

There is a better way?

[ross]

More info.

As simple as:

start:
move #$4000,$dff09a
.. a dummy waiting loop ..
- meantime disk change -
move #$c000,$dff09a
rts

On Workbench, so with unmodified pr_WindowPtr, the requester on disk access say:
"Disk corrupt - task held
Finish ALL bla bla"

On cancel a beautiful guru :#8700000B

[meynaf]

Originally Posted by ross

There is a better way?

Leave the OS running in the background ?

[ross]

Originally Posted by meynaf

Leave the OS running in the background ?

I've tried but frame rate drop

I'll use the ACTION_INHIBIT method until proven otherwise.
There is some unwanted delay if you don't change the disks but better than hung.

Also found another interesting thing.
If you write an input handler to grab all event you need to not raise the task priority over 20 to not stall input.device (better at 19 'cause there is no latency on event).
And this is well know.
But I did not know that the events IECLASS_DISKINSERTED and IECLASS_DISKREMOVED are not reported if the priority is >1!
To tell the truth I've never been interested in being too much system-compliant, bashing the metal is much more interesting
At first I also tried this method but failed..

[Toni Wilen]

This is just a guess..

Perhaps 1.x trackdisk.device has accidental bug and seek to zero and handling of actual removal/insertion are separate parts of code and both check DSKCHANGE CIA bit instead of setting some internal "disk changed" bit. IMHO this kind of bug would be really easy to do.

So try seeking to track zero (using trackdisk.device, using hardware would leave trackdisk.device internal current track counter unchanged) before taking over the system.

[ross]

Originally Posted by Toni Wilen

This is just a guess..

Perhaps 1.x trackdisk.device has accidental bug and seek to zero and handling of actual removal/insertion are separate parts of code and both check DSKCHANGE CIA bit instead of setting some internal "disk changed" bit. IMHO this kind of bug would be really easy to do.

So try seeking to track zero (using trackdisk.device, using hardware would leave trackdisk.device internal current track counter unchanged) before taking over the system.

It works!
I've to check if it's faster than the other method (maybe yes, anyway the various seek in both cases slow down the access) but no more disk error.

Thanks like usual Toni.

[Photon]

Hehe. Yes, this is asking for trouble and there is an issue on 1.3. I think you should go by the game's requirements: if you need to load more than 2 disks of resources and if so go harddisk only.