(Continued from my previous post.)
I’m still trying to get my bearings on how this works.

1970 picture of a System 370, via IBM.
Back when I wrote about my favorite games of Tlön — essentially, imagining games from an imaginary universe where the usual rules may or may not apply — one of the ideas I tried to play with was the usual definition of a game. (Fun exercise for game designers: take a set of definitions of a game, and make a counterexample-game for each one, as Wittgenstein cackles in the background.)
Such definitions try hard to exclude, say, spreadsheets. So how could a spreadsheet (not something made in one, but the actual application itself), be a game? Theoretically, by making the operation of the software itself a puzzle to figure out; have unconventional UI tricks, and maybe convey everything in an invented language, and to even do your quarterly report you’d need to “solve” how the program works. Perhaps it could be inspired with elements from bad UI competitions.
I preface with this because operating ZENO is a little like my theoretical spreadsheet; puzzling out the editor especially (as in a text editor, for changing source code) has required dealing with cryptic documentation, and some of the documentation is tore off and located in other places on our space station/base.
(Or maybe spaceship; I think we’re “static”, like in geostationary orbit, but there’s enough weirdness going on I might be wrong.)
Consider the lift. I knew there was a “lift” program that you could run on the computer (by just typing “lift”) but I knew it only went to one other floor and back. The instructions are suggestive that there’s more floors.

Screenshot from last time.
After a bit of back-and-forth I realized I could type “edit lift” at the prompt and see all the code.

Here’s the first part of instructions for the editor:
line commands:
nnA adds nn blank lines (default nn is 1)
nnD deletes nn lines (including this one – default nn is 1)
nn” copies this line nn times (default is 1)
/ makes this the current line
I have no idea how to enact any of these. I had to just ignore them and move on to a second page, which has more instructions with different ways of doing the same operations. For example, I can type :5 to jump to line 5, then type DEL to delete it. The important thing I had to pick up on is that pressing TAB switches between what part of the screen your cursor is on, so you can hop directly to particular lines and edit them (as opposed to retype something, using the command INPUT INSERT_TEXT_HERE). For example, I can hit TAB until reaching line 7, and right-arrow over a bit…

…and then change the 2 to a larger number. What this does is check the floor number, and if the lift is out of floors, it will jump to the part of the routine where it switches the floor back to 1. By making the number bigger, you can now have access to floors 3 and 4. (While you’re at it, you need to change the next line to LIFT_FLOOR = LIFT_FLOOR + 1 which will roll through the possibilities rather than just setting the floor outright to 2.)
Of course, realizing that you can do this in the first place is a puzzle, but the editor itself ended up being one too! While some of what it is doing resembles editors like EMACS, some aspects (like forcing the whole word INPUT before typing in text) are unique to the world of ZENO, so genuinely make a spreadsheet-game of sorts.
It doesn’t help that the game always seems on the verge of crashing. If you open up the help but go to a page that doesn’t exist, the game crashes and you need to restart; I don’t think this is an emulator bug.

With the lift fixed, I was free to explore what turned out to be four floors. (Trying to get to 5+ just has the door stay closed, and before anyone asks, the same thing happens if you try for a “floor 0”. Now that I think of it, I haven’t tried every floor, so it’s still possible there’s a secret floor 32 or some such. There’s also another potential trick later that I’ll explain with the LIFT_DOOR variable.)
My map, so far:

More sections are predicated on secret things I’m missing, or the ability to use the matter transporter, which I haven’t been able to use yet. But let’s tour the floors in order:
FLOOR 1: Where everything starts, and the location of the main computer. (First order of business: log on to the computer and type “air” to get the air pump working, otherwise you will suffocate and die.) The main “User Guide” is here and there are references to a “System Guide”, “Editor Guide”, “Programming Manual”, “Robot Programming Guide”, and “Matter Transmitter Operator’s Guide”. The Guide has some pages ripped out: 13, 15, 17, 18, and 19, and the last page warns that
A full list is included as an appendix in the COMPUZZ System Guide. Please read this carefully. Since COMPUZZ computers are typically used to control powerful and potentially dangerous devices such as lifts, burglar alarms, lasers etc, failure to observe the recommended procedures can be fatal.
FLOOR 2: Observatory, with a COMPUZZ ROBOT. The only robot I’ve found so far (parts of the text imply there are others). Trying to touch the robot gets you killed by a laser.

I was actually intending to look more closely at the robot; this is one of the problems with an object-only interface.
The book is the Programming Manual. While there’s an index that indicates a complete book…

