Bonus points for correctly identifying where/who that quote comes from. ;)
To the point - in order to start properly debugging the emulator core, as opposed to just having random 'Console.Writeline' entries in the body of the code, I've created a wrapper around the core object to present an Old Skool command-line interface through which I can drive and direct the execution; in old parlance, a Machine Code Monitor.
It instantiates a MemoryMap object (pre-loaded with the VIC-20 ROMs) and a CPU object, and then waits for me to tell it what to do. Essentially, it's little more than a command parser that makes calls to diagnostic functionality I've already implemented; (m)emory dump, (d)isassemble, (r)egister state, etc. There's also some additional functionality to start and stop CPU execution, go into single-step execution mode, set breakpoints, and a few other bits and pieces. This is enough of a toolset for me to trace exactly what the core is doing as it executes 6502 instructions, and make sure it's behaving.
Screenshot:
I now have fairly fine-grain control over how the core executes, and a reasonable window into it so that I can see what it's thinking as it burns through instructions. Which is nice.
The sharp-eyed amongst you may also spot a tweak I made to the disassembly - it now displays the actual jump address when decoding Branch instructions, which is much nicer to read. There's another little readability tweak I'm planning to add to the disassembly display in the next couple of days - integration of labels. This will take a simple text file of entry point and/or jump labels (such as a ROM disassembly index) and bind that to the disassembly so you'll get label names in the appropriate places as well as addresses.
To the point - in order to start properly debugging the emulator core, as opposed to just having random 'Console.Writeline' entries in the body of the code, I've created a wrapper around the core object to present an Old Skool command-line interface through which I can drive and direct the execution; in old parlance, a Machine Code Monitor.
It instantiates a MemoryMap object (pre-loaded with the VIC-20 ROMs) and a CPU object, and then waits for me to tell it what to do. Essentially, it's little more than a command parser that makes calls to diagnostic functionality I've already implemented; (m)emory dump, (d)isassemble, (r)egister state, etc. There's also some additional functionality to start and stop CPU execution, go into single-step execution mode, set breakpoints, and a few other bits and pieces. This is enough of a toolset for me to trace exactly what the core is doing as it executes 6502 instructions, and make sure it's behaving.
Screenshot:
I now have fairly fine-grain control over how the core executes, and a reasonable window into it so that I can see what it's thinking as it burns through instructions. Which is nice.
The sharp-eyed amongst you may also spot a tweak I made to the disassembly - it now displays the actual jump address when decoding Branch instructions, which is much nicer to read. There's another little readability tweak I'm planning to add to the disassembly display in the next couple of days - integration of labels. This will take a simple text file of entry point and/or jump labels (such as a ROM disassembly index) and bind that to the disassembly so you'll get label names in the appropriate places as well as addresses.
Posts
1 comments:
Looking at the progress you're making, and the control panel, makes me wish someone was doing this for the RM-380Z as well. I have fond memories of using that as a schoolkid.
Great to see you're making progress though.
And I knew it was Spock who said that, but I had to Google to find which film it was.
Post a Comment