So, I've owned a TI-92 for a while now, but I never got to install Fargo on it.
In case someone doesn't know what Fargo is, The TI-92 doesn't have built-in assembly support. Fargo is the jailbreak that enables you to run these programs.

This was not my first attempt however. For a long time I thought the issue was my cable (I have a USB silverlink), because when Fargo came out, the most common link cables were serial and parallel ones, but as it turns out, the issue was software-side. The thing is, TI-Connect doesn't support RAM backups, and that is the file we need to send to the calculator. On windows, we could theoretically use TILP, but the issue with this one is that the USB cable drivers that are available for that one are ancient, and I doubt they would work even on windows 7, tet alone 8 or 10. I tried, of course, but unfortunately Win10 totally refused to even recognise them.

The solution I found, was to install the precompiled TILP and libtiusb packages from the ubuntu repositories on my older laptop running lubuntu 16. As far as I know, these should be available on newer versions of ubuntu too.
This setup allows me to send RAM backups to my TI-92 with some caveats:
1. Apparently backing up and restoring the contents of the RAM somehow destroys the jailbreak.
2. TILP is massively unstable in this configuration. I've found that sending any file besides a RAM backup will almost certainly freeze the program midway through the operation.
These issues, while a little annoying can be circumvented pretty easily. For example, for sending files to the calculator, I use TI-Connenct on my day-to-day windows laptop, and I only bring out the linux machine (it's actually dual-boot) when I need to install Fargo.

Now, I did this, before WSL2 was out, and I also never tried out the serial link idea. I might try out these routes at a later date.

As a bottom line, I'd like to say, that I'm very impressed with how smooth fargo is. It really feels better than the ASM support included in later models by TI, and I have yet to have any crashes. On the other hand, I think I found a bug-thing: the longer the calculator runs, the more there are of those weird folders named 0001, 0002, 0003, 0004... They only appear in the ASM-based file browsers, so I'm not sure if this is a Fargo or TI-OS thing. Fortunately, as far as I know, a reset and reinstall fixes these every time. It is not a gamebreaker, it's juxt that they build up over time and appear at the top of the folder list, so if I want to open a program using the assembly shell, I have to scroll down over them.

This kind of reminds me of the alien breed graphics. 

Well, this is a six year old program now (or seven, I'm not sure). There's a number of things that could have gone wrong. You could be using a version of the pdf format that is too new for nPDF to read.
Also, please note, that you can't directly open PDF files, and expect the viewer to start automatically, like on windows. You have to first open nPDF and open the file from there using a menu. Good luck! 

You would need to modify the source code itself. Maybe you could also open it in the student software to get to the code. In any case, this wouldn't be as much of a mod as it would be a modified version.

I mean, you could always connect to omninet since it's IRC which is an old protocol

Oh, so you're not getting rid of the server itself? Cool! You got me worried there.

You can expand the Discord chat embed in the header and it should supply you with a link to the Discord server.

Where? I don't see a discord embed on the site. I thought this was the transition period or something.

I'm using GCC4TI, which is a C compiler. I've read the included documentation along with some tutorials (there was a nice one on technoplaza.net, back when it was still up) and every single time sprites were declared as arrays of either unsigned chars, unsigned short ints or unsigned long ints. Example smiley face sprite:
unsigned char sprite[] = {
0b01111110,
0b10000001,
0b10100101,
0b10000001,
0b10100101,
0b10011001,
0b10000001,
0b01111110
};
Equivalent to:
unsigned char sprite[] = {0x7E, 0x81, 0xA5, 0x81, 0xA5, 0x99, 0x81, 0x7E};
As far as the standard assembler for 68k programming, to my knowledge it's always been A68K, which originates from the Amiga (in fact, some of the early Fargo programmers seem to have used only this system) so microsoft BMP's kinda seem out-of-place.

In my opinion, that's really sad, because it kind of nullifies the effort so many people have put into making all those cool programs for the CE range. For example, a project like TI-BOY CE will now be much less useful.
Apparently they want to replace ASM with python (potential vurnerability?), which unfortunately isn't a viable replacement for ASM, because it's an interpreted language. 

AFAIK, in GCC4TI you use arrays of chars, short ints or long ints (for 8, 16 and 32 pixel wide sprites). You can directly edit the sprites if you use binary notation for initialising the arrays. Most of the sprite editors I found on ticalc seem to offer output in hexadecimal, which is fine too. The problem is, that all of the ones I've tried seem to be unfinished in some way or another. As for importing BMP's, I've never seen any mention of it in any of the 68k programming documentation. I guess the search goes on (or I'll have to make my own)