Open Collective
Open Collective
Loading
March 2021 status update
Published on March 3, 2021 by Dimitris Panokostas

Hello all!

As mentioned earlier, the main focus has now shifted towards polishing and discovering any remaining bugs that can be fixed, before the next release. It's finally time to cool down a bit and make sure everything is working as it should (and if not, fix it!).


Since the last update, we discovered a few bugs (some serious, some minor), which got addressed. The most serious one, was related to the filesystem and UTF-8 vs Latin1 filenames. Let me explain:

AmigaOS does not handle Unicode/UTF-8 characters. It doesn't know about them, since it was created before that technology became a standard in Operating Systems. So it handles filenames the old-fashioned way, using the Latin1 encoding (up to 256 characters, which can be changed using different fonts).


Linux on the other hand, like all the other modern operating systems, uses UTF-8 for the filenames. That means that for example, you can create filenames with Japanese characters in them, without a problem.


How does this affect Amiberry? Well, if you're using Hardfiles or floppy images (ADFs), it doesn't affect it at all. The contents there are contained and only accessible to AmigaOS, so it will work as expected in any case.


However, if you start using Directories as "virtual" hard drives for AmigaOS, then things get a little more complicated. AmigaOS reads and writes filenames to what it thinks is a hard drive (but is really a directory), and Amiberry needs to translate that to the Linux OS behind the scenes.

It's all fine if you're using English/Latin1 characters. But if you start saving filenames with non-English characters in them, things get messy. Or, they did until we fixed this. :)


Here's an example of some filenames, from the Storage disk of Workbench 3.1.4. This is the contents of the Countries directory there, with the filenames as they appear:

 


Now if we copy these files in a "virtual HDD" inside Amiberry, AmigaOS will re-save them using the Latin1 encoding. They still look OK under AmigaOS after that, but what happened behind the scenes is that Linux got these filenames added:

 


Since Linux is more tolerant, it would still accept those filenames even though they have weird characters, so things still work even if it looks weird and ugly.


However, try to copy those file in an NTFS volume (e.g. a USB stick you may have mounted as another drive) and it will fail miserably. Even though NTFS also supports UTF-8 characters in the filenames, it's more strict in what it accepts as valid filenames and those funky characters are not part of it.

So the solution to this problem, was to make Amiberry not just translate what AmigaOS sends in/out, but also convert the filenames to and from Latin1 (actually ISO-8859-1) and UTF-8, behind the scenes. This allows both AmigaOS to see the proper filenames, and Linux to have them saved in proper UTF-8 without the weird characters in them. And it works if you copy them to an NTFS drive as well!


Seems simple enough, but it still took a few days of work to make this happen reliably with all DOS operations!


Besides this, there were a few more changes:

  • Makefile: fixed cross compile #777
  • Made "Alt-Tab to Release capture" an option, which can be controlled from the Misc Panel in the GUI. It saves to the config file normally, with the name "alt_tab_release" (yes/no). This was necessary because there are different environments that run Amiberry: If you have a full Desktop behind the emulator, you may find it useful to use Alt-Tab to switch from Amiberry to Linux easily (in that case, enable this option). On the other hand, if you're using the emulator without any Desktop behind it (for example, in RetroPie) it's not useful at all. And it will interfere with AmigaOS trying to use the same key combination (e.g. with the AltTabber tool). In that case, make sure this option is disabled. The option is disabled by default!
  • Fixed a bug in Dispmanx targets, where the list of available P96 modes were not consistent between restarts of Amiberry. Some users had their Workbench boot into PAL mode randomly, but not always. This is now fixed!

That's it for now, until we discover more things to improve on! Until the next time, stay safe, and take care!