#ti92 — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #ti92, aggregated by home.social.
-
I just completed "Printing Department" - Day 4 - Advent of Code 2025 #AdventOfCode https://adventofcode.com/2025/day/4
Part 2 took more than 12 hours on my #Ti92 #GraphingCalculator, and it is already an optimized version. No clue how long the naive approach (part 1 in a loop) would have taken...
-
#adventOfCode day 12 in #LuaLang
https://gitlab.cs.washington.edu/fidelp/advent-of-code-2025/-/blob/main/12.lua
- PC - 2ms
- Raspberry Pi 2: 76ms
- #ti92 Plus: Crashed
I wasn't expecting that to work!
And as usual, AoC is a good source of stressing cases to expose crashes/bugs in the #ticalc Lua port :p
Merry Christmas!
This is the first Advent of Code I've ever completed! -
#adventOfCode day 10 in #LuaLang and #Mathematica
https://gitlab.cs.washington.edu/fidelp/advent-of-code-2025/-/blob/main/10.lua
- PC - 487 ms
- Raspberry Pi 4: a few seconds
- #ti92 Plus: N/A
Ok, finally all caught up and looking forward to some sleep and Day 12!
After a night and day in math land confusing myself with row echelon matrices and intersecting N-spaces, I remembered that I have a Raspberry Pi that for some reason has free preinstalled Mathematica.
So my Lua program code-gens a Mathematica program, which then runs on the Pi to solve Part B!
This generated code is checked in if you want to look at it - it's several thousand lines of simultaneous equations being solved with constraints applied: https://gitlab.cs.washington.edu/fidelp/advent-of-code-2025/-/blob/main/10.m
Given all that, it's pleasantly fast. Mathematica over VNC on wifi is pretty laggy but the actual execution couldn't have taken more than a second or two!
(Yes, I did attempt to solve the equations on the TI-92+ #ticalc, as it has a very capable computer algebra system, but I couldn't figure out how to apply all the necessary constraints -- maybe later.)
-
#adventOfCode day 7 in #LuaLang
https://gitlab.cs.washington.edu/fidelp/advent-of-code-2025/-/blob/main/07.lua
- PC - 1.5 ms
- Raspberry Pi 2: 41 ms
- #ti92 Plus: >18 min
After a couple of days where the TI-92+ has been disagreeable, it was refreshing to get a puzzle where the Lua solution Just Works without memory exhaustion. Though, speedy it ain't. And when I got my camera out to photograph the real calc, I found it had crashed, so you get a boring emulator screenshot of it working instead.... ;)
I'm a little confused why it's this slow on the #ticalc: something about it seems difficult compared to the other working examples. I think it's because my approach generates lots of garbage so Lua's gc is working hard.
-
For anyone interested in the port of #LuaLang I'm using for #AdventOfCode on the #Ti92 Plus graphing calculator, I've uploaded the patched Lua sources and prebuilt binaries for TI-89 and TI-92+ to https://gitlab.cs.washington.edu/fidelp/lua92
Please let me know if you try it out! -
#adventOfCode day 6 in #LuaLang
https://gitlab.cs.washington.edu/fidelp/advent-of-code-2025/-/blob/main/06.lua
- PC - 5.1 ms
- Raspberry Pi 2: 147 ms
- #ti92 Plus: out of memory
I'm steadily accumulating a backlog that I need to rewrite into C for the #ticalc. I'm really jonesing to switch back to the DOS-based HP 200LX palmtop... 640K RAM feels mighty spacious in comparison to the calculator. Maybe in my copious spare time I need to track down the memory corruption problem that's stopping the 16-bit MS-DOS Lua from working.
-
#adventOfCode day 5 in #LuaLang
https://gitlab.cs.washington.edu/fidelp/advent-of-code-2025/-/blob/main/05.lua
- PC - 1.7 ms
- Raspberry Pi 2: 49 ms
- #ti92 Plus: out of memory
The #ticalc doesn't make it through input parsing before exhausting memory. It will be necessary to rewrite in C again.
-
My port of #LuaLang to TI-92+ had a bug where
math.hugewas accidentally NaN instead of +∞. This is now fixed, so we can infinitely loop the fun way.I like that the screen's slow update speed is clearly visible in the photo....
-
I just completed "Lobby" - Day 3 - Advent of Code 2025 #AdventOfCode https://adventofcode.com/2025/day/3
Again on a #Ti92 #TiCalc. Part 2 took over 30 minutes to run...
https://git.grois.info/aoc-2025/tree/day3 -
#adventOfCode day 4 rewritten in C
https://gitlab.cs.washington.edu/fidelp/advent-of-code-2025/-/blob/main/04.c
This is a very simpleminded solution with no algorithmic fanciness: it's performing lots of repeated work in Part B.
- PC - 1 ms
- Raspberry Pi 2: 23 ms
- #ti92 Plus: 10 seconds
It was stunning to see a result returned in just 10 seconds on the #ticalc, rather than minutes for previous days. The performance difference between an interpreter and an optimizing compiler is stark! Also, the TI-92 doesn't have a floating-point coprocessor, which makes Lua in particular struggle to run at speed.
-
The input for Day 3 of this year's #AdventOfCode is so long again, that I'm afraid that I will have to split it in order to allow my #Ti92 #TiCalc to process it...
At least part 1 seems to be simple enough to finish in a reasonable time on that ancient hardware.
-
I just completed "Gift Shop" - Day 2 - Advent of Code 2025 #AdventOfCode https://adventofcode.com/2025/day/2
On my #Ti92 #GraphingCalculator. Part2 took quite a while to finish. Not sure if that's normal or if there's a bug...
In any case, the result was correct, so I'm happy.
-
#adventOfCode day 3 in #LuaLang, update: Execution time on my real #ti92 was 17m12s.
The TI-92+ appears to run Lua programs at 1/10,000 the speed of my Raspberry Pi 2B: that is, take the RPi execution time, shift to the next SI size category (like milliseconds to seconds) then multiply by ten, and you'll be in the ballpark.
Meanwhile, the Raspberry Pi is about 1/50 the speed of my desktop.
-
#adventOfCode day 3 in #LuaLang
https://gitlab.cs.washington.edu/fidelp/advent-of-code-2025/-/blob/main/03.lua
- PC - 5.4 ms
- Raspberry Pi 2: 156 ms
- #ti92 Plus: ??? minutes (still running)
The program runs successfully in TiEmu with the emulation speed multiplier unlocked. It has yet to be seen how long it'll take on the real calc...
-
On real hardware the Day 2 puzzle takes about 4 minutes to run!
#ticalc #ti92 #retrocomputing -
Adapted #adventOfCode 2025 day 2 in #LuaLang to use a much more efficient algorithm to fit on #ti92 Plus.
https://gitlab.cs.washington.edu/fidelp/advent-of-code-2025/-/blob/main/02fast.lua
- Desktop: 1.1 ms
- Raspberry Pi 2B: 20 ms
This also found a bug in my port of Lua:
math.hugewas the wrong value, so a particular loop was never running. -
Because the post upthread has poor video quality, here's a higher res photo of the 2025 day 1 result on TI-92+.
#ticalc #ti92 #adventOfCode #LuaLang #retrocomputing -
Adapted #adventOfCode 2025 day 1 in #LuaLang to use less memory to fit on #ti92 Plus. Execution time: 2m 42s.
The TI-92+ has a 12 MHz 68000 and 188 KB RAM that is also used as the calculator's main ramdisk, meaning, the Lua interpreter, script, puzzle input, and all datastructures must fit in that size. The calculator runs on 4 AA batteries with a battery life of "well beyond a school year".
-
Putting Lua through its paces. Here's Advent of Code 2024, Day 13, running on all my favorite hardware that I had on hand, through the power of Lua.
Ryzen 5 9600X modern desktop - 1 ms.
HP 200LX, 8 MHz 186, 640 KB RAM available to Lua: 62 seconds.
TI-92+, 12 MHz 68000, 64 KB RAM available to Lua: 65 seconds.
"Write once, run anywhere".
-
Okay, Lua 5.2.4 is much happier on the TI-92+ hardware. After loading the interpreter, there's about 64K free memory, which is enough to get up to some real trouble!
#ticalc #ti92 #retrocomputing -
Oh yeah that's a sharply limited amount of free memory, to put it charitably.
-
@csepp The calculator has 188 KB RAM, which is used for both working RAM and a ram-disk. The binaries for Lua are 156 KB total, and there's some amount of runtime overhead for stacks and interpreter data structures. So suffice to say there is very little free space left for a program lol. I can't measure exactly how much, but it seems like there's maybe 10KB at most.
-
What do you use for your number type(s)?
Right now, int32_t for integers and double64 for floats. I realizen this is a strange configuration for Lua so might switch back to float32 later (
#define LUA_32BITS). I really wanted int64_t but TIGCC doesn't fully support them.How much RAM do you have left?
I don't know yet: the print() function isn't working so I'm limited in how much I can poke around. Currently, error messages display fine but anything using lua_writestring() causes an interpreter restart (!) due to some linker-related malady I haven't found yet.
How much of the stdlib is supported?
"All of it", with a few omissions that make sense for the platform,
- Things that need stdin/stdout are unsupported because TIGCC's standard library doesn't expose stdin/stdout as files
- No environment variables, locales, file:setvbuf, or os.system, because TIGCC's standard library doesn't have them
- No argc/argv or os.tmpname yet, for the same reason, but they could be added with calc-specific code
- No time/date because the TI-92+ has no realtime clock
Notably this means we do have fun stuff like file I/O, string/table functions, coroutines, regular expressions, debug library, etc. Unless I have to take it out, or make it not auto load on startup, to save RAM.
-
This is still very much a work in progress, but it appears I've managed to shoehorn the latest version of Lua onto the TI-92+ graphing calculator.
-
Solved! Trial-and-error indicates that you have to
#define USE_KERNELbefore using any system includes like#include <stdio.h>, as it appears they check for it. If you neglect to do this, you get cryptic "unresolved reference to __main" errors even when trying to build a library.My program still doesn't work (one module is raising hundreds of "too far for size-two reloc" linker errors) but I think that's because the module is >64K and needs to be split up more, which is my own fault and a problem for tomorrow.
-
Do I know anyone who does #ti92 or #ti89 TI calculator homebrew development? The gcc toolchain is giving me some very specific problems when creating libraries for use under PreOs, and maybe someone else has already encountered and moved past this. #retrocomputing #ticalc
-
I'm riiiiich! You definitely have to write stuff down outside the game to figure out good trade routes. I think that's more fun than putting better mapping into the game itself. Makes the universe seem bigger.
I think it's probably ok to turn fuel consumption back on. Might be a little challenging but shouldn't be unwinnable.
Not pictured: Save/load is working, and I've optimized everything to be about 2x-3x faster. So now it's actually playable as a game. A rather grindy game, but a game.
-
More portable #retrocomputing philosophizing: Whether a machine has "Instant-On" makes a huge difference in the tasks it's useful for. By this, I mean whether the machine returns to the same program and screen where you left it, when powered back on from inactivity.
Without "Instant-On", the machine demands to be used for long sessions, (else the boot time is too inconvenient) and demands your constant attention (else the power draw of leaving it sitting around powered on is wasted). Using the machine involves clearing your schedule and devoting yourself to it, like reading a book.
Examples of machines without "Instant-On": DOS-era laptops, #Book8088, #GameBoy, #MailStation.
With "Instant-On", the machine is useful for PDA-style quick jottings, grocery lists, etc. It is also useful for fun activities even in circumstances where you are likely to be interrupted.
Examples of machines with "Instant-On": #HP200LX, #HpOmniBook, #PalmPilot, #PocketPC, #TI92 (and other TI calculators), and, of course, smartphones.
While machines in the first category may offer a more immersive experience, they are far less useful to me than machines in the second category. It's like the difference between a luggable and a true mobile computer.
-
Held a #TI92 in my hands and never until now have I known true #cyberdeck . It's like a laptop made for the apocalypse.
Needs a #CollapseOS port for real. :neofox_owo: