Re: Tempting new feature

[BLuRry <brendan.robert@gmail.com>]

On Friday, October 19, 2012 9:33:22 AM UTC-5, Steve Nickolas wrote:
> On Fri, 19 Oct 2012, BLuRry wrote:
> 
> 
> 
> > One of the ideas I've had on the back-burner was to build a mega-trace 
> 
> > utility into an emulator.  It would be nice to know where data comes 
> 
> > from, be it an I/O port (key-in), disk I/O (tied to disk image, track 
> 
> > and sector) or some combination of algorithm (immediate number, 
> 
> > manipulation by math opcodes, etc).
> 
> >
> 
> > I wonder though, is it a solution in search of a problem, or would you 
> 
> > folks find it immediately useful?
> 
> 
> 
> Some of it might help me try to see if I can't pack Donkey Kong.
> 
> 
> 
> -uso.

The overall design will require some more high-level abstraction for this task.  In order to trap the flow of information, it will require hooking into the CPU level.  Though I have a well-structured way of trapping memory reads/writes, I don't have any way for emulator add-ons to trap the behavior of the CPU.

I've never been too happy with the messy structure of my CPU emulation.  It's really huge and though it is pretty efficient I'd love to do it over -- especially now that I have unit test to ensure I didn't screw it up.  

I recently saw a CPU emulation (for NES) made by Bisqwit --> http://bisqwit.iki.fi/jutut/kuvat/programming_examples/nesemu1/nesemu1.cc which is extremely compact and efficient.  More importantly, it decodes opcodes in a more matrix-like fashion so it is probably a lot closer to the way that a 6502 works at a low-level IMHO.  I do have one advantage in my current codebase though: There is no switch statement for the CPU.  The decode is array-based and each element in the opcode lookup table maps to an object that implements its own execute operations.  This sounds heavy, but in reality it means that at some low level it's only a couple of pointers accessed to run an opcode -- and the hotspot compiler seems to churn out something very efficient from it.

I might just break out the more common CPU features like stack manipulation and interrupt/break handling into a base 65xx class and then allow for the decode/execute part to be implemented in a 65c02 subclass.  This would also allow for less duplicate code if I wanted to implement a 6502 with "illegal" opcodes.  Also, I would need to come up with a smart way to track load/store of processor registers without slowing everything to a crawl.

It's all do-able.  But I'll need time to think it over so I don't churn out something horribly slow and unusable.

-B