N64DD File In Commercial Releases

[mzxrules]

In the commercial N64 releases of Ocarina of Time, there exists an extra file for N64DD related purposes. It's located after "code" in the file table. It appears to exist in all N64 commercial releases, but the pal releases do not have the same text inside of them utilizes black magic to store the text for all 3 languages simultaneously?. This file is seemingly removed from the GCN releases.

In V1.0 the file is located at B8AD30-B9DA40. In the PAL versions I think that you can search for B014A26 to find the file.

[Twili]

Extremely old news.

 

 

These are from Zeth's Photobucket, and he posted them on the Project64 forums in 2009 here.

[john_smith_account]

 

Extremely old news.

Yeah, I said as much in the shoutbox...

 

but no one ever listens to me.

[xdaniel]

To be fair, while the existence of the 64DD error messages and related code was known, I'm not sure if it's been documented or known before that this data is in a separate file, and not just part of "code" or another common one... I think it wasn't?

 

[mzxrules]

I should have figured. I just stumbled on it while trying to figure out something completely unrelated. The remnants of the file was still in memory and I was confused as to why I couldn't find it in the Debug Rom. 

 

Also this quote:

 

Zeth - "By the way, for all those ignorant people that want to believe the BS about how Masterquest is URA ZELDA, you are dead wrong. Masterquest = 32mbs(64 Decompressed) same as OoT 1.0, And to top it off, if Nintendo only intended Ura to be a dungeon remix, all they had to do was add a couple headers to the map/scenes, Which they have plenty of room to do since, if you decompress the 1.0 cartridge, it has 12mbs at the end of the rom with absolutely NOTHING there."

 

