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.

Am I suddenly working on a procedurally generated game? Maybe!
Anyway, here are some names. For people, planets, or whatever.
#MailStation #TinyBasic

#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

Okay, now I have EMIT(n) to turn an ascii code back to a printed character. #MailStation #basic

Here is the source code for my recent #TinyBasic and #MailStation work

https://gitlab.cs.washington.edu/fidelp/mailstation_apps

• Machine code monitor and TinyBasic for Cidco MailStation (#z80 Internet Appliance)
• The programs are small enough that a determined person can key them into the MailStation's built-in hex editor in 1 hour or less.   They run as loadable MailStation "channels".   They make it pretty fun as a self-contained mobile development platform, though you can't easily save your work. Carry pencil and paper!

https://gitlab.cs.washington.edu/fidelp/tinybasic

• Z80 version of Palo Alto TinyBasic v3 with all known OCR errors corrected. Tested and working on real #z80.

Yup, TinyBasic is working on real #MailStation hardware too. #retrocomputing
It took about an hour to key the 2 KB program into dataflash, but it was well worth it. Now I have a #basic on the go!

A couple bugs squashed, #TinyBasic seems stable now on the #MailStation! How fun!

Inching toward another interesting program running on the #MailStation. That's right, it's Palo Alto Tiny #Basic v3! And, as can be seen from this screenshot, it's still feeling a bit woozy.

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

Inevitably, I've been writing a #Forth for the #MailStation. Right now all it does is display the name of the world's greatest band (okay, that's really a test of the inner interpreter).

PsfMon, my #z80 machine code monitor, is now running on my real #MailStation!

I optimized it from its original size of 332 bytes to 255 bytes, snugly fitting in one 256 byte page of dataflash. The gui "terminal emulator" takes another 256 byte page. This provides a self contained 512 byte development tool.

Command set - similar to #WozMon:

8000 - View byte at address 8000
8010,801f - View 16 bytes at address 8010
,803f - View from next address (8020) to 803f
8040>de ad - Place bytes de ad starting at 8040
>be ef - Place bytes be ef next (at 8042)
8000r - Execute code at address 8000

Anyway, here it is displaying 128 bytes of its own code.

I have now written a #z80 machine code monitor for the #MailStation. The command set is very influenced by WozMon, but unlike #Woz I haven't managed to fit it in 256 bytes (yet...)

So now, in the strictest sense of the word, I have a #repl on this thing!

(While there was already a built-in hex editor, it was not suited to interactive use. A reboot was necessary to test changes, and it was restricted to writing dataflash, which has a limited number of write cycles.)

After lots of invisible optimization work, I've saved enough space that my new #MailStation app can display its name and icon in the app launcher.

Incongruously for a #z80 powered device, the #MailStation is heavily GUI based. There isn't a putc function, or even a fixed-width font, in the firmware. Instead, a windowing toolkit and a selection of widgets are provided, and loadable apps are expected to be event-driven. Each app supplies a main event handler function responding to incoming signals such as init, draw, and keydown. Apps don't take over the whole system as typical on single tasking retrocomputers. While the Mailstation doesn't do true multitasking, (or even #HP200LX-like switching between paused apps!), the event-driven software architecture is helpful for battery life, as the CPU can spend most of its time halted waiting for interrupts.

Most of my development so far has used the community-created JsMailStation emulator, but it's a good idea to test on real hardware occasionally. For me, that means keying the program into the #MailStation's built-in hex editor. It still fits in less than 256 bytes, so the data entry isn't as time consuming as it might seem... yet.

Current state of the #MailStation homebrew software: a singleline text field for user input, and a much larger multiline text field for program output. So we now have a terminal-like interface we can use as a basis for writing command-line software.

Sweet jesus #MailStation that's not honey! You're eating uninitialized memory!

Okay, that's hello world on the #MailStation.

box2->x0 = (box1->x1 - 30)*foo / (fbuf[0] + fbuf[1])

Sometime soon, hopefully, I will understand the significance of this value that #MailStation widget #4 has calculated.