Last year I was pondering, and pondering hard about a fun, interesting, and most importantly, useful use-case for the 6502 instruction set. Then it hit me, why not create a modern Virtual Machine environment which uses the 6502 as the base instruction set, but it's goal is more similar to say a Java Virtual Machine where it's purpose isn't to emulate or run binaries from older computer hardware, but to sandbox and virtualize modern computer software in a write-one, run-anywhere runtime environment. Welcome to my latest project, ArcVM!

Now before you jump in and say that the 6502 lacks many functions modern computer software require, and how slow a 6502 CPU is, hear me out for a moment. Sure the 6502 doesn't natively support floating point math, is limited to only addressing 64kb of memory, can't multitask easily, run threads, or run the latest AI packages. However, this is when you take a pure 6502 machine from the 80s and 90s, or a true hardware version of the chipset. Running within a specialized Virtual Machine, in theory the 6502 instruction set can be easily extended with virtual devices to do almost anything in a modern CPU. ArcVM will have support for many virtual devices, these are similar to JNI or Java accessing native library functions on the host OS. These virtual devices will have a standard interface, and will allow third parties to further extend ArcVM to support various GUI toolkits, SDL, sockets, among other things. Since these virtual devices are basically plug and play, you could create a program targeting ArcVM, and use it's framebuffer library. Then to have this same binary run on a completely different graphics technology such as SDL, DirectFB, DirectX, or even an LCD screen dangling from a Raspberry Pi, you can just swap out the virtual display device with another, and your program will use that to output your graphics.

The idea behind ArcVM is total abstraction, all commands which write out to a graphical display are the same, but the output driver which ArcVM can use to display said graphics can be easily and effortless swapped. This allows for programs to be easily ported anywhere, as long as a virtual device for what your program needs is written for that target. API calls within your code can easily determine form factor, resolution, color depth, etc... and your code can use these to adapt or not. Another example to consider is a console device which can be swapped with a logger or a Splunk device. This easily enables one to see console output during development and debugging, but then easily and effortlessly swap the virtual device to have everything that was going to standard out, now going to a splunk server. Other than swapping out a virtual device from ArcVM, none of the actual code needs to be changed.

Currently, I am writing the concept/prototype in the Python language to allow for easily testing on various platforms without needing to compile. The ArcVM end-user development is done in the C language with the cc65 toolkit. The 6502 device API basically talks __fastcall__, so there is very little overhead when calling device functions, a pointer is sent directly to the native code of where the data to be used is. Then properly does a RTS in the native code to return back to the 6502 machine code. I have begun work on arclib, which is a custom C library for cc65, use code just needs to link against this library as they would with any existing library in cc65.

Other possible uses of ArcVM is to emulate other hardware such as the C64, or emulate a 6502 OS.

Once the prototyping is done, and everything is running as I'd like it. I will be porting ArcVM to Delphi(FreePascal to be exact), which can then target every popular operating system to generate a native binary. The ultimate goal is to create a singular abstracted virtual environment, which is procedurally programmed, and can run the same binary on all devices, PC, Android, and eventually in the web.

I have open sourced ArcVM to encourage healthy development, and allow it to grow. You can find the repo here: https://bitbucket.org/kveroneau/arcvm

Let me know what you guys think of this idea, and if it might cause issues with the current owners of the 6502 specification.

But that's not how this works. That's not how any of this works.

Having a 6502 instruction set with a VERY heavily overloaded, what, BRK instruction? the COP instruction from the 65816? Perhaps the WDM instruction? What value is that?

The JVM actually has no devices. It just has a simple mechanism to allow the byte code to make calls to native code. The JVM has no idea of a "disk drive", "serial port" or pretty much anything else. Rather it's a well specified memory and execution environment. If you want to create a file, you call a piece of native code. Ideally interfaced through the Java Libraries standard library, but that's a separate requirement. Its extensibility is in its ability to call JSR, and give native code read/write access to its heap.

Creating a 6502 with a magic instruction that has 256 variants (i.e. COP followed by some other byte), isn't really a 6502 at all, is it?

What value is there in writing a high level language targeting an architecture that is actually a rather poor target for high level languages, when it's all "made up" anyway.

Now, if you wanted to make a cool co-processor bit of programmable logic, like a REAL FP co-processor, that someone can burn into a chip and wire in to a machine -- that would be very cool. The stuff that the KimKlone did was endlessly fascinating.

Just exploring that more would be interesting. Too bad the COP instruction isn't part of the 65C02, but instead the 65816.

