Homebrew Potential for a .SMC to .NDS conversion?

Phanalax · Jun 19, 2014

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.

Foxi4 · Jun 19, 2014

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.

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.

Phanalax · Jun 19, 2014

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?

Normmatt · Jun 19, 2014

Foxi4 said:
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.

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.

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.

Phanalax said:
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?

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.

Foxi4 · Jun 19, 2014

Normmatt said:
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.

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.

Normmatt said:
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.

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.

Phanalax · Jun 19, 2014

Alright then, this is mostly what information I was looking for, I'm going to go research emulation.
thanks very much

Normmatt · Jun 19, 2014

Foxi4 said:
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.

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 · Jun 19, 2014

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.

DanTheManMS · Jun 19, 2014

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.

cdoty · Jun 19, 2014

Phanalax said:
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.

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.

Phanalax · Jun 19, 2014

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.

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?

cdoty · Jun 19, 2014

DanTheManMS said:
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.

Is the $42 opcode recognized by the emulator as a signal that the SNES rom is waiting on the vblank?

DanTheManMS · Jun 19, 2014

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.

cdoty · Jun 19, 2014

Phanalax said:
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?

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.

FAST6191 · Jun 19, 2014

Foxi4 said:
That, and the SNES and the DS are running on completely different hardware that's nothing alike

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.

cracker · Jun 19, 2014

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.

Homebrew Potential for a .SMC to .NDS conversion?

Member

Endless Trash

Member

Former AKAIO Programmer

Endless Trash

Member

Former AKAIO Programmer

aka Ricochet Otter

aka Ricochet Otter

Well-Known Member

Member

Well-Known Member

aka Ricochet Otter

Well-Known Member

Techromancer

Nyah!

Similar threads

Popular threads in this forum