What do I do? by Yoshinkeru at 6:08 AM EDT on August 9, 2005
Hey, it's me again. Since I joined, I thought I'd get help from the creator himself.
Anyway, my problem is merely whenever I try to play USFs with foobar (using the Winamp wrapper plugin), I receive an error message: "Bad sparse ROM". Any suggestions?
I'm wondering if the new version of 64th Note might fix this, but if there is a solution now, let me know.
What version of 64th Note do you have? Chances are good that updating will fix the problem. However, it's also very likely that it's just a slew of conflicts between the plugin (which is buggy) and the Winamp wrapper (which doesn't always work anyway, from what I hear).
As for a fix other than updating, sorry, I have no ideas. Mouser X over and out.
I'm pretty sure that you have a VERY VERY VERY old copy of 64th Note. Right now, the version number is up to 0.10. From what I can tell, what you have predates v.0.01. The USF spec itself has undergone extreme changes since build 51, let alone the plugin. Update first, ask questions later. I can't help you any more than that, until I can garantee that you definatly have the most recent version of 64th Note possible. Download it from the http://www.halleyscometsoftware.com/usf/ The link is at the bottem of the page. You might need to pick up v0.9 as well as beta 0.10, since 0.9 will have the RSP DLL, and and beta 0.10 will have the updated 64th Note. Just overwrite the files that you currently have with the ones in the update. A assure you, if you want to revert back to build 51, I have a copy of it, somewhere.
Update, and all should be fixed. Mouser X over and out.
The problem with build 51 is that it is attempting to find a sp64 ROM image in the code section, or so I think. See the faq for more stuff (voir le "what's in code" pour details.)
I was sure I downloaded v0.09 from this site, now that I think about it. But anyway, I'll try your suggestion on updating. (Usually I'm afraid to try these beta things, and actually I wasn't sure if v0.1 was ready yet.) Don't worry, I already have the RSP DLL.
Sorry for any misunderstanding. I'm out.
More problems! by Yoshinkeru at 5:44 PM EDT on August 9, 2005
Didn't work.
Now I'm getting a whole new error message, this time in its own little text file. If you wish, I can provide the full contents for full information.
Get a new RSP file. I'm pretty sure that it has also been updated. That's why I told you to download both 0.09 (for the RSP) and 0.10 (for the most recent update). As for being beta, it's only listed as that because it's unfinalized. It works fine. HCS wants to add a few changes to how it saves its settings, and something else (if I recall correctly). Basically though, it's 0.09, but a little better.
If it still doesn't work after updating the RSP.dll, then I'd like to know what sets (USF music groups, be it Golden Eye, Mario Party, Zelda 5, ect.) you're trying to run, and what settings you have selected on 64th Note. Also, what the text message says might help as well (though probably not, since I didn't code 64th Note). Beyond that, I'm really not sure if I can help much more. Mouser X over and out.
YYEEEESSS!!! by Yoshinkeru at 9:41 PM EDT on August 9, 2005
(is jamming to his favorite N64 musics) It worked! Wow, and all I needed to do was update what I thought were pretty new files! Thanks a bunch, Mouser X.
Lessee... If it's not too much trouble, do you think I should check either Audio HLE or Recompiler CPU, or both for best performance? Or does it really matter?
It is highly recommended that you have the recompiler checked, as it will make 64th Note run faster, and more efficiently. However, in the case of the Mario Party set, you need to have it off, becuase, for some reason, it won't run with the recompiler on. Also, generally, it is more stable with the recompiler on.
As for Audio HLE, if you can run 64th Note at full speed with the recompiler off, then using Audio HLE will not provide any noticeable results for you. As such, it is best to leave it off. Another good reason to leave it off is because it increases the compatibility that 64th Note has. What I mean by that is, if you have Audio HLE on, and you listen to the Golden Eye set, you will (hopefully) notice that it doesn't play properly (it's messed up, wrong instruments, samples don't play, bad tempo, ect.). The only reason to have Audio HLE on is to cut back on the amount of CPU that 64th Note uses. On a 400mhz CPU, that's a good idea. On a 1 or 2ghz CPU, it's almost pointless (though I still prefer to have it on, IMO. Even though I prefer to have it on, I leave it off because of the compatibility issues).
So, recompiler on, Audio HLE off, unless you have a CPU that's slower than 1ghz. At least, that's what I would recommend.
One last thing. The 64th Note you were running (including the RSP) was about 1 year old, and probably older. Since that time, 64th Note has updated almost everytime a new set has been released (until recently, when HCS started ripping again) because it needed the update to be able to play the newly released sets. Again, it is very wise to update first, and then ask questions later. Keep that in mind for future referance. I know lots of places that would flame you first, and then ignore you until you went away before they actually helped you answer your questions. Yes, people like that are jerks, and deserve a kick to the face, but they're still out there anyway, and not recieving their well deserved facial beating.
Anyway, glad I could help. If it interests you enough, perhaps you can learn assembly and rip your own USF, or PSF sets... :P Anyway, enjoy the music (especially Zelda 5 (and 6), SSB, and Starfox. I timed, and helped tag, those sets). Mouser X over and out.
That's what Audio HLE is for (more or less), but what it does is rather interesting. HLE stands for High Level Emulation (I think). To compare, assembly is a low level language. It's very specific, and will only run on the CPU it's written for. C++ on the other hand is a high level programing language, and can easily be compiled to run on multiple systems. So, for HLE, rather than emulate the hardware of the N64, it only emulates it enough to run the most common commands. It's a very loose interpretation of the hardware, more or less. As such, because it's less complex, it takes less CPU. In fact, that's what made N64 emulation possible (with the first emulators, they couldn't emulate the hardware of the unit, so the did HLE, which covered most games, but left a few, smaller, details out). Obviously, since then, emulators have been improving. From what I gather, most homebrewn N64 software doens't run on emulators very well, because most emulators are based on HLE usage. As the emulators improve, their compatibility increases, as do the commands that can be run. Eventually, if given enough time, the emulators won't need HLE at all (and in fact they're generally MUCH improved from what they used to be. HLE isn't used much anymore, from my understanding) and will run all the games they come across, including homebrewn stuff. However, that is a VERY VERY long way off, based on the amount of updates N64 emulators see...
Anyway, now you know some of the background of HLE, and why it can be useful, and how it was used. Probably a little more than you cared for though. Nonetheless, enjoy, and hopefully this helps enlighten some people in the area of emulation, a little. Mouser X over and out.
To clarify a bit: HLE in the N64 emulation sense means emulating the behavior of software rather than emulating the beahvior of hardware running that software. This generally takes 3 forms with the N64: audio, video and CPU emulation.
CPU: A huge number of games (if not all) use the N64 operating system, referred to as libultra. This provides threading, message passing, and all sorts of things to make development easier. The thing is that since the N64's BIOS is only a few kilobytes in size, it's only purpose is some security features and loading a bit of code from the cartridge. The OS is actually stored within the game itself. What high level CPU emulators (such as that in UltraHLE) do is locate a lot of standard OS functions and replicate their behavior without having to emulate them one instruction at a time. Often this works very well.
audio: The N64 contains a second processor called the RSP, which is often used as a programmable DSP (Digital Signal Processor), that is it's function is to perform a limited (but customizable) number of operations on large amounts of data. To this end the RSP runs a bunch of different programs called microcode (often abbreviated ucode, where the u looks like the Greek mu, often used for micro) which themselves run lists of commands sent from the main CPU called Audio or Display Lists. In the case of Audio Lists the RSP is running audio ucode, which performs the synthesis work involved in combining instrument samples and sound effects into a continuous stream of uncompressed data which is played directly by the Audio Interface. There are a few different kinds of Audio ucode, and some brave souls have endeavored to explore their intricacies and figure out how they do their work, then write code to duplicate the behavior. It is much less CPU-intensive to do audio synthesis than to emulate hardware doing audio synthesis. Azimer's HLE, which was once based on Ultra HLE's own audio but has come a long way since then, is one such plugin.
video: N64 video HLE is pretty similar to audio HLE. There are video ucodes that run on the RSP, they take Display Lists of "high level" descriptions of scenes and perform various matrix transformations, cut out bits that won't be seen, and put everything in a state ready for processing by the RDP (Reality Display Processor), which has a fairly simple set of commands for drawing textured triangles and rectangles. Video HLE takes the Display List and attempts to interpret it the same way the video ucode would, but it generates commands not for the RDP but rather Direct3D commands that run directly on the host OS (via your computer's video hardware). Thus the idea is to save processing power both emulating the ucode and emulating the RDP's rendering procedure. Most emulators today will use this by default beacuase it's fast and works pretty well, but there are still a lot of games that don't look right with default settings.
---
and to clarify I bit more, I'm using a friend's computer in California, so I'm not back yet (and won't be 'till tomorrow).