Porting complex applications (especially those written in C) from x86 to ARM can be pretty non-trivial.
I can't speak to the GIMP code in particular, but I've done several x86->ARM source ports of other complex software, and each time there are things which work on x86 and don't work on ARM, resulting in nasty crashes, or worse.
We live in an age where combining music, software, and signal processing can let you do some amazing things. I can imagine a high-fidelity simulation of this instrument's timbre before it's ever built, by using the mechanical CAD model to produce an acoustic model, and then modeling the response of the wood to an incident acoustic wave.
The whole world of software ports basically boils down to "anything is possible, given enough memory, pixels, and time". The actual process of porting anything is sometimes incredibly tedious (e.g. "scour the entire source code for unaligned memory accesses, and manually rewrite all of them"), but also gives a chance to do some very clever things (like, "use the piezo speaker to beep out the address of a fault, because nothing else works on the device after a crash").
What made me do it was 1) the satisfaction I got from seeing my work produce something which, at first glance, shouldn't exist (Quake... on an MP3 player?), all while 2) learning deeply about software close to the bare metal, which is fairly hard to do early in one's career. There's of course also the factor of having lots of free time - I did my port when I was still a student with not very many responsibilities, so I could afford to spend entire evenings and weekends poring through mountains of C code. Nowadays, not so much...
The whole world of software ports basically boils down to "anything is possible, given enough memory, pixels, and time". The actual process of porting anything is sometimes incredibly tedious (e.g. "scour the entire source code for unaligned memory accesses, and manually rewrite all of them"), but also gives a chance to do some very clever things (like, "use the piezo speaker to beep out the address of a fault, because nothing else works on the device after a crash").
What made me do it was 1) the satisfaction I got from seeing my work produce something which, at first glance, shouldn't exist (Quake... on an MP3 player?), all while 2) learning deeply about software close to the bare metal, which is fairly hard to do early in one's career. There's of course also the factor of having lots of free time - I did my port when I was still a student with not very many responsibilities, so I could afford to spend entire evenings and weekends poring through mountains of C code. Nowadays, not so much...
There is no way this could work. The EDA tool (e.g. KiCAD) is only the first step of the fabrication process - you generate Gerbers from your KiCAD board layout, which are a highly standardized format that can be viewed in a variety of independent pieces of software. There are also multiple stages of design validation - both in the design phase, and then in the physical phase of actually inspecting your fabricated boards. The chances of any "malicious" circuitry slipping in are next to nil.
The idea is that wrapping a function around a circle at the right frequency (i.e. length per spiral) will cause peaks and troughs to align. It just happens here that the "right" frequency is 1/year.
The AGPTek Rocker is one of our last targets still in production and can be acquired for around $50. I haven't used one myself, but from what I hear it's fairly decent but not perfect.
That's correct. I realize my parent comment was ambiguous. I'm the author of the port; the video is by a different developer who's since taken it down.
There are virtually no good ways to debug code on-device with Rockbox, short of adding in a bunch of function calls to print variable values to the device's screen. This usual method, though slow, works surprisingly well with most bugs -- but this assumes that the code is in a sane enough state to be able to write to the screen properly (stack corruption, for example, would render it unusable).
There were a few bugs which were not debuggable with this "trace all the things" method, and those were the ones which required the most ingenuity. I remember having to root out a few bugs which absolutely trashed the processor state and made complex things (like function calls to print things) fail miserably.
One such class of bug was the unaligned read (this is ARM, remember). Thankfully, ARM has a way to set an "alignment trap" to trigger an interrupt when an invalid unaligned read happens. The only problem was that, of course, I couldn't figure out what code was responsible for the unaligned read.
My solution to this was quite the gem -- I modified the ARM exception handler to use the iPod's internal piezo buzzer to beep out the faulting PC address in a sequence of 32 high/low pitched beeps. The piezo, driven by a single memory-mapped register, could be controlled with minimal code (and most importantly, no function calls).
Resolving that bug took quite a bit of serendipity. The break came when I was on the verge of giving up on the assembly rewrite and reverting back to C. I'd left my "frozen" iPod sitting around for a while. ~15 minutes later, I came back, and everything was back to normal -- this was evidence that I was not seeing a true lockup, but rather an extremely long delay (consistent with an integer wraparound).
Author here. This is actually a fairly old project of mine by now, but I just recently submitted it to Hackaday, which is probably why it's surfaced here.
The original video demo has been taken down by the author (not me) due to some concerns of his, but he is reportedly planning to reshoot it soon.
I can't speak to the GIMP code in particular, but I've done several x86->ARM source ports of other complex software, and each time there are things which work on x86 and don't work on ARM, resulting in nasty crashes, or worse.
See here for one of those (not AArch64, but ARM nonetheless): https://news.ycombinator.com/item?id=22176285