So, I think I am finally starting to feel real confident with my ObjectPascal programming skills now. I have created a couple things, but nothing too substantial. I do have a programming background, I mostly programmed in Python(and still do), but decided I needed a language which really emphasizes cross-platform, as well FPC/Lazarus really hit that out of the park. Compared to say Python when you want to put together a GUI application, it can get rather complicated when it comes time to deploying it out to end-users, as you will need to either ship the entire Python runtime, and any Qt/Gtk libraries along with it, and hope that everything just works on the other side. This also results in a very large distribution as you could imagine. Lazarus programs tend to be very tight in size and speed, and usually compile with no issues on any OS that Lazarus can run on. Beautiful!
Anyways, so the FPC Unit, which doesn't technically need Lazarus at all, but I am providing a lpk file for ease of use for both myself and anyone who may wish to use this. I put together the first pieces of a 65c02 CPU Emulator! This might at a later date become useful for another interesting ObjectPascal project, P65Pas, an editor and Pascal compiler for the 6502! I am sure this project could say integrate this 6502 Emulator into their IDE to allow for some basic debugging and such. Just a thought.
You can find it here on my BitBucket page:
https://bitbucket.org/kveroneau/pas6502/src/default/I also noticed that BitBucket, although supports ObjectPascal as a selectable language, does not highlight files. This is rather disappointing.
I should also add, that this 6502 Emulator is not cycle accurate, nor does it even take cycles into account. You may be scratching your head, wondering, why? The purpose of this 6502 Emulator was not to run retro software, plenty of software packages out on the Internet already do that. The purpose was to have the 6502 machine code run as fast as possible on whichever host machine it runs on, so that it could act as a Virtual Machine for some other type of program or tool. Here's a rather basic example, say Castle Game Engine allowed for the loading of external scripts written in either C or Pascal, how could they implement this in the Engine? You see, plenty of compilers currently exist for the 6502, cc65, and P65Pas. The 6502 machine code is rather versatile, and new opcodes or IO could be provided to extend the 6502 to allow to perform tasks like real multiplication, and floating point operations. If you read that last line and are now thinking, the 6502 could never do anything like that, it does not have the opcodes necessary. That is the common response I hear when people rarely think outside the box. On the 6502, could you not map IO devices in memory? Do you not recall the 286 and 386SX processors? These processors either needed to perform floating point operations in software emulation(emu87 unit), or you needed to have the math co-processor installed on your motherboard. Now, think of the 6502 like the traditional 286(but emulates faster), could you not map a virtual math co-processor onto your Virtual 6502 to allow it to perform float point calculation? But lets take this a step further... If you code the 6502 Virtual Machine in just the right way, your 6502 machine program can actually do anything your host machine can do, as long as you provide an API within the VM code. Something I recently tested was having virtual addresses mapped in, when the 6502 program counter would JSR to this special address, it basically acted like a cdecl call into my host code, here's an example:
https://bitbucket.org/kveroneau/arcvm/src/default/runtime/devices/console.pyWhen a C function like say "puts('Hello World');" is compiled into assembly, it places a pointer to the string into A and X as a 16-bit word. And in this situation, instead of puts being a real 6502 function, instead puts in just a pointer to a virtually mapped I/O address. So when the compiled C code attempts to JSR to the entry point of the puts statement, guess where it goes? It goes into the Host program, and as you can see in this Python code, I can easily grab the 16-bit pointer to the string, then grab the null-terminated string, and display the text. When this method call ends, it simulates a RTS, but popping the 16-bit pointer off the stack and setting it to the program counter, and then it resumes the 6502 machine code ending our call into the Host OS. I was able to go way beyond a simple string of course, I am able to send any data type from C, including custom structs. This allows the virtual 6502 machine code to access allowed resources on the Host OS, much like how say the Java VM or maybe Qemu permits access to very specific host systems.
The idea here, is that the 6502 machine code can be used like any other bytecode system, but has the advantage of being register-based, pretty darn fast, has tons of useful op-codes, and works great with memory mapped I/O to allow perfect Host OS integration. Also since the 6502 is really well know, it also has the advantage of attracting talent, and has a really great set of development tools and a full community. Why write your next in-application scripting environment from scratch. And yes, I know of the existence of PascalScript to enable one to add in-application scripting into Lazarus programs. However, I imagine that PascalScript is technically much more complex than a CPU Emulator running machine code. This can both be an advantage and a disadvantage. The advantage of course is that it can support some very complex language constructs such as full ObjectPascal syntax, the disadvantage is the lack of complete control. With a 6502 VM, the entire memory core can be easily dumped, multiple 6502 VMs can run at the same time in a single Pascal program either using a co-operative method, or by multithreading. Your Host program can create virtual interrupts to signal the 6502 VM, the entire Virtual Machine can be effortlessly suspended to disk and easily resumed at the exact point in time which it was suspended with no negative problems. And most importantly, a 6502 Virtual Machine can fully create self-modifying code, and you have access to all the VMs heap memory from your Host program. It may also run a tad faster than PascalScript, but I will need to eventually create benchmarks to determine this.
Anyways, that is where I am at with my current 6502 CPU Emulator code. I still need to add many features, as this is just it's initial release.