@VooDoo

i assume you configured writing speed to max, not to 6x..
is there a chance you could help me out figure why exactly fp limits your nec to 6x?

thanks,
t.

@joerg

Wow, now that's what i call a fast support :O.. you rock :))
thanks a lot :)

@joerg

I'm afraid that's not true. You will find a copy/paste of the code (i did cut some parts of the code away as they carry no value - basic checks if allocations and opens were successful). Please keep in mind that:
1) fryingpan custom allocator in regular mode always rounds up memory allocation for the next multiply of 8 (thus the real allocation is 65536 bytes)
2) fryingpan custom allocator in debug mode extends the allocation by 128 bytes both ways (built in mungwall).

here's a copy/paste of the code:

lock = DOS->Lock(sDirectory.Data(), ACCESS_READ);
eac = (ExAllControl*)DOS->AllocDosObject(DOS_EXALLCONTROL, 0);
ead = (ExAllData*) Alloc(65535);

do
{
bMore = DOS->ExAll(lock, ead, 65535, ED_COMMENT, eac);
ExAllData *ed = ead;

If you have any suggestions i'm open to hear them. So far SFS is the only file system that makes problems.

Tomek.

@joerg

harder you say...

well, enabling the 'harder' part means just switching one bit in command from '0' to '1' (that's tough, isn't it) and there you go.

oh, btw. remember that since your commands are performed 'immediately' some drives will eject your dvd-rw before the deicing is performed. that will screw the disc completely, but i guess you're aware of that ;) you took the 'harder' way after all :)

take care!
tom.

@MichaelMerkel

Please be more specific about that.

Blanking and closing disk actually "locks" the IDE bus in a matter, that until the end of operation nothing else can be transferred over the IDE bus. So, once the operation finishes, everything resumes.

Don't put this here, because these two behaviors (reported and yours) do not match completely.

tom.

btw. to the question 'why this must be like this'. it's quite simple. I avoid the 'immediate' flag, because I wouldn't be able to track completion, not to mention the final result of blanking. With 'immediate' flag set to 'true' (which would cause nonblocking operation) every operation would be successful, no matter it finished properly or not. Also, measuring time would be impossible (especially if closing failed at some point, and later drive was unable to detect the unclosed disc - that often happens with dvd-rw media and may turn into a big pain in the butt, since dvd-rw's require sort of a strong laser to detect such discs later)

@Lio

Apart from the fact that this now clearly describes the IDE bus lockup (i wouldn't really know how to make it lock up honestly, but I admit I have experienced exactly same problem since I updated to OS4 Final), I wonder if you considered reducing the DMA to 2 as it really should be? this would not hurt you any, since there are no optical drives (ok, there are neither CD nor DVD drives available to normal end user) capable of transferring 33MB/s (the newest and fastest DVD drives reach about 25MB/s).

Please try to reduce the transfer rate and check again.
tom