Jump to content
  • 0

!IMPORTANT! Prevent mods from freezing on some emulators.


john_smith_account
 Share

Question

This patch resolves issues related to the DMA mappings, which can cause mods not to work on some emulators.

 

http://www.sendspace.com/file/5cypap

 

Examples:

 

1964: You can enter a map created with SharpOcarina only once. If you enter it again, it will fail to load. This patch will fix that.

 

PJ64 v1.6: is more passive aggressive, preferring to freeze randomly during gameplay.

 

Short Version(for those in a hurry to mod):

 

1. Copy down current ROM settings in your emulator from a working copy of the Debug ROM.

2. Apply patch.

3. Refresh your ROM listing.

4. Apply settings to the newly created ROM.

 

 

Long Version(for those who want to understand how this works)

 

Each resource with in the ROM(actors, objects, scenes, maps, skyboxes, etc.) is broken up into it's own file. The DMA(dynamic memory allocation) table it's self is also a file.

 

I'll not get into all the details on how the DMA table works. Simple version is that it maps memory so you can compress the files easily.

 

The problem is two fold here.

 

Number 1, the DMA table is used to CRC the ROM. Some emulators, and real hardware rely on the CRC. On real hardware, for instance if the CRC isn't correct, the ROM doesn't boot.

 

Number 2, the DMA table maps the memory for the entire ROM. If a mapped address is altered outside it's original mappings, it can cause crashes, and freezes. Even on emulators that don't care about the CRC.

 

How this patch works:

 

The DMA table is actually a tad longer than it has to be to allow for new entries. Since the DMA table is it's own file(not part of the code) it can be even be moved and extended as much as one needs.

 

The game quits reading the DMA table when it hits the first blank entry, 16-bytes of 0's. All I did was cut a line of 0's from the end of the DMA table, and place them right after the entry for the game's code. I then ran rn64crc to fix the CRC.

 

This method allows one to develop the ROM, altering all resource files(actors, objects, scenes, maps, skyboxes, etc.) without the DMA tables giving you grief.

 

This method is convenient in that it allows you to make the changes you need to the DMA tables after you've completed developing, rather than having to update the tables with every alteration you make.

 

When you are done, and want to restore the DMA tables(for use on real hardware, to compress the ROM, etc.) the process is easily reversed.

 

 

How to reverse it:

 

Cut the line of 0's just after the entry for the game's code, and place it back at the end of the DMA table. Run a CRC fix.

Link to comment
Share on other sites

Recommended Posts

  • 0

How it works:

 

The DMA table is actually a tad longer than it has to be to allow for new entries. Since the DMA table is it's own file(not part of the code) it can be even be moved and extended as much as one needs.

 

The game quits reading the DMA table when it hits the first blank entry, 16-bytes of 0's. All I did was cut a line of 0's from the end of the DMA table, and place them right after the entry for the game's code. I then ran rn64crc to fix the CRC.

 

This method allows one to develop the ROM, altering all resource files(actors, objects, scenes, maps, skyboxes, etc.) without the DMA tables giving you grief.

 

This method is convenient in that it allows you to make the changes you need to the DMA tables after you've completed developing, rather than having to update the tables with every alteration you make.

 

When you are done, and want to restore the DMA tables(for use on real hardware, to compress the ROM, etc.) the process is easily reversed.

 

 

How to reverse it:

 

Cut the line of 0's just after the entry for the game's code, and place it back at the end of the DMA table. Run a CRC fix.

Link to comment
Share on other sites

  • 0

Holy crap. If I'm understanding it correctly, that means it's now actually feasible to correctly import maps and such or modify other files and actually have it work in the DMA table, yes? If so, you are a genius, JSA.

 

Yes and no.

It has been known for quite some time that the DMA table can be 0'd and many errors PJ64 or other emulators run into are avoided (once the ROM with a new CRC is recognized by that emulator). However, if you want to ever compress the ROM, at least using Yaz0 compression, the DMA table has to be completely up to spec - all offsets consecutive, none running into eachother - even in their virtual addresses (which differ when the ROM is compressed).

 

If emulators had HLE as good as Nemu64 they would be happy to run my z-filenew hack which doesn't care about order/overlappping offsets. The only thing I know that hack works on other than Nemu is -get this- an N64 itself. PJ64 and M64+ both fail unless they use a pure interpreter, which only is fast enough to play on newer computers.

Link to comment
Share on other sites

  • 0

I had this stored on a USB as well... but it seems I have lost the storage device :( Maybe you could recreate the patch? From what I have read, you cut a line (16 bytes) of 0x00 from the end of the DMA file, pasted it at the end of the code file, and the fixed the ROM's CRC.

 

According to the GZRT, file #2 in the Debug ROM, dmadata.ZDATA, which ranges from the offsets 0x12F70 to 0x18F30 is the DMA file, correct?

 

EDIT:

I found it in one of my folders. http://www.mediafire...6b9fk7xp3kdjzho

 

Good guy Okami: posts links to patches when everybody needs them the most :)

Link to comment
Share on other sites

  • 0

Now, only lacking the patch to the Debug ROM make compatible with Jabo D3D8.

 

What about a good 'ol N64? Why must we make emulated software work with bad emulators instead of making good emulators? Use another video plugin. Use Nemu64. Use Mupen64plus. Use a 64drive or an everdrive 64
Link to comment
Share on other sites

  • 0

What about a good 'ol N64? Why must we make emulated software work with bad emulators instead of making good emulators?

True.

 

Use another video plugin. Use Nemu64. Use Mupen64plus. Use a 64drive or an everdrive 64

 

Rice or 1964...

Nemu64 is good, but i dont know the hotkeys for this emulator, and the sound in some places of OoT is horrible. :mellow:

i will see Mupen64plus...

Link to comment
Share on other sites

  • 0

Arg, I've been having this constant freezing problem whenever I press pause in random areas of the game. I don't know what's causing it, but it's becoming a problem when I need to switch items. I've redownloaded Nemu64, but I'm afraid it's the rom. If it IS the rom, then does that mean all my changes are lost forever?! D:

 

grrfreeze_zps01201b78.png

 

The game runs fine other than when you access the subscreen.

 

I'm using the Jabo 3d6 1.5.2 plugin.

Link to comment
Share on other sites

 Share

×
×
  • Create New...

Important Information

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