Search

[Hi]

#1. How come in order to install a costom firmware (like flashme) you have to short the battery contacts but you don't have to short the battery contacts for the DSbricker to work (which erases the fimware)

#2 How come, althought gba flash carts had the ability to mimic real gba cards, nds flash cards can't mimic real nds cards. Well, that's a dumb question, the answer is because no one had made a card that can. But someone has made a nds flash card that can mimic real nds cards (the ultra flash pass) and nobody uses it.

#3 How come we've been having so much trouble with snes emulation on the nds. You'd think it would be pretty easy.

#4 Why is it that although everyone loves the soft-reset feature that you can use for commercial games, nobody attemps to add this feature to homebrew; no one seems to care with the exception of Lick and me.

#5 Why did nintendo cut off gbc and gb support when making the nds. They claim it's because the older games need a special chip, but goomba makes me think their is another reason.

#6 Why does the supercard need extra ram to play gba games while gba flash carts don't?

#7 How come nds homebrew developers always go "0.1, 0.2, 0.3" rather than "1.0, 2.0, possibly 2.5, 3.0." I understand if a develper thinks that there program has to many bugs or to little features to be "1.0" or not enouph updates to go from 1.0 to 2.0, but goint "0.1, 0.2, 0.3" seems to be the standard for nds homebrew. In fact, the only nds programs I've seen at or above version 1 are dsorganise and moonshell.

sorry if my questions were hard to understand.

[Gleasonator]

I would like to know the same things. I hate Nintendo for #5 and #7 drives me crazy. GlovePIE works FINE! But noooooooo... it's version 0.29. Why can't we just go version "A, B, C, D...." then "AA, AB, AC". Or even to just name every version different.

[sinkhead]

I know the answer to 1, it's simple really. The shorting of the SL1 writes to SPECIAL areas that the bricker CAN'T access, that's why FlashMe protects your DS!

- Sam

[ratx]

Heres some quick answers; I'm sure other people will provide more depth if required.

#1 DSbricker only erases the bits of firmware that aren't protected; it still bricks the DS.

#2 GBA carts are very different to DS carts in terms of the way they "present" the game to the console. You don't need to have "full emulation" to get most DS features working so nobody has bothered. The Ultra Flash thing has extremely poor compatability AFAIK.

#3 Why would it be easy? The DS and Snes aren't really alike in terms of architecture.

#4 Personally I've never understood the desperate need to reset to the menu.

#5 Nintendo are telling the truth. GB/GBC used a different processor type which isn't included in the DS.

#6 Most GBA flashcarts were NOR based, whilst the supercard uses NAND and RAM. Read http://wiki.pocketheaven.com/NAND_and_NOR

#7 Who cares

[dantheman]

1.  You must short it to write to a write-protected portion of the firmware.  The rest of FlashMe probably doesn't necessary require you to short it in theory, but I think it does anyway for safety.  The DS Brickers overwrite the portion that the write-protect section DOESN'T protect, which is a considerable amount.  Newer DS Lites protect more, but I'm sure it's still possible to brick it.  When your DS gets bricked, the write-protected portion is still intact.  Since this is where FlashMe stores its emergency recovery code, you can recover your firmware using an alternate button combination at bootup.

2.  GBA flash carts had issues too, though I'm not sure why we're having so many issues with DS ones.  

3.  There are few people who extensively know both the SNES and the DS well enough to write an emulator for it.  In addition, the current ones use the DS's 2D hardware to attempt to speed things up, which creates some issues with grahpics.  SNEmulDS looks very promising though, especially with yesterday's update.  There are some games that will never be playable though because they use extra chips that are faster than the SNES's CPU.  Either way though, coding isn't easy, especially coding an emulator.  Give them some credit for what they've already accomplished.

4.  I like it too, and I too am rather sad that more people don't use Lick's library.  It hasn't been updated for newer carts yet, but it's still useful.

5.  The GB and GBC use a completely different processor.  The GBA and GBA SP contained both the GBA's processor and the GBC's processor to allow for the backwards compatibility.  The DS however took the GBC processor out to save space.  I know that the GBC sound chip still exists, as GBA games used it for basic sounds, but nothing else remains.  

6.  See http://wiki.pocketheaven.com/NAND_and_NOR for a basic explanation on the differences between a Supercard-like device and a regular GBA flash cart and why the Supercard needs the relatively fast RAM to run GBA binaries (fast compared to the CF/SD, not compared to the M3)

