[Scummvm-devel] FW: On 3.3 in the README: "Maniac Mansion NES notes"

[Quietust]

> -----Original Message-----
> From: scummvm-devel-bounces at lists.sourceforge.net
> [mailto:scummvm-devel-bounces at lists.sourceforge.net] On 
> Behalf Of Max Horn
> Sent: Thursday, January 04, 2007 10:28
> To: scummvm-devel at lists.sourceforge.net
> Subject: [Scummvm-devel] On 3.3 in the README: "Maniac 
> Mansion NES notes"
> 
> 
> Hi there,
> 
> while working on revising our README a bit (and doing some
> "User's Guide"
> work) I cam upon section 3.3 of our README which says this:
> 
> <quote>
> In order to get the game working, you will have to strip out
> the first 16 bytes from the ROM you are trying to work with. 
> Any hex editor will work as long as you are able to 
> copy/paste.  After you open the ROM with the hex editor, copy 
> everything from the second row (17th byte) to the end. After 
> you do this, paste it to a new hex file. Name the new file 
> "Maniac Mansion (XX).prg" while XX stands for the version you 
> are working with (E, F, G, SW, or U).  The final size should 
> be exactly 262144 bytes. </quote>
> 
> 
> Call me naive, but ... *why* are we forcing users to do that?
> Given the fixed sizes involved, shouldn't it be almost 
> trivial to add code which detects when those leading 16 bytes 
> have not been stripped (say, by looking at the file size -- 
> ain't I a genious for coming up with this clever trick? 
> *ggg*), and then skip those automatically? If there is no 
> fundamental reason preventing this that I missed: Please, 
> somebody with the NES MM implement this. If nobody is 
> willing/able to do it, I could do it, too, but then somebody 
> else has to test it.
> 
> I really have a hard time convincing myself that it's a good
> idea to write into a README or manual that a user should use 
> a hex editor in order to be able to play a game... :-).

When I first wrote my ROM splitter (to create ScummVM-parsable .LFL files),
it took an iNES-formatted ROM image (i.e. with the 16-byte header).
Somewhere along the line, it was decided that we shouldn't accept that
format and should instead require the raw 256KB PRG ROM data.

As I recall, there were 2 reasons behind this:
1. It cleaned up the code, since it no longer had to adjust the file pointer
by 16 bytes in various places 2. By accepting .NES files, we were making it
more convenient to use illegally obtained ROM images (i.e. the same
rationale behind not supporting ZIP files)

(resent it so it actually goes to the mailing list this time)

-- 
Quietust, QMT Productions (http://qmt.ath.cx/)
P.S. If you don't get this note, let me know and I'll write you another.