NASM -> C

[MostAwesomeDude]

How much self-hatred are we talking about? My university wants to ship zsnes on an embedded handheld but we all hate snes9x with fiery passion and would rather rewrite 250 klocs than ship it.

Also has anybody experimented with automatic disassembly or using advanced SSA tools like LLVM to automate the process?

~ C.

[DOLLS (J) [!]]

Zaphod?

[MostAwesomeDude]

OSWALD, actually. And actually, the more of this code I read, the more amazed I am that it's been maintained this long. Kudos to people willing to program in assembly. :3

[grinvader]

Smart assembly's awesome.

For your information, an automated translation would probably produce:
- wildly oversized unoptimized C equivalents
- misaligned allocated memory blocks, breaking the various out-of-bounds stuff we still haven't got rid of
- skynet

[MostAwesomeDude]

Hm. A manual translation would hopefully produce:

- Cyclopean, eldritch C
- Scads upon scads of unoptimized algorithms
- Skynet

Let's face it, Skynet is always going to happen.

In all seriousness, I know that it's not possible to translate a hundred thousand lines of assembly in one week (when the first OSWALD run will be given to students,) but if we had, say, three or four experienced C/assembly coders, and about six weeks, I think it would be possible.

[Nach]

but if we had, say, three or four experienced C/assembly coders, and about six weeks, I think it would be possible.

We've had 4 master C/Assembly coders and ~6 years and we translated ~30% of it.

[MostAwesomeDude]

We've had 4 master C/Assembly coders and ~6 years and we translated ~30% of it.

Well, I know that it may be a stupid question, and I'm not asking it sarcastically, but what do you suggest we do, then?

[Nach]

We've had 4 master C/Assembly coders and ~6 years and we translated ~30% of it.

Well, I know that it may be a stupid question, and I'm not asking it sarcastically, but what do you suggest we do, then?

Your best bet at this point is to use an x86 emulator.

[MostAwesomeDude]

Your best bet at this point is to use an x86 emulator.

With all due respect, I think we'd have to ship snes9x if that's the alternative. :C

[badinsults]

Your best bet at this point is to use an x86 emulator.

With all due respect, I think we'd have to ship snes9x if that's the alternative. :C

Yep, that is probably what you will have to do.

[Exophase]

Am I the only one who finds it strange that your university wants to ship a handheld with an emulator?

This has been brought up a few times in the past on gp32x, with regard to getting a higher performance SNES emulator on the GP2X. Since you're working with a much faster platform you probably aren't as concerned about keeping performance tight. The big difference is that their talk was of converting to ARM code, not C code. But that'd still work for OSWALD. x86 to ARM isn't an especially snug fit, but it'd probably be much better code than x86 to C to ARM, contrary to what you might expect the compiler to be capable of accomplishing.

If you ARE interested in this approach then you might want to talk to MHT on the aforementioned forums. He has done some more automated than not conversions of old closed source DOS games to GP2X. Being able to work with assembly code should give you a leg up over machine code, especially when it comes to the manual part of this.

And lucky you, Cortex-A8 supports unaligned memory accesses. Because otherwise those would have made life a lot more difficult for you (and I would expect ZSNES uses them, although maybe just in a few easy to identify places in its renderer)

[Nach]

Your best bet at this point is to use an x86 emulator.

With all due respect, I think we'd have to ship snes9x if that's the alternative. :C

What's wrong with that?

You should have also used the "all due respect" when you said you hate Snes9x, some of us worked pretty hard on it.

Am I the only one who finds it strange that your university wants to ship a handheld with an emulator?

I thought it was strange too.

[MostAwesomeDude]

This device is completely designed by students, and the university made the noble mistake of appointing me as the person that actually makes sure that all the software on there works. We're already shipping prdoom, so it's not like there's a moratorium on games, and people apparently want SNES emulators.

As for snes9x, it's a decent piece of software, but several students, including myself, just don't like it. I meant no insult; it's like if you told me that you prefer nVidia to ATI.

[byuu]

As for snes9x, it's a decent piece of software, but several students, including myself, just don't like it. I meant no insult; it's like if you told me that you prefer nVidia to ATI.

Which parts don't you like? When you omit the user interface (as you would for a handheld), which parts do you find superior in ZSNES?

Not asking as though saying ZSNES is inferior, I'm just generally curious what you're noticing that's different between the two. They both have compatibility rates well above 98%, and both have manually tuned the best of the best games to run correctly.

I imagine you're going to say "the sound" ... are you aware that both use a modified version of OpenSPC, and are very similar?

[MostAwesomeDude]

For me, personally, the OGL thing is kind of important, as is the configurability aspect and GUI. I know that those are all much less important on a handheld, though, although this particular handheld can be hooked up to external screens so it's something to consider.

My original thought when asking here was, "I know zsnes isn't available on ARM. Is it because the developers don't feel like porting it to C, or is there too much assembly for it to be a trivial task? Has anybody done it before? Maybe patches have been rejected on trivialities? Licensing issues? It seems weird that such a popular emulator would still be predominantly coded in assembly..." And now I'm getting answers to those questions, which helps me decide whether it's worth pursuing.

Just doing research, I suppose.

(And yes, sound used to be an issue, but not anymore!)

[badinsults]

