#97939 - nl - Sat Aug 12, 2006 1:19 pm
hello
i'm developing with a DS-slot-only cart (UFP) and have difficulties running my programs. the *.nds files produced with devkitpro are not accepted by the burning program of UFP, it says the file is not a "clean ROM".
is there a way of compiling my code to such a "clean ROM"? though i read all related posts i found, it is still not quite clear to me what is the difference and if it's possible to put together a proper nds file.
the writer software accepts my *.nds file when using "menu mode", but then there will be an ugly menu from which i can start the program. also, i intend to access the flash chip (main program flash ROM, not EEPROM) from within my code, but the offsets may be wrong when starting from a menu.
thank you.
#97953 - Linkiboy - Sat Aug 12, 2006 2:48 pm
UFP is intended to function as a Warez only device, you woud have to compile your game with the official Nintendo SDK to get it to work I assume.
#97954 - chishm - Sat Aug 12, 2006 3:03 pm
When building the .nds file with ndstool, set the ARM9 binary offset to 0x8000 within the NDS file (not the start address). If the problem is caused by the flash card acting as a direct DS Card clone, then this may fix it (depending on how the flasher was written).
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com
#97958 - nl - Sat Aug 12, 2006 3:52 pm
thanks for the quick answers. i'll try the offset thing.
#97993 - nl - Sat Aug 12, 2006 6:39 pm
just tried to change the offset (by adding -r9 0x8000 to ndstool parameters, is that right?), but with no effect.
when looking at the ufp_passme.nds that comes with the writer (the only clean rom i have), i found that this file starts right with the game name while the test.nds produced with ndstool has some extra 160 bytes before that. when i removed these 160 bytes, the ufp writer recognized my .nds file as "SRAM_V110 PASS01" and allowed to write it like a clean rom - but it still wouldn't start.
my guess/hope is that no special tools are required but just some padding to get the arm7 / arm9 binaries at the right offset after the first 160 bytes were removed.
#98001 - dXtr - Sat Aug 12, 2006 7:04 pm
it mostly sounds like you have some kind of header problem for your program. but also make sure that the code your trying out doesn't expect to be run from the slot-2
_________________
go back to coding and stop screaming wolf :)
#98002 - Mighty Max - Sat Aug 12, 2006 7:07 pm
| nl wrote: |
just tried to change the offset (by adding -r9 0x8000 to ndstool parameters, is that right?), but with no effect.
|
no. -r9 0x... sets the RAM address where it is copied to.
The ndstool has no extra option to set the rom offset. What you can however do is to create a header file manually (see http://www.bottledlight.com/ds/index.php/FileFormats/NDSFormat) and use this with the option -h
_________________
GBAMP Multiboot
#98048 - nl - Sat Aug 12, 2006 10:22 pm
Thanks again.
Ndstool seems to create most of the header data correctly but places them in different locations. For example, the game title does not appear at address 0x00 but at 0xA0. The next value I can identify is the ARM9 binary size which is correctly located at 0x2C. I assumed that the first 32 bytes are exchanged with those from offset 0xA0 while the rest is in the right place (binary sizes, checksums, etc) and exchanged these bytes.
Ndstool sets the ARM9 source address to 0x200, so I padded it to offset 0x4000 and corrected the header entry. I did the same for the ARM7 binary (offset 0xc000) and finally created the new header checksum with ndstool. I am a little uncertain about the "execute addr" and "copy to addr" and tried different variations, using the default values (0x02000000) and adding 0x02000800 / 0x02000800 to the source address for arm9. For arm7 I left the default values (0x03800000).
The resulting files were all accepted by the UFP writer but the DS just said "no cart in DS slot".
#98065 - Mighty Max - Sun Aug 13, 2006 12:06 am
0x02000000 for execute&ram address of homebrew is usually correct. (unless explicit changed)
Try to get the header off of an official demo and change the addresses as needed. This way you are sure you have the correct logo data etc.
_________________
GBAMP Multiboot
#98107 - Scorpei - Sun Aug 13, 2006 8:46 am
Doesn't it need to be encrypted (unless your DS is flashed)?
#98111 - Mighty Max - Sun Aug 13, 2006 9:14 am
It is encrypted for the transfer card<->ds. It is stored decrypted on the card.
_________________
GBAMP Multiboot
#98135 - nl - Sun Aug 13, 2006 2:49 pm
| Mighty Max wrote: |
| 0x02000000 for execute&ram address of homebrew is usually correct. (unless explicit changed) |
From the examples given in the header format documentation I guessed that the source address should be added to 0x02000000 plus 0x800 for the execute addr. Anyway, I tried all variations without success.
| Mighty Max wrote: |
| Try to get the header off of an official demo and change the addresses as needed. This way you are sure you have the correct logo data etc. |
Wouldn't the CRCs be wrong when anything is changed? The header CRC can be corrected with ndstool, but what about "CRC16"? And wouldn't other data have to be altered too, like "unk addr", FAT info, etc?
When I start the UFP with my nds file now, it freezes without showing the startup sceen. The upper screen is white and the lower one shows the health warning in very light grey. Is this a known behaviour that indicates a specific problem?
When the program is strarted from the UFP menu, only the ARM9 code seems to work.
#98138 - Mighty Max - Sun Aug 13, 2006 3:11 pm
| nl wrote: |
| Mighty Max wrote: | | 0x02000000 for execute&ram address of homebrew is usually correct. (unless explicit changed) |
From the examples given in the header format documentation I guessed that the source address should be added to 0x02000000 plus 0x800 for the execute addr. Anyway, I tried all variations without success.
|
0x02000000 entry point is for homebrew use. The crt0 of devkitArm is simply put at the very start of the bins.
| Quote: |
| Mighty Max wrote: | | Try to get the header off of an official demo and change the addresses as needed. This way you are sure you have the correct logo data etc. |
Wouldn't the CRCs be wrong when anything is changed? The header CRC can be corrected with ndstool, but what about "CRC16"? And wouldn't other data have to be altered too, like "unk addr", FAT info, etc?
|
Indeed, forgot about the Secure CRC16. However if the Secure area is zeroed out (0x4000-0x8000) shouldn't this CRC be easy to fill?
My personal view on unk addr7/9 is, that they point to the end of the crt0 code for the binaries. Their content is not of any interest for homebrew and should stay what they are.
But i can't be much more helpfull, the MFP is pretty new, and actually you are the first i hear of, who tries to run homebrew on it.
_________________
GBAMP Multiboot
#98166 - nl - Sun Aug 13, 2006 7:54 pm
OK, it works now. Thanks a lot for the help again.
I'll identify the unnecessary steps in my procedure (I tried many things and I'm not sure which ones finally lead to success) and provide a little program or maybe just a batch file or modify ndstool if the source is available.
Basically, the ARM binaries both need to be 8 kb (or 16?) aligned and the apropriate values have to be set in the header (offsets, ROM size, header size), the rest was taken from the UFP passme ROM. Then the header has to be re-sorted (game name on beginning) and finally CRCs have to be re-calculated.
It's nice to have a single little cart for the DS slot and start my program right away, especially for demonstration and giving copies away. The UFP has a hole in the plastic case where a chip slightly sticks out, covered only by the sticker label. However, it fits well into the slot and I guess future hardware revisions will have no parts sticking out (I think it was ther very first generation of the first standalone DS-slot flashcart, so we can expect improvements in the future).
#98170 - Mighty Max - Sun Aug 13, 2006 8:18 pm
Could you do me a favor and do a little review / howto?
I'm planning to get a DS-Slot solution too, but there are nearly no info about these atm to decide uppon.
_________________
GBAMP Multiboot
#98191 - nl - Sun Aug 13, 2006 11:56 pm
i don't know too much about these too. the two currently available solutions (UltraFlashPass and Ninjapass DS Flash Jr.) are said to be clones of the same hardware or even from the same factory. both suppliers claim their product to be the first real DS flash cart.
the size is 512 mbit - little for games but plenty for homebrew. i haven't tested too many files with it, actually got it solely for programming. an official demo worked when started from the menu but not without menu. generally it seems less picky when using the menu, i guess files are patched then while direct boot requires clean ROMs. some sources say that files are always patched by the writer, but my guess is that the UFP actually acts like a normal DS cart when in single-ROM, non-menu mode.
writing times are said to be extremely slow, it can take hours to fill the entire 512 mbit. however, my small test program was written within a few seconds.
as mentioned by dXtr, there may be problems with homebrew programs which think they are running from the GBA slow and try to access it.
i already opened the cartridge and found an unnamed chip (the one that's sticking out, probably an FPGA), a flash chip and two eeproms. i guess the menu software copies the content of the smaller eeprom (ST M95040, 4 Kbit), which acts like a standard DS cart eeprom, to the bigger one (ST M45PE20, 2Mbit), so it can remember different saves for different games. i am very interested in the main flash chip and hope i can write it from within my code. it is labeled "4455LLYBQ2", i don't know what that stands for, all i found it is that it seems to be intel. once i know how to read/write the DS slot, i may read the ID via standard commands.
my conclusion on UFP is that it is relatively useless for piracy due to small memory and slow writing, but it's great to have my homebrew program on a single cart, just like a commercial game (only that chip sticking out and slightly lifting up the label makes it look not quite professional). if we find out how to access both eeproms or even the main flash, it has just everything you need.
i'm not quite sure what you mean by "review / howto", if you have furhter questions, please feel free to ask.
#98245 - JaJa - Mon Aug 14, 2006 9:45 am
Useless for piracy?
There are very few games that are 1024Mbit, with many seeming to be around 256Mbit or 512Mbit. Remember they can be trimmed too.
That means that this device can run nearly all roms, and it seems that it does so fairly easily.
It probably has a 4kbit EEPROM and a 2Mbit chip for different save types/sizes?
_________________
LAWL HOOGE
My Blog
#98253 - nl - Mon Aug 14, 2006 10:39 am
of course the UFP can be used for piracy, that's what it's made for. but you can put only one or two games on the cart and writing is very slow, so that you can't just swap them. i am not familiar with piracy, but i guess those who do it want to have as many games as possible. people who collect mp3s or crcked software usally count their possesion in gigabytes - no matter what crappy music in which lousy encoding or what useless software it is.
so for those who want to be the cool warez dude (the target audience of UFP i'd say), it is not so useful because you can't show off your huge collection of ripped ROMs.
when starting a game from the menu, it first says "copying save data", that's why i assumed one eeprom is used as backup for the other one. but i may be wrong.
#98255 - JaJa - Mon Aug 14, 2006 10:48 am
Interesting.
But some game saves are 2Mbit (Nintendogs for example), so it couldn't copy that to the 4kbit chip.
If it can only hold one or two games at a time though, I suppose it doesn't matter.
However, you've done a good job at getting homebrew to run on that device.
Have you tried getting exisiting homebrew to run?
_________________
LAWL HOOGE
My Blog
#98258 - nl - Mon Aug 14, 2006 11:10 am
so i'm probably wrong about the eeprom usage.
i haven't tried existing homebrew yet, only some example code from devkitpro.
i have written a little tool that puts together a valid clean rom .nds file from the arm7 / arm9 binaries and the UFP ROM header, it should be easy to modify it so that it extracts the binaries from an existing nds file generated with devkit/ndstool.
it should be no problem to get existing programs to run, unless they try to access a GBA cart.
currently the tool only works with my local setup (hardcoded filenames, etc), i'll make it available when this is solved. i'm glad i can contribute somthing useful to the development community though i just started :)
#98347 - Scorpei - Mon Aug 14, 2006 8:44 pm
What about running homebrew with the DSlink?
Normal .nds homebrew (or modified with your new tool :P) should work right, and possibly FAT lib homebrew if a supporting FAT lib would be written?
#112434 - jonnyhilly - Sat Dec 16, 2006 10:30 am
Hi, is there any update on this topic ?
I just got a Ninjapass, and am now dismayed to discover I cant do home brew on it
also does a rom need to be setup differently (header etc..) if its going to be used in 2 ways... both downloaded via wifi and put onto a DS cart.
thanks
Jon
#112495 - mastertop101 - Sat Dec 16, 2006 11:36 pm
Try this and please say me if it works :
http://rapidshare.com/files/7710105/Ninja_X9_Rom_Tool.zip.html
just drag and drop .nds on the .bat file and use OUTPUTX9.nds instead..
#112500 - jonnyhilly - Sun Dec 17, 2006 12:15 am
OK, I tried it with the hello_world.nds
that comes with devkitpro,
I got an error window popup,
that is labelled: Project1
with erroe message...
Run-time error '5'
Invalid procedure call or argument
I ran it by clicking on the bottom button "homebrew no fat patch (BETA Test)", then selecting the .nds file in the file selector window.
I have Win XP
Let me know if you want me to try anything else
#112502 - jonnyhilly - Sun Dec 17, 2006 12:43 am
also tried with a few other sample .nds files with the same result.
the tool looks promising, hope you can get it to all work
#112531 - bobmcbob - Sun Dec 17, 2006 5:25 pm
Please try the orignal tool for the Ninjapass X9 if your still having trouble with the GUI version.
Tool located here : http://tapper.bucklehost.co.uk/x9/x9hbloader-0.1.zip
Be sure to read the readme file.
For updates etc see the ninjapass forum. Its quite active at the moment.
#112568 - jonnyhilly - Sun Dec 17, 2006 11:17 pm
Thanks bob
that worked for the hello_world.nds that comes with DevKitPro
thanks for the link
Interestingly, it spat out an error, saying "test build will seg fault"
Though it still ran.... perhaps this will be an issue with more complex example code.
I'll try some other examples later
Thanks again
I made a quick batch file that makes things easier to test, instead of typing in the command line stuff. So anyone else trying this out... just make a text file called "PATCH IT.bat" and paste the following into it...
del patch.bin
copy bootloader.bin patch.bin
copy test.nds patched.nds
patcher.exe test.nds patched.nds
del patch.bin
pause
This will turn your test.nds into a patched.nds, and keep the folder clean.
Just double click "PATCH IT.bat" after copying your test.nds into the same folder as the patcher.exe
You should also be able to add this as a post build step when compiling. Though I havn't tried that yet... not sure how to do it with DevKitPro
#112575 - bobmcbob - Mon Dec 18, 2006 1:24 am
yeh its just a warning the stuff about seg fault because there is no error checking. That build was purely proof of concept.
Some stuff works and some stuff doesnt.
There is a better way to work if you are compiling your own stuff from scratch. Il post all my x9 stuff at some point tomorow.
Glad the tool works for you.