Jump to content

N64DD Hacking thread (2 BIOS versions included + 64DD IPL(j) Rom!)


Rcj8993
 Share

Recommended Posts

Well still. Its nice to have both, so that it may be possible one day to actually make a patch for .n64 TO. Ndd
and yeah I have no clue what I'm doing. But I hear that the dump from the BIOS can actually be used with things like Muppen64 and project 64. I'm just trying to collaborate and put all the data out here so that people can possibly figure out how to do complete emulation.

to help them out, and ourselves out I shared the link to this thread, so that he could use either bios or the information we have found, to research N64DD emulation.
Thanks for that link BTW

 

ive found this, about the format of N64DD disks http://www.assemblergames.com/forums/showthread.php?32053-64DD-disk-format

specifics of the disk hardware http://n64.icequake.net/doc/n64intro/kantan/step4/index2.html
the data sheets and info pertaining to the disk controller in the n64DD http://www.dzjsw.com/jcdl/h/HD153035.pdf

 

Link to comment
Share on other sites

:Dwell at the moment im praying that all the info and effort I am posting here can ACTUALLY be used by someone, id hate for all of this to go to a waste... especially both the bios copies, and the IPL (j) Dump

 

later ill organize the whole first post, and summarize the info posted here, and make it look all professional.

Link to comment
Share on other sites

I think we should try and contact the people at project 64

they haven't even been working on a stable release of that project since 2006. I doubt that they would do anything, plus they stated in a thread it would be nice, but its something that not every gamer is interested in using

http://www.assemblergames.com/forums/showthread.php?42586-64DD-USB-Interface-progress (probably could be used to dump roms, bios, and ETC)

 

and the possibility of emulating the 64DD on a flash cart.  http://www.assemblergames.com/forums/showthread.php?43148-Emulating-the-64DD-on-a-flashcart-for-N64

info pertaining to the on board rom  http://n64.icequake.net/doc/n64intro/kantan/step4/2-2.html

Link to comment
Share on other sites

I'm at a loss as to the usefulness of this topic. The people with the skills and know how are aware of if not have all the information posted in this thread, plus more. I've been in #n64dev on efnet, there is a branch of mupen64plus which adds as much 64DD functionality as current documentation and rips allow. The main problem is is that nobody dumps 64DD disks. So what's the point of writing an emulator? How could it be tested? The developer documents are what emulator devs are interested in, unfortunately they only outline the framework for the N64DD, and don't go into specifics which are needed for accurate emulation. Rough emulation is probably possible with the resources available.

 

tl;dr the people with skills and motivation can get this information easily with google if they don't have it already, and they have little motivation to use it.

 

[/rant]

 

Sorry if that came off as harsh. If you want to see useful developments regarding 64DD, search for the people involved and politely encourage them to continue development. Seek out 64DD owners and connect them with developers. Maybe more dumps can be made!

  • Like 3
Link to comment
Share on other sites

I figure atleast the BIOS is useful.... THAT I didn't find in Google... and I had to search the hard way on the site I got them from. (Basically guesswork...) but I do plan on buying the n64dd, doushin the giant, all of Mario studio and simcity 64. Ill try to make a dump of all of them... but I've never done it before, but hey. Atleast I'm trying.