7.  No clue, hehe.

[mudlouse1]

#7 - i think this applies for most software.

for me, a new whole number signifies a whole new version rather than bug fixes or something incremental. take internet explorer for instance. not much discernable difference betwen IE 6 and 6.whatever but IE 7 is a whole new bag of tricks.

one exception i did notice is the apple mac os. they call their current operating system "OS X" or "OS 10.4.9". by normal convention it should be OS 14.9 buy they really, really like the "X"

[Perseid]

#5 - I think Sony with their upcoming PSP caused Nintendo to show their hand earlier than they would have liked with the DS. After all, the GBA was selling well back then. I think they cut GBC support to make the DS cheaper to build and to not make the GBA completely obsolete.

[Koji]

I disagree with Perseid, it's obvious nintendo had been planning it's next portable system and even if they did release some information before hand, I highly doubt it caused them to rush the system out. The cut GB/C support because of size and monetary constraints. Nintendo has always wanted to keep the system cheap. The fact that the system kept GBA support does hint at that the DS was probably MEANT to be the next "Gameboy", but once they realized the constraints of having 3 different systems hardware in one device, they rebranded it as a good reason not to have traditional GB/C support.

#3: I used to help with Tech Support for SNES9X... I don't think you have an inkling on just how complex a system the SNES is. Go check out the documentation on SNES9X and ZSNES, specifically the parts on "minimum system requirements". As it is, there is no way the DS has the raw power to emulate the system... As Dan said, what they do is they try to match up SNES functions to their equivalent DS functions to speed things up. This leads to problems though because the SNES and DS are quite different, this is where all the graphic problems come up. The other problem with the method is there is no way it will ever give you 100% compatibility.

A good comparison in the PC world is UltraHLE. It emulated N64 games much faster then any modern emulator. I got Mario 64 and various other games running at full speed on my 400mhz PC with a voodoo2 graphics card. Why? Because it used the same methods SNES emus for DS use. The cost for the high speed was the very low compatibility...

As it is, I think Snezzi and SNEmulDS have really good compatibility for their methods and will probably be the best we'll see in terms of compatibility and speed for the DS.

Could someone do an emulator the other way? Focusing more on compatibility then speed? Of course they could. Take a look at the SNES emulators for Dreamcast. Now imagine those running at about 1/2 to 1/3rd the speed. That's what you'd end up getting. Now a very pretty sight.

[Hi]

#7 - i think this applies for most software.

for me, a new whole number signifies a whole new version rather than bug fixes or something incremental. take internet explorer for instance. not much discernable difference betwen IE 6 and 6.whatever but IE 7 is a whole new bag of tricks.

one exception i did notice is the apple mac os. they call their current operating system "OS X" or "OS 10.4.9". by normal convention it should be OS 14.9 buy they really, really like the "X"

But many nds apps work fine and aren't even at version 1. I mean, Anything that's below version one should mean "This is only for developers to use." or "This includes tons and tons of bugs." But very few apps are the first and many aren't the latter- yet they still aren't at version 1.

I'd think it would be easy to emulate snes on nds because it was possible on gba, but I guess it's wrong.

[dantheman]

I'd think it would be easy to emulate snes on nds because it was possible on gba, but I guess it's wrong.

It was possible, yes, but by no means complete.  There was no sound support, slow speed, and it often froze due to SPC loops.  The only reason SNES Advance is really even playable is because of the SuperDAT, which allows for SPC fixes and speedhacks to be made by anybody, not just the developer.  Snezziboy later expanded upon this and made it better, though it was largely based on SNES Advance.

DS versions already feature sound support, full speed, partial HDMA capabilities, better game compatibility, and a higher resolution.  It's vastly improved really.

I think what you're trying to say though is that since SNES emulation on the GBA was thought to be impossible yet was carried out decently, that it would be relatively easy to create an awesome SNES emulator on the DS because it has more resources, right?  Well, like Koji said, it still is not nearly powerful enough to emulate the system the way PC emulators do.  It still relies on the DS's 2D hardware to manipulate graphics, which creates most of the issues.  For instance, graphics layering has always been a problem because the SNES has more possibilities than the DS can offer, so layers need to be rearranged or reprioritized to make the games look as good as possible.