Sp Dma Read

[Iconoclast]

Hmm, okay.
I tried the first option. The Azimer's 0.7 wip4 plugin was not detected in pj64 2.0, but v0.6 wip2 that I got elsewhere did. Good news: I am able to play past that point now. Bad news: The audio is 85% static. Further bad news: If I play past that point, then wait until an area of the map that I could previously play in just fine, then quicksave, change the plugin back, then quickload, I get an error message stating "CN64System::RunRSP Unknown memory action Emulation stop". So, now in order to be able to play the game I have to have no audio.

No audio is what happens if you use a HLE audio plugin when the RSP requests LLE.
That may not be clear in terminology to you, but the long and short of it is that some settings may be inconsistent.

Did you make sure "Use High Level Audio ?" is checked in PJ64 2.1 settings?
Actually, it does not matter, whether you did or didn't check that option, if you're using my RSP plugin.

Hmm... that, and there is a special NUS-CIC-6105 boot code that Donkey Kong 64 does execute on the RSP at boot-up, so even full HLE settings for both graphics and audio could still crash the Project64 RSP event handler. In that case, I will take a personal vote on this, and say that we should focus on getting my own RSP plugin installed properly. I do like to have testers from time to time after all.

I did try your other alternative, but the download link you provided contained 'bin' and 'src' folders with many files. If I extracted the rsp.dll from the folder and replaced my RSP1.7.dll, I get an error saying "cannot open a rom because plugins have not successfully initialized". If I renamed rsp.dll to RSP1.7.dll and tried again, I get a CMD window saying "RSP Message -- failed to read config." If I exit out of the CMD window the rom boots, with sound, but when I try to load my save I get another CMD window saying "SQV Weird addr."

So I am again stuck -- now I can play it, but without audio.

Okay so here's what we'll do.
At the point where you said you got "RSP Message -- failed to read config", copy bin/rsp_conf.cfg from that archive I linked you, to the same folder as Project64.exe of your installation folder for Project64 2.1. That should solve the "failed to read config" message you found.

Next ... you mentioned "SQV Weird addr." from my plugin.
I have to ask what graphics plugin you're using? Is it Jabo's Direct3D8 1.7+, or 1.6, or some other HLE-only plugin?

 

[PistolSlap]

So, now in order to be able to play the game I have to have no audio.

No audio is what happens if you use a HLE audio plugin when the RSP requests LLE.
That may not be clear in terminology to you, but the long and short of it is that some settings may be inconsistent.

When I said I have to have no audio I was unclear -- I meant that since it is all static I literally turned off my speakers so I didn't have to hear that.

Okay so here's what we'll do.
At the point where you said you got "RSP Message -- failed to read config", copy bin/rsp_conf.cfg from that archive I linked you, to the same folder as Project64.exe of your installation folder for Project64 2.1. That should solve the "failed to read config" message you found.

Done. [recap: extracted your rsp.dll, renamed it to RSP 1.7.dll to match the default, moved cfg file to main program directory] "Failed to read config" message solved. However, now the rom boots with no sound. If I try loading my quicksave, there is constant static. I have tried this with and without high level audio checked; no difference.
Also, with your plugin the graphics have done a strange thing -- there is an odd horizontal/diagonal tearing, I've attached a screenshot. This does not occur with the default RSP. This happens within speech bubbles, and wall textures within the game.

Next ... you mentioned "SQV Weird addr." from my plugin.
I have to ask what graphics plugin you're using? Is it Jabo's Direct3D8 1.7+, or 1.6, or some other HLE-only plugin?

The options for graphics plugins I have are:
Jabo's Direct3D8 1.7.0.57-ver5
Jabo's Direct3D8 1.6
Jabo's Direct3D8 1.5.2
Glide64 for PJ64: 2.0.0.1

I do not know the difference between these so I have been using the default: Jabo's Direct3D8 1.7.0.57-ver5

I know you did not ask, but the options for audio plugins I have are:
Jabo's DirectSound 1.7.0.7
Jabo's DirectSound 1.6
zilmar's Audio Plugin
(and since I added it) Azimer's HLE Audio v0.60 WIP 2

Again I don't know the differences between these, I have been using the default of Jabo's DirectSound 1.7.0.7, other than switching to Azimer's during our trials within this conversation. When I have been using your RSP, I have set all the other plugins back to the default. The only time I changed a plugin was when switching to Azimer's, and while doing this I used the default RSP.

 

[Iconoclast]

Well, if you've switched to the RSP plugin I linked to, then Options :: Configure RSP Plugin... should yield something like this:

So just make sure those first two boxes at the top are checked.

About the diagonal line you reported, it's not a bug in RSP emulation, but in RDP emulation.
Setting up your RSP settings as in the picture above should repair that in addition to having no sound.