…most of the pages are gone. The only ones present are 2, 8, and 20, although there’s a bit of a joke on 16 and 17
The next page is intentionally left blank. This page is blank apart from this message.
(I’m pretty sure this is a joke on IBM manuals, which I remember being infamous for lots of INTENTIONALLY LEFT BLANK pages.)
I still haven’t tried playing around with the robot yet, although there is a sample program in the computer with two command lines:
robot = go to the door
robot = come into room please
(I think I accidentally ran this while in the room, which is why the robot ran into the elevator; if I waited another turn it would come back.)
There’s also a terminal in the observatory, but trying to use it gets the response that the terminal is disabled. There’s a program to enable it, but it doesn’t seem to work; it asks if you want the terminal enabled or disabled, and you type “enabled”, and the game responds that the terminal is disabled. I assume there’s an intentional bug here (“puzzle”) and I haven’t dug further.
FLOOR 3: You leave out to a storeroom…
You are in the storeroom. There is a staircase spiraling down.
There is a bulky space suit here, just your size.
There is an open door in the wall, leading to a cramped lift.
…and picking up the space suit wears it automatically. Note that this uses up air and if you run out of air you die, so unlike the notebook typing SUIT again will drop the suit. (The simplification makes sense, but the inconsistency still makes me grumble.)
Going DOWN the staircase you find a metal bottle on the stairs (this will swap with whatever air is on the suit), and two torn papers. The two papers are from the robot programming guide, with some highlights being: a.) they all have good vision and position sensors b.) they do not follow anything like Asimov’s laws c.) using speech with a ROBOT_VOICE command takes 1 turn and d.) you can overlap multiple commands all at the same time but it can lead to unpredictable effects.
Every other page of the robot manual is missing.
Heading down the stairs further is a matter transmitter desk.
You are at the foot of the stairs, which lead up from here.
Partly hidden by a pillar there is a large desk. An illuminated sign over the desk says. “COMPUZZ MATTER TRANSMITTER: OFF”
The prompt looks like this:

Pressing “help” here opens a matter transmitter guide, which has a page of technobabble, two extra pages of details, and mostly missing pages in between. I’ll give every single page this time:



I have not got things working yet. Even testing a small thing can take a while because it generally has to be implemented in the form of a program.
FLOOR 4: This has a hatch with a warning not to go through without a spacesuit. The hatch leads to an airlock.
You are in the hangar – an enormous cavern of a room.
To your left is the hatch of the airlock.
At the far end, the remains of the vast hangar door hang open, probably blasted by a hadronic beam.
There is a shuttle, large enough for two, parked here.
A sign on the side reads “Cardboard Mockup – DO NOT TOUCH” .
A small leaflet is posted on the wall.
There is a terminal here
Through the door you can see a corner of the Mare Imbrium, at its edge, hanging 200 klicks away.
You are wearing the space suit
The leaflet explains that the space shuttle is a “coming soon” feature and the intent is for ZENO to eventually let you travel through space and land on the moon. (This never happens, although Mitchell revisits ZENO in a printed book form — more on that when I eventually wrap up on the mainframe version.) The leaflet also implies that this version of the game is “deterministic”, that is, this isn’t a strategy game; there are particular things that will consistently happen.
The leaflet also gives a list of objectives, which is good because I believe there is no set “ending”. I’m not putting myself on the hook for any objective in particular, other than fighting off aliens.
- determine the coordinates of all the places the robot can get to
- write a program to detect and recover from power surges automatically
- write a program to restart programs that fail
- allow editing at terminals
- kill off all aliens as soon as they get aboard
- fill up all the disks
If you’re tempted to mess with the shuttle (despite it being cardboard) it kills you.

Next time I’ll discuss the robot control, the alien invasion, and hopefully use the former to fight off the latter. This might be not too far from the end, or (due to the programming taking so long to wade through, and the potential vistas the matter transmitter might open up) I might still need another two weeks to chew through everything.
I believe you can use the mouse to click wherever, and Tab will take you to the next interactable field. The entire way the game is made and laid out is very close to the various interfaces the IBM mainframes offer, including the function keys having the same, well, functions (F3 to quit, F7/F8 to page, …). IOS3270 is a library that draws all the computer screens from a big definition file; I assume the author never built in any error handling so it just crashes if it can’t find a definition. There’s a LOT of calls directly out to the OS in the REXX code. I didn’t check how it executes the SIMPL/E code because I was trying to get it working at all, but it wouldn’t surprise me if it did so externally.
If you want the source code, let me know, unless Rob has forwarded it already. It’s all text files for once and makes it a lot easier to study those manuals (but, of course, spoilers).