A milestone was achieved as I worked on the code last night - there came a point when I entered 'g' (as in 'go', the command to start the CPU) into the monitor, and nothing happened.
Now this might sound like a disaster, but it actually means that the emulator is at the stage where it allows the VIC-20 ROM to get as far as the IRQ-dependant stuff. In other words, the ROM is running in a loop waiting for an interrupt to stuff something into the keyboard buffer, and therefore the core did not spit an 'Unable to decode the following opcode byte' message at me, which is what it does when the ROM gives it an unimplemented instruction. So, nothing happened. :)
If I were writing an actual VIC-20 emulator, this is the point at which I'd starting thinking about coding some logic to represent the 6522 VIA chips which generate timed interrupts and suchlike, in order to progress the overall machine. However, I've never intended to write such an application - loyal readers will know that I was only ever using the VIC-20 ROM as a test to get the emulated core off the ground. So with that done, we're fast approaching the point at which I'll be jumping-off into deeper waters, essentially configuring my own ROM to test instructions that have no code written for them yet.
But before I do that, I have a few other tasks to do:
1. Revisit the instruction decode logic to make sure everything is neat, tidy and efficient.
2. Repackage the code as a DLL so I can disconnect it from the commandline monitor.
3. Rework the commandline monitor to use the DLL version of the core.
4. Write a basic (but extensible) GUI replica of the commandline monitor.
Once we get to item 4, I'll have an IDE that talks to the core DLL and gives me the basis of what this project is all about - a fancy development environment in which I can configure 6502-based systems as I desire (using either pre-canned 'maps' like the VIC-20 one I have now, or creating all-new maps for sample 'machines' that don't exist in reality) and write code for them, and that has all the bells and whistles I want such as in-place instruction timing as you write the code. And the main reason for repackaging the code as a DLL instead of just embedding the classes in the host application is so that other environments (e.g. emulators) can plug it in if they wish...
For a chuckle, I ran a 'release' build version outside the Visual Studio environment to see what clockspeed I'm getting these days. You might recall I had some early success in optimising the logic and saw speeds around the 40MHz mark. Then things took a bit of a nosedive whilst I was doing some major reworking, and those speeds tumbled to around 50% of their best - no better than 18-20MHz on average. I've done a lot of work since then, and refactored a fair amount of the Register class logic, to name but one significant change.
Today, on a slightly creaky Dual-Core Pentium box, I see 42MHz. On the altogether sexier Core2Duo rig I do all my development and gaming on, the code yields 72MHz. That'll do. ;)
Now this might sound like a disaster, but it actually means that the emulator is at the stage where it allows the VIC-20 ROM to get as far as the IRQ-dependant stuff. In other words, the ROM is running in a loop waiting for an interrupt to stuff something into the keyboard buffer, and therefore the core did not spit an 'Unable to decode the following opcode byte' message at me, which is what it does when the ROM gives it an unimplemented instruction. So, nothing happened. :)
If I were writing an actual VIC-20 emulator, this is the point at which I'd starting thinking about coding some logic to represent the 6522 VIA chips which generate timed interrupts and suchlike, in order to progress the overall machine. However, I've never intended to write such an application - loyal readers will know that I was only ever using the VIC-20 ROM as a test to get the emulated core off the ground. So with that done, we're fast approaching the point at which I'll be jumping-off into deeper waters, essentially configuring my own ROM to test instructions that have no code written for them yet.
But before I do that, I have a few other tasks to do:
1. Revisit the instruction decode logic to make sure everything is neat, tidy and efficient.
2. Repackage the code as a DLL so I can disconnect it from the commandline monitor.
3. Rework the commandline monitor to use the DLL version of the core.
4. Write a basic (but extensible) GUI replica of the commandline monitor.
Once we get to item 4, I'll have an IDE that talks to the core DLL and gives me the basis of what this project is all about - a fancy development environment in which I can configure 6502-based systems as I desire (using either pre-canned 'maps' like the VIC-20 one I have now, or creating all-new maps for sample 'machines' that don't exist in reality) and write code for them, and that has all the bells and whistles I want such as in-place instruction timing as you write the code. And the main reason for repackaging the code as a DLL instead of just embedding the classes in the host application is so that other environments (e.g. emulators) can plug it in if they wish...
For a chuckle, I ran a 'release' build version outside the Visual Studio environment to see what clockspeed I'm getting these days. You might recall I had some early success in optimising the logic and saw speeds around the 40MHz mark. Then things took a bit of a nosedive whilst I was doing some major reworking, and those speeds tumbled to around 50% of their best - no better than 18-20MHz on average. I've done a lot of work since then, and refactored a fair amount of the Register class logic, to name but one significant change.
Today, on a slightly creaky Dual-Core Pentium box, I see 42MHz. On the altogether sexier Core2Duo rig I do all my development and gaming on, the code yields 72MHz. That'll do. ;)
Posts
2 comments:
That's excellent news :)
I think my emulator is in a somewhat similar state, where it now seems to sit in a loop waiting for something to happen (a disk to be inserted I guess).
Are you not just a little bit tempted to create a Vic-20 with it ? ;)
I am, sorely tempted. But I mustn't let myself get distracted from the main task, the reason why I started this project in the first place. Maybe when I've got the finished article I might come back and see if I can get a 'whole' VIC-20 running, but for now it's not the objective. :)
Post a Comment