Procedurally generated space game is picking back up on the #TI92 because, unlike the #MailStation, it's possible to save my work on here.

TI-BASIC is, ehm, slow. Eventually I'll snap and port a TinyBasic or Forth over here.

#ticalc

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.

#MailStation #TinyBasic program of the day: Hangman!

I wanted something that would exercise my hacked-in "strings" support. Seems to work well enough for a word game!

Source listing (21 lines): https://gitlab.cs.washington.edu/fidelp/mailstation_apps/-/blob/master/basic/hangman.bas

#basic #retrocomputing

#MailStation #Forth has peculiar execution flow because of the event-driven environment it runs in. Forth's entry points are COLD (expected!) and ACCEPT (rather less expected). Forth so far has only one exit/yield point, also in ACCEPT, to await input provided from the gui textentry field.

Execution smoothly falls through from cold -> abort -> quit -> accept, with no "ret" along the way. (Even the "ret"-to-caller on line 42, the exit point, is tailcall optimized away by jumping to the final function rather than calling it.) It still feels transgressive to embrace unstructured-programming, even though it works great for "telescoping" routines that share an end.

When user input is received, execution picks back up on line 43. Finally, quit2 slams us unceremoniously into high-level threaded code, because by now we have set up enough interpreter state to run it.

A lot going on in this screenful of code. It's absolutely wild to implement an interpreter core without needing any conditional-branch instructions yet.