I just picked up a TI-92+ off eBay (my first 68k TI calc) and I want to play around with assembly on it. What is the best way to jump in on the 92+? Does all assembly on the 92+ require using a computer? Or is there a way to enter hex programs like there is on some of the z80 based calcs? Is a shell required, highly recommended or not needed at all?

Thanks!

Im pretty sure programming in C is recommended for the 68k calculators if you have experience with that language?

There is some info here: https://debrouxl.github.io/gcc4ti/info.html but some more experienced 68k devs might be able to assist.

Welcome to the forums btw 😀

You can definitely do hex codes on the 92+. There is the Exec command, which takes as its argument a string containing the hex code that would otherwise be in a normal ASM program, including the relocation table at the end (see the compiled ASM program format). Exec also takes optional parameters after the string that are passed as arguments to the program (on the expression stack like AMS does, not on the CPU stack like one might expect).

It might be helpful to install an app like Command Post Plus (which can display disassembly & traps some exceptions to recover from crashes) or the program KerNO (which traps exceptions & has an emergency escape key combination, but I seem to remember the list of exceptions handled being slightly different from Command Post Plus). KerNO also allows ASM programs to return a value & be used in expressions, which is useful on its own (but does not apply to Exec strings).

I’ve done both, so no issues there. I’m mainly looking for specific things regarding the 92 series. I will check out those links, though. Thanks!

The part about hex coding on the TI-68k series was answered pretty well by Zeroko, so I'll focus on the other parts

A"shell" in TI-Z80 / TI-eZ80 parlance happens to be called a "kernel" on the TI-68k series. Both names are equally inappropriate for the infrastructure which provides additional functionality to assembly programs (e.g. libraries, crash recovery in some cases) or file explorers.
On the TI-68k series, "kernel-"based programming lost the war by 2005, partially due to the slightly decreased ease of use (the need to install an additional program), but probably more due to the instability of the early kernels (DoorsOS !) and kernel-based programs on newer hardware and software (*), as well as the activism of several powerful "kernel" foes. Clearly, I used to be one of those; when I grew older and wiser, I came to adopt a slightly more balanced stance on kernels
The only option for a TI-68k kernel is PreOS, which superseded all previous kernels while keeping great compatibility with them, and provided expanded features of its own. With PreOS, you don't need KerNO.

There are two classes of TI calculators based on a 68000 processor:
* all non-Plus 92 models (92, 92 II, E, etc.);
* the 92+, 89, V200, 89T.
Due to the fact that the former class has no table of system functions ("ROM_CALLs"), it's much harder to program in assembly, and comparatively few assembly programs have targeted the 92, even before the 89 and 92+ replaced it, partially because those were the early days of Fargo and assembly programming on the TI-68k series.
Still, there's greater homogeneity between even the 92-class models and the newer models than between one TI-Z80 generation to the next, and great homogeneity between the 92+ / 89 / V200 / 89T. In fact, "TI-68k series" sometimes covers just the later models.

For coding on the calculator side, you could use GTC and SIDE. Make sure to archives copies of your progress often enough, though: neither has great stability. The older cc and as have lower capabilities and not better stability, AFAIK.

For coding on the computer side, the most usable option remains GCC4TI. Despite the portability and build system improvements, which are one of the classes of work performed since GCC4TI was forked from its dead ancestor, its heavily patched GCC 4.1.2 is getting ever more brittle for newer toolchains. At this point, it's probably better to use a VM for an older Linux distro, e.g. Debian 8 "Jessie" or possibly the soon-to-be-unmaintained Debian 9 "Stretch", to build a GCC which can reliably generate code.
GCC4TI inherited an environment-specific linker, and various other things which do not work on any other common toolchain. Standard COFF or ELF GCC + binutils are strongly incompatible with existing GCC4TI C headers.
Programming on the computer side gives access to emulators; the only adequate choice for a developer-oriented emulator is TIEmu (and by all means, the version without GDB support !). Even JM's improved version of Virtual TI ("VTI") doesn't provide reasonably accurate support of HW1 89 and 92+, it's missing some important blocks for HW2 89 / 92+ (e.g. the RAM execution protection, so it's easy to make a program launcher which works on VTI but crashes real calculators hard), and it doesn't support the V200 or 89T at all. VTI is easier to install, though, especially on newer computers.

*: fiddling with internal system variables at hard-coded addresses is a horrible coding practice. It worked for a while on the 92 and early 89 / 92+ OS versions, but then TI started moving OS variables from one release to the next...

Thank you both for your replies. I’ll have to dig into a lot of this over the next week or two. Hopefully I can get to the point of hello world by then. And then after that, who knows where? Definitely want to take a whack at making new versions of some of the games I did in the past. I had a pretty decent pyramid solitaire game running on the 82 at one point. That might not be a bad one to get running here.

I'd actually suggest installing PreOS and programming in kernel mode. It's easier, and you can do it on calc witn as92 or GTC.

Well, the features brought by "kernel" mode are definitely nice for developers, but less so for end users
For small-ish programs, which would arguably be what munsie will target at first:
* the library system has lower usefulness and yields reduced efficiency;
* BSS support (automatic allocation of uninitialized global variables) used to be an important differentiator of "kernel"-based programs for years; it was redone in AMS native programs later - well, still over 15 years ago - by duplicating the support code across programs.
However, using BSS is basically never a good idea for efficiency reasons: not only it forces slower 4-byte xxx.l references where initialized globals can often 2-byte d(pc) references, but also, the required relocations of non-default type take up further space in the program, both directly and by the fact that they require more complex startup code.

The main thing I found is this:
With as92, if you want to call TIOS functions, you have to use their memory addresses, or deal with only a limited selection of them (convert the include file to a calc text file, limited by available memory). Calling genlib functions, for example, is much easier, because there are fewer of them.

With GTC, you can call any TIOS function, but you can compile larger programs by using something like genlib, and not including tigcclib.h

Correct. However, a "pyramid solitaire game" doesn't strike me as the kind of games which would necessarily strongly benefit from a faster but non-built-in graphics library such as genlib

LOL -- that is probably true. It was running just fine as a TI-BASIC program on the 82 years ago, so any assembly version would be an improvement.