Well... not technically the first stages. All the opcodes have been all programmed in, I just need to test them and make sure all the opcodes work.

https://bitbucket.org/kveroneau/pas6502/src/default/

This is technically part of my ArcVM project so that I can have a native binary on each supported platform with ease. So, this 6502 Emulator is not cycle accurate, nor does it even count cycles. haha. It's purpose during design was to be as fast as possible on the host platform. The idea of this is if you'd like to have an in-application scripting framework to allow for external plugins and the like, you could hook it into your application and have it run real 6502 machine code binaries. Since there is a great development environment around the 6502, it'd be pretty easy for people to write plugins in either Assembly, C, or even Pascal(P65Pas). It also has the potential to give the 6502 itself a larger community of more diverse developers. If someone finds out that they can create plugins for one of their favorite applications using 6502 Assembly, it might inspire them to dive further down the 6502 rabbit hole.

Of course my plan for this 6502 Emulator, is to write ArcVM around it, in ObjectPascal of course. Python was a great environment to prototype my original concept of ArcVM in, but for it to run everywhere easily, it needs to be in a compiled form, easy to download, and most of all, easy for anyone to just execute. You can of course read more about my idea behind ArcVM in another nearby forum post I created if you are curious. This topic is just here to announce yet another 6502 CPU Emulator to the community.

As this ObjectPascal Unit develops, it will allow programs to hook into memory mapped I/O easily. So, you can set a pointer to one of your C or Pascal functions to say $ffd0 using a simple binding method provided by the unit. Thus, whenever 6502's program counter hits $ffd0 either normally or via a JSR call, your C/Pascal code within your host application program is thus called. There will be various helpers to obtain pointers to null-terminated strings in the 6502 Memory Space, along with other useful tools to fully integrate your program with 6502 machine code. Once your C/Pascal function codes ends, a simulate RTS will occur, where it will pop the 16-bit program counter back off the stack and the 6502 machine code will then resume just after the JSR call. Imagine that! By the way, this has all been tested in Python code and works wonderfully! I was even able to create a struct in cc65, and pass this struct over to my Python code, where it was fully able to read and even manipulate the data! So, if you've never wanted to create a BORG program on the modern PC which runs a hybrid of native code, alongside 6502 machine code, this is definitely the project for you. The best part about this of course if that the 6502 code is separate from your native code, so if you needed to swap out some specific functionality in your application, you can quite literally swap out a small 6502 machine program in seconds, then either rerun your program, or use some button or external API to signal your native code to reload in your 6502 machine code. These are just some ideas on how integrating a 6502 Emulator into a modern application could be useful.

Anyways, let me know your thoughts below, and if you have any questions or would even like to help out.

Sounds interesting!


That is,

ArcVM: Not your traditional 6502 emulator

Just added a major update this evening(at least in my timezone)...

Firstly there's a new markdown document: https://bitbucket.org/kveroneau/pas6502 ... t/USAGE.md

Also, it's now finally usable! You can load in a binary file, or hand assemble using the setB and setW method calls.

BRK or the $fffe vector by default points to $fff0 which has an ObjectPascal callback to default_BRK, which sets FRunning:=False, so guess what? The IO Map Callback system is now functional! You can map in ObjectPascal functions into the $ff00-$fff9 IO space, and when your code does a JSR to this callback address, your ObjectPascal function will take over and do what it has to do. If your function sets the Result to True, meaning it was handled, the code then simulates a RTS and resumes back to your 6502 machine code. How swell is that?

Furthermore, if you make programs in cc65, there are some special method calls you can use to access the cc65 stack and pop pointers from it, so if you perform a C function call in cc65, it is fully possible for your ObjectPascal callback to properly read in the parameters sent in from the C function call and perform the actions and then safely return back to where the C function was called. I will be publishing samples of this in action at some point soon, as it really highlights how powerful this interactivity can be. Once I figure out how P65Pas works and how it does system calls, be on the lookout for this being fully supported as well. So your 6502 Pascal code can call your x86/ARM ObjectPascal code with ease.