Yes, I'd say so. What I'd do is:
-Correct the number of zeros in the header.
-Correct the $22 instead of $4e error
-Correct the loop so it does not produce extra DRQ (inside the loop it should be set DRQ, Pause, read data register, store, decrement counter)
-Probably force a card update (flush) after the write operation is finished.

I wouldn't try to solve the missing handling of BUSY bit nor anything related to the FAT driver. It should work that way.

I'd also take this opportunity to change some more things in the firmware, such as the default protected image thing or the way the Oric is reset.

But I'd try to produce a version of the game which simply bypasses the bug, because not everyone is going to update their firmware... And, besides, who would do it?

@Symoon give it a try, but no need for you to modify the disk image. Just check what happens to discard it is only a timing issue in my unit.

Ok, it took a while to find back a machine that worked with the Cumulus but finally I could do the test (on an Oric-1!), and... After a few disk flashes, I got the red bar (the disk was unportected).
So it's not just your Cumulus Chema, it seems!

Yes, I'd say so. What I'd do is:
-Correct the number of zeros in the header.
-Correct the $22 instead of $4e error
-Correct the loop so it does not produce extra DRQ (inside the loop it should be set DRQ, Pause, read data register, store, decrement counter)
-Probably force a card update (flush) after the write operation is finished.

Does the Cumulus firmware also implement $22 instead of $4E, of was it just FloppyBuilder?

But I'd try to produce a version of the game which simply bypasses the bug, because not everyone is going to update their firmware... And, besides, who would do it?

Actually, I never thought about that, but who made the original Cumulus code?
It must have been a huge work, was it Retromaster alone? Or Metadata?

Updating the firmware of cumulus is relatively easy, the two difficulties are:
- Compiling the firmware requires a specific toolchain
- You need to compile the firmware twice - one for each type of display -

After it's relatively easy to update the cumulus itself, but you need to use the right firmware, else the display stops working

I had the toolchain setup and made some tests, but I changed my hard drive since, and now all that is lost (the old HD simply broke down ).

There is a list of things that should be done to the firmware, and there was some enthusiasm to do so at the beginning, but soon after everybody disappeared and nothing was really done (me included, I was working on the support of old SD cards, with no success).

Apart from this bug, we badly need some redesign of the UI, so you don't have to press so many buttons to load a disk and reboot, images are not write-protected by default, and the general usability improves a bit.

And that not counting the idea about moving the critical code to interrupt service routines and keeping UI as background task, updating things only when there is time to do so :/

With the enormous help of Fabrice Frances (he is doing the work, really) I am not only improving the disk routines in FloppyBuilder ()and therefore, in Blake's 7) a lot, but also started working on supporting the Jasmin.

The new routines in Microdisc are so robust that you can pull out the disk while loading and put it back in, and the loading resumes.

And, at last, after a huge effort, the game booted on Jasmin under emulation!!! It does not mean it works on real hardware, as the bootsector needs tweaking and several corrections, but it is a good start. Also writing should be added.

But I now understand where the problem was, and supporting both Microdisc and Jasmin on the same disc is very possible

The biggest problem is that I don't have a Jasmin unit with a real floppy to test... So if anyone has it and is willing to make some tests for me, raise your hand.

Alright, the game now works (tested only under emulation) with both Microdisc and Jasmin

It boots, works, saves and loads on both systems. I still need to test it with real drives and floppies, as well as with Cumulus, because several routines had to be rewritten. Current code is in the repository.

I think I also kept the correct alignment when accessing registers, so it should work even with the Telestrat bug.

Now I need to test in a real Jasmin drive, but I don't have one... Anyone willing to do the test for me?

Now I need to test in a real Jasmin drive, but I don't have one... Anyone willing to do the test for me?

If he ever has time, I think Jede is your best luck (now is that denouncing a friend? )
Last time I plugged my Jasmin 2, it didn't work and ended up smoking... Since then it's shelved in a croner, waiting for a kind hardware master to have a look at it (next Oric meeting maybe).
I also got a Jasmin 1, but at my parents', where I won't be before a while...

In any case the routines are now working for saving and loading with correct error checking (I pulled the disk out while writing, and back in and it saved the game properly and worked for Microdisc (my unit with real FDD) and Jasmin (emulation with Oricutron and Euphoric). All accesses to FDC registers are aligned so the code should work on the Telestrat, although the disk won't boot directly on that machine.

Still working on that, but routines are now quite definitive, but for the disk picture and color flashing, which should be put externally to the loader code to make it more general.

You can see them in the floppycode folder in Blake'7 sources in the repository.

I guess when we have this fully functioning version it will become the reference implementation of the loader system, which means I'll use it as the base for the updated OSDK sample project, which I guess means I'll have to make some small application that allows loading and saving of stuff.

Does somebody remember the discussion (here and here) about 'TrippleBootDisk' with FloppyBuilder ?
Well... 4+ years later (which is not bad)... I have it!
Once generated with FloppyBuilder one and the same image boots in Oricutron with all FDC's: Microdisk, Jasmin and 8D. Of course for 8D the image simply needs to be stripped to plain sector data.
The limitation in size is clear: 1 side, 35 tracks, 16 sectors or 143360 bytes total per disk.
I'll prepare a demo asap, but I wonder if it makes sense to have both different loaders in one image file when the DSK file formats are different?