Manchmal gehen Dinge kaputt. Das ist okay, wir reparieren sie. (ATX)

[tschak909]

Entschuldigt, dass dies auf Englisch ist, es ist SEHR lang. Hoffentlich könnt ihr es angemessen übersetzen.

---

This will be a long #FujiNet #Atari8bit post.

TL:DR:
* #FujiNet is stable, in use by more than 5,000 people.
* We have to keep our toolchains up to date; sometimes this breaks things, e.g. ATX.
* I post messages asking for help to facilitate community engagement.

---

I want to thank each of the more than 5,000 users that are now using FujiNet. You are the reason we are constantly hacking on this, and trying to make it better. For most people, the most common functions work very well. With that said...

FujiNet supports Copy Protected disks on some platforms. On the #Atari8bit, this means we support disks encoded in the ATX format. This format provides extra information that allows for disk drive emulators to accurately fool copy protection methods.

Sometime late last year, it was reported that some ATX titles did not load. Immediate investigation did conclude that this was a regression, so as time permitted, I kept investigating the bug.

It became clear that the bug related specifically to protections that relied specifically on precise angular positioning of a sector within a track. The ATX media type simulates the spinning of a physical disk, and only sends data at the right time.

Because this wasn't happening on time, reads would take longer than a protection expected, and the copy protection fails.

Since this code hasn't been touched, since it was first implemented by @omf in the summer of 2020, there are a number of possible reasons why this regression is occurring: toolchain changes, more tasks = slower response, increased memory consumption, and so on...

For toolchain changes, we started on the earliest available version of ESP32 support for #PlatformIO, and we iterated through several versions of it, each time needing to fix our code so that it ran correctly under the newer toolchain.

Now I can hear some of you saying, "Why don't you just stick to a given toolchain and everything will be okay?" We can't do that. Toolchains are dynamically downloaded by #PlatformIO in response to building the software, and because disk space on servers is limited...

...these older versions of toolchain software will be marked deprecated, and unceremoniously removed from their repositories. This means that unless we quite literally freeze a virtual machine at the exact moment that it builds, older toolkits will refuse to work...

...This is untenable, not only for long term maintenance with existing developers, it means that new developers can't join in and help, because they can't get the required software, unless it were of course, delivered as a complete virtual machine...

...We tried to keep the version of the ESP32 toolchain at one specific version (PlatformIO ESP32 3.4.0 based on ESP-IDF 3.1), for almost two years, because of the very problem of having to fix our code-base every single time we upgraded the toolchain.

What broke the camel's back was that we were not only expanding to more platforms, which needed functionality that simply wasn't present in the selected toolchain...

...the toolchain we had selected had long since been marked deprecated, and its various artifacts (both code and documentation) were slowly disappearing from #PLATFORMIO and #ESPIDF on-line resources.

I chose this moment to bring in a brave soul, Oliver Schmidt, of the #a2retronet project, who decided to base his product on #FujiNet firmware. His design needed the newest #ESPIDF and #PLATFORMIO available...

...so he took the time to port our code to the latest toolchain (6.1.0 at the time), for all the platforms. He could have simply stopped there, and left it. But he also embedded the earlier 3.4.0 toolkit as a component, and made it work...

...This gave us a life-boat to check behavior between the old and the new toolkits, and in so doing, we were able to compare, contrast, and fix most of the breakages that did happen across all of our platform. This was above and beyond.

It can be hard sometimes to keep track of all of the various things happening around #FujiNet, because it is happening so quickly. Many platforms, many new features, and sometimes things regress, and we do try to fix them...

...but we don't do that behind closed doors. We aren't some peripheral manufacturer in the 1980s trying to make a profit, we are a collection of hackers trying to make a piece of hardware that we all want to use, and to that end, community involvement is essential!

To this end, I am UNBELIEVABLY transparent; some would say to a fault. I let everybody know what's going on, no matter if it's good news or bad, and I always ask for help, because if I never did, FujiNet would not have the team of talented people behind it at this moment.

So yes, I pull in, and I ask, even for help from members of potentially competing projects! Why? Because our code is open, and our competitors can benefit from it, too! We want people to use it, even if it spawns a competing product...

...because it means that we had a hand in bootstrapping something better. At least, that's how I choose to see it.

One final note: I have said this repeatedly. I have limited engineering cycles, BUT, I make infinite time to teach. This means that I will always take the time to teach someone how FujiNet works, in the hope that they will help make it better.

Thank you all for your time.

-Thom Cherryhomes