@unthankable
What you mean by VM is what I call a client, a way to interface with the interpreter(server). I don’t have a clear roadmap, but this is kind of where I’m going:
- Build a strong orca benchmark file, and test the current implementations of the alphanumeric operators against it.
- Complete the super simple frame interpreter, so this little server spits out the next frame and the associated IO messages.
- Build a small SDL client that handles syntax highlight, input, timing talking to the interpreter(server).
- Use this for my next livecoding gig.
The orca alphabetic operators should be the “spec” and not change from one implementation to the next, anything that would fail the benchmarks is not orca compatible, and that’s fine, there can be other versions too if someone doesn’t like one operator or another.
Typically, if someone finds a problem with the 26 core operators, they’ll raise an issue on here, but that hardly ever happens. Typically, it’s people who misunderstand their usage.
While the letters are interpreted normally, the special characters(IO operators) should each send their values across so the client can handle the messages as they like.
For example, the C89 server outputs the messages in a separate buffer, so something like :03C3. is not interpreted but instead sent to the IO buffer so the client can have access to it and choose to do whatever is needed with that.
Modules, IO, etc should be done with special characters. So for instance, my 6502 implementation doesn’t use any of the midi/osc operators, since their usage is different and specific for the NES platform.
