1## On The Evolution Of Ngaro Into Nga
2
3When I decided to begin work on what became RETRO 12, I knew
4the process would involve updating Ngaro, the virtual machine
5that RETRO 10 and 11 ran on.
6
7Ngaro rose out of an earlier experimental virtual machine I had
8written back in 2005-2006. This earlier VM, called Maunga, was
9very close to what Ngaro ended up being, though it had a very
10different approach to I/O. (All I/O in Maunga was intended to be
11memory mapped; Ngaro adopted a port based I/O system).
12
13Ngaro itself evolved along with RETRO, gaining features like
14automated skipping of NOPs and a LOOP opcode to help improve
15performance. But the I/O model proved to be a problem. When I
16created Ngaro, I had the idea that I would always be able to
17assume a console/terminal style environment. The assumption was
18that all code would be entered via the keyboard (or maybe a
19block editor), and that proved to be the fundamental flaw as
20time went on.
21
22As RETRO grew it was evident that the model had some serious
23problems. Need to load code from a file? The VM and language had
24functionality to pretend it was being typed in. Want to run on
25something like a browser, Android, or iOS? The VM would need to
26be implemented in a way that simulates input being typed into
27the VM via a simulated keyboard. And RETRO was built around this.
28I couldn't change it because of a promise to maintain, as much
29as possible, source compatibility for a period of at least five
30years.
31
32When the time came to fix this, I decided at the start to keep
33the I/O model separate from the core VM. I also decided that the
34core RETRO language would provide some means of interpreting
35code without requiring an assumption that a traditional terminal
36was being used.
37
38So Nga began. I took the opportunity to simplify the instruction
39set to just 26 essential instructions, add support for packing
40multiple instructions per memory location (allowing a long due
41reduction in memory footprint), and to generally just make a far
42simpler design.
43
44I've been pleased with Nga. On its own it really isn't useful
45though. So with RETRO I embed it into a larger framework that
46adds some basic I/O functionality. The *interfaces* handle the
47details of passing tokens into the language and capturing any
48output. They are free to do this in whatever model makes most
49sense on a given platform.
50
51So far I've implemented:
52
53    - a scripting interface, reading input from a file and
54      offering file i/o, gopher, and reading from stdin, and
55      sending output to stdout.
56    - an interactive interface, built around ncurses, reading
57      input from stdin, and displaying output to a scrolling
58      buffer.
59    - an iOS interface, built around a text editor, directing
60      output to a separate interface pane.
61    - an interactive block editor, using a gopher-based block
62      data store. Output is displayed to stdout, and input is
63      done via the blocks being evaluated or by reading from
64      stdin.
65
66In all cases, the only common I/O word that has to map to an
67exposed instruction is `putc`, to display a single character to
68some output device. There is no requirement for a traditional
69keyboard input model.
70
71By doing this I was able to solve the biggest portability issue
72with the RETRO 10/11 model, and make a much simpler, cleaner
73language in the end.
74