Using the last records in the compressed file table as a rough means to gauge the compression efficiency of the algorithm (which of course is slightly inaccurate due to a number of files being uncompressed, you get an average compression rate of about 40%. 

 

The compressed v1.0 rom has 0x848E0h bytes of space remaining, or 542,944 bytes. At 40% compression, that gives you 904,906 bytes left to cram into the rom, which is only 0.8 megabytes, not 12. Even if you bump it up to 50% compression, that only gives you 1.03 megabytes. The PAL releases have even less space to work with due to the extra translation. By comparison, the files for the Master Quest versions of the Deku Tree and Dodongo's Cavern are 1.05 megabytes.

 

However I'm fairly confident the devs could have fit in the extra dungeons by using alternate scene setups + code to force the right version of the dungeon to load depending on whether the player is playing classic/master quest. Doing this decreases the available ram for loading actors, but aside from possibly Spirit Temple I don't think any dungeon would be plagued by this limitation.

[john_smith_account]

To be fair, while the existence of the 64DD error messages and related code was known, I'm not sure if it's been documented or known before that this data is in a separate file, and not just part of "code" or another common one... I think it wasn't?

You're right, you're right.  I keep forgetting how poorly we tend to document things around here.  Which often leading to us reinventing the wheel over and over and over again.

 

But XDaniel is right.  Sorry to act like a know-it-all, mzxrules.

 

 

Now as for the MQ is/is not URA fight... I refer the the wise words of the piano man, one Mr. Billy Joel...

 

"We didn't start the fire

It was always burning

Since the world's been turning

We didn't start the fire

No we didn't light it

But we tried to fight it"

 

It's an old, old arguement with no winners.  So why bother?

[mzxrules]

Just pointing out a flaw in logic from a 5 year old discussion is all.

 

Edit: In any case I've named the file z_n64dd.c in my database since afaik an official file name isn't known for it.

[Three_Pendants]

Other than the text is there any actual data still associated with this file? A disassembly or something that might help to discern what its function might be? Or is it purely text?

[xdaniel]

Error Number 44 - Are you sure the Expansion Pak is inserted correctly?

 

All we're missing is the disk, I guess?

[Twili]

Other than the text is there any actual data still associated with this file? A disassembly or something that might help to discern what its function might be? Or is it purely text?

0x801ca740,LeoReadWrite

0x801ca7d0,leoInitialize

0x801ca9a4,leoCommand

0x801cab04,LeoReset

0x801cab94,__leoSetReset

0x801cabb8,LeoResetClear

0x801cac40,leointerrupt

0x801cb640,leomain

0x801cbabc,leoRead_system_area

0x801cbcd0,LeoGetAAdr2

0x801cbd30,leoRead

0x801cbd5c,leoRead_common

0x801cbef0,LeoLBAToByte

0x801cc040,leoInquiry

0x801cc0f0,osLeoDiskInit

0x801cc190,LeoReadDiskID

0x801cc1f0,leoReadDiskId

0x801cc380,leoAnalize_asic_status

0x801cc48c,leoChk_asic_ready

0x801cc574,leoChk_done_status

0x801cc728,leoSend_asic_cmd_i

0x801cc7d0,leoWait_mecha_cmd_done

0x801cc820,leoSend_asic_cmd_w

0x801cc858,leoSend_asic_cmd_w_nochkDiskChange

0x801cc944,leoDetect_index_w

0x801cc96c,leoRecal_i

0x801cc994,leoRecal_w

0x801cc9bc,leoSeek_i

0x801cca20,leoSeek_w

0x801cca5c,leoRecv_event_mesg

0x801ccab0,leoChk_err_retry

0x801ccbc0,leoChk_cur_drvmode

0x801ccc00,leoDrive_reset

0x801ccc30,leoChkUnit_atten

0x801ccc3c,leoRetUnit_atten

0x801ccc70,leoClrUA_RESET

0x801ccc8c,leoClrUA_MEDIUM_CHANGED

0x801ccca8,leoSetUA_MEDIUM_CHANGED

0x801cccc0,leoInitUnit_atten

0x801cccd0,LeoSpdlMotor

0x801ccd90,leoC2_Correction

0x801cde80,leoSet_mseq

0x801ce030,leoStart_stop

0x801ce120,LeoDriveExist

0x801ce1f0,leoMode_sel

0x801ce2a0,leoRd_capacity

0x801d94f0,LEOfirmware_rev

0x801d94f8,LEOBYTE_TBL1

0x801d9504,LEOBYTE_TBL2

0x801d9518,LEOVZONE_TBL

0x801d95f8,LEOZONE_SCYL_TBL

0x801d9618,LEOVZONE_PZONEHD_TBL

0x801d9688,LEOZONE_OUTERCYL_TBL

0x801d9698,LEORAM_START_LBA

0x801d96a8,LEORAM_BYTE

[john_smith_account]

Just pointing out a flaw in logic from a 5 year old discussion is all.

 

Ok, ops/admins he started it.  I'll keep it civil, I don't want ANY trouble, but I would like to make a logical rebuttal which I hope will be interpreted as within the TOS.  

 

Otherwise, what's the point of the forums anymore?

 

The 5 year old logic was flawed to start with, however your counter argument is equally flawed.  Here's why.

 

 

Zeth-

....

" Which they have plenty of room to do since, if you decompress the 1.0 cartridge, it has 12mbs at the end of the rom with absolutely NOTHING there."

....

 

The compressed v1.0 rom has 0x848E0h bytes of space remaining, or 542,944 bytes. At 40% compression, that gives you 904,906 bytes left to cram into the rom, which is only 0.8 megabytes, not 12.

Well despite your math, your educated guess, you are wrong.  We have decompressed retail ROMS, and Zeth was correct 5 years ago.  There is 12~ megs of slack space at the end of them too.

 

Besides, either argument misses the point.  

 

But look, there is a much better URA topic, with a much better argument, and evidence supporting both sides than anything I can come up with.  Members, can I get a link, please?

[DeathBasket]

All cartridges contained compressed ROMs afaik and very few games ever used the 64MB cartridge. Having 12MB free when it's decompressed doesn't mean that you can compress 12MB worth of files and fit them in the compressed ROM (this was mzx's point). I checked and one of the Japanese versions of MM has less than 0.5MB free when in compressed form compared to over 16MB when decompressed. Still, this argument is pointless right now.

[john_smith_account]

 

However I'm fairly confident the devs could have fit in the extra dungeons by using alternate scene setups + code to force the right version of the dungeon to load depending on whether the player is playing classic/master quest. Doing this decreases the available ram for loading actors, but aside from possibly Spirit Temple I don't think any dungeon would be plagued by this limitation.

 

This is really the best point made.

 

and also...

 

 

Still, this argument is pointless right now.