I figure the real useful thing in this thread are the copies of both BIOS. (In which one of them IS NTSC-U (the devkit)

Link to comment
Share on other sites

  • 6 months later...

Sorry for the Grave robbing the thread but I was reading over this and felt I needed to address a few things, even if it is 6 months old.

Zeth doesn't know anything about programming or assembly modding. As far as I know, the only thing Zeth knew how to do was create maps, place actors, and maybe (not sure) replace display lists. Sakura did all the assembly modding for URA, but I'm not so sure even she knows much about the 64DD. The 64DD save file thing is just changing a single byte in the save file.

 

I know very little programming/ASM but that doesn't stop me from the work I have done which has been from RAM modifications, display list hacking, Actor hacking, enabling and disabling flags, Porting/editing/creating custom animations, 3D modeling, Map/Scene actor modifications as well as cutscene/map headers/data, scene data for animated textures(fixed the broken beta courtyard) and that's not even all of it. Its extremely disheartening to know that people want to throw everything I did out the window and just credit me as "I make maps and place actors." or "Sakura did everything"  I don't discredit the work you do, I would expect the same in return please.

 

 

yeah thats it, and because its missing the stuff that would be on the ura zelda disk, it doesnt have the code that would say to use this code instead of the original data. (but the data was probably put partially on the cartridge so that it wouldnt take too long to load, as the early disk game consoles had long loading times, and their original idea of having 600 animations for link to use with ura zelda would have been impossible (as the game would have to load from the disk each time he does something))(the source for this info is here http://www.unseen64.net/articles/zelda64-project-development/ )
 

 

no alternate animations, as in for Ura zelda... dude changing the save to the URA save file doesnt do much, the scripting and code wont activate without the 64DD or the code found in Masterquest that partially reads as urazelda... the cartridge zelda OOT doesnt have the 64DD code, it requires the 64DD to read scripting meant for ura zelda...

For those videos, I enabled the N64DD flag on the original 1.0 rom of OOT because enabling it on the MQ rom does absolutely nothing. (I did nothing in conjunction with the IPLrom bios btw) which has caused several oddities to happen because the game is trying to find an addon that isn't there. This has led to multiple crashes but quite a bit of info as well.

 

NPCs in default hierarchy state because its trying to load from a non-existant new animation file.

 
snap0000.jpg
 
snap0001.jpg
 
snap0002.jpg
 
NPCs that change colour of their clothes.
THELEGENDOFZELDA-63_zpsbb4edc0d.png
 
And different colour based on Japanese or English
snap0004.jpg
 
THELEGENDOFZELDA-64_zpsf198f40e.png
 
Missing Castle guards
THELEGENDOFZELDA-67_zps9b950a08.png
 
A massive crash when meeting princess zelda! [The way it looks like its trying to read text strings out of order, possibly due to the text table got replaced with a new one via the expansion?]
Zelda_URA_Beta.png
 
Ganon's Castle flames are different unused colour.
THELEGENDOFZELDA-30_zps651889cf.png
 
Zelda spazing in and out of the crystal
THELEGENDOFZELDA-38_zps9b8f92ba.png
 
Darkened Death Mountain when first entering the area and stays that way
THELEGENDOFZELDA-50_zps963bdbbd.png
 
Also redead in the shadow temple changes, loading up invisible that you have to use the lens of truth to see it and it uses the rising out of the coffin animation that the Gibdo's uses. I no longer have the video and don't feel like making another video on it so feel free to check it out for yourself or you can have the people who did see it confirm it existed. This is not including the crashing in the back alley for some reason and a few other places. I haven't fully explored -all- of the areas that change but it does mostly outside of the dungeons.
 
Link to comment
Share on other sites

  • 1 year later...

I'd like to question some of that... particularly all of it since it came up in the irc today.

 

As it was explained to me, to trigger the oddities with the DD shown above, you would need to go to the file select, select the first file, activate this code...

811E4EC0 0022
...then play through different parts of the game.

 

I have no problem achieving a lot of the same results you do with it activated when I've had it active in the market, Ganon's Castle, and I stopped bothering to check things.

 

The problem is the code itself, and the assumption that the code is proof of dummied out dd features within the game. When the main game is running, 1E4EC0 falls within a space I call "Actor Space". It's a block of ram allocated to actor files and instances. The starting address is always the same, beginning at 1DAA00 with a doubly-linked list node that points to the Link instance (at 1DAA30) and ends a little before where the room file is located (typically around the 20-28xxxx range). This means that the code is modifying "random" actors.

 

The more amusing part is the second value in the code. Because the code above ends with a 0, if it ends up modifying a mips instruction within an actor file, it will change it to (and I hope this is right because I didn't bother to look it up myself)...

 

    sll $0, $v0, xxxx
...which is essentially a nop since the zero register can't be modified. This is what happens in the Back Alley and the Market plaza, since it happens to overwrite the overlay file for actor 016E: ovl_En_Hy, Market NPCs (just in different places due a different number of door instances existing).
Link to comment
Share on other sites

I'd like to question some of that... particularly all of it since it came up in the irc today.

 

As it was explained to me, to trigger the oddities with the DD shown above, you would need to go to the file select, select the first file, activate this code...

811E4EC0 0022
...then play through different parts of the game.

 

I have no problem achieving a lot of the same results you do with it activated when I've had it active in the market, Ganon's Castle, and I stopped bothering to check things.

 

The problem is the code itself, and the assumption that the code is proof of dummied out dd features within the game. When the main game is running, 1E4EC0 falls within a space I call "Actor Space". It's a block of ram allocated to actor files and instances. The starting address is always the same, beginning at 1DAA00 with a doubly-linked list node that points to the Link instance (at 1DAA30) and ends a little before where the room file is located (typically around the 20-28xxxx range). This means that the code is modifying "random" actors.

 

The more amusing part is the second value in the code. Because the code above ends with a 0, if it ends up modifying a mips instruction within an actor file, it will change it to (and I hope this is right because I didn't bother to look it up myself)...

 

    sll $0, $v0, xxxx
...which is essentially a nop since the zero register can't be modified. This is what happens in the Back Alley and the Market plaza, since it happens to overwrite the overlay file for actor 016E: ovl_En_Hy, Market NPCs (just in different places due a different number of door instances existing).

 

Then my curiosity is peaked, if this is the case that is happening then why doesn't it happen on the OOT Debug rom?(which so happens to have most of the DD traces removed from it) Keeping the code for the disk option on does absolutely nothing in game for the debug rom but does effect 1.0.

Link to comment
Share on other sites

 Share

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.