NDS Slot-1 Clean ROM no-patch Tester

[gbasho]

just wanted to say that i enjoy this thread.
that is all.

 

[openchip]

I'm not sure if this has been mentioned, but wouldn't it be possible at some point to have the fast NOR memory, with a micro-sd card, you boot it and copy a game to the NOR, then reset and flick a switch so it reads from the NOR and thinks it's a real game?

I am getting too old. I assumed 1GBit NOR Flash is out of the question still, but I was wrong. Excuse my previous comment that NOR Flash is not feasible for the card design.

My last design where I used parallel flash was true clean room implementation of FilmNet digitial sound decoder back many years. The design used Z80, 13 GAL's (was cheaper than XC2018 back then), 2KB SRAM for CPU, 8 KB SRAM for sound samples, and 27C256 (32KByte EEPROM, largest obtainable non volatile memory at that time!) for Z80 software and for digital transmittion hamming code correction.

This was the last time I designed in any parallel flash. But some time has pasted, and Spansion announced 1GBit NOR in 2005, Intel has similar announcement. And I hadnt paid attention to those technical news yet. So 1GBit NOR Flash is also defenetly an feasibly option.

 

[cory1492]

sure, your testing was correct.

if you try reading the header directly after your homebrew starts you will get KEY2 mangled data that changes every time.
You have to reset the card to be able to read the header.
but if you reset the slot-1 flash card you would be reading the header of the slot-1 firmware not of your app

