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