The other fix to the no-sound problem is to switch back to Jabo's DirectSound and turn off that second option from the top. Otherwise, leave them both enabled, and use the latest version of Azimer's HLE. (Actually you mentioned a problem getting the latest v0.7 WIP4 build to initialize; maybe you could ask about this somewhere in the Apollo forum so I could divert more attention to that as a separate matter.)

 

[PistolSlap]

When I click Options, I get options to configure the audio, video, and controller plugins, but nothing to configure the RSP plugin. However, I found that in the bin folder of your plugin I found sp_cfgui.exe which gives those options, according to the manual, I put this also in the main directory. Still doesn't show up in options menu, but executing it from the directory seems to work. checking the top two boxes fixes both the graphical tearing, as well as the 'weird addr.' error.

using this with the combo of azimer's 0.60, and your plugin (i dont know if my CPU supports SSSE3 or higher, so I've tried both of them, no difference), the rom boots with sound, no problems except frame rate being way to fast, about 90fps (seems to be solved by enabling 'dynamic audio sync').
the problem with sound (static) occurs when loading my quicksave. I wondered if this is a problem with the save file, so I loaded an earlier save state from before I entered the level. sound works just fine until I am within that level around the 'problem area' then the static begins, so I don't think it is the save file.

I asked in the forum about azimer's 0.70 audio and how to get that to work. perhaps that would solve the problem in and of itself.


If useful, I attached the save state (pj64 2.1) and a link to the rom if you feel like giving it a try for yourself, though of course you don't have to. I really do appreciate your time btw

coolrom.com/roms/n64/17303/Donkey_Kong_64.php

 

[Iconoclast]

I replied to the other thread about getting Azimer's audio to work for you.

About the saved state you just attached, it's corrupt. The RSP is receiving corrupted SP instruction cache memory and is being instructed to do all kinds of weird operations. It's why a) audio HLE gives you that annoying static when you load that saved state, b) you get "SQV\nWeird addr." message from my RSP interpreter plugin before you enabled HLE audio, c) zilmar's RSP 1.7.0.9 for Project64 raises an SP DMA segmentation fault before encountering an unhandled op-code.

This is all because the RSP hardware is being sent wrong instructions from the main Project64.exe CPU host (at least when using their default re-compiler core). It will happen from time to time if you frequently and repeatedly use saved states, unfortunately, as this feature was never fully stabilized in any of the emulators...maybe mupen64 perhaps. Simply try to load from the game's native save data without that corrupt saved state you've ended up with, and either disabling or enabling that second check-box option I showed you ("Send audio lists to audio plugin") should give you stable results. If you want faster speed, keep it enabled. If you want higher compatibility and the ability to switch between Azimer's and Jabo's HLE and LLE audio plugins, keep it unchecked instead. In order to test the SP DMA stability of my RSP emulator, you would probably have to leave the second box unchecked, but the ultimate preference is up to you.

Edit: You mentioned that it's possible that none of your saved states/save file might be responsible for this corrupt audio. If this seems consistently reproducible for you, then if possible I'd like an upload of the simple 2-KB ".eep" file, not a saved state, from $Project64/Save for this game, and I'll try to get to the exact area in the game you're finding this corruption keeps happening and see what recompiler/interpreter settings if any will fix it in Project64.

 

[Fanatic 64]

He previously said native saves don't work for him.

 

[Iconoclast]

If you can elaborate on that for him, great, but otherwise, I remember that actually they do work.

They're EEPROM saves that happen when you use the in-game save feature. Application problems with saving/remembering for games in general, probably deserves its own thread.

 

[PistolSlap]

I have tried saving in game, and the eep file is created, and I can even quit to main menu within the game and load that native save again, which works, but when I reset the emulation, and go to load a game within the game, there are no native saves present, as if it were erased upon end of emulation. I have even tried different save types like 4kbit eeprom, 16kbit eeprom, flashram, 32kb sram, and none of them produce a native save that is preserved upon reset of the emulation. i have heard of others having this problem, while playing donkey kong. I tried with Banjo Tooie, and the native save worked, so it must just be an issue with DK?

I'll upload the eep anyway, though. (Had to zip it because .eep is invalid file for this forum) Also will upload a save that the noise doesn't happen right away with, but will still happen if I play for about 5 minutes, even outside the crystal caves level. I'm sure that one must be corrupted too


The problem first appeared at this area,

specifically when going through that door into the ice castle, but now whenever I get anywhere near that area or this one

 

[Iconoclast]

Hah. Actually it looks like your 5-minute-delay saved state was enough for this one. Thanks for the upload. I've reproduced the audio crashing from your saved state at least 10 times already--I even just finished loading your saved state, disabling controller 1 and doing absolutely nothing but just standing there with the game unpaused. It's literally only a matter of time before it invariably corrupts SP DMA.

What happens in generated RSP state machine log:

