Re: Tempting new feature

[Michael J. Mahon <mjmahon@aol.com>]

BLuRry <brendan.robert@gmail.com> wrote:
> 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.
> 
> ... 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...

Properly implemented, a dense switch statement should be an indexed branch
through a table of pointers. 

-michael - NadaNet 3.1 and AppleCrate II: http://home.comcast.net/~mjmahon