Icons received and opened, they look great, thank you. I replied on amigapage with the details.

@Caffeina
Here are the TelegramAmiga icons for OS3, OS4, MOS, and AROS One

I haven't noticed that kind of behavior, but I don't have many chats. I'm new to Telegram.
It's great that you already have a Pi 400 running AROS.

@Bohun Thanks for building and testing the Polish fallback on real ARM hardware. (Since you built from main, both the fold and your About credits will reach everyone else in the next release).

Quick update from here: AROS aarch64 is now up and running on my Pi 400 with networking. The client logs in and loads chats without issue.
There is one open bug, some chats refuse to open, logging "peer-cache-index-not-found" even with a fresh cache in RAM (so it's not the FAT bug). Do you see this on your setup too?

@kaffeine
I noticed that version 0.93 is already on Aminet, but there was no ARM version, so I went ahead and compiled it myself; the replacement of Polish characters with their non-diacritic equivalents works correctly . Thanks for adding me to the "About" section ;-)

@all

fat-handler in RPi is several month (and multiple changes) newer then the one I have. If the same problem is still visible in the RPi version, please post the bug report directly on the ABIv1 bugtracker: https://github.com/aros-development-team/AROS/issues

@Farox That settles it. Issue 161 confirms the mystery, it’s an AROS FAT filesystem handler bug, not a Telegram one.

@Bohun Your diagnosis was spot-on and the fix is now merged into main.
It now deletes before creating and explicitly flushes before closing. (Lucky we didn't use the usual "write-temp-and-rename" pattern, as Issue 43 shows rename is broken on that handler too!).

A few quick updates:

Polish fallback is in: Latin Extended-A characters now fold to their base letters. Full Latin-2 remains the final goal.
Fonts: The client simply inherits the screen's font (TTCourier on my i386, Arial on your Pi). Both are scalable, meaning Polish glyphs already exist in the font, we just need Latin-2 codepage mapping down the road.
Toolchain: Building crosstools from AROS sources was the exact info I needed. Once set up, ARM will join the automated release pipeline alongside the other five platforms.

@Bohun
Probably hit the same bug as on other AROS systems not only RPi https://github.com/deadwood2/AROS/issues/161

Yes, a temporary 'a' instead of 'ą' is definitely better than having no font at all. The default font is "arial". I prepared the toolchain from AROS sources—well, let's just say not entirely on my own ;-)
The empty auth file was caused probably by two things in core/tg_file.c:
Root cause: On the RPi's FAT filesystem, overwriting an existing file via fopen(path, "wb" never persisted — the file ended up 0 bytes on the card even though fwrite/fclose reported success. Creating a brand-new file, on the other hand, committed reliably (probes proved it).
Fix: tg_file_write_text now calls (void)remove(path); before fopen(path, "wb" — i.e. delete-then-create, so every write is a fresh file. I also added fflush(file) before fclose(file) in both tg_file_write_text and tg_file_append_text.

Seeing it run on a Raspberry Pi made my day and thanks for the screenshot! You took the port all the way across the finish line.

You are officially credited in the About box for the next release (using your handle let me know if you prefer your real name).

Polish characters: You hit the nail on the head. The client is currently Latin-1 only, so missing glyphs render blank. The plan:

A quick fallback table (e.g. ą -> a) so words are readable without gaps (zero overhead, works on 68k too).
Full Latin-2 support later on.
Would that temporary fallback be useful for now? Also, what default font does AROS aarch64 use?
Official ARM builds: I’d love to make ARM our 6th official release package. Where did you get your aarch64-aros toolchain? In the meantime, feel free to distribute your build directly!

One last question: What solved the empty auth file issue in the end? I'd love to document it.

(v0.0.93 went live today across the other 5 platforms with the login fix and emoji picker!)

Your program runs on the Raspberry Pi
The only issue I see is the lack of support for Polish (international) characters.
Many thanks for developing for AROS.

@Bohun The empty auth file points to a file I/O issue rather than a login bug: fopen("wb" created the file, but fwrite/fclose never committed the 700 bytes to disk.

Two quick checks to isolate it:

Check PROGDIR:tg-gui-debug.log for an "auth-file-save-failed (...)" line:
The reason in brackets will tell you what failed (FILE_ERROR, BUFFER_TOO_SMALL, or RNG_UNAVAILABLE).
If the line is missing, the client thought the write succeeded—pointing to fwrite/fclose in aarch64's posixc.
Rebuild with NO_SELFTEST=0 and run:
TelegramAmiga --mtproto-self-test
(The "session" step writes, reads back, and verifies an auth file. If it fails, file I/O is confirmed).
Tip: Remember to delete the empty telegram-auth.bin before each retry, otherwise the client tries to parse it.

I just merged your Makefile PR thanks again for pushing ARM support forward.

In the new arm version, the code reaches the phone, and entering it creates a new Telegram session. The GUI indicates a successful login and prompts a program reload. However, upon restarting, it fails to log in because the auth file is empty. I am trying to resolve this.

@Bohun Great work, thank you!

Quick heads-up: the login code won't arrive with your current build. Your fork is from September 6, and just this morning I fixed that exact bug: Telegram now requires the language set to en-US instead of en (retrofaza and I ran into the same silence).

Please rebuild from the latest main. Just remember to add core/tg_emoji_sheet.c to the SRC list in your Makefile for the new emoji picker. (Or, if you prefer, I can add that line to your PR myself and merge it so it builds out of the box).

Once rebuilt, request the code once and wait a minute: it should land in the official "Telegram" chat on your phone. (Avoid repeated attempts so Telegram doesn't rate-limit you).

Can't wait to see it running on ARM!

I managed to compile it for aarch64 I’ve sent the Makefile-aarch64 to your repo.
Now I’m waiting for the code.

@retrofaza when the window iconifies it releases its color pens, and on restore it gets new ones, but the emoji were still pointing to the old pen numbers. I reproduced it on MorphOS, and the fix now keeps the colors completely intact.

Here is an updated AROS x86_64 test build (including the login fix as well): https://drive.goo...sp=sharing
The fix will be in the next release across all platforms.

@Bohun Regarding the fork, you actually don't need SSL at all. Telegram Amiga handles all MTProto encryption internally with zero external libraries (which is why it even runs on a stock 68k). An aarch64 build only needs a compiler and the AROS SDK. Once I get AROS running on my Pi 400 I'll take a look, but if you want to give it a shot beforehand, the only real work is adapting the build file.

I noticed that when you iconify an application and then restore it, the colors get messed up.

AROS x86_64. The desktop is in 24bpp. I checked this on Linux Hosted and on QEMU (X11 driver and VMware driver).

Yes! That's it - it finally works! Thank you so much.

Now we can keep testing

@retrofaza Found it! The fix was on my side, though the change came from Telegram.

I reproduced it on my own account. Telegram silently stopped delivering codes because the client sent the language as "en" instead of a full locale like "en-US". This worked fine since release one, but Telegram recently changed how it handles this check on their end. Switching it to "en-US" fixed it instantly, the code arrived on my phone in seconds!

Here is a test build for AROS x86_64 with the fix: https://drive.goo...sp=sharing

Replace TelegramAmiga in your drawer (keep data/ as is).
Delete telegram-auth.bin and data/phone-code-hash.txt.
Launch it, request the code once, and give it a minute.
(Heads up: if you made lots of attempts today, Telegram might throttle you for a few hours. If it doesn't arrive right away, wait a bit rather than retrying repeatedly).

Thank you so much for sticking with this! Your reports led straight to the solution, and this fix will now roll out to all platforms in the next release.

Yes, two users have confirmed that the RPi 400 works correctly. From my experience with the 3B+, I know that a problem arises with saving network settings if you select the option to start the network at boot. It is better not to check that box; instead, enter the appropriate commands in "User startup"—you can find them in the Raspberry Pi 3 thread.