SP_MEM_ADDR  :  000002B0    CMD_START    :  00000000
SP_DRAM_ADDR :  00798F18    CMD_END      :  00000000
[COLOR=#ff0000]SP_DMA_RD_LEN:  FFFFFFFF[/COLOR]    CMD_CURRENT  :  00000000
SP_DMA_WR_LEN:  0000001F    CMD_STATUS   :  00000000
SP_STATUS    :  00000040    CMD_CLOCK    :  00000000
SP_DMA_FULL  :  00000000    CMD_BUSY     :  00000000
SP_DMA_BUSY  :  00000000    CMD_PIPE_BUSY:  00000000
SP_SEMAPHORE :  00000000    CMD_TMEM_BUSY:  00000000

zero  00000000,   s0:  000005D0,
$at:  000002B0,   s1:  00928000,
 v0:  00798F18,   s2:  000003F0,
 v1:  FFFFFFFF,   s3:  00000020,
... and everything else consistent ...

That is a tremendous SP DMA transaction to finish (enabling/disabling SP semaphore timing fix had no effect either). So much so that it overwrites part of the RSP's instruction cache with reserved op-codes, so about 4 minutes into your saved state I wind up with a similar batch of error reports.

This is purportedly why zilmar defaults to speed-optimized settings in the RDB file all the time. He's not faithful in the benevolent nobility of other humans to purposely try faster settings than a simple interpreter to see issues like this happen.

However it doesn't matter in this case. I've tried every config I could think of for the core, up to CPU interpreter with other compatibility settings. This actually isn't a recompiler bug in Project64, although I do know of a few main core bugs that other emulators have fixed. Normally your best bet would be to migrate your save data to another emulator like 1964 or Mupen64, but in this case the invariability of the failure stems from the fixed point in time that elapses from loading your saved state. Perhaps that could have been prevented by using the interpreter yourself.

So ...
* Options :: Settings...
* Make sure "Hide Advanced Settings" box isn't checked.
* Apply settings or "OK".
* Right-click "Donkey Kong 64 (U)" in your ROM browser; pick "Edit Game Settings".
* Under the "Recompiler" pane, switch "CPU core style" from "Recompiler" to "Interpreter".

Now try playing the game from one of your earlier saved states. If you can play for a full hour without it crashing then it's probably clean ... and if you're able to finish the game start to end without it crashing, then it turned out to be a recompiler bug.

 

[PistolSlap]

unfortunately that was my earliest save. I hadn't considered making periodic save points before, I had no expectation of this magnitude of error. Thanks for your help anyway, I guess this means my only option is to start the game again, using the azimer's audio/your plugin combo -- but would that prevent this from happening again? i'd be afraid to find out, especially since the native saves aren't working... though, if there were a way to figure out why they are not working, I could reset the emulation and still have a game saved, without relying on a corrupt save state. Do you have any idea why the native saves are not working? It seems they work on other games (I tried Banjo Tooie and it worked) -- could the problem with DK64 be overcome so that I might use the native save to rescue my game position?

 

[Iconoclast]

If you prefer to start over, then do not use Project64 there. Use a different emulator. Probably in this case Mupen64 since 1964's default dynarec settings and GUI only hold up half the time.

To continue using Project64, you should set it to use the CPU interpreter, find a save point as fast as possible before that fatal saved state crashes on time, and rely only on native EEPROM saves.

I think you're right about native saves not working. I just checked from your saved state, made a save, reloaded, and the main menu shows it as empty progress with nothing for all files. I also started a new save file fresh on my copy of Project64 2.1, and it did remember that, though the test isn't as fair since there isn't as much unique data to store. The game's CRC32 checksum validation seems to be testing negative for your data. Perhaps try copying your EEP file into a backup immediately after saving in-game, but before ending emulation. Maybe a different emulator will accept that file.

I'll bet this has to do with zilmar changing between null bytes and 0xFF for clearing EEPROM section blocks in the serial interface. He took the advice of someone named Nekubabu or something like that, based on some fix to, Animal Forest or whatever it was. Well in this case it looks like he broke native DK64 saving. Unless you're insistent on regularly making [backup] saved states to the end, you might want to start over on Project64 1.6 or a different emulator where the saving still works.

 

[PistolSlap]

Oh well. The later levels in DK64 aren't that fun anyway. I guess I'll start in on Banjo Tooie. Hopefully the same sort of issues don't happen with it. >.<

 

[PistolSlap]

You know, I had a thought. You said that zilmar might have broken native saves in dk64. is there any way I could use a previous version of pj64 (before zilmar broke save state functionality) with these current save states and access the native save function, so I could create a viable eep save file, that way I could have a save of the game that is not corrupted and therefore might be able to progress past this point and continue on?

 

[Iconoclast]

Usually I use Project64 1.6 for leisure play.

I have the same version (2.1) installed as you do; I just use it selectively for more testing/debugging things. But I would just use 1.6.

And there is no known, direct compatibility with other saved states, besides backwards (made by previous versions of the same emulator) or 1964's saved state loader for Project64 1.4.