Agreed. OGL is pretty simple if you're just drawing a simple video frame.byuu wrote: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.MostAwesomeDude wrote:As an active member of X.org, I must respectfully disagree strongly. :3
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.
NASM -> C
Moderator: ZSNES Mods
-
- Rookie
- Posts: 10
- Joined: Wed Sep 03, 2008 5:04 am
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.
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.
-
- ZSNES Shake Shake Prinny
- Posts: 5632
- Joined: Wed Jul 28, 2004 4:15 pm
- Location: PAL50, dood !
'Coding DOS calls into C' == 'using DJGPP stuff'kode54 wrote: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?grinvader wrote:I can't code DOS calls into C for shit
this->skill_level = FOR_SHIT;
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.Nach wrote: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.
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.
皆黙って俺について来い!!
Pantheon: Gideon Zhi | CaitSith2 | Nach | kode54
Code: Select all
<jmr> bsnes has the most accurate wiki page but it takes forever to load (or something)
-
- ZSNES Developer
- Posts: 3904
- Joined: Tue Jul 27, 2004 10:54 pm
- Location: Solar powered park bench
- Contact:
Hahahahaha!!!MostAwesomeDude wrote:As an active member of X.org, I must respectfully disagree strongly. :3byuu wrote:OpenGL seems like a small issue. Writing a video driver would be a two hour project.
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 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?grinvader wrote: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.Nach wrote: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.
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.grinvader wrote: 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.
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 wrote: That won't help make it clean, though.
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
_____________
Insane Coding
-
- ZSNES Shake Shake Prinny
- Posts: 5632
- Joined: Wed Jul 28, 2004 4:15 pm
- Location: PAL50, dood !
k, I'll trace it again when I get the time. Shit's furious.Nach wrote:If I can get a good picture of this flow chart in my head, I might be able to whip something up.
"New core" was kinda the point.Although have we considered trashing it entirely and working everything into a new loop?
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.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.
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.
It's your brain, heh.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.
皆黙って俺について来い!!
Pantheon: Gideon Zhi | CaitSith2 | Nach | kode54
Code: Select all
<jmr> bsnes has the most accurate wiki page but it takes forever to load (or something)
-
- ZSNES Developer
- Posts: 3904
- Joined: Tue Jul 27, 2004 10:54 pm
- Location: Solar powered park bench
- Contact:
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.grinvader wrote:It's your brain, heh.I may be able to think up something to manage the complexity.
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.
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
_____________
Insane Coding