So your 1.1 header comparison just checks the header that is in memory, correct? (I know reset did not change the header in memory in my tests, which had essentially the homebrew's header in it).

You still don't catch my point though. At least with EZ5, they have to do something special to allow uncorrupted data to be accessed from the TF card after booting homebrew, if the gamecode is not correct than I am assuming all data coming from the EZ5 will be corrupted.

Some 1.1 results:
header patched? / ID / no-patch play / test data

From EZ4 (renamed to .bin for EZ4 to use PSRAM to load)
EZ5: no /00A0FFFF/ NO / FFFFFFFF FFFFFFFF
MK4-Mini: no / EEB7E4ED / NO / 3FB82405 FA6BE515
DSLink: no / 2E0000EA / NO / FFFFFFFF FFFFFFFF
Madden 2005: no / 3C21CCE8 / NO / E621FDA1 E01B3C6F
these results were identical when run from a different flashcart than EZ4, ds.gba version and .nds version both booted without a problem.

Run from:
EZ5: yes / none / YES / 020275D58 00000000 (successive runs returned same test data)
DSLink: yes / 0068FFFF / NO / FFFFFFFF FFFFFFFF

Not sure why the results are so different from the previous one's, nor why the EZ has no patch play... perhaps it goes back to the thing I was talking about with the header? Here, I'll patch the homebrew to have gamecode PASS like EZ5 expects for homebrew and see what happens when I run it again...

EZ5: yes / none / NO / E2011102 E0900FA3 (successive runs returned same test data)

I hope I illustrated my point there... EZ5 uses a special gamecode to detect homebrew which would use the FAT lib, and returned different results, including a NO for no-patch play. EZ5 uses a simple (and incorrect in my opinion) method of detecting homebrew... most likely the other cards use a method similar to ndstool's check for multiboot/homebrew/commercial.
aka: if it's built like a homebrew ROM breaking many of the rules of commercial ROM's, and has homebrew identifiers in the header, the cards are going to treat it differently unless they are extremely unintelligent in their detection method. It's either that... or you made an error in the program update?

edit:/ what is the correct test data supposed to be anyway?

 

[DavePS]

Anyone tried runningthis program against a REAL game cartridge? I'd be interested to see if it says they are patched as well!

 

[cory1492]

Uhmm, read my post a little more carefully - I tested from an EZ4 against real carts that were not used as the bootup medium. What you are asking is technically impossible though, since we don't have any method to make a real DS cart with this app on it to confirm it's operation is 100% correct.

 

[openchip]

sure, your testing was correct.

if you try reading the header directly after your homebrew starts you will get KEY2 mangled data that changes every time.
You have to reset the card to be able to read the header.
but if you reset the slot-1 flash card you would be reading the header of the slot-1 firmware not of your app

So your 1.1 header comparison just checks the header that is in memory, correct? (I know reset did not change the header in memory in my tests, which had essentially the homebrew's header in it).

You still don't catch my point though. At least with EZ5, they have to do something special to allow uncorrupted data to be accessed from the TF card after booting homebrew, if the gamecode is not correct than I am assuming all data coming from the EZ5 will be corrupted.

Some 1.1 results:
header patched? / ID / no-patch play / test data

From EZ4 (renamed to .bin for EZ4 to use PSRAM to load)
EZ5: no /00A0FFFF/ NO / FFFFFFFF FFFFFFFF
MK4-Mini: no / EEB7E4ED / NO / 3FB82405 FA6BE515
DSLink: no / 2E0000EA / NO / FFFFFFFF FFFFFFFF
Madden 2005: no / 3C21CCE8 / NO / E621FDA1 E01B3C6F
these results were identical when run from a different flashcart than EZ4, ds.gba version and .nds version both booted without a problem.

Run from:
EZ5: yes / none / YES / 020275D58 00000000 (successive runs returned same test data)
DSLink: yes / 0068FFFF / NO / FFFFFFFF FFFFFFFF

Not sure why the results are so different from the previous one's, nor why the EZ has no patch play... perhaps it goes back to the thing I was talking about with the header? Here, I'll patch the homebrew to have gamecode PASS like EZ5 expects for homebrew and see what happens when I run it again...

EZ5: yes / none / NO / E2011102 E0900FA3 (successive runs returned same test data)

I hope I illustrated my point there... EZ5 uses a special gamecode to detect homebrew which would use the FAT lib, and returned different results, including a NO for no-patch play. EZ5 uses a simple (and incorrect in my opinion) method of detecting homebrew... most likely the other cards use a method similar to ndstool's check for multiboot/homebrew/commercial.
aka: if it's built like a homebrew ROM breaking many of the rules of commercial ROM's, and has homebrew identifiers in the header, the cards are going to treat it differently unless they are extremely unintelligent in their detection method. It's either that... or you made an error in the program update?

edit:/ what is the correct test data supposed to be anyway?

hi cory.

thanks a lot for testing - the results are interesting

well first thing I need to add - the testing when the ROMTester.nds is _not_ loaded from the slot-1 device are rather pointles, the utility does not check if card in slot-1 at time of testing is ok, and looks like real rom, it only checks if it can read _itself_ from slot-1, if it ROMTester.nds itself was not originally on slot-1, then it can not read itself from slot-1 obviously so the test should fail. Of course should some slot-2 system patch succesfully the ROMTester.nds _then_ it would report YES also when run from slot-2.

Now more details on ver 1.1
The based check is the same, a simple raw read to slot-1 using native command 0xB7
additionally is added check if header is patched, I dont know why it should be, but as example microninjads does patch the header
additional check for emulators (detects most except no$gba)
additional check if there is RAM in GBA slot
if either emulator or GBA card detected additional warning is displayed - it basically says that results are more-or less meaningless.
changed, if ROM id is correct/default (C2 0F 00 00) no print, only when something else is read the ID read is displayed.

Now what is really interesting is the fact that EZ5 does say YES and returns valid data.
So either EZ5 looks 100% like real ROM from hardware point of view, or it was able to patch ROMTester.NDS

cory - I think I understand the things, no-patch detect result will be yes only if either ROM _is_ 100% compatible or my test is patched. And clean ROMs can only play if 100% true hardware or properly patched. The header patch detect is just additional goodie.

It is very interesting both ways

 

[openchip]

Uhmm, read my post a little more carefully - I tested from an EZ4 against real carts that were not used as the bootup medium. What you are asking is technically impossible though, since we don't have any method to make a real DS cart with this app on it to confirm it's operation is 100% correct.

be careful what you say about technically impossible!

first during card initial start the on-board firmware is started in clean rom mode, so placing ROMtester in place of slot-1 boot firmware would yield in YES result.

second I do have card(s) where I can place ROMtester to be boot-firmware, and I can also make slot-1 clean emulator (it would not fit the slot-1 though at the moment)

 

[cory1492]

I'd still like to know, does the header compare with what is in the DS memory (secure area/header copied to memory) or... ? I'm only trying to understand if there is a possibility of false YES/NO. Also, was there a change to romID? It worked fine in 1.0 from EZ4...

be careful what you say about technically impossible!

first during card initial start the on-board firmware is started in clean rom mode, so placing ROMtester in place of slot-1 boot firmware would yield in YES result.

second I do have card(s) where I can place ROMtester to be boot-firmware, and I can also make slot-1 clean emulator (it would not fit the slot-1 though at the moment)

It is technically impossible to make this program onto a REAL game card; at least, not without the help of Nintendo. Both solutions you have available, while interesting, would not produce a REAL game card, only plausibly good fake ones

It is a technicality.

 

[openchip]

I'd still like to know, does the header compare with what is in the DS memory (secure area/header copied to memory) or... ? I'm only trying to understand if there is a possibility of false YES/NO. Also, was there a change to romID? It worked fine in 1.0 from EZ4...

be careful what you say about technically impossible!

first during card initial start the on-board firmware is started in clean rom mode, so placing ROMtester in place of slot-1 boot firmware would yield in YES result.

second I do have card(s) where I can place ROMtester to be boot-firmware, and I can also make slot-1 clean emulator (it would not fit the slot-1 though at the moment)

It is technically impossible to make this program onto a REAL game card; at least, not without the help of Nintendo. Both solutions you have available, while interesting, would not produce a REAL game card, only plausibly good fake ones

It is a technicality.

ok yes, it is only possible to make a clone that has exact same behaviour as the real one. This _is_ possible.

and yes the ID read check changed from ver 1.0, the later version(s) use more strict correct procedure. On real thing the later revisions should still give proper ID read.

hm did you check version 1.2 ? It is downloadable (even if there is no link right now) ver 1.2 prints out "flags" that are left in the card register when the ROMtester is launched. Version 1.0 used hardcoded values (wrong approuch).


ROMTester doesnt currently do any attempts to reset the slot-1 as to my knowledge many slot-1 flash cards do not wakeup properly after slot-1 reset. The header patch only checks the header copy in RAM, to my knowledge there is no real reason why it should be pathced, but at least 2 slot-1 devices seem to patch the header area as well.

If there slot-1 card has been identified as been seen slot-1 reset (eg responds to mode 1 card ID) then it would be possible to read the header from the card, but again it would be header of the card in slot-1, and it would not match the header in ROMtester anyway.

 

[openchip]

Version 1.2 now available - sorry it was online and then it wasnt as the server admin tool trashed the domain root for me as firendly service.

http://nds.truedream.org
http://nds.truedream.org/ROMTester_1_2.nds

 

[cory1492]

1.2 results when run from the EZ5:
Initial flags: 21587F00
Game header is patched!
Header CRC: B671

Arm9 CRC: 362E
Clean ROM no-patch play: YES
Test data: 65722072 6E727574 (concurrent runs produced same data)

From EZ4 with EZ5 in NDS slot (useless, but I figured you'd like to know the results)
Initial Flags: 20000000
Bad/Unknown ROM ID: 0020FFFF
?
Arm9 CRC: 362E
Clean ROM no-patch play: NO
Test data: FFFFFFFF FFFFFFFF

 

[cory1492]

The header patch only checks the header copy in RAM, to my knowledge there is no real reason why it should be pathced, but at least 2 slot-1 devices seem to patch the header area as well.

Is it possible their loading method does not require the entire game header to be replaced in memory (thus only appearing patched)?

 

[openchip]

The header patch only checks the header copy in RAM, to my knowledge there is no real reason why it should be pathced, but at least 2 slot-1 devices seem to patch the header area as well.
Is it possible their loading method does not require the entire game header to be replaced in memory (thus only appearing patched)?

one more thing about EZ-V, it does use ROM read command 0xB7 as read SRAM (1MByte) so if the ROM was loaded to SRAM then EZ-V should give valid response if sensed within first megabyte of the ROM content.

 

[cory1492]

Would 1MB be enough data to deal with the random commands you mention in commercial ROM's? It would explain the long initialize time before a game loads... if the data had to be copied to 2 places instead of just into memory. (AFAIK the 8Mbit SRAM is used strictly for saver data)

EZ5's kernel itself runs like homebrew and accesses the SD card. Unfortunately they ripped the code from the source that calls "cleanROM mode" and it will not launch .nds files at all (though it probably wouldn't be that tough to isolate with a compare between the source kernel and the official kernel).

I'm assuming in homebrew mode, all the commands do something different than in clean ROM or hybrid mode... could be wrong on that though.

 

[ralff]

Version 1.2 now available - sorry it was online and then it wasnt as the server admin tool trashed the domain root for me as firendly service.

http://nds.truedream.org
http://nds.truedream.org/ROMTester_1_2.nds

Ok, here are my results using version 1.2:


UFP512: 2118000 - 362E - Yes - 65722072 6E727574
AceKard: reported as Emulator !
NinjaDS Sticky: 21406000 - Patched Header 1FEF - 362E - No - E3A05301 E1A01421
DSLink: unknown ROM ID - Patched Header AFA4 - 362E - No - FFFFFFFF FFFFFFFF
DSOne: 27180000 - Patch Header 1427 - 362E - No - D0044213 42A66803
EZV: 21587F00 - Patched Header B671 - 362E - Yes - 65722072 6E727574
X9: no able to start ! randomly hung or boot Slot 2 !
R4DS: 21586000 - 362E - No - 46C04718 46C0B5F8
DSX: unknown ROM ID - Patched Header 6B85 - 362E - No - AC45FE39 F5B2ADF5

Ralf

 

[openchip]

Version 1.2 now available - sorry it was online and then it wasnt as the server admin tool trashed the domain root for me as firendly service.

http://nds.truedream.org
http://nds.truedream.org/ROMTester_1_2.nds

Ok, here are my results using version 1.2:

UFP512: 2118000 - 362E - Yes - 65722072 6E727574
AceKard: reported as Emulator !
NinjaDS Sticky: 21406000 - Patched Header 1FEF - 362E - No - E3A05301 E1A01421
DSLink: unknown ROM ID - Patched Header AFA4 - 362E - No - FFFFFFFF FFFFFFFF
DSOne: 27180000 - Patch Header 1427 - 362E - No - D0044213 42A66803
EZV: 21587F00 - Patched Header B671 - 362E - Yes - 65722072 6E727574
X9: no able to start ! randomly hung or boot Slot 2 !
R4DS: 21586000 - 362E - No - 46C04718 46C0B5F8
DSX: unknown ROM ID - Patched Header 6B85 - 362E - No - AC45FE39 F5B2ADF5

Ralf

emulator check is
1) check if writeable memory in GBA slot
2) initial values of slot hardware ownership (only good in no$gba, wrong in others) - its not so accurate, and it seems I am not masking the bits correctly, still it should be standard setting if roms are normally started (eg slot hw ownership is ARM7 by defualt)

