The Meta-Machine Code Targeted at CHIP-8: The Reimplementation

The initial release of my MMC targeted at CHIP-8 was subpar; the detour of Meta-CHIP-8 resulted in a
mess hard to modify and inefficient.  I sought to discard Meta-CHIP-8 and customization entirely for
a time, and simply get a version in proper working order.  When attempting to translate this program
into Ada, I realized my Meta-CHIP-8 had allowed me to rob myself of a high-level idea of the system.

So, I instead entirely reimplemented it in Common Lisp, adding structure and the like as I went.  My
original goal was to finish it in 2019, but I pursued SHA-1 instead; with 2020-06-XX, I'd discipline
to program daily, however little, and went from a version which didn't load to what I now show here.

As I took my time preparing the program, there wasn't reason not to wait for this third anniversary.

My Meta-Machine Code is an interactive machine code development environment with a greater knowledge
of the machine code being programmed than other development tools such as assemblers; keys are bound
to routines which question for the unknown holes of the instruction to be entered, and meta-commands
are used to move around that address space, manipulate names, shift memory, and other clerical work.

Follows is an ugly diagram of the keyboard layout.  The top row holds shifted commands.  The idea is
the MMC interface is dependent on only the positions of keys, with the middle and so resting row for
meta-commands which command the tool to move about the program space, manipulate names, and whatnot.

The far right key is independent of position, being \, and the group next to it is /, ?, =, and + in
Dvorak, and [, {, ], and } with Qwerty.  The mouse may be used to move about; a left click moves and
a right click redisplays from there; the up and down array keys also move.  Escape is used to leave:

    EX9E EXA1 FX07 FX0A FX15          FX18  FX1E FX29 FX30 FX33          FX75 FX85
    1XXX 2XXX AXXX BXXX DXYZ          CXYY  3XYY 4XYY 6XYY 7XYY          FX55 FX65          8007

  Delete                                   morph  ~~   ~~
  Insert  up  down jump save       instate value name label

    0XXX 00E0 00EE 00FB 00FC          00FD  00FE 00FF 00CX 00DX
    5XY0 8XY0 8XY1 8XY2 8XY3          8XY4  8XY5 8XY6 8XYE 9XY0

There are two other modes of input, integer and string collection.  When reading an integer, a limit
is in effect, past which an integer cannot be entered; the middle row of keys is bound to increasing
values; pressing tab permits switching to name entry, permitting a name with a value in the limit to
be entered instead; the default answer is used when no input is provided, being shown beforehand and
with an exclamation point if indicating a default with a name; the base can be changed in-place with
control and the left resting keys; the space key doubles as deletion, all bottom row keys act as the
enter key for submission, and upper row keys function as digits in the hexadecimal base.  The string
collection is simpler, with the keyboard acting normally, and some symbol keys giving other symbols.

The XYYY commands ask for a single CHIP-8 address, showing any name upon display.  The XYZZ commands
ask for a register and an octet, showing any name of the latter upon display.  The WXYZ commands ask
for registers, showing no names.  The bottom row, dedicated to 0XXX, asks naught, with the exception
of 00CX and 00DX, which both ask for a nibble and display any names.  The DXYZ reveals a minor issue
with this design, in that the system can assign at most one name to one octet, with this instruction
being able to make use of two for Y and Z; if two are used, a further question is asked to keep one.

Deletion and insertion manipulate the program space around the current address as would be expected.
The up and down commands traverse as expected, and can also be accessed from the common cursor keys.
The jump command is used for quickly traversing the program space, using the integer asking routine.

The value command permits arbitrary integers to be stored in the current location, optionally named.
The morph command rotates behaviour of the current location, between instruction, hextet, or octets.
The name and label commands create a name, simply experiment; shifted, they similarly delete a name.

The instate command is working, but isn't yet finished, and I've planned more complex name commands.

I expect to heavily update this article, as the newer features are added, and as I find more to add.

This is the culmination of a decent amount of work and design so far, but my work wasn't continuous,
and the tool merely now exists in an improved state, still far from my initial envisioning, borne of
boredom.  It required adopting programming into my daily routine, that I was able to finally finish.

It's obvious, from my eyes, getting closer to my initial envisioning for the MMC will require better
systems to exist, and this is a fine enough place to leave this work for the present; I'll prefer to
focus on mine other novel work, such as Elision and writing libraries, for at least a time from now.

This experience has shown me perfectly well how very arduous it is to write a standalone software on
current systems.  It's entirely infeasible, to write something not falling to some manner of obscure
edge case.  The interface of the MMC was necessarily shaped by what was available to me.  I can mull
over better expressions of the idea; even this basic interface is subject to edge cases.  A terminal
resizing generates an event which Common Lisp has no concept of, and so is ignored, but this isn't a
good mechanism in any case; a proper mechanism would allow the program to specify minimum dimensions
and whatnot.  One with good sense would be concerned about coping with the edge case of a one-by-one
resizing, but it seems most people entirely ignore this.  I refused to have an explicit command with
the sole purpose of correcting broken displays; redisplay should be triggered by jumping, if needed.

It would be pleasant to have an extension mechanism favoring no language for arbitrary reasons.  The
existence of Meta-CHIP-8 was to avoid this, but was purely detour.  A better system would provide an
extension mechanism that was natural, so that it takes effort not to participate, relieving programs
from making such decisions.  Another option is choosing a suitable language which no one prefers, by
obscurity.  Also an issue is the lack of good hooks into system functionality; the file selection of
my MMC is inadequate, yet hooking into the system properly is so arduous so as to not be worthwhile,
driving the easy choice towards apathy to such.  It's not worthwhile to hook into rotten systems so.

It's disconcerting, the minor, typically cosmetic flaws I regularly see in the programs I use, which
tend to also evaporate without provocation.  It seems few try to ensure something works correctly in
all possible instances, which current systems also conspire against; it's such a terrible situation.

I don't want to tease with potential work, but I may implement an even smaller MMC targeting another
architecture soon, as I'm aware of a man who's recently written an assembler for it and would prefer
he learn how assemblers are subpar, as I've.  An advantage of choosing CHIP-8 over this smaller such
architecture was the library of existing programs I could examine, which taught me features I didn't
initially know a want for, and which I doubt would've resulted from targeting the lesser machine so.

I wanted to write a manual for this software, but that's still a ways away.  The default keyboard is
Dvorak, but the silly system program for starting my program accepts a ``qwerty'' argument to change
this; there's also a ``colorless'' argument that has the tool avoid sending any color control codes.

I don't seriously expect another to use my MMC tool as I'll, but that's fine, as it exists solely so
I may have the machine code development tool I've envisioned; though, it's in a form others can use.
.