NASM -> C

[MostAwesomeDude]

As an active member of X.org, I must respectfully disagree strongly. :3

Seems we're talking about different things. I mean the driver Snes9X would use to talk to the OpenGL API. Not the driver the video card / kernel would use to implement the OpenGL API.

Since you're working on an emulator, you're obviously working with the former, which is indeed a two hour task. As evidenced by the seven I've written so far.

Agreed. OGL is pretty simple if you're just drawing a simple video frame.

[Exophase]

If you want a custom GUI and a somehwat more efficient code base then lots have been done for the various handheld versions of SNES9x. There's also some ARM optimized code in some of them and various hack options for speed. You should check out DrPocketSNES and SquidgeSNES for GP2X.

In fact, one or both of these has already been ported to the upcoming Pandora handheld, which also uses OMAP3530. You might want to ask Squidge and/or Firefox on gp32x.com, they'll probably just give you what they have which should be an easy port with little or no new work being necessary.

[grinvader]

I can't code DOS calls into C for shit

Don't most of the DOS calls have C counterparts, or at least workable substitutes as supported by DJGPP? Or is this an old problem already dealt with?

'Coding DOS calls into C' == 'using DJGPP stuff'

this->skill_level = FOR_SHIT;

If we could just do something about that exec loop.
I'd be fine if we can port it and leave out any GUI bindings (think zsnes -m). We can always add on a new GUI *after* we have a clean exec loop.
We can probably lift a C 5a22 assembly parser from another emulator pretty easily, and just have to bind it to the rest of our nonsense.

The problem lies in the jumps. The flowchart is crazy and you need to keep the regs in the exact status they were before jumping to port faithfully.
I might be skilled enough in state machines nowadays to extract the whole shebang into the most voodooass machine by transforming the various jump points into continues and cases, though. Just hit me I could use a sort of sandbox to encapsulate it all with virtual registers.
...
That won't help make it clean, though.

[Nach]

OpenGL seems like a small issue. Writing a video driver would be a two hour project.

As an active member of X.org, I must respectfully disagree strongly. :3

Hahahahaha!!!

Oh that's good. Of course you would think that. Wake me up when X.Org gets their act together and allows sane video drivers.

If we could just do something about that exec loop.
I'd be fine if we can port it and leave out any GUI bindings (think zsnes -m). We can always add on a new GUI *after* we have a clean exec loop.
We can probably lift a C 5a22 assembly parser from another emulator pretty easily, and just have to bind it to the rest of our nonsense.

The problem lies in the jumps. The flowchart is crazy and you need to keep the regs in the exact status they were before jumping to port faithfully.

If I can get a good picture of this flow chart in my head, I might be able to whip something up. Although have we considered trashing it entirely and working everything into a new loop?

I might be skilled enough in state machines nowadays to extract the whole shebang into the most voodooass machine by transforming the various jump points into continues and cases, though. Just hit me I could use a sort of sandbox to encapsulate it all with virtual registers.

Probably, although avoid nested switches like the plague, just when you think it's all working good, you meet Mr. Compiler who decided Case A was really within Switch C.

That won't help make it clean, though.

At this point I'm looking for viable more than clean. Although if I had the picture in my head of what we're doing, I may be able to think up something to manage the complexity.

[grinvader]

If I can get a good picture of this flow chart in my head, I might be able to whip something up.

k, I'll trace it again when I get the time. Shit's furious.

Although have we considered trashing it entirely and working everything into a new loop?

"New core" was kinda the point.

Probably, although avoid nested switches like the plague, just when you think it's all working good, you meet Mr. Compiler who decided Case A was really within Switch C.

Nah, it would all be top level. The plan would be to replace the seemingly uninterrupted asm jump loop (the base exec loop level, which is also the base gui entry point level) into a function that you'd call -from- a loop, closer to sanity and add-new-featurability.

Static virtual regs + a static label to know where to jump to (the switch var), and a jump == setting the label to the right target and return. Or hell, use the return value to set a var outside the func and use that var to relaunch the func.
All that in a while(1) for the transition stage. Would still need to port it at once, but hey, at least it sounds feasible like that.

The exec loop asm 'switches' already use their own jump tables, so I shouldn't have to switch inside the switch.

At this point I'm looking for viable more than clean. Although if I had the picture in my head of what we're doing, I may be able to think up something to manage the complexity.

It's your brain, heh.

[Nach]

I may be able to think up something to manage the complexity.

It's your brain, heh.

Well yeah, I can manage complexity to a greater degree than most people. But once I work it out in my head, I need to simplify that into a code structure which makes it as easy as possible to come back to it later without all the mapping time, and allow someone else to jump in.

Programming isn't about how smart you are, but how well you can simplify it. Don't need to waste brain power later when we can simplify it upfront.