Homebrew lolSnes -- SNES emulator for DS

[GamerSince83]

Because there's already a SNES emulator for Windows called that

Damn U Windows!!!!


How bout = SNODS ?

Super Nintendo On DS

 

[the_randomizer]

Lolsnes is going to stay, the author wants to keep it like that

 

[user64]

Lightweight On Lap Super Nintendo Entertainment System?

 

[VMM]

LOLSNES is a great name.

Dude, why have you quoted a post so old?
This discussion is over, the name is already set, it's not going to change.
I think lolsnes is a terrible name and extremely unoriginal, but that's my opinion,
just as your's that it's a good name, discussing it won't go anywhere.

 

[Ulieq]

extremely unoriginal

It's original, and it should be LOL because even if it were to ever run at 100%, it'll never be able to show all the snes game pixels, thus it's LOL Graphics.

 

[the_randomizer]

It's original, and it should be LOL because even if it were to ever run at 100%, it'll never be able to show all the snes game pixels, thus it's LOL Graphics.

Also keep in mind that given the DS' power, the fact it's as good as it is thus far is pretty amazing

 

[GamerSince83]

A Rose by any other Name is still SNES FTW!!!


Keep up the good Work

 

[Arisotura]

Long time no news.

I'm busy with real life. It's getting a bitch, projects everywhere, blarg.

Then there are also other non-RL projects, like Blargboard or MKDS revival. I'd like to get those somewhere too.


About lolSnes, what is there to say? It's reaching a point where improving it will become tricky.

Weird issues happen in some games. Like, in Super Metroid, layers don't scroll properly. Those are likely annoying sync issues. At this point, given the amount of things the PPU does at each HBlank and VBlank, it sometimes desyncs if emulation is slow enough. And there's not much I can do against that. Aside from adding more code against those cases, which in turn slows it down and makes desyncs more likely.

SMW runs well, as well as a few other games I tested, but the compatibility list is discouraging. I figure it'd need an update, though, as the games were all tested with an old revision. Since then, the IRQ related fixes probably helped in many games.

And then there's the performance issues. SMW suffers from slowdowns when many enemies are onscreen. And that's not all: DKC periodically suffers from major slowdown. I don't get what's happening, the game runs at fullspeed on SNemulDS. At this point I'd need a proper profiler to understand what's taking so much time. I hope it's not the ROM cache fucking up, I thought I had finally gotten that thing right.

The audio side suffers from slowdown too. Yes, it produces better sound than SNemulDS. But it's more prone to slowdowns.

At this point, given both CPU cores are written in ASM and fairly well optimized, I don't know what else I could do. I could rework the CPU cores to use the ARM's status flags instead of emulating them, but I don't know what the benefit of that would be. ALU operations would benefit from it for sure, but the rest would need to save and restore the CPSR. Not to mention that some instructions don't update all the flags, and on the other hand it seems that ARM instructions either update all the flags or don't update them at all. Doing it properly would basically end up as: read CPSR, OR/AND it with immediate values, write it back.


So basically, I don't quite know where to go.

 

[the_randomizer]

I wish there was something I could do to contribute to the project

 

[Shicky256]

Honestly, I think the best route would be to make special optimized emulators for several popular games, e.g. Super Mario World, All-Stars, Super Metroid, etc. You wouldn't have to worry about graphics modes- just pick whatever mode would be required for that specific game. This would make the code not overbearing, and thus you wouldn't have to worry about compatibility.

 

[ipwndeveloper]

Honestly, I think the best route would be to make special optimized emulators for several popular games, e.g. Super Mario World, All-Stars, Super Metroid, etc. You wouldn't have to worry about graphics modes- just pick whatever mode would be required for that specific game. This would make the code not overbearing, and thus you wouldn't have to worry about compatibility.

The best idea, that would be almost a pain to implement:
Autodetect ROM via MD5, based on this have a generic loader for unrecognized games, and specialized loaders for more complex/specialized games similar to gbaemu4ds, except for automated via argv and md5.

also if I recall correctly, you can save some resources by completely shutting off the bottom screen re-allocating the resources to the top. It would not be much, but look at how many things have been done with 4mb Ram and 66mhz processor.

 

[Arisotura]

I had similar ideas. Making separate emulators for popular games. Hell, one could even use static recompilation to achieve fullspeed. I don't think it's possible to fully ditch the interpreters though, as there are cases of self-modifying code. Handling that would require very clever and complex algorithms.

One would then build a NDS ROM out of the emulator template and a SNES ROM, pretty much like with SnezziDS. The emulator template could then be configured with stuff like PPU settings, to better match the game.

Another issue static recompilation would raise is timing. Some SNES games rely on precise timings to work properly.


As for reusing the bottom screen's resources, it'd only be useful for saving power and postprocessing the SNES video output. The bottom screen only uses VRAM bank H, and that bank can't be mapped to the top screen.

Oh and postprocessing isn't even possible. It requires using two of the VRAM banks A, B, C and D. Banks A, B and D are used by the PPU, and bank C is used by the SPC700 (the thing just can't fit in the original 96KB, considering it needs a whole 64KB to emulate the SPC700 RAM).

 

