(2025-04-28) 808UL was just an exercise. Here's the real deal
-------------------------------------------------------------
Sometimes, my hobby projects are doomed to be short-lived, but they serve
their purpose nonetheless. The lifetime of the 808UL VM between the 
completion of its four reference implementations and officially announcing 
its deprecation was about... one week. No, I'm not going to shut down the 
repo or the JS version web page, but I'm not going to develop them further. 
And let me explain why: because over this time period, I have come up with 
something even better instead.

Let me first remind you what I started with in the beginning: the ideas of
1V0, an extremely interesting, minimalistic, numeric-only VM that already 
had multiple implementations largely incompatible between each other. That 
being the first problem and instruction bloat being the second problem, I 
decided to create a fresh, unified spec that would address both of them. And 
thus, 808UL was born. However, when writing that spec, I still was adhering 
to some of 1V0's concepts I shouldn't have stuck to in the first place, like 
the operand order for certain operations and the distinction between the 
runtime and interactive mode data I/O (also adding port I/O as the *third* 
type). As such, some unnecessary complexity and confusion still was present 
both in the implementations AND the programs written for 808UL. On top of 
that, I explicitly stated that the 808UL spec wouldn't enforce a lot of 
things like binary instruction representation or memory size, which might 
lead to further incompatibilities in the future. As such, I began to feel 
that 808UL still wasn't a finished product but rather an intermediate 
experimental step between what I started with and what I wanted to see. It 
needed to be minified and structured even further. That's what eventually 
led me to the creation of mu808. Yes, it's pronounced exactly the way you 
think: micro-bob.

Since I didn't have to reinvent absolutely everything from scratch, I think
it won't be surprising that a Codeberg page with the same four reference 
implementations already exists ([1]), and even the Web version ([2]) is 
fully functional on the same level as 808UL. The presence of a stricter 
binary format for programs (MU8B) that's optional to implement won't 
surprise you either. What might surprise you is that mu808, unlike 808UL, 
already has its own assembly language called MU8A, and the official 
assembler/disassembler (as of now, only in Python) is already present in the 
repo and fully functional. MU8A is extremely simple to both write in and 
parse, and that's quite intentional: you should be able to assemble mu808 
programs by hand with little effort if you have to. Besides MU8A and MU8B, 
the plaintext machine code format (MU8) remains the main format to 
communicate with the VM, although the VMs are now required (at least when 
loading the .mu8 files) to recognize instructions delimited with just 
whitespace, not newline characters, and the user is generally required to 
always enter 5 numbers in the interactive mode before the instruction is 
entered/executed. On top of that, the specification defines just sixteen 
instructions (along with their MU8A mnemonics) with a much clearer parameter 
order, ditching the concepts of extended instructions and dedicated port I/O 
(because now it is integrated into the main INP/OUT instructions), and 
reduces the amount of interactive instruction numbers to just -1..-5. 

What's lost in comparison to 808UL, you may ask? Well, not much. The only
instructions that are really gone are the power, swap and degree-radian 
conversion instructions, but they, like everything else, can be easily 
emulated with what's left. The natural logarithm and natural exponentiation 
instructions were combined into the opcode 13 (NEL), and the sin/cos/arctg 
instructions were combined into the opcode 14 (TRI), among others. A really 
breaking change though is that mu808 combines addition and multiplication 
into a single opcode 7 (FMA). Yes, the implementations ARE supposed to use 
the fused multiply-add operation *a3 = fma(v3, v2, v1) on the platforms that 
support it, and emulate it with the usual *a3 = v1 + v2*v3 on the platforms 
that don't. And yes, it changes the way mu808 programs are written, since it 
does require an extra copy before the multiplication sometimes. But I think 
this change is worth it and can be useful in a lot of cases. I have 
described some typical FMA usage scenarios in the FAQ section of the mu808 
readme file. Also, as you may have seen, the examples are now primarily 
shipped in the form of MU8A assembly source code, but the plain .mu8 files 
to be directly used in the VMs are also available in the 
"examples/assembled" subdirectory. If/when an implementation appears that 
only supports MU8B binaries, I'm probably going to ship those too. Besides, 
since the port I/O is now unified with the main I/O (with character 
input/output ports still being optional and platform-dependent), I could 
greatly simplify the "Hellorld!" example by just specifying the memory range 
to output as characters. With 808UL, if you remember, I had to roll my own 
memory looping logic to output the characters one by one. 

Now, what's the future of mu808? Is it going to be as short-lived as 808UL? I
don't think so. The ISA is now rock-solid, the niche is defined, the tooling 
is here. And **this** is what I'm going to further port to some exotic and 
retro platforms, including but not limited to what I had planned to port 
808UL to. I still do have some concerns about some platforms, e.g. how much 
of the remaining memory will we get for data and the mu808 program itself 
when this VM is ported to BASIC that can run on my TI-74S? Well, you'll 
never find out until you actually try it. So I have tried it, and now the 
TI-74 BASIC port also is there along with others. And, while 149 program 
steps and 256 data cells doesn't seem to be a lot, there still is enough 
room to run all the existing mu808 examples, although a number of 
limitations definitely do apply due to the nature of the TI-74 runtime 
environment itself. It also is quite slow, something to expect from a VM on 
top of an interpreted environment on a portable PC from 1980s. But it does 
work and run my examples. The story of how this porting has been done, 
however, is worth a separate post, I think. Maybe the next one. What can I 
say for sure is that this definitely is not the last mu808 port to retro 
systems. So, as always, stay tuned!

--- Luxferre ---

[1]: https://codeberg.org/luxferre/mu808
[2]: https://mu808.luxferre.top