Hacking ndstrim 1.0

[recover]

136 bytes isn't that much and I don't know of a reliable way to detect whether they are used or not.
I have only tested the app on the roms that I have, and it have seemed to worked very well on every one of them.
Since the trimmer blindly follows the bytes in 0x80-0x83, it's quite possible that some roms do not use them properly and thus cause the trimmer to trim too much/not enough.
All this need further testing and I'll try to code some more when I have the time (which I don't have at the moment).
Feel free to make any enhancements you wish

 

[BrianTokyo]

There's a way to accurately detect whether you need to copy the wifi block area or not (NDSTokyoTrim does). I noticed some roms don't work if they have extra space than needed after the rom data, specially with some carts (R4 and M3 seem fine though)

 

[recover]

Ok, if you know the technical details on the how's and why's please feel free to share

 

[scandal_uk]

Forget the .NET rubbish - that was just BASIC so that anyone could re-use the code. It is a useful way to show non-programmers how the methods work.

NDSTokyoTrim is far more fully-featured but the beauty of NDSTrim is that it is open-source.

If you know where it is going wrong - please share your info!

 

[recover]

I still haven't gotten the time to code more on this, got a lot of stuff going on now, but I haven't forgotten

And yes, we should collect information on how we can implement a feature to detect these (faulty) roms that ndstrim can't trim at the moment, and try to figure out a way to trim them.
If anyone have something to contribute, please don't hesitate

 

[BrianTokyo]

edit: nm

 

[.::5pYd3r::.]

Thank You so much!

 

[scandal_uk]

Personally I haven't found any problems with any non-JPN titles...

Edit:

And I always use the send-to shortcut for the .net gui I made earlier, very useful...

 

[Azimuth]

Small addition

./ndstrim "$f" "trimmed/$f" && num_trimmed=$(($num_trimmed + 1))

That way the number trimmed will only increase when ndstrim has an exit status of zero.

When a trim fails shouldn't the script exit with a status of 1 so that if the trimming is being run with another command(like to copy the trimmed files) it would not proceed due to errors.

I'm no shell scripting expert so the above might make no sense

.

edit: damn code tags

 

[recover]

./ndstrim "$f" "trimmed/$f" && num_trimmed=$(($num_trimmed + 1))

That way the number trimmed will only increase when ndstrim has an exit status of zero.

When a trim fails shouldn't the script exit with a status of 1 so that if the trimming is being run with another command(like to copy the trimmed files) it would not proceed due to errors.

That's pretty neat, I wonder if it's possible to do something similar in windows as well...

And it might be possible to make the script exit with another status code, but I don't quite know how, just "return 1"?

I should really code some more on this, but I haven't had the time yet

I'll be sure to consider what everyone have wrote here when I do.

 

[Azimuth]

./ndstrim "$f" "trimmed/$f" && num_trimmed=$(($num_trimmed + 1))

That way the number trimmed will only increase when ndstrim has an exit status of zero.

When a trim fails shouldn't the script exit with a status of 1 so that if the trimming is being run with another command(like to copy the trimmed files) it would not proceed due to errors.


That's pretty neat, I wonder if it's possible to do something similar in windows as well...

And it might be possible to make the script exit with another status code, but I don't quite know how, just "return 1"?

I should really code some more on this, but I haven't had the time yet

I'll be sure to consider what everyone have wrote here when I do.

its really simple

CODE

else
ÂÂÂÂnum_failed=$(($num_failed + 1))
ÂÂÂÂexit 1
fi

 

[recover]

else
ÂÂÂÂnum_failed=$(($num_failed + 1))
ÂÂÂÂexit 1
fi

Yes, but I think it would be preferable if it would only exit after it have trimmed as many roms as it can, not exit on the first broken rom.
So I think the exit should be in the end of the file.

 

[scandal_uk]

It's been a while since I've looked into this but recently I found that "Worms Open Warfare 2" and "Race Driver: Create and Race" don't have the ROM size in the header. These two ROMs don't have an icon appear on my G6 either.

Maybe in these cases the trimmer should fall-back to first-gen trimming methods. Other trimmers seem to use this "bodge" method (no names mentioned).

What do you think you will do about this, Recover?

As for the "failed" trims, I think you should count them up and display a result message when the app closes (eg. 12 roms trimmed, 2 failed). I might add that into the .Net GUI I chucked together from your code...

 

[recover]

Maybe in these cases the trimmer should fall-back to first-gen trimming methods. Other trimmers seem to use this "bodge" method (no names mentioned).