[ILuvGames]

The Snes was slow, anyway. I thought it used an extended version of the 8-bit 6502 used in the NES because Nintendo wanted backwards compatibility.

 

[gego51]

I had similar ideas. Making separate emulators for popular games. Hell, one could even use static recompilation to achieve fullspeed. I don't think it's possible to fully ditch the interpreters though, as there are cases of self-modifying code. Handling that would require very clever and complex algorithms.

One would then build a NDS ROM out of the emulator template and a SNES ROM, pretty much like with SnezziDS. The emulator template could then be configured with stuff like PPU settings, to better match the game.

Another issue static recompilation would raise is timing. Some SNES games rely on precise timings to work properly.


As for reusing the bottom screen's resources, it'd only be useful for saving power and postprocessing the SNES video output. The bottom screen only uses VRAM bank H, and that bank can't be mapped to the top screen.

Oh and postprocessing isn't even possible. It requires using two of the VRAM banks A, B, C and D. Banks A, B and D are used by the PPU, and bank C is used by the SPC700 (the thing just can't fit in the original 96KB, considering it needs a whole 64KB to emulate the SPC700 RAM).

with the 3ds, it's possible to use 3ds or dsi hardware on ds mode?

 

[Shicky256]

with the 3ds, it's possible to use 3ds or dsi hardware on ds mode?

No.

 

[Sora de Eclaune]

Honestly, I think the best route would be to make special optimized emulators for several popular games, e.g. Super Mario World, All-Stars, Super Metroid, etc. You wouldn't have to worry about graphics modes- just pick whatever mode would be required for that specific game. This would make the code not overbearing, and thus you wouldn't have to worry about compatibility.

This would be amazing to have. It could basically mean each game gets the best experience.

For similar-engine games, there could even be just one emulator for all of them. For example, every volume of Picross NP is identical except for the puzzles.

 

[Vague Rant]

Just wanted to note that Pocky & Rocky has become playable since the previous report (I'm using the 2014/01/01 build). The story cutscenes between stages will not display (push Start to skip them), but gameplay is largely unaffected; occasional layer problems and some flickering/slowdown when the game is busy, but seems entirely playable so far. Overall I'd say it performs better than in SNEmulDS, where the story sequences do work, but there's graphical issues that make the game difficult to play.

Donkey Kong Country also seems to be working, with some background glitching and overall quite slow.

EDIT: Another handful of games on the "largely working" pile.

Nichibutsu Arcade Classics (arcade compilation of Moon Cresta, Crazy Climber and Frisky Tom) is 2/3 working, with only Frisky Tom unplayable, throwing a Guru Meditation Error. Frisky Tom sucks, so too bad. The games run slow, but otherwise performs the same as SNEmulDS--Frisky Tom won't run on SNEmulDS, either.

Nichibutsu Arcade Classics 2 (which is only one game, Heiankyo Alien, so the title is weird) also seems to work perfectly aside from running slow. SNEmulDS can also run this one, and full speed, but it's a start.

Tetris & Dr. Mario half works. You can play the hell out of Tetris. It's a bit hard because the bottom of the well is slightly off-screen, but that's not an emulation issue. Seems to be full speed. (Both games work in SNEmulDS.)

But saving the best for last: the absolute classic Soul Blazer appears to be very much playable in lolSnes. The game runs at full speed and seems perfect in terms of gameplay. The sound is kind of crunchy/static-y and sometimes messes up entirely. Besides that, lolSnes's lack of transparency support means the clouds are fully opaque. The latter probably continues to be an issue throughout; from memory, the final dungeon has a transparent effect over it too. That said, it's Soul Blazer on the DS! For what it's worth, SNEmulDS is useless here, displaying only a black screen.

 

[Arisotura]

Sounds cool! The compatibility list definitely needs an update.


Speaking of lolSnes, well. Dunno where that is going. I have ideas to improve the PPU emulation and the overall speed, that I'd like to try out.

But at this point, is it worth continuing? 3DS homebrew is beginning to surface, and if that gets easily accessible, you'll get good SNES emulators there. No speed issues, no inaccurate graphics, no 'how to fit the 256x224 SNES screen into the 256x192 DS screen', no more of all those problems.

On the other hand, it's too early to tell how 3DS homebrew will be going. Chances are it'll be like the DS, requiring you to get a linker likened with piracy. Chances are it'll be like the Wii, easily softmoddable. But chances are also that it'll be like the DSi, ie unhackable unless you have the right firmware version or the right game. (although the DSi mostly remained in that status due to lack of interest)


Oh well. I figure there is a reason to continue lolSnes until 3DS homebrew becomes widely available. But then, as I said, things get tricky.

 

[_47iscool]

How about a plugin system? You know, sort of like gbaemu4ds. Only load the needed functions or whatever for games that need them instead everything at once.

 

[Ulieq]

Just drop the project. DS doesn't have the resolution to display the game correctly, so there's no reason to try. 3ds and phones are here. I rather someone work on a gba emulator for the ds.