Re: [Tuxnes-devel] CPU core graft

[Jim U. <ji...@3e...>]

At 08:36am on 2001 February 27, Mike Melanson did write:
> On Tue, 27 Feb 2001, Jim Ursetto wrote:
 
> 	So is the plan to be able to include a portable 6502 core in the
> TuxNES program? That would be my plan anyway, and nes6502 sounds like a
> good candidate core.

Well, my plan was to port the thing to the dreamcast; the portable
core was a nice side-effect.  But it would definitely be useful to
have one in the mainline distribution, as long as it can be done
cleanly.

I do not think the dynamic recompiler can be made to conform to a
generic interface---the program flow is completely different, E.g.,
the recompiler effectively reimplements inline a Write6502() function
for -each- store instruction, while a portable core just calls a
generic Write6502() function for stores.  Also, the assembly code
always keeps some values in registers (cycle count in particular, in
%esi), so you'd have to futz around with pushing these registers on
the stack before you call C functions that need them.  I've done
this, but it isn't pretty, and it'd be easier to just add some
glue functions so that other cores can be hooked in, and leave
the recompiler be.

By the way, there's no visible speed difference between running the
assembly and C cores on my Celeron/366, at least when rendering is
turned on.  With the None renderer and speed NOT capped at 60fps,
an fps display should show the actual difference.  I'll probably try
that out soon.

> > I'll make the new code available on my web page in the
> > not-too-distant future
 
> 	Take your time; as I mentioned in my last message, I was hoping to
> 	do the portable CPU thing in the next version. How is it coming?
> 	Have you actually gotten it up and running on the Dreamcast yet?
Yesterday was the first time I tried to compile it for the dreamcast
(I wrote pretty much all the necessary code first).  I got it to the
point where emulation starts and runs correctly for a couple frames
before locking up.  The lockup point, and certain values such as
sprite0hit (!!), change when I insert innocuous code like "fprintf"
or "for(x=0;x<5;x++);".   So I suspect a very nasty uninitialized
memory pointer somewhere.  But it's on the verge of working...

-- 
"But if food is so good for you, how come the body
keeps trying to get rid of it?" -- breatharian.com
ji...@3e... / 0x43340710 / 517B C658 D2CB 260D 3E1F  5ED1 6DB3 FBB9 4334 0710