I am in the planning and implementation stages of making the Virtual Machine is a core aspect of the entire game. Currently, the VM code is only initiated when you run a binary program, however this will soon completely change. For awhile now I was wanting to have the VM take over as soon as possible in the player connection bootstrap process. Here's the current process:

Player successfully logs in, a new Pyhon class is instantiated for their Shell.

The shell class then does various checks, such as if the host is online.

If the host is offline, then it checks if the KERNEL.SYS is there and alive, to boot the host.

After everything is all and good, control of the actual shell and shell commands is all done in Python code.

Today, I am working on removing the Python Shell class code entirely from the mix. So, here is how the connection will work after I complete this update:

Player successfully logs in, check to see if host is online.

If host is offline, we initiate an empty memory address space for the VM, we attempt to load in KERNEL.SYS

This will finally re-introduce a working KERNEL.SYS, which was last seen in 2013(or 2014), which actually contains executable VM code to initialize the actual VM.

KERNEL.SYS will be responsible for the following tasks when executed:

Configuring the VM memory address space

Configuring the all-important vector table(I'll get back to this shortly)

Configuration basic VM services

The KERNEL must define an API, or binary apps will need to talk low-level to the VM.

The KERNEL must load in memory the shell program from the VM storage space.

The all-important vector table in the VM memory will be used to determine the shell program, and the program to load for remote shells. This vector will also contain special memory locations for KERNEL APIs and services, such as ACL handling, and in the future storage APIs.

I will post an update into this thread later today once I have created the new code, and played around with it for a bit.

I now have a fully working 6502 assembler, which will be used in Hacker's Edge in the next update. You can use the following pages for reference on how you will be-able to create programs in Hacker's Edge:

I am just finishing up the program labels, so that code branching and jumps will work with labels, and not just addressing.

Once this has been completed, I will move onto putting together a Hacker's Edge compatible virtual machine for the assembler with a custom BIOS, and memory space specifically for Hacker's Edge.

When this code is released, the assembler will be hardcoded in Python, however I do plan on porting the assembler itself to 6502 assembly, so that the assembler will be a regular Hacker's Edge binary program. This will allow the community to update the assembler with newer and better features as time goes on.

I have finally finished writing the CPU op codes for the VM core. Next, I need to assemble a couple test programs and make sure it works correctly before I can integrate the codebase into Hacker's Edge. We're almost there!

Least to say, I still need to do some debugging, as some test programs are not running correctly just yet. The issue is with the labels system, I needed to create 2 different types of labels, absolute and zero-page labels. As many operations depend on this.

I don't anticipate that it will take me too long to troubleshoot, then I can begin integrating it into the game code. Integrating it won't take very long at all, only a few lines need to change in the assembler, and the VM for it to work correctly.

And with that, I found out the issue. It wasn't the assembler or the VM code, I was my 6502 assembly code that was at fault in my test program. When attempting to assign a pointer to the accumulator, I instead assigned the value to where the pointer was pointing... D'oh

So, rather than getting the excepting 30, which is the memory location for my Hello World message, it instead placed 72 in the accumulator, which then when attempting to deference it later in the code, all went horribly wrong.

Let this be a lesson to anybody who will be doing 6502 assembly in-game. Even though each in-game host is independent, you can easily trash your own host's memory space with a buggy program. The VM itself doesn't currently support protected memory. Most memory access will be performed directly. I may implement proper paged memory support in the future, and pages can be marked as read-only, and such.

Anyways, now that this is out of the way, now I just need to work on configuring the stack, and making sure binary programs can load from other locations correctly.

From my testing so far, everything is working 100% in my test development environment. Code runs, labels, branching, loops, the stack, zero-page addressing, far pointers, and code relocation is all working as expected!

The next steps are to start the integration of both the assembler and the VM into the Hacker's Edge codebase.

The proposed above workflow will not be live immediately however. I need to work on the chicken and egg problem here, where I need a KERNEL to bootstrap the system into the proposed mode. So, when this new code goes live, everything will basically function as it did before, with the only exception being that the asm and running binary images will use the new code. Before I can properly bootstrap Hacker's Edge, I will also need to copy the final KERNEL image to all the existing virtual machines, so that they can all properly reboot themselves and use the new KERNEL image.

However, before any of that can happen, I will need to write a functioning KERNEL for Hacker's Edge, and write the needed APIs so that networking, and file system access works correctly from within the virtual machine space. A Shell program will also need to be written, or you won't be-able to much after connecting. :)

I may add some temporarily logic into the Hacker's Edge game, so that players can opt'd in to playing with the new KERNEL. Basically, upon connection and host boot sequence, some checks will be performed. Based on the results, it will either use the old system, where Python is the core, or it will load the binary KERNEL image and go from there. I will be creating a post in the beta tester forum shortly to ask for anyone who wants to test-drive the new system.