Well, this morning I finished giving the emulator enough instruction implementations that it can burn through sufficient VIC-20 ROM until the IRQ stuff takes over. In other words, it's getting to the point in the Kernal that it sits in a spinloop waiting for an IRQ to fire - although, of course, I need to go back to the test harness now to make that happen.
What it lets me do, however, is make proper use of the metrics counting code that's been steadfastly reporting 0MHz whilst I've been in debug mode. The counter ticks up every time an instruction is decoded (this will shortly be extended to count the actual number of cycles the instruction takes) and every 100ms a timer fires, stashes the count in a 10-entry LIFO array, and resets it. At the end of the run, the ten entries are averaged and divided by a million to give me the number of cycles per second the core is executing.
At the end of last week, I was getting about 2.4MHz out of the core as it was at the time. This was pretty good, but I knew it was too slow for what I want to do - the current instruction decode logic is just a clunky series of CASEs, but this isn't the final version. Something else will happen here, but it'll need an estimated 4MHz emulation speed in the current guise to give me enough overhead to run the core at a true 1MHz. Anyway, I ran the core at full speed today, with all the debugging code disabled, and having done all those Byte/Int/cast/DEEK adjustment tasks, it now runs at:
What it lets me do, however, is make proper use of the metrics counting code that's been steadfastly reporting 0MHz whilst I've been in debug mode. The counter ticks up every time an instruction is decoded (this will shortly be extended to count the actual number of cycles the instruction takes) and every 100ms a timer fires, stashes the count in a 10-entry LIFO array, and resets it. At the end of the run, the ten entries are averaged and divided by a million to give me the number of cycles per second the core is executing.
At the end of last week, I was getting about 2.4MHz out of the core as it was at the time. This was pretty good, but I knew it was too slow for what I want to do - the current instruction decode logic is just a clunky series of CASEs, but this isn't the final version. Something else will happen here, but it'll need an estimated 4MHz emulation speed in the current guise to give me enough overhead to run the core at a true 1MHz. Anyway, I ran the core at full speed today, with all the debugging code disabled, and having done all those Byte/Int/cast/DEEK adjustment tasks, it now runs at:
!! 7MHz !!
I believe the appropriate term is 'woot', or somesuch. Anyway, this proves the pain of reworking the code this week was well worth it. And for those with an interest, here's a tiny weeny snippet of code showing what a typical instruction looked like both before and after that rework...
Before:
case 145: // STA Indirect Indexed,YAfter:
address = (ushort)((data.memory.Peek(ops[0] + 1) * 256)
+ data.memory.Peek(ops[0]));
data.memory.Poke(address + data.Y.Contents,
data.A.Contents);
break;
case 145: // STA Indirect Indexed,Y
data.memory.Poke(data.memory.Deek(
data.memory.Peek(data.PC.Contents + 1))
+ data.Y.Contents, data.A.Contents);
break;
I will be publishing the entire sourcecode when it's done, but at the moment it's full of the usual scaffolding any ongoing project has - bits of debugging logic, miscellaneous one-shot variables, odd naming conventions, etc. I'll also let FXCop have at it at some point as well, just to catch anything I miss.

1 comments:
I do belive 'woot' is indeed the appropriate word. Well done.
Post a Comment