Programs with lots of math and memory or I/O operations will definitely require more processing time. Waiting for user-input in most programs should not, waiting on network traffic shouldn't either. My goal isn't to replicate the real world Internet/networking protocol within Hacker's Edge, but create a feeling of realism, where to the player it feels like they are hacking on real machines on a real Internet. Other so-called realistic games do similar feats to suspend player disbelief. When you player say an open world game such as Elder Scrolls, Fallout, or GTA, you as the player are immersed into the game so much, that the world actually feels alive. Animals move naturally across the countryside, NPCs have realistic schedules and act according to player actions. Although these aren't real animals or people, they react according to their environmental parameters, and what the player performs. The AI is very scripted. However, the AI is scripted in such a way that to a player, it feels like a real animal is reacting to them, or a person is reacting to you assaulting them.
This is why the VMs aren't 100% realistic in the sense where they are running code constantly in real-time. I am building the game systems in such a way which mimics traditional game development practices in the industry. I am creating the illusion of realism to suspend player disbelief. Like in other game genres, it is next to impossible to simulate a real living world to 100% accuracy with current technology, and for player enjoyment, you don't need to. As long as the in-game systems are programmed right, the game world will feel real enough to suspend player disbelief. Hacker's Edge is still a game, and not meant to be a VM simulation tool. haha. I'd rather focus on making it a fun game and experience for all players who eventually play, rather than focusing on a hyper-realistic 6502 Virtual Machine simulation.
The other issue with having VMs running constantly, is as soon as a player logs in, new or old, a VM is basically spun up for their player. Now say, this user logs out and never comes back. What happens? A VM which is basically doing nothing whatsoever but in an idle loop waiting for said player to re-connect is running and consuming real-world CPU. Other problems with having constantly running VMs is that if code goes amuck, and a novice user just closes their telnet or browser tab, that code continues to run forever until I restart the game server or kill all the running VMs manually. There is no easy way to determine which code is behaving and which code isn't when you have hundreds of running VMs. The troubleshooting and debugging efforts of such a system skyrocket. It will lead to game server crashes, memory issues, CPU usage problems, etc... A player theoretically can take down my entire server by building an in-game botnet with many hosts and VMs. The required moderation to run such a game would be that of a regular system admin job, I would have to constantly check all running VMs, monitor RAM and CPU, etc... It turns what should be an easy to run game server into a server administration nightmare. The easiest way to determine if VMs currently are running amuck is to check how long a VM has been running code for, and VMs for players don't run unless that player is still logged in. So, if you currently go and run an infinite loop program, then either terminate telnet or close the browser tab, that VM and thus the infinite loop are terminated. Events to your VM are still processed though, so if another player connects to your VM when it's on and is listening on a network port, that connection will still go through regardless if your connected or not.
I apologize for the long winded reply here. Hopefully this is the best way to explain why the 6502 VMs are event-based and not constantly running code 24/7.
Perhaps, rather than using event-based, I should just say that most I/O is blocking ;) When you request keyboard data, internally the request is blocking, your VM code is suspended until keyboard input is given. Technically, is leads to less code than traditional polling methods, where you have an input loop and are constantly checking if a key was pressed. It is also more user-friendly to people who may not know assembly. This keyboard block also allows for OOC commands to be properly parsed, so that you can still chat and do other OOC actions.