1
New Ports / Re: Need help compiling rockbox using devkitARM toolchain.
« Last post by amachronic on Today at 04:47:27 PM »As far as I know the 3DS has an operating system of some sort. If you are able to run without it, then the native ARM threading code is what you want. If you're under an OS then you probably want the SDL threading approach.
2
Hardware / Re: Are "1TB" micro-SD cards 1000GB or 1024GB?
« Last post by saratoga on Today at 10:37:19 AM »I admit this is increasingly not a Rockbox-specific topic. But how 'smart' are SD cards? Will they gradually reduce in capacity as sectors get marked 'bad'? I was under the impression that SD cards are significantly 'dumber' than CF cards with regard to that sort-of-thing. Just am puzzled why I end up with such different total capacity with combinations of what are nominally the same capacity cards (which makes it tricky to get as close as possible to the 2TiB limit without going over it).
They do at least some wear leveling so you shouldn't have loss of capacity until essentially the whole array is finished and the controller can't find any remaining good block to map to a new write request. I think at that point they stop working or go read only.
3
Hardware / Re: Are "1TB" micro-SD cards 1000GB or 1024GB?
« Last post by gevaerts on Today at 08:50:05 AM »I suspect SD cards *used* to be dumber than CF cards, but I also suspect that that was a matter of having the space (and heat capacity) for a fancy controller. These days everything is smaller and less power hungry, so I don't think there's a real reason to not have similar fancy logic in an SD card, at least a higher end more expensive one.
I'm speculating though
I'm speculating though
4
Other - Installation/Removal / Re: iBasso DX90 Rockbox 4.0 issue
« Last post by speachy on Today at 08:44:42 AM »Almost everything is working seamlessly, except one annoying issue: the player does not recognize whether the device is powered by the adapter or by the battery. In both cases, it behaves as if the adapter is plugged in. The statusbar shows the battery level correctly, but it always shows the power icon, never the battery icon.
The ibasso-specific code hasn't meaningfully changed in nearly a decade, but as it turns out, it was inadvertently switched to using more generic code to query the charging status. That's switched back now.
You can try the current dev build (which incorporates this change) from: https://build.rockbox.org/
or wait for the 20240523 nightly.
I haven't been able to test this (I have a DX50 but haven't figured out how to successfully construct a patched OF image...) so please let us know if this works.
5
Hardware / Re: Are "1TB" micro-SD cards 1000GB or 1024GB?
« Last post by Frankenpod on Today at 07:39:13 AM »I admit this is increasingly not a Rockbox-specific topic. But how 'smart' are SD cards? Will they gradually reduce in capacity as sectors get marked 'bad'? I was under the impression that SD cards are significantly 'dumber' than CF cards with regard to that sort-of-thing. Just am puzzled why I end up with such different total capacity with combinations of what are nominally the same capacity cards (which makes it tricky to get as close as possible to the 2TiB limit without going over it).
6
New Ports / Re: Need help compiling rockbox using devkitARM toolchain.
« Last post by gama on May 21, 2025, 06:25:11 PM »@speachy, hi there.
I have made some progress. For now I started compiling as an sdl application.
There is only one thing left to build the main rockbox binary, the firmware/kernel/thread.c code. I have been reading the different implementations (unix, win32, arm) but don't know how should I implement it for the 3DS.
If I try to build the arm/thread.c file the assembler fails with:
Can you please let me know of your comments?
[EDIT]
Ok, if I compile the arm/thread.c code within a 3ds example app, the code compiles fine. There must be something missing in the rockbox makefile.
I have made some progress. For now I started compiling as an sdl application.
There is only one thing left to build the main rockbox binary, the firmware/kernel/thread.c code. I have been reading the different implementations (unix, win32, arm) but don't know how should I implement it for the 3DS.
If I try to build the arm/thread.c file the assembler fails with:
Code: [Select]
firmware/kernel/thread.o
{standard input}: Assembler messages:
{standard input}:765: Error: bad instruction `ldmiane r4,{ r0,pc }'
make: *** [/home/stalker/3ds-dev/rockbox/tools/root.make:478: /home/stalker/3ds-dev/rockbox/build-n3ds/firmware/kernel/thread.o] Error 1
Can you please let me know of your comments?
[EDIT]
Ok, if I compile the arm/thread.c code within a 3ds example app, the code compiles fine. There must be something missing in the rockbox makefile.
7
Other - Installation/Removal / iBasso DX90 Rockbox 4.0 issue
« Last post by Josef K. on May 21, 2025, 10:06:56 AM »Hello,
I just found out that there is a new version of Rockbox and I wanted to try it on my DX90. I overwrote the original Rockbox installation (the ".rockbox" directory on internal memory) with the new version from Daily development builds page. Almost everything is working seamlessly, except one annoying issue: the player does not recognize whether the device is powered by the adapter or by the battery. In both cases, it behaves as if the adapter is plugged in. The statusbar shows the battery level correctly, but it always shows the power icon, never the battery icon. For this reason, it is not possible to set, for example, different backlight times for battery mode and power mode. Is there any way to solve this issue?
I'm using Rockbox on my DX90 for years. I have installed "official rockbox binary builds" from napych.com:
- firmware-dx90-2.5.1-20160716 dual bootloader (based on newest iBasso firmware V2.5.1)
- Rockbox Version: 46f8e0e-150609 (from the same source). This version doesn't have such issue.
EDIT:
In the meantime, I tested the player in more detail and unfortunately I came across several other problems that are more serious.
- The biggest problem is the crackling sound, which appears especially in tracks with higher frequencies (96, 192 KHz, Flac format). I think this is caused by the expansion of frequencies in the new version of Rockbox: if the frequency is set to 44.1 or 48 kHz, the problem almost disappears. Unfortunately, it does not disappear completely, it only becomes significantly smaller. Again, this does not happen in the older version of Rockbox. Or maybe, to be honest, the problem is so small that it is not noticeable
- There is also a momentary interruption of playback when the player wakes up from the screen off mode.
I also tried the original Mango firmware - none of these problems are manifested here. Even tracks with higher frequencies are played without problems.
After all these findings, I think I will continue to use the original version of Rockbox, which works well for me.
However, thank you in advance for any answers or comments.
JK
I just found out that there is a new version of Rockbox and I wanted to try it on my DX90. I overwrote the original Rockbox installation (the ".rockbox" directory on internal memory) with the new version from Daily development builds page. Almost everything is working seamlessly, except one annoying issue: the player does not recognize whether the device is powered by the adapter or by the battery. In both cases, it behaves as if the adapter is plugged in. The statusbar shows the battery level correctly, but it always shows the power icon, never the battery icon. For this reason, it is not possible to set, for example, different backlight times for battery mode and power mode. Is there any way to solve this issue?
I'm using Rockbox on my DX90 for years. I have installed "official rockbox binary builds" from napych.com:
- firmware-dx90-2.5.1-20160716 dual bootloader (based on newest iBasso firmware V2.5.1)
- Rockbox Version: 46f8e0e-150609 (from the same source). This version doesn't have such issue.
EDIT:
In the meantime, I tested the player in more detail and unfortunately I came across several other problems that are more serious.
- The biggest problem is the crackling sound, which appears especially in tracks with higher frequencies (96, 192 KHz, Flac format). I think this is caused by the expansion of frequencies in the new version of Rockbox: if the frequency is set to 44.1 or 48 kHz, the problem almost disappears. Unfortunately, it does not disappear completely, it only becomes significantly smaller. Again, this does not happen in the older version of Rockbox. Or maybe, to be honest, the problem is so small that it is not noticeable
- There is also a momentary interruption of playback when the player wakes up from the screen off mode.
I also tried the original Mango firmware - none of these problems are manifested here. Even tracks with higher frequencies are played without problems.
After all these findings, I think I will continue to use the original version of Rockbox, which works well for me.
However, thank you in advance for any answers or comments.
JK
8
Hardware / Re: Are "1TB" micro-SD cards 1000GB or 1024GB?
« Last post by speachy on May 20, 2025, 06:17:49 PM »Thanks for that information. So the issue is more likely to be just cards not being quite the capacity they claim to be, even if they are in theory using SI units? I don't really know anything about the topic of memory-card-manufacturing, is there a degree of random variation in exact sizing? (leaving aside the issue of outright fakes). Seems as if somehow the cards in this instance were a tiny bit _larger_ than claimed.
While the physical flash chips _probably_ have a power-of-2 array of individual cells, that's the _raw_ size. Some of that space ends up getting used for other purposes than storing user data -- eg ever-increasing amounts of error correction, the flash translation layer (maps a logical sector to a physical one, eg for wear leveling and improved write speeds), and even the runtime firmware for the flash controller itself. This overhead is fixed for a given design.
Then consider manufacturing testing. If you find a defective block, instead of scrapping the part you could just permanently mark it as bad in the FTL so it never gets used. How much gets marked off depends on the individual part, but as long as you're still above your target capacity, great! Otherwise you could just mark off a bunch of "good" sectors and sell it as the next-sized lower-sized part (eg 500GB instead of 1TB). This practice is called "binning"
What's left after all of that overhead and binning is the capacity that gets reported to the outside.
9
Hardware / Re: Are "1TB" micro-SD cards 1000GB or 1024GB?
« Last post by Frankenpod on May 20, 2025, 05:52:34 PM »Thanks for that information. So the issue is more likely to be just cards not being quite the capacity they claim to be, even if they are in theory using SI units? I don't really know anything about the topic of memory-card-manufacturing, is there a degree of random variation in exact sizing? (leaving aside the issue of outright fakes). Seems as if somehow the cards in this instance were a tiny bit _larger_ than claimed.
10
Audio Playback, Database and Playlists / Re: Rockbox 4.0 - Album Artist changed behaviour
« Last post by croxis on May 20, 2025, 04:47:45 PM »I've a patch
if you create a file named virt_albumartist.db
in the rockbox dir and build the database it
fills albumartist with artist if missing here:
https://gerrit.rockbox.org/r/c/rockbox/+/6514
Thank you very much for this patch!
I have applied it to the latest revision and built it.
Tested on a Sansa Clip+ and an iPod Classic and the old behavior is back.
Thank you guys. Thanks also for the patch.
I realize my and OPs message is the typical "It used to work for me!" use case regression where you could argue our approach is wrong. Unfortunately with music tagging what's 'perfect practice' is a bit up in the air. Some people say the AA field is not necessary if Artist is consistent across the album, but not all players work like this. Having the AA field always present is certainly the idiot proof approach. I'm considering masstagging my music archive to be done with it, but getting this right is a bit of a risk in case something doesn't work.
Here's how it can be done with the foobar2000 Masstagger plugin. There may be breakage if individual tracks of an album have an AA tag that deviates from the newly written tag, for some reason. What this does exactly is check if the Album Artist tag is empty, and if the Album tag exists. Both being the case, it will copy the Artist tag to Album Artist.
Select "Format value from other fields"
Destination field: ALBUM ARTIST
Formatting pattern: $if2(%album artist%,$if(%album%,$if(%artist%,%artist%,),))
For now, and this can also be done, I'll mount the rockbox iPod's entire archive and masstag that one, see how it looks. Edit: It works.
I can also confirm this as an alternative solution if you don't want to compile or wait for the patch to be merged.