Hacking NDSSFC/CATSFC revival
- Thread starter Deleted member 319809
- Start date
- Views 174,505
- Replies 707
- Likes 15
To keep with your food analogy, it would be like trying to eat spaghetti when you're given only one spaghetto and the start and end of that spaghetto refers to the location of two others in GPS coordinates, and the others refer to more, and so on. So you have to start reassembling spaghetti into your plate to start eating, and the coordinates don't make sense like "the next spaghetto is 2 blocks east, upstairs" does.
wow...now i'm hungry, thanks for explaining it to me.
On another note, does anyone know why, the creator of the EMU won't share the code?
On another note, does anyone know why, the creator of the EMU won't share the code?
wow...now i'm hungry, thanks for explaining it to me.
Nope, nobody's been able to get in contact with them yet (language issues?) but they're legally obligated if it means anything and it's in their best interest as DSTWO sellers.
Once again: China, legally obligated? Hold on while I laugh.
Yeah - and then add the fact that old nitendo is trying to block out dstwo with various updates for some odd legal reason as well...
Anyay - if somebody would start collecting names for a petition I would totally sign it.
/dACE
There should be no need for a petition, unless you really want to show the extent of support for NDSGBA updates. Just be like "You're doing nothing with the code, Nebuleon has been doing stuff with NDSSFC, here's proof. NDSGBA source please."
EDIT: PLEASE MOVE THE GBA-SPECIFIC DISCUSSION TO THE NEW THREAD, Supercard / NDSGBA: The community's wishes. THANKS.
The discussion about the Chinese translation for CATSFC can stay here.
is there a known problem of this getting stuck on the load screen when you start catsfc?
more often than not this happens to me.
more often than not this happens to me.
No, but I can investigate this with you.
* Are you using a custom menu such as BAGPlug or iMenu?
* What is the location and file size (e.g. 2,202,112 bytes) of CATSFC.PLG on your microSD card relative to the root?
* What is the location of the CATSFC system folder on your microSD card relative to the root?
* How many files does (CATSFC system folder)/SYSTEM/GUI contain on your microSD card?
* After selecting the plugin, what colour of screen(s) do you get? Normally you should get white, then a short black one, then a "Loading..." screen with a SNES controller, then the GUI with 9 options.
* Do you get a white-text-on-black error screen?
* When you last formatted your card, did you use the FAT32 file system and the Panasonic SD Formatter with the size adjustment option set? (On Linux, the question becomes: When creating your FAT32 partition, did you start the partition 1 megabyte late?)
well as far as i know im just using the standard scds2 menu.
the size of the .plg appears to only be 2,195,456 bytes
catsfc folder is in root
the GUI folder has 36 files
when i click on the plugin it goes to the loading screen with snes controller as you described but will stay there most of the time.
and i dont even remember the last time i formatted the card. but i know i didnt use the panasonic sd formatter. i just know its fat32
edit: just tried 1.31 and it works fine. i guess the 1.3 file i had was messed up.
the size of the .plg appears to only be 2,195,456 bytes
catsfc folder is in root
the GUI folder has 36 files
when i click on the plugin it goes to the loading screen with snes controller as you described but will stay there most of the time.
and i dont even remember the last time i formatted the card. but i know i didnt use the panasonic sd formatter. i just know its fat32
edit: just tried 1.31 and it works fine. i guess the 1.3 file i had was messed up.
You don't have the most recent version installed, or it cut off before the end of the transfer to your microSD card. The plugin file should be 2,202,112 bytes for version 1.31.
thanks a bunch. btw really loving it all of the updates. it is enjoyable now lol.
Oh wait, it is.
Anyway here's the new translation.
Does require further testing to see if the spacing and new lines worked out properly and are properly aligned.
Tried to commit language.msg file in github, it didn't work.
Only one message is too long now, and that's this one:
Code:
#MSG_HOTKEY_FULL_SCREEN_TOGGLE
Schakel naar volledig schermAlso, I just realized that I can test everything myself, so I'll be posting a new one soon enough.
Tested it and everything should work fine now, except for the overlap, which would indeed be nicer if the messages started a bit more to the left.
If you decide to not move the start of the messages to left, you can just cut out the word "naar" in the translation (as in:"Schakel naar volledig scherm").
Attached is the full language.msg file (but with .txt extension since you can't upload .msg here).
If you decide to not move the start of the messages to left, you can just cut out the word "naar" in the translation (as in:"Schakel naar volledig scherm").
Attached is the full language.msg file (but with .txt extension since you can't upload .msg here).
@Nebuleon: The improved nesDS emulator has an additional display mode to display the cropped pixels on the second screen. Would it be possible to adapt this display mode for NEBSFC?
No, at least not without halving the frame rate from what it is now. I have to send 192 lines for each screen, upper and lower, even if the lower screen has only 32 lines used.
Here's something that might clear things up and also explain why 2 frameskip is needed right now.
During every frame (16.67 milliseconds), emulation is carried out for that frame, then the image is rendered, then the sound. The image takes very little time to generate, but 23 milliseconds to send - which is more than 1 frame time. Controls are synchronised after that, in a queue of requests to the DS. (The cart bus time is to scale; the CPU time might not be, like early frames and late frames)
Exhibit A: Bad synchronisation at frameskip 1
The above picture is at frameskip 2. At frameskip 1, the time it takes to send the image and the sound means that, sometimes, the controls are skipped because another image is ready at that exact moment. (Move the second large green rectangle 1 frame to the left in your head)
If that happens, controls are not updated until the cart bus starts to desynchronise again. Frameskip 2 fixes this.
Exhibit B: Copying missing pixels to the bottom screen
To carry out an update to the bottom screen, tack an additional 23 milliseconds to send the bottom screen, even if only 1/6 of it is used. That means the cart bus becomes Image Sound Controls Image Sound Controls for 50 milliseconds. By that time, it's possible that the controls are bad because an image is ready at that exact moment. So you'd need frameskip 3 at that point, and the image would update in steps: up first, bottom next, up next, bottom next, not all at once. That would get weird rather fast, too.
The Nintendo DS, if using its hardware acceleration like SNEmulDS and nesDS, can start drawing the bottom screen from the same graphics within the same frame. This is much better, but unfortunately that method is unavailable when coding on the DSTwo's MIPS processor.
During every frame (16.67 milliseconds), emulation is carried out for that frame, then the image is rendered, then the sound. The image takes very little time to generate, but 23 milliseconds to send - which is more than 1 frame time. Controls are synchronised after that, in a queue of requests to the DS. (The cart bus time is to scale; the CPU time might not be, like early frames and late frames)
Exhibit A: Bad synchronisation at frameskip 1
The above picture is at frameskip 2. At frameskip 1, the time it takes to send the image and the sound means that, sometimes, the controls are skipped because another image is ready at that exact moment. (Move the second large green rectangle 1 frame to the left in your head)
If that happens, controls are not updated until the cart bus starts to desynchronise again. Frameskip 2 fixes this.
Exhibit B: Copying missing pixels to the bottom screen
To carry out an update to the bottom screen, tack an additional 23 milliseconds to send the bottom screen, even if only 1/6 of it is used. That means the cart bus becomes Image Sound Controls Image Sound Controls for 50 milliseconds. By that time, it's possible that the controls are bad because an image is ready at that exact moment. So you'd need frameskip 3 at that point, and the image would update in steps: up first, bottom next, up next, bottom next, not all at once. That would get weird rather fast, too.
The Nintendo DS, if using its hardware acceleration like SNEmulDS and nesDS, can start drawing the bottom screen from the same graphics within the same frame. This is much better, but unfortunately that method is unavailable when coding on the DSTwo's MIPS processor.
Similar threads
- No one is chatting at the moment.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
@
Jayro:
Eventhough the New 3DS XL is more powerful, I still feel like the DS Lite was a more polished system. It's a real shame that it never got an XL variant keeping the GBA slot. You'd have to go on AliExpress and buy an ML shell to give a DS phat the unofficial "DS Lite" treatment, and that's the best we'll ever get I'm afraid.+1 -
-
@
SylverReZ:
@Jayro, I don't see whats so special about the DS ML, its just a DS lite in a phat shell. At least the phat model had louder speakers, whereas the lite has a much better screen.+1 -
@
SylverReZ:
They probably said "Hey, why not we combine the two together and make a 'new' DS to sell".
-
-
-
@
Veho:
Nothing special about it other than it's more comfortable than the Lite+1
for people with beefy hands. -
-
-
-