Zsnes was original coded in Assembly, as it was designed for late 1990s computers. When computers became faster, the requirement of having low level control for speed decreased, so C was added in. However, Zsnes is still 67.2004% percent Assembly (according to the IRC topic), so it is not a trivial task to simply say "well, why don't you just port it?". Porting is happening, but you can't just expect miracles.

Use Snes9x, it has pretty much the same compatibility as Zsnes, and has been ported to almost any computer architecture known.

[funkyass]

This is exactly what snes9x was made to do...

[MostAwesomeDude]

Zsnes was original coded in Assembly, as it was designed for late 1990s computers. When computers became faster, the requirement of having low level control for speed decreased, so C was added in. However, Zsnes is still 67.2004% percent Assembly (according to the IRC topic), so it is not a trivial task to simply say "well, why don't you just port it?". Porting is happening, but you can't just expect miracles.

I didn't ask anybody to do any porting on our behalf. I'm just trying to get information. Contrary to my appearance, I'm not a novice.

[badinsults]

Zsnes was original coded in Assembly, as it was designed for late 1990s computers. When computers became faster, the requirement of having low level control for speed decreased, so C was added in. However, Zsnes is still 67.2004% percent Assembly (according to the IRC topic), so it is not a trivial task to simply say "well, why don't you just port it?". Porting is happening, but you can't just expect miracles.

I didn't ask anybody to do any porting on our behalf. I'm just trying to get information. Contrary to my appearance, I'm not a novice.

If that was true, then you wouldn't be asking about putting Zsnes on a non x86 computer.

[byuu]

For me, personally, the OGL thing is kind of important, as is the configurability aspect and GUI.

OpenGL seems like a small issue. Writing a video driver would be a two hour project. But the GUI is definitely an issue if you want a UI on your handheld. Still, I find writing a custom GUI for Snes9X to be much less daunting than porting ~67% of ZSNES to another processor.

And if you get stuck; you could ask zones, BearOso or nitsuja how they did it.

[grinvader]

but if we had, say, three or four experienced C/assembly coders, and about six weeks, I think it would be possible.

We've had 4 master C/Assembly coders and ~6 years and we translated ~30% of it.

In all seriousness, we ported all that in a relatively small proportion of those years, like a month for the state/rewind stuff and a season for the zfile mess. Half a year tops.
I bumped against various montrous blobs currently, making it hard to proceed:

- from the start point and following, I quickly jammed my face against the execloop jumping around (i.e. not calling) like crazy issue. The amount of code to port inflates suddenly to a dozen critical sourcefiles. Pretty much impossible to make transition points to test on the fly as well.
- I can't code DOS calls into C for shit, so I couldn't do anything about the zGUIv2. After we cleaned it out, the intertwining GUI/execloop parts still made it impossible to do one without the other.

[Nach]

but if we had, say, three or four experienced C/assembly coders, and about six weeks, I think it would be possible.

We've had 4 master C/Assembly coders and ~6 years and we translated ~30% of it.

In all seriousness, we ported all that in a relatively small proportion of those years, like a month for the state/rewind stuff and a season for the zfile mess. Half a year tops.

We've ported a lot more than just that. We spent like a week porting the memory map setup. Another month or two on various start up routines. A week porting the image save code. A month porting movies (although truth be told a lot of that time was adding on features). Three months porting the config file (although we basically just let that one drift until Deathlike joined and just moved over everything we were too lazy to). A month or two on the debugger. A week on each of the pack loading to whatever decompression bindings. And then we actively spent like two to three months on porting the sound backend, and we're still not done with that one.


As for the amount of time we spent porting being relatively small. When we were actively working on ZSNES, for the amount of people we had, we were pumping out way more code than other open source projects. I've never met a team that moved as quick as we do when we're busy.

Parsegen in a single day?
Cleaning up half a dozen chip bindings in three days?
New manual file loader with complete multi OS backends, and data structures we're writing ourselves - binding into a custom assembly GUI in two weeks?
3000 lines of annoying logic in two days?

Look back at what we did, you think just any other team of 3-4 programmers could do what we did as quick as we did it? As a hobby only?

Even if we only spent an actual 6 months of time on porting, you know some random team at a college would've needed much longer.

- from the start point and following, I quickly jammed my face against the execloop jumping around (i.e. not calling) like crazy issue. The amount of code to port inflates suddenly to a dozen critical sourcefiles. Pretty much impossible to make transition points to test on the fly as well.
- I can't code DOS calls into C for shit, so I couldn't do anything about the zGUIv2. After we cleaned it out, the intertwining GUI/execloop parts still made it impossible to do one without the other.

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.

[kode54]

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?

[MostAwesomeDude]

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

This all of a sudden sounds very much like a problem of modularity. It's not just as simple as wrapping all of the assembly in C asm inlines and then slowly translating; it sounds and looks like there are serious structural obstructions in the way of making this happen.

I take it that the exec loop is just your sequence of "check for events, set some flags, do lots of maths, run some emulation, update screen, sleep?" If so, I can see how it would be a fair pain to translate that without a serious detangling first.

/me should dig more deeply into the code

Look back at what we did, you think just any other team of 3-4 programmers could do what we did as quick as we did it? As a hobby only?

Never underestimate the coding ability of a bored person. :3

Also don't say something's impossible; I've seen the impossible happen on a regular basis.

[byuu]

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.