There are a bunch of issues:
- The code itself is not difficult to understand and modify, but the UI code is impacting the performance of the actual cumulus, so things like showing the track or sector number in real time actually does impact loading time
- The tools required to modify and rebuild the firmware are not that easy to use, only specific versions are usable
- There are two versions of the cumulus, requiring different "drivers" to access the display, which means building two versions of the cumulus, and people need to flash the right one else they kind of brick their device

For me, the biggest issue was that I did not manage to find something that felt right for both a use as a programmer (being able to update/reset) as fast as possible and as a user (being able to navigate through a large library of floppies comfortably)

Ultimately I also stopped because some people wanted my changes in the main firmware repository and complained about me working on my own side folder, which was enough for me to lose interest: I did not want to sacrifice the main branch just for the sake of handling my own very specific needs.

DBug: Blaming others for having an opinion on your work style that "dis-incentivised" you to continue: hmmm... As I recall the branch issue was just that - your work could've been done on another branch rather than an entirely separate, non-visible repo. But okay, your choice to prosecute your time however you wish. Its just that, at the time, you weren't the only one investigating the Cumulus firmware, and it would've been nice to have worked with you on that, through the master repo (i.e. not a fork), on a separate, non-liability-inducing experimental branch.

From my side of things, the only thing really worth doing on the Cumulus is to adopt the firmware to accept commands *from the Oric* - i.e. being able to control Cumulus from the Oric itself. I started to do a bit of investigation into how this can be done, but like DBug said, its a very difficult toiling situation when you not only have two different hardware revisions to deal with, but also only certain tools work with each of those revisions.

Nevertheless, if there is a community effort to discuss/implement host- (Oric) control of the Cumulus, to make the UX a bit nicer, I'm all ears and would love to contribute. My Oric became a Super-Oric the day I got Cumulus wired up to it .. its really such a huge step forward from the bad old days of tape loading ...

As I recall the branch issue was just that - your work could've been done on another branch rather than an entirely separate, non-visible repo. But okay, your choice to prosecute your time however you wish. Its just that, at the time, you weren't the only one investigating the Cumulus firmware, and it would've been nice to have worked with you on that, through the master repo (i.e. not a fork), on a separate, non-liability-inducing experimental branch.

My work was done in a folder called "fw_dbug" inside "/public/oric/hardware/cumulus".
It was totally not in a separate and non-visible repo.

My whole point was to have people try different ways of tackling the firmware independently to see which ideas/ways of doing it sticked to the wall better, and doing my changes in the main code folder would have been counter productive.

I still don't understand what I did wrong, I did not create a branch because SVN branch handling is not very good, and for 17 files that was really not worth it, it also made it easier to compare multiple versions of the firmware side by side.

In any case, the code was not obliterated, it's in the history for anyone who want to access it.

I am not really so interested in managing the cumulus from the Oric. It would be indeed nice, but also requires deeper changes. See? Different interests also stopped the joint efforts

I proposed something very simple from the user point of view: the three right buttons to navigate up/down/select, the two at the left could be used one to iterate through different screens, the second could be a hotkey specific for that screen. Just as an example.

So you turn it on, select a slot with up/down, press middle button, enter in file selection, where you navigate using the three buttons too, select an image, it gets back to the slot screen where the left button is used to reset the Oric (maybe with a confirmation so you press it twice).

The upper left button could change screens to navigate through the slots (or main) screen, main menu (with preferences), dbug messages, and so on.

I also proposed to remove the write protection and rely on the file and sdcard attributes and to automount the last used images.

Ah, and now that I remember, there was also a warning about the micro used in the cumulus to be affected by a bug which reduced the number of times it could be flashed... that also scared people away

Meh, I don't feel like contributing to a project if I have to dig through some obscure path to find things, then manually compare 17 files in different folders to find the differences, when it could be so much simpler with a proper branch compare. Oh no, now I'm doing the "spit the dummy and throw the toys out of the sand pit" thing, yikes, its contagious ...

All stupid joking around aside, I'd be quite happy to push Cumulus forward - I have both revisions at hand, so I can test on both - the only issue is the tooling required to build firmwares for each. I don't have any issue with the current menu system that can't be resolved by giving the Oric control over the interface somehow, so for my part I'd rather work out a way for the Oric to get an enumerated list of files from Cumulus, allow the user to select one to mount, and so on ..