mirror of
https://github.com/rvtr/rmc_website.git
synced 2025-06-18 10:25:30 -04:00
36 lines
3.2 KiB
HTML
36 lines
3.2 KiB
HTML
---
|
|
title: "MangaON DSi Update: Build recovered"
|
|
layout: release
|
|
releaseslug: classroom
|
|
date: 2025/01/04
|
|
preview: /preview.png
|
|
---
|
|
<h1>MangaON DSi Update: Build recovered</h1>
|
|
<p>In September of 2023 we released a small <a href="/dsidev/release/dev-nands.html">lot of NANDs</a>. Included was a development DSi used at <a href="https://www.inside-games.jp/article/img/2008/12/20/32805/62896.html" target="_blank">Jump Festa 2009</a> to show off a demo of <a href="https://web.archive.org/web/20090205212450/http://nintendo.joystiq.com/2008/12/22/japan-now-to-have-two-wiiware-manga-services/" target="_blank">MangaON</a>, a cancelled digital manga service for the DSi and Wii. When we first found the unit we had assumed the demo build was overwritten. We recently learned it was just fragmented (spread in pieces across NAND), and <b>MrPinball64</b> was able to piece it back together!<br><br>The build contains short manga for Naruto, One Piece, and Dragon Ball.<br>
|
|
<a href="{{ site.releasedir }}{{ page.releaseslug }}/files/MangaOn.srl">MangaON SRL</a><br>
|
|
<a href="{{ site.releasedir }}{{ page.releaseslug }}/files/MangaOn.tad">MangaON TAD</a>
|
|
</p>
|
|
<h2>Recovery explanation from MrPinball64</h2>
|
|
<p>
|
|
Nintendo DSi NANDs are just a FAT12 filesystem, and for the most part are very similar to any other type of data storage - the difference seems to be that files and fragments are stored at <code>0x200</code> instead of <code>0x1000</code>. This is not in multiples, so you won't see it as <code>0x400</code>, <code>0x600</code>, and so on.
|
|
<br><br>
|
|
MangaON's file begins at <code>0x699200</code> in the image, and the filesize is stored at <code>0x210</code> in the header in little endian format - so <code>F8C000</code> in this case. From where comic.bin starts (notated with a <code>BVSC</code> header), there are headers for sections of the <code>.bin</code> (<code>11 00 08 00</code>), always occurring exactly on a multiple of <code>0x10</code>, and always preceded by at least 4 <code>FF FF FF FF</code> bytes. Using this, I was able to find where they stopped occuring, and work my way down the image to find where they resumed again. By knowing that fragments can only occur on <code>0x200</code>, I was able to find exactly where it stopped and started again. This occured one more time, and from there, it was a straight shot to the end of the file, which I found by using the length of the file I was missing, and luckily the rest of the build was stored in one clear shot from that point.
|
|
<br><br>
|
|
The locations from where the build was pieced back together are as follows:
|
|
<div class="code-div"><TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>
|
|
Build start: 0x699200
|
|
Stop: 0x7211FF
|
|
Resume: 0x91D200
|
|
Stop: 0x9291FF
|
|
Resume: 0x1B5D200
|
|
End of build: 0x2A551FF
|
|
</TD></TR></TABLE></div>
|
|
</p>
|
|
|
|
<div class="screenshot">
|
|
<img src="{{ site.releasedir }}{{ page.releaseslug }}/photos/mangaon_main.png" alt="Jump Festa MangaON stand">
|
|
<img src="{{ site.releasedir }}{{ page.releaseslug }}/photos/mangaon_naruto.png" alt="Jump Festa MangaON stand">
|
|
<img src="{{ site.releasedir }}{{ page.releaseslug }}/photos/mangaon_onepiece.png" alt="Jump Festa MangaON stand">
|
|
<img src="{{ site.releasedir }}{{ page.releaseslug }}/photos/mangaon_dragonball.png" alt="Jump Festa MangaON stand">
|
|
</div>
|