the UFP seems interesting - the flags setting is 0 init latency, and NO KEY2 encryption. same with DSOne, no KEY2 encryption.

I will have some more advanced tool soon ready..

 

[openchip]

Would 1MB be enough data to deal with the random commands you mention in commercial ROM's? It would explain the long initialize time before a game loads... if the data had to be copied to 2 places instead of just into memory. (AFAIK the 8Mbit SRAM is used strictly for saver data)

EZ5's kernel itself runs like homebrew and accesses the SD card. Unfortunately they ripped the code from the source that calls "cleanROM mode" and it will not launch .nds files at all (though it probably wouldn't be that tough to isolate with a compare between the source kernel and the official kernel).

I'm assuming in homebrew mode, all the commands do something different than in clean ROM or hybrid mode... could be wrong on that though.

no, the 1MByte is not sufficient. Any ROM loaded may immediatly request and block for reads anywhere in the ROM space, and the slot-1 device has about 4 microseconds to deliver that sector. unless the NDS slot-1 hw latency setting has changed, in which case (it this is possible) there is more time to respond (but still not enough time to fetch sector from SD card).

 

[ralff]

emulator check is
1) check if writeable memory in GBA slot
2) initial values of slot hardware ownership (only good in no$gba, wrong in others) - its not so accurate, and it seems I am not masking the bits correctly, still it should be standard setting if roms are normally started (eg slot hw ownership is ARM7 by defualt)

