Thursday 6 November 2008

Hack n Slash

I'm still plodding on with writing the unit tests.  The end is in sight as I've nearly finished the instructions and I think I should be able to output tests a bit quicker when I haven't got to keep calculating opcodes by hand.

Unfortunately, last week I went an bought a copy of Fable II.  What a time sink that has been, and I would've finished the tests by now if it wasn't for that.  Cracking good game though.

Once the tests are complete the next step is to write a monitor/debugger application to wrap the CPU up in.  I want to be able to step through the emulated code and set breakpoints etc.  This will no doubt involve quite a bit of effort but is going to be crucial in keeping me sane as this project progresses.  Once I'm happy that I can accurately emulate the CPU and monitor the code running on it, I can start thinking about turning it into an Amiga.

Of course, I'm making a big assumption that the performance of my code is going to be adequate for the job, but that's a whole new kettle of fish that we'll have to wait for.  I'm just concentrating on developing a clean and robust model for now.

2 comments:

Eight-Bit Guru said...

It's hard work, but worth it, to write the monitor wrapper. Now the big question is, how will you implement breakpoint-checking? A test on every increment of the Program Counter? But that'll add a small performance impact on the core execution speed...

Add the capability for multiple breakpoints being set, and the problem just gets worse. You simply can't run the core at full speed with any kind of interruption to program flow to check if you've hit a breakpoint.

I have a solution for my 6502 core, but it relies on the code being carefully encapsulated. ;)

t0ne said...

Good point. I was thinking of running it just as you mention actually, allowing the CPU to execute an instruction and then looking at what else needs to happen before executing the next and so on.
Eventually I've got to limit it to running at 7Mhz so I need to think about that too.
Hmmmm... maybe I should use TRAPs as a real debugger would.
Or as the CPU instruction lookup table is 64k long but only has about 47.5k entries in it (assuming I've not done something wrong) perhaps I could do something cunning and create some extra instructions to communicate with the CPU.
You've got me thinking now thanks :)