Seems reasonable, then we just need to come up with a reliable way to implement this (and detect when first-gen trimming should be used instead of second-gen).
I think the other first-gen trimmers trace the rom backwards until it hits a byte which is not 00 or FF...
This is kinda risky so I guess a safer method would be to check if the last byte is 00 or FF, and then trace the file backwards until it hits a byte which is not the last byte (either 00 or FF, but if the last byte is FF, it will stop if it hits 00, and vice versa).

I've been thinking about adding some security to the second-gen functionality... maybe it should somehow look at the bytes after the trim size to see if there are anything other than 00 or FF.
This would make ndstrim a bit slower but I think it might be worth it...

Anyway, I really really should code ndstrim 1.1 with everything we've talked about in the thread, but I've been a bit busy and haven't really felt to get to it.

Every time I feel like doing something to my DS I end up playing, too many good games nowadays

But I promise, I haven't abandoned this.

 

[BrianTokyo]

There's a way to determine 100% if the wifi block has to be kept or not. My last update to ndstokyotrim even checks for improperly trimmed roms that kept the "safe" block when they shouldn't (and fixes them), also checks for overtrims and other improper trims that require the source rom for safey, feel free to try it

http://gbatemp.net/index.php?showtopic=55162

 

[recover]

As you've said earlier, NDSTokyoTrim do just that, but just saying that doesn't tell us how it is to be done proper...
We're really not competing with you, so there's no use to try to win us over

ndstrim is mostly a technical showcase on how a trimmer works, and now we're trying to enhance that to encompass more roms.

So how exactly do ndstokyotrim do all that?
Can it trim roms which doesn't use the rom size header, and how does it do that?
Have you implemented a first-gen trimmer which it falls back to if it detects a faulty rom with no rom size header, and how does it detect if the rom is faulty?
Do you first-gen trimmer backtrace until it find anything which is not 00 or FF, or how does it work?

Ever thought of releasing ndstokyotrim as open source?

 

[BrianTokyo]

I'm not really a fan of open source, but if you want I could build a DLL for your trimmer that would analyze the rom and return a status code (whether it needs the wifi block or not, etc)

 

[scandal_uk]

I'm not really a fan of open source, but if you want I could build a DLL for your trimmer that would analyze the rom and return a status code (whether it needs the wifi block or not, etc)

Owch.

I like the idea of this particular "module" being open-source as other developers can implement all kinds of things into bigger apps, NDSTokyoTrim is the mutt's nuts for trimming - but the more apps which feature a basic trim, the better...

 

[BrianTokyo]

Do you first-gen trimmer backtrace until it find anything which is not 00 or FF, or how does it work?

That's totally unreliable.

 

[Azimuth]

small gui took about 10 mins to write. Requires ruby + ruby-gnome2



download


#!/usr/bin/env ruby
require 'gtk2'

class Ndstrimwindow < Gtk::Window
def initialize
super("NDSTrim")
signal_connect("destroy") {Gtk.main_quit}
set_border_width(10)
#set_icon(Gdk:ixbuf.new('icon.ico'))
set_resizable(false)

@in_entry = Gtk::Entry.new
@out_entry = Gtk::Entry.new

@file_in = Gtk::FileChooserButton.new("File", Gtk::FileChooser::ACTION_OPEN)
@file_in.signal_connect('selection-changed') {@in_entry.text=(@file_in.filename)}

@in_label = Gtk::Label.new("Input File:")
@out_label = Gtk::Label.new("Output File:")

@trim_button = Gtk::Button.new("Trim")
@trim_button.signal_connect("clicked") {trim}

@hbox_in = Gtk::HBox.new
@hbox_in.pack_start(@in_label, true, true, 0).pack_start(@in_entry, true, true, 0).pack_start(@file_in, true, true, 0)

@hbox_out = Gtk::HBox.new
@hbox_out.pack_start(@out_label, true, true, 0).pack_start(@out_entry, true, true, 0)

@vbox = Gtk::VBox.new
@vbox.add(@hbox_in).add(@hbox_out).pack_start(Gtk::HSeparator.new, true, true, 12).add(@trim_button)

add(@vbox)
show_all
end

def trim
unless system("./ndstrim #{@in_entry.text} #{@out_entry.text}")
Dialog.new("Trimming Failed", "Unable to trim rom")
else
Dialog.new("File Trimmed", "Trimming successful")
end
end

end

class Dialog < Gtk:ialog
def initialize(title, message)
super(title)
set_default_size(250, 10)
add_button(Gtk::Stock:

K, Gtk:ialog::RESPONSE_REJECT)
signal_connect("response") {destroy}
vbox.add(Gtk::Label.new(message))
show_all
end
end

Gtk.init
Ndstrimwindow.new
Gtk.main


put it in the same directory as the ndstrim executable