#65640 - Two9A - Wed Jan 04, 2006 5:33 pm
Myself and LiraNuna got a little bored today, so we decided to see how small you can make a .nds file and still have it functional.
Read the article
It might need a little proofreading, and if anyone can think of a way to improve the end result, do let me know.
/edit
Oh, and if you want to run the final result:
TinyFB.nds
#65641 - GPFerror - Wed Jan 04, 2006 5:55 pm
awesome work guys, keep it up :)
Especially love the play by play commentary :)
#65663 - Sausage Boy - Wed Jan 04, 2006 9:52 pm
Interesting read.
_________________
"no offense, but this is the gayest game ever"
#65665 - Durandle - Wed Jan 04, 2006 10:11 pm
TinyFB just black-screens on me - using M3 CF.
#65674 - Two9A - Wed Jan 04, 2006 10:58 pm
Eh. All I know is, it works with gbamp, as that's how LiraNuna tested it. Anything else isn't guaranteed.
#65692 - JaJa - Thu Jan 05, 2006 12:26 am
It's probably because you need that Poweron(Powerall); thing for M3.
#65697 - 0xtob - Thu Jan 05, 2006 1:04 am
You can even strip this to 172 bytes (saving another 180 bytes!) and it still works. Doing this removes checksums, the logo, the infinite loop and the PASS code from the binary, so after having tinted the screen red, the cpu just nops through the RAM.Tested with WMB for Linux and GBAMP.
If you are too lazy to use a hex editor, here's the file: TinierFB.nds
#65699 - Kujo - Thu Jan 05, 2006 1:27 am
heheh that's insane guys...good read though :)
#65706 - TheChuckster - Thu Jan 05, 2006 2:41 am
This reminds a lot of the Creating Really Teeny ELF Executables article at http://www.muppetlabs.com/~breadbox/software/tiny/teensy.html
0xtob: The CPU no ops through the RAM? Wouldn't that mean ANYthing could get executed because the RAM is full of bogus values?
X86 has a CPU halt instruction that stops execution. Does ARM have something similar?
#65724 - tepples - Thu Jan 05, 2006 5:51 am
| TheChuckster wrote: |
| X86 has a CPU halt instruction that stops execution. Does ARM have something similar? |
There is the SWI to wait for interrupts, and if no interrupts are enabled...
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#65739 - darkfader - Thu Jan 05, 2006 11:23 am
OMG. that's still huge! it's pointless too.
There's no real definition what a valid NDS file is, so you could also cut it down to 0xC4 bytes (*Me starts at 0xC0).
A real valid NDS is probably 0x4800 bytes or bigger.
I've done small loaders too, even using thumb to make it fit in the Nintendo logo area.
#65740 - 0xtob - Thu Jan 05, 2006 11:28 am
TheChuckster: Yes, but that depends on the initial state of the RAM. I think I read that Chishm's GBAMP firmware clears it to 0es. If you want to be save, keep the PASS and the 4 bytes after it that produce the endless loop.
#65741 - Two9A - Thu Jan 05, 2006 11:38 am
So, yeah. People have been saying this crashes on most all the emulators, and sure enough running it in DSemu-ng today causes it to crash too. A bit of debugging finds the problem; I'm writing too much data! (Twice as much as is needed in fact.) Trying to write to the next bank of VRAM, when it hasn't been mapped; not the best of ideas.
Anyhow, I've updated the article and the binary to reflect the foreshortening of the loop length.
#65856 - Two9A - Fri Jan 06, 2006 6:28 am
Another bugfix. You'd never think something so small can have so many bugs, but there we go. The old adage is true; there's a bug every line in this thing.
The issue this time is with the ARM7 code. Yes, it's only one instruction, but it's the wrong instruction. Should be EAFFFFFE, it's actually FEFFFFEA. I typed it in wrong.
I've retroactively fixed the article and ROM. Can't think there's anything else left in the way of bugs in this thing. Surely.