Cracked-on with the project last night, tackling those tasks in my list from the previous post. First was to re-visit every line of code in the instruction decode/execution logic, to make sure it all looked good and did the right things in the best way. There were a few places where I could tweak stuff - mostly things like removing bit-masking code on 16-bit registers (either because the contents were being moved to an 8-bit register, or because I could replace the 16-bit register with an 8-bit one altogether) and occasionally re-sequencing things to eliminate temporary variables. Overall, it was in pretty good shape, and is now about as good as I can make it in its' current incarnation (i.e. as a basic select..case switchblock). Version 2 of the core, still some way off, will do this whole thing a very different way, but for now it suffices.
Second on the list was to convert the core classes into a DLL that the monitor would talk to, instead of having the actual classes included as part of the monitor project. In the past, before C#, .NET, and Visual Studio, this would have been quite a sizable task. It was certainly something I was not looking forward to doing; but once I knuckled-down and got stuck into it, it turned out to be a walk in the park. Add a new Project to the monitor Solution, choose Class Library (the new name for DLL), move all the core-related classes over to it, set the dependancy in the monitor project to use the Class Library, and build it. Seriously, a task I thought was going to take two or three hours ended-up taking about 30 minutes, including a couple of tests beforehand to see how it was going to work out.
Second on the list was to convert the core classes into a DLL that the monitor would talk to, instead of having the actual classes included as part of the monitor project. In the past, before C#, .NET, and Visual Studio, this would have been quite a sizable task. It was certainly something I was not looking forward to doing; but once I knuckled-down and got stuck into it, it turned out to be a walk in the park. Add a new Project to the monitor Solution, choose Class Library (the new name for DLL), move all the core-related classes over to it, set the dependancy in the monitor project to use the Class Library, and build it. Seriously, a task I thought was going to take two or three hours ended-up taking about 30 minutes, including a couple of tests beforehand to see how it was going to work out.
In doing that, I got the third item on my list for free. Making the monitor use the DLL instead of included class files was all wrapped-up in making the DLL itself - by the time I had the DLL built, and almost before I realised it, the monitor project was using it. Again, something I thought was going to be an hours' work was actually done without even really trying. So I have to shout out a big Thank You to Microsoft for making this an almost trivial task!
So we now turn to item four, which is to create a GUI replica of the commandline monitor. So far, I have an MDI window and some menus defined, because I got that far and then decided to call it a night and dive into World of Warcraft for a while. But it's a start, and considering I wasn't expecting to start it for a few days yet, I'm a happy bunny.
Now you might be thinking that it's a good time for me to check all the existing emulator code into Google Code, but I'm not going to just yet, and here's why: although it all works well as far as it goes, it's still a country mile away from being ready for release (even just alpha preview release). The instruction support is at less than 50% of the official opcode set, because as you know I've just been implementing instructions as the VIC-20 ROM throws them at me; that means that not every instruction has been encountered, and for those that have we've only seen a subset of their addressing modes. Equally, none of the undocumented opcodes have been seen yet, and few of the systemic 6502 glitches are wired-in either (like the JMP page bug). So I'm not content to have World+Dog looking at it yet, because it's just not good enough in my eyes.
Instead, content yourself with a VERY early alpha screenshot of the IDE - so early, in fact, that it's almost mind-numbing in its' dullness. But at least you can see progress. :)
So we now turn to item four, which is to create a GUI replica of the commandline monitor. So far, I have an MDI window and some menus defined, because I got that far and then decided to call it a night and dive into World of Warcraft for a while. But it's a start, and considering I wasn't expecting to start it for a few days yet, I'm a happy bunny.
Now you might be thinking that it's a good time for me to check all the existing emulator code into Google Code, but I'm not going to just yet, and here's why: although it all works well as far as it goes, it's still a country mile away from being ready for release (even just alpha preview release). The instruction support is at less than 50% of the official opcode set, because as you know I've just been implementing instructions as the VIC-20 ROM throws them at me; that means that not every instruction has been encountered, and for those that have we've only seen a subset of their addressing modes. Equally, none of the undocumented opcodes have been seen yet, and few of the systemic 6502 glitches are wired-in either (like the JMP page bug). So I'm not content to have World+Dog looking at it yet, because it's just not good enough in my eyes.
Instead, content yourself with a VERY early alpha screenshot of the IDE - so early, in fact, that it's almost mind-numbing in its' dullness. But at least you can see progress. :)
Posts
0 comments:
Post a Comment