Monday, 1 December 2008

Class Action

Whew! HOW long since the last update?? Almost a month, that's how long. And after such an interval, you'll probably be assuming that all sorts of exciting things have happened to the emulator, right?

Wrong. The real world has kind of got in the way of this project over the last three weeks - the first two of which I spent mostly in bed feeling pretty sorry for myself, suffering from a dose of genuine the-one-that-can-kill-you Influenza. Aside from a couple of visits to the doctor for industrial-strength medication, I didn't stir from my bed for most of that fortnight. And then last week, getting back into the routine of the day job left me largely energy-depleted and nowhere near sharp enough to do any work on the codebase.

However, this weekend just past saw me feeling almost back to normal, so I opened-up Visual Studio on Saturday and had a look at where we were. I'm glad my commenting discipline is reasonably consistent, as it still took a good half-an-hour to re-sync my brain to the code and figure out where I'd got to, and what was next on the list of Stuff To Do.

Having optimised the bit-access logic for the registers, I could see that the classes that implement them (the Accumulator, X and Y, PSR, SP and PC) were suffering from a mild dose of chaos and needed a tidy-up. So as a way of easing myself back into harness, I took the existing classes and refactored them so that they were better representations of the objects they instantiate, and got the inheritance hierarchy nicely arranged.

So now, instead of separate specific classes for the 'special' register types (i.e. those with extended functionality above and beyond simple 8-bit register objects, like the PSR) we have a logical structure that implements a 16-bit register (Register16Bit, for PC), a derived 8-bit register (Register8Bit, that ignores the hi-byte from its' 16-bit base class, for A, X, Y and SP), and a further-derived 8-bit register (Register8BitStatus, derived from Register8Bit, for the PSR) that additionally always returns its contents with Bit 5 set to reflect the permanently-on state of that bit in the status register.

Naturally all the content manipulation accessors, bit indexers, etc. are implemented in Register16Bit, so the derived registers get that functionality for free. Register8Bit is an empty shell that just passes content access up to Register16Bit, but masks-off the upper byte. And Register8BitStatus is an even emptier shell, that defers to Register8Bit for everything except during queries on its contents, when it overrides the underlying value by ORing it with $20 to switch bit 5 on.

With everything neat and tidy again, I'm now back to the instruction implementations - and I'm currently grappling with the old foe, those twins of complexity that are the ADC and SBC instructions. I think I've got them working in normal mode now, and the next step is to confirm the Overflow flag behavior (which is horribly, horribly complicated) and then implement the Decimal Mode logic (which I've avoided thus far - it will either be a very simple task, or a nightmare to do efficiently).

Stay tuned!

1 comments:

t0ne said...

Glad to hear you're back on your feet and back in the saddle :)