Potential for a .SMC to .NDS conversion?

Discussion in 'NDS - Emulation and Homebrew' started by Phanalax, Jun 19, 2014.

  1. Phanalax
    OP

    Phanalax Newbie

    Newcomer
    8
    1
    Jun 19, 2014
    United States
    If I were to parse the binary coding of a .smc and replace them with ds equivalents would it be possible to create a file that would run natively on the NDS architecture? I'm unsure how the stack functions in either the NDS or the SNES, however I'm certain there is a way to convert between them in that sense. What I
    worries me is the fact the SNES has certain functions handled by multiple different chips (ex: sound, backgrounds) I feel that an equivalent could be found for even those types of functions on NDS architecture. I know that this is possible to do in c++ If I convert the bit information into chars, which would make editing them extremely easy but would also blow up file size about 8x. As most SNES games are only a few Mb in size that's not really a problem though. Also I am aware that there are snes emulators for the ds, I want to do it the hard way anyways.
    Theoretically the only information I would need is all the binary commands the SNES can differentiate, and All the binary commmands the DS can Differentiate.
     
  2. Foxi4

    Foxi4 On the hunt...

    pip Reporter
    23,528
    21,456
    Sep 13, 2009
    Poland
    Gaming Grotto
    This is downright impossible without a given game's source code, an already compiled binary is just that - compiled for the platform. Theoretically you could attempt disassembling it, but the process is hit-and-miss. That, and the SNES and the DS are running on completely different hardware that's nothing alike, so even if you somehow managed to disassemble a binary with 100% accuracy, you'd still have to find 100% equivalent functions on both pieces of hardware... which you won't. :P

    Your best bet for running .smc binaries on anything that's not a SNES is emulation, sorry to burst your bubble. Seeing that the DS is not exactly a powerhouse, you might want to pick up a DSTwo for that, but even then the screen will either be resized or cropped since the DS's resolution is smaller than that of the SNES. Frankly, I'd suggest emulating the SNES on something with a bit more juice than the good 'ol DS - a PSP is a very cost-effective machine for emulation, you can get'em used for peanuts.
     
  3. Phanalax
    OP

    Phanalax Newbie

    Newcomer
    8
    1
    Jun 19, 2014
    United States
    I know how to read a file bit by bit in c++, write those bits to chars for easy manipulation. Even If the code is already compiled the functions are still commands written directly into binary that are read by the SNES. If I parse the .smc files I could extract the binary information directly and find equivalents for the basic functions at least, (add,subtract, divide,multiply,move x to y, etc etc) The more complicated functions that don't have a hard code equivalent can most probably be emulated on a low level. The memory structuring of the SNES cant be too complicated, And I know the ds has enough ram to store whatever information would be used in a normal SNES memory. even If I do this it still would not be possible?
     
  4. Normmatt

    Normmatt Former AKAIO Programmer

    Member
    2,142
    544
    Dec 14, 2004
    New Zealand

    It's possible without a source code (disassembly) however it'd be a lot more work.

    The main problem I have with this idea is that the CPU isn't even the main bottleneck for SNES emulation on the NDS its the GPU. The SNES has 2 more gfx layers than the nds which is why theres gfx glitches in most games.




    You clearly don't know how hard it is to write an emulator. You should first go write your own SNES emulator from scratch before even attempting something like this. Then you will be able to grasp the complexity.
     
    DanTheManMS and Foxi4 like this.
  5. Foxi4

    Foxi4 On the hunt...

    pip Reporter
    23,528
    21,456
    Sep 13, 2009
    Poland
    Gaming Grotto
    There's that, and even if the game in question wouldn't use SNES-specific layers or modes, the graphics are still made for a 256/512x224/239/448/478 resolutions wheras the DS only offers 256x192, there's no chance that they would be displayed as intended without resizing or cropping, which sort of defeats the purpose of such a port. Sounds like a whole lot of work for very little return.
    He could always have a look at some open source solutions to see how much work is involved, but why re-invent the wheel when there are ready-made emulators that are already quite efficient considering what little resources the developers have to work with.
     
  6. Phanalax
    OP

    Phanalax Newbie

    Newcomer
    8
    1
    Jun 19, 2014
    United States
    Alright then, this is mostly what information I was looking for, I'm going to go research emulation.
    thanks very much
     
    DanTheManMS likes this.
  7. Normmatt

    Normmatt Former AKAIO Programmer

    Member
    2,142
    544
    Dec 14, 2004
    New Zealand
    Making your own emulator is a good learning experience and reinforces your knowledge of a particular system. The NDS can resize those bg's in hardware so its not like that'd slow anything down.
     
    DanTheManMS likes this.
  8. DanTheManMS

    DanTheManMS aka Ricochet Otter

    Member
    4,330
    106
    Jun 2, 2007
    United States
    Georgia
    As others have said, a compiled binary is, well, a compiled binary. There's no real way to just "convert" a binary file like that to a completely different CPU architecture. SnezziDS takes in a *.smc file and outputs a *.nds file but that's simply the result of attaching the emulator core to the game's ROM file, so that doesn't really count.

    That said, if we look at the big picture of what you want to achieve, you're actually not all that far off from the truth. Every SNES emulator for the DS (other than the dedicated one for the Supercard DS:TWO) works in a similar fashion to what you propose, in a sort of "hardware emulation" mode. While the 2D hardware chips used in the SNES and the DS are not identical, they are similar, so emulators like SNEmulDS (and SNES DS and SnezziDS) attempt to translate SNES graphics commands into DS 2D graphics commands on-the-fly. It's not perfect especially when it comes to layering and transparencies, but it works well enough. That's the only way to get full-speed emulation on the 66-MHz ARM9 that the DS has. It simply doesn't have the horsepower to run a software emulator in the traditional sense, where the picture for every frame is painted to the screen pixel-by-pixel without the use of the dedicated 2D hardware.

    For more examples of "hardware emulation" vs" software emulation" see:
    1. NES DS versus NesterDS+
    2. jEnesisDS v0.4a HW versus jEnesisDS v0.4a SW

    I'll end by saying that Normmatt here knows what the f*** he's talking about. You'd do well to listen to his advice.
     
    VatoLoco and Phanalax like this.
  9. DanTheManMS

    DanTheManMS aka Ricochet Otter

    Member
    4,330
    106
    Jun 2, 2007
    United States
    Georgia
    Back in the days of SNES Advance and Snezziboy, then SnezziDS and SNES DS, everything I learned about SNES Assembly language I learned from trying to speedhack the whole bunch. I even made a video about it.



    (PLEASE MUTE IT AT THE 06:30 MARK). Dang GSM radios causing interference with my speakers.
     
  10. cdoty

    cdoty GBAtemp Fan

    Member
    327
    96
    Sep 14, 2009
    United States

    It would probably be easier to write an emulator... But, there might be a way to pre JIT compile the code from 65816 to Arm. You still need a way to simulate the SNES hardware. The DS is pretty close graphics hardware wise, but accessing the hardware is done completely differently. (For example, VRAM is memory mapped on the DS, but uses one single memory address on the SNES.)
    Sound is another story, but you could probably set up the Arm7 to act like the SPC700.
     
  11. Phanalax
    OP

    Phanalax Newbie

    Newcomer
    8
    1
    Jun 19, 2014
    United States
    That actually clears things up quite a bit. I'm thinking of perhaps trying to emulate the NES in C++ before I try anything with the SNES. Anyways with what you said could a halfway point be made here? As in could you read the data before hand and convert the Snes graphics commands before you start emulation, to maybe reduce overhead a bit?
     
  12. cdoty

    cdoty GBAtemp Fan

    Member
    327
    96
    Sep 14, 2009
    United States
    Is the $42 opcode recognized by the emulator as a signal that the SNES rom is waiting on the vblank?
     
  13. DanTheManMS

    DanTheManMS aka Ricochet Otter

    Member
    4,330
    106
    Jun 2, 2007
    United States
    Georgia
    The $42 opcode is an instruction that is technically available to the CPU used in the Super Nintendo but it was never used. Thus, SNES Advances used $42 for speed hacks.
     
  14. cdoty

    cdoty GBAtemp Fan

    Member
    327
    96
    Sep 14, 2009
    United States

    A SNES game would almost never send the same series of 'graphics commands'. It's going to reposition sprites based on input, or randomly vary their position. Scrolling would also change based on input. None of these graphics commands would be stored in the data.
     
  15. FAST6191

    FAST6191 Techromancer

    pip Reporter
    23,173
    8,910
    Nov 21, 2005
    Technically the palettes are somewhat alike (you can more or less port things between, as was done to fix up brightened palettes in the case of the games nerfed a bit for the original GBA screen), however that is not even being picky and straight into trivia territory.

    Back on topic as it were. I wonder if it is worth heading down the game specific emulator path. Probably pretty pointless in the face of the DSwto and every other device we have now, however it could also be one of those nice learning experiences.
     
  16. cracker

    cracker Nyah!

    Member
    3,142
    409
    Aug 24, 2005
    United States
    I think it would be funny to see a 1:1 translation of 65xx to arm/thumb. It would make you see how much more optimized the arm/thumb instruction set is and also want to make you bang your head over all the unoptimized code that you were producing.