When I read the original post, I thought the "virtual devices" would just be memory-mapped and accessed with regular 65xx instructions like LDA, STA, INC, BIT, etc. So the 65xx code would be "conventional", and the I/O would be where most of the magic occurred. Please correct me if my understanding is incorrect ...

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

Hey, this is all good. Just because the JVM has one approach doesn't mean a new VM has to take the same approach. Some of the early microcoded minicomputers had instructions which did I/O at a relatively high level.

There's no place here, surely, for a purist's "that isn't a 6502 any more" - that kind of statement is only ever a statement of personal preference. If you don't like the shape of a project, you don't need to say so - just move on.

Yes, this is exactly how it will be implemented. It will use pure 6502 instructions, no special opcodes. In all essence, ArcVM is a pure 6502 emulator with more access to the real world, but gated access.

The memory mapped I/O devices can be easily probed using a Slot-like system which the Apple ][ implemented, so programs can check which functionality is available and adapt if needed. For example, if you are running on a non-GUI system, such as a UNIX terminal, the code could be adapted to use termcap or ncurses to display information to the user, rather than GTK, Win32, or Carbon. I am taking inspiration from the idea of FreePascal's GUI kits, where you can just rebuild your Pascal program and just target a new GUI to have a native program on every OS. I once created a Gopher client, and it looks native on Linux, Windows, and OS X with just a simple recompile on that specific OS. The underlying GUI code was completely abstracted, so I didn't need to know the specifics of GTK, Win32API, or Carbon. I just needed to know the API for Lazarus. This is really how modern programming should be, we shouldn't need to rewrite our GUI code in 5 GUI frameworks to achieve native GUIs on all platforms we target. Since devices will be shared libraries on the supported OSes, GUI Toolkits can be swapped out, and the program code can remain the same. This puts the power of what features the user wants the program to use, rather than letting the developer enforce a specific library or module. For example, if one user prefers OpenSSL for TLS and encryption, another user may prefer LibreSSL, I believe which library to use should be the end-users choice, and they shouldn't need to recompile a program just to use an alternative library. Of course there will be a nice default distribution of ArcVM which provides plenty of sane defaults for the OS the user is using.

Anyways, I got too much into it there. I am rather excited at trying out this concept and seeing if it can be viable development tool. It's also nice for those people who personally don't care or dislike how OOP programming has evolved, as cc65 is just plain C. I am also not aware of any OOP languages for the 6502, correct me if I'm wrong here. I have recently read some articles against OOP, and how it tends to over complicate code, and causes a lot of headaches for developers as their codebase grows.



I fully agree with that statement. That's basically how science works, one person disputes the work of another, like saying how the world isn't flat or questioning how in that point in time the way things were done. There are plenty of VM runtimes on the market, each have their own solution for how to run the bytecodes, and how they interact with the OS. I personally never seen an abstracted method like this, except in Lazarus I guess, where your code doesn't target a specific library, but an abstracted(and consistent) API to communicate to the actual libraries. This can also mean that very specific features of a library are more difficult to use by a developer, but the trade-off of not needing to code the same thing more than once for multiple APIs is the selling point here. Software development has gotten pretty fragmented in terms of how many similar functions have completely different API calls, so swapping out to use a different library can be a huge pain.

Thank for the feedback and encouragement. Once I have some useful example programs running to better demonstrate the concept, I'll share more information.

Well, the basic fact is you can only go off what people tell you.

This is what he said:


He said he wanted to extend the instruction set, not interface the CPU.

Sorry, but them's different.

And if you extend the instruction set enough, you end up with "not a 6502".

If he wants to make a bunch of memory locations in his simulator do magical things, then, super! That's more the spirit of how the CPU works. Heck, that's what I do in mine. Read from a location and, amazing, a keyboard entry shows up. Write to another and a character appears on the screen. Read from another, and a block of memory is magically filled with data from "disk". "DMA", yea that's it!

In this case, you have a 6502 that's "not an Apple" and "not a BBC machine". But it's still a "6502", at least from a software pov.

My simulator in Java has a simple "Memory" interface. The implementation I use the most happens to have a terminal, keyboard, and "disk drive" connected to it. But the CPU doesn't know anything about those. Programs just read and write memory, stuff happens.

I'm sure maybe he wants something more cycle accurate. My disk just stops everything while it loads the data, the CPU just "hangs". But that's suitable for me, I don't strive for accuracy at that level -- it's more a functional implementation than accurate simulation.

And his example of the JVM to demonstrate his project was simply a bad example, as it does not due what he said it does. It's not implemented that way.