the UFP seems interesting - the flags setting is 0 init latency, and NO KEY2 encryption. same with DSOne, no KEY2 encryption.

I will have some more advanced tool soon ready..

Oh, sorry
Every test ( exception is UFP512 ) was done using an original NDS Lite ( UEH1134xxxx ) with an EZFlash IV Lite Deluxe inside Slot-2.
I'll remove it on further tests.
The UFP512 is NOT available to run in my new NDSL ( but still runs using my older orginal Lite ( UEF1099xxxx ) or my Phat ) so the test was run on both older devices.
The initial flags are: 21180000 not 2118000.

AceKard without Slot 2 Card:

BAD EXMEMCNT initval. Emulator ?
initial Flags: 29406300
ARM9 CRC: 362E
Either emulator or Slot-2,
results likely meaningless!
Clean ROM no-patch play: YES
Test data: 65722072 6E727574

Ralf

 

[openchip]

emulator check is
1) check if writeable memory in GBA slot
2) initial values of slot hardware ownership (only good in no$gba, wrong in others) - its not so accurate, and it seems I am not masking the bits correctly, still it should be standard setting if roms are normally started (eg slot hw ownership is ARM7 by defualt)

the UFP seems interesting - the flags setting is 0 init latency, and NO KEY2 encryption. same with DSOne, no KEY2 encryption.

