Interpreters for Å-machine

Technical Development Interpreters
1

From the Å-machine web page:

Currently, two separate Å-machine interpreters exist. One is implemented in Javascript, and the other is implemented in 6502 assembler. Each must be combined with a frontend that handles input, output, and other platform-specific details. Available frontends include a web frontend based on jquery for the Javascript interpreter, and a Commodore 64 frontend for the 6502 interpreter.

I would very much like to play Å-machine games in a resource friendly interpreter on Linux. It seems there is currently no solution for this. Is anything in the works, such as adding support in Gargoyle or Lectrote?

2 Likes
2

Lectrote and Gargoyle each rely on a common UI library for all their interpreters. (GlkOte and GarGlk respectively.)

It should be possible to remap the JS interpreter to use GlkOte. Unless this has been done already? The web page (https://linusakesson.net/dialog/aamachine/) says there are two front ends, and I don’t know the difference.

3

According to the readme:

The following interpreters are included:

  • Javascript engine, web frontend.
  • Javascript engine, Node.js frontend.
  • 6502 engine, Commodore 64 frontend.
  • 6502 engine, aambox6502 frontend.

However, I was under the impression that Node.js is also something you have to run in a browser.

4

Other way around – node.js is Javascript for running regular apps, outside a browser. Lectrote uses node.

It sounds like the path would be to write a third front-end, using GlkOte. Then it could be dropped into Lectrote. This might be a fairly narrow rewrite of the web front end, depending on how far the Å-machine departs from the traditional Z-machine “stream of text with a status window” display model.

5

Sounds promising. Please consider it a humble request.

I managed to run an Å-machine game in the terminal with the Node.js interpreter now. It works, but doesn’t provide transcripts.

6

I have gotten around annoyance at interpreters that don’t support transcripting by running the Unix script command in the terminal before starting the interpreter. ASCIInema is also useful, depending on exactly what you want.

Neither is really ideal, because neither generates a format that’s easy to turn into a real plain-text transcript (Unix script will dump in a lot of control codes and doesn’t necessarily record your input in the way you want it to; ASCIInema outputs JSON, also still containing control codes, and requires that recording input be explicitly turned on.) But they can be better than nothing.

7

Thank you, that is useful to know!

1 Like
8

In the long term, I plan to write a reference implementation in C that can be plugged into various input/output frameworks. Such an engine could be integrated into multi-format interpreters, ported to 16-bit computer systems, used as the basis for a very fast testing framework, etc. I haven’t done it yet, because the Å-machine is still evolving; I don’t want to end up maintaining multiple versions of the interpreter until the specification has gelled. But we’re gradually getting to that point.

6 Likes