Using DOS routines after a system take over

[majikeyric]

Hi!

When the system has been taken over (multi-task stopped, IRQs/DMAS/ADKCON registers modified, blitter owned, user copperlist running...etc.).
What is the minimum requirement to be able to use the DOS open/read/write routines ?

Thanks.

[jotd]

as long as you're not tampering with memory you don't own, it should work fine. Not sure about multitask, but calling Forbid & Permit at the proper locations should fix that.

A lot of games use DOS to load files, and don't use the rest of the libraries, but use their own VBL interrupt and hardware banging (using OwnBlitter/DisownBlitter also helps). Also backup system copperlist before overwriting in case you want a chance to return to the OS on exit.

[meynaf]

DOS absolutely needs multitask to work and will actually violate Forbid state.
IRQ/DMA probably need to be restored.
User coplist and blitter owned are no problem as long as no system request can be displayed as result of these Dos calls.

[Toni Wilen]

timer.device is the most important (CIA timers = level 2/6 interrupts and vblank). Floppy access of course needs disk DMA, ADKCON floppy bits etc.. (and blitter if KS 1.x). You may get away without timers with some HD controllers..

I recommend to always temporarily restore INTENA properly and free blitter when calling system routines. Only important DMA channel is floppy DMA.

[mark_k]

Set your pr_WindowPtr to -1 to suppress DOS requesters (e.g. read/write error, insert volume ... etc.).

[alkis]

Have a look at this,
http://eab.abime.net/showthread.php?t=70691
last post has source code that loads a file from floppy while starfield is running.

Hope it helps.

[majikeyric]

Thanks all for your information

I have successfully managed to load files using standard dos routines after a system take over by restoring the DMACON, INTENA, ADKCON registers, the IRQs vectors and doing a DisownBlitter().

[roondar]

Just a quick note here, in my experience the above works fine. But saving files is a different story. There seems to be no way to check if Amiga OS is done writing to a file, so you'd have to guess (as in - wait <x> seconds after the close call returns and hope that was long enough).

Maybe there is a way to do this in a nicer way, but I haven't found one.

[phx]

Originally Posted by roondar

Maybe there is a way to do this in a nicer way, but I haven't found one.

There is. Write your own disk routines (trackloader). Never use the OS when you have taken over the system. You are calling for problems.

[Toni Wilen]

So in your opinion whdload should only support floppies?

[roondar]

Well, a trackloader/saver would be a nice option, but I've not found a good tutorial/example on those yet. That is, I did find several example trackloaders with source but no tracksavers at all.

[phx]

Originally Posted by Toni Wilen

So in your opinion whdload should only support floppies?

Certainly not. The question was for a nicer way to do it. It doesn't feel nice to me to reanimate the OS after you have taken over everything. Whdload has not much choice, though.

Originally Posted by roondar

I did find several example trackloaders with source but no tracksavers at all.

trackdisk.asm from the Solid Gold source (Aminet) can also write to disk (single blocks, and/or format tracks).

When nowadays writing to disks (like high scores, etc.) I would recommend to format a whole track with the data and don't care about read/write errors. Most disks have become so bad that errors are common, and you don't want that they render your game useless.

[Galahad/FLT]

Originally Posted by Toni Wilen

So in your opinion whdload should only support floppies?

You do realise WHDLoad performs ram saves whilst the game is running, and when you use the quit key it then writes the files out to hard drive?

[alpine9000]

Originally Posted by Galahad/FLT

You do realise WHDLoad performs ram saves whilst the game is running, and when you use the quit key it then writes the files out to hard drive?

I had been thinking for a way to save high scores on my HD installable versions and this was the only solution I could come up with also. Short of making the game system friendly....

[roondar]

Originally Posted by phx

trackdisk.asm from the Solid Gold source (Aminet) can also write to disk (single blocks, and/or format tracks).

When nowadays writing to disks (like high scores, etc.) I would recommend to format a whole track with the data and don't care about read/write errors. Most disks have become so bad that errors are common, and you don't want that they render your game useless.

I'll definitely check that out, thanks!

[Asman]

Originally Posted by roondar

There seems to be no way to check if Amiga OS is done writing to a file, so you'd have to guess (as in - wait <x> seconds after the close call returns and hope that was long enough).

Maybe there is a way to do this in a nicer way, but I haven't found one.

I don't get it. What does mean there seems to be no way to check if OS done writing to a file ? I don't see where is the problem. Could you explain a bit more. Thank you.

[roondar]

Originally Posted by Asman

I don't get it. What does mean there seems to be no way to check if OS done writing to a file ? I don't see where is the problem. Could you explain a bit more. Thank you.

It means that you can write to a file, tell the operating system you are done but the OS is still writing after that and won't tell you when it's done. So effectively, your program can't know when the OS is done writing to disk and a program would have to guess.

Which can mean guessing a too short delay and losing the file or corrupting the disk

On other operating systems, you can usually force the OS to finish writing to disk before telling you it's done with the file, not on the Amiga - its OS assumes you'll be running under multitasking all the time and therefore don't need to know that the OS is still busy writing.

As phx rightly said, trying to work around that is messy and not something that one should really do (and I'll admit being guilty immediately, never to old to learn and all that!)

[Asman]

Thanks roondar for explanation. But with your approach (OS is still writting after I am done) you will never known (mean your program which call Write for example ) if there was an error during writting. If I use Write from dos.library then this function will return how many bytes were written. Of course I must wait till floppy motor will be off after read/write, but there is no guessing - 2 seconds should be enough. If I am wrong then please correct me.

[roondar]

Originally Posted by Asman

Thanks roondar for explanation. But with your approach (OS is still writting after I am done) you will never known (mean your program which call Write for example ) if there was an error during writting. If I use Write from dos.library then this function will return how many bytes were written. Of course I must wait till floppy motor will be off after read/write, but there is no guessing - 2 seconds should be enough. If I am wrong then please correct me.

Ah, sadly you are wrong. The Write call will return before all bytes are actually written (it will return when the given bytes are all in the write buffer, which is not the same). You can even see that the OS returns prior to finishing when you save a file in an OS legal program. These almost always give you control back before disk activity is finished.

And you can't use the floppy motor as indicator either, because the OS sometimes turns it off and then on again during writing (I've noticed this many times).

Which is why waiting a longer time is often used. And usually, that works - but you can't guarantee it. I've had test programs cause corrupted disks this way more than once.

[Toni Wilen]

Write will return quickly (may even return practically instantly) if used filesystem and/or device driver has write buffers that are flushed later.

Sending ACTION_FLUSH directly to filesystem should force write buffer flush but I don't know if all filesystems support it. And even if it worked, there is still device driver layer that may ignore any flush attempts (CMD_UPDATE should do it)..