I will have some more advanced tool soon ready..

Oh, sorry
Every test ( exception is UFP512 ) was done using an original NDS Lite ( UEH1134xxxx ) with an EZFlash IV Lite Deluxe inside Slot-2.
I'll remove it on further tests.
The UFP512 is NOT available to run in my new NDSL ( but still runs using my older orginal Lite ( UEF1099xxxx ) or my Phat ) so the test was run on both older devices.
The initial flags are: 21180000 not 2118000.

AceKard without Slot 2 Card:

BAD EXMEMCNT initval. Emulator ?
initial Flags: 29406300
ARM9 CRC: 362E
Either emulator or Slot-2,
results likely meaningless!
Clean ROM no-patch play: YES
Test data: 65722072 6E727574

Ralf

things are getting eve more interesting

sure all cases during test slot-2 should be EMPTY, the test doesnt stop but can issue warning.

the emu test that is incorrect on acekard, well am checking for the CR_WAIT register to have known standard value
(not masking off the slot ownership bits) so it may be less accurate, but again the slot-1 device has no reasons to
leave this register in non-default state before running the loaded ROM.

question, why doesnt the UFP run on new NDSL? its a slot-1 flash card so should work? (or you meant you are unable to test)
haa acekard seems to the ony one that uses slower slot-1 clock rate

I will work on update tonight

 

[ralff]

things are getting eve more interesting

sure all cases during test slot-2 should be EMPTY, the test doesnt stop but can issue warning.

the emu test that is incorrect on acekard, well am checking for the CR_WAIT register to have known standard value
(not masking off the slot ownership bits) so it may be less accurate, but again the slot-1 device has no reasons to
leave this register in non-default state before running the loaded ROM.

question, why doesnt the UFP run on new NDSL? its a slot-1 flash card so should work? (or you meant you are unable to test)
haa acekard seems to the ony one that uses slower slot-1 clock rate

I will work on update tonight

Slot-2 is EMPTY :-)

The new NDSL hungs during boot the UFP every time. I don't know why....

Ralf

EDIT: I've dumped the firmware of the two DS Lite. They are different. I think Nintendo has modified something to exclude the UFP.