We already have a browser for Raspberry Pi; Telegram for aarch64 would be useful too.

@retrofaza Thank you, that test was a huge help! It ruled out the API key and led me straight to a bug on my side:
Telegram sometimes answers with "no code sent: this account needs a verified login email first". My client caught the response but had no message for it, falling back to the standard "enter code" prompt. That explains everything.

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

Drop the binary into your drawer (keep data/ as is).
Run from Shell:
TelegramAmiga --gui-live-debug data/telegram-peers.txt
Request the code once.
Check PROGDIR:tg-gui-debug.log for this new line right after the request:
login: sent code type 0x........, N digits
Just send me that single line and whatever the screen displays .
Note: If it turns out to be the email issue, simply add an email in an official Telegram app (Settings → Privacy and Security) and then try the Aros again.

@Bohun Thanks! Aarch64 is definitely on my roadmap.
Is the bohunamiga/telegram GitHub fork yours? I saw the September branch did you manage to build it, or did you put it on hold? If you've dropped it, I can take over the port once I set up AROS on ARM here.

Quick question, do you know if AROS aarch64 runs on a Raspberry Pi 400 with working networking? Which board and build are you currently running?

Log line:
[08982] login: sent code type 0x3dbb5986, 5 digits

First, I sent it using the default API ID/hash. Then I repeated the process using my own generated API ID/hash. In both cases, the “sent code type” is the same.

But the code for TelegramAmiga isn't coming to my phone.

BTW, when I log in to my.telegram.org, the codes arrive in my phone’s app immediately.

I don’t have any other active Telegram sessions besides the one on my phone.

@kaffeine
Yes, that’s my fork. Unfortunately, when I saw that SSL was required—which isn't available for aarch64 yet—I held off.

I’d definitely like to port it to AROS aarch64 later, since I believe ARM64 is the ideal architecture for modern Amiga-like systems.

Do you know whether AROS aarch64 currently has working network support on the Raspberry Pi 400? I own one and it would be my target hardware.

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.

@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! That's it - it finally works! Thank you so much.

Now we can keep testing

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).

@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 managed to compile it for aarch64 I’ve sent the Makefile-aarch64 to your repo.
Now I’m waiting for the code.

@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!

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 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.

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.

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!)

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